WikiDer > Пересылка электронной почты

Email forwarding

Пересылка электронной почты в целом относится к операции повторной отправки сообщение электронной почты доставлен одному Адрес электронной почты на один или несколько разных адресов электронной почты.

Период, термин пересылкаиспользуется для почты задолго до электронных коммуникаций, не имеет особого технического значения,[1] но это означает, что электронное письмо было перемещено «вперед» в новое место назначения.

Пересылка электронной почты также может перенаправлять почту, идущую на определенный адрес, и отправлять ее на один или несколько других адресов. И наоборот, элементы электронной почты, отправляемые на несколько разных адресов, могут сойтись посредством пересылки и оказаться в одном почтовом ящике.[требуется разъяснение]

Пользователи электронной почты и администраторы почтовых систем используют один и тот же термин, говоря об обоих на базе сервера и клиентский пересылка.

Перенаправление на основе сервера

В доменное имя (часть справа от @ в Адрес электронной почты) определяет цель сервер (ы)[2]для соответствующего класса адресов. Домен также может определять серверы резервного копирования; у них нет почтовых ящиков и вперед сообщения, не меняя ни одной части конверта.[3] Напротив, первичные серверы может доставить сообщение пользователю почтовый ящик и / или вперед это путем изменения некоторых адресов конверта. ~ / .forward файлы (см. ниже) представляют собой типичный пример пересылки на сервере разным получателям.

Администраторы электронной почты иногда используют термин перенаправление как синоним серверной пересылки электронной почты разным получателям. Инженеры протокола иногда используют термин Посредник для ссылки на сервер пересылки.[4]

Потому что спам, становится все труднее надежно пересылать почту между разными доменами, и некоторые рекомендуют избегать этого, если это вообще возможно.[5]

Использование пересылки на сервере разным получателям

Ролевые адреса
Информация, продажи, почтмейстер, и похожие имена[6] может появиться слева от @ в адресах электронной почты. Организация может пересылать сообщения, предназначенные для данной роли, на адрес лиц, которые в настоящее время работают в этой роли или офисе.
Псевдонимы-адреса
Наиболее хостинг доменного имени средства предоставляют возможности для пересылки почты на другой адрес электронной почты, например, в почтовый ящик пользователя. Интернет-провайдер; есть также отдельные поставщики услуг пересылки почты. Это позволяет пользователям иметь адрес электронной почты, который не меняется при смене провайдера почтового ящика.
Множественные или неподдерживаемые адреса
Когда пользователи меняют свой адрес электронной почты или имеют несколько адресов, пользователь или администратор могут настроить переадресацию с этих адресов, если они еще действительны, на один текущий, чтобы избежать потери сообщений.

Пересылка или повторная отправка

Обычная пересылка сообщения изменяет получателей конверта и оставляет отправитель конверта поле нетронутым. Поле «отправитель конверта» не приравнивается к От заголовок которое обычно отображает программное обеспечение почтового клиента: оно представляет собой поле, используемое на ранних этапах SMTP протокол и впоследствии сохранен как Обратный путь заголовок. Это поле содержит адрес, на который почтовые системы должны отправлять сообщения возврата - сообщение об ошибке доставки (или успехе) - если есть.

Напротив, условия пересылка или перераспределение иногда может означать повторную отправку сообщения, а также переписывание поля «отправитель конверта». Электронные списки рассылки представим типичный пример. Авторы отправляют сообщения в отражатель который выполняет повторную отправку на каждый адрес списка. Сюда, сообщения возврата (которые сообщают о сбое доставки сообщения любому подписчику списка) не дойдут до автора сообщения. Однако досадно неправильно настроенный отпуск автоответы доходят до авторов.

Как правило, обычная пересылка сообщений расширяет псевдонимы, а правильная пересылка сообщений, также называемая пересылка tout-court[1] служит для списков рассылки. Когда в сообщение вносятся дополнительные изменения, чтобы оно больше походило на действие Почтовый пользовательский агент отправка нового сообщения, срок пересылка становится обманчивым, и повторная отправка кажется более подходящей.

в Структура политики отправителя (SPF), доменное имя в отправителе конверта остается под политическими ограничениями. Поэтому SPF обычно запрещает пересылку простых сообщений. Внутри домена перенаправление соответствует SPF, если соответствующие серверы используют согласованную конфигурацию. Почтовые серверы, которые практикуютмеждоменный пересылка сообщений может нарушить SPF, даже если они сами не реализуют SPF, т.е.они не применяют проверки SPF и не публикуют записи SPF.[7]Схема перезаписи отправителя обеспечивает универсальный механизм пересылки, совместимый с SPF.

Пересылка на основе клиента

Автоматическая переадресация на основе клиентов

Перенаправление клиентов может происходить автоматически с использованием неинтерактивного клиента, такого как агент по поиску почты. Хотя агент поиска использует клиентский протокол, эта пересылка напоминает перенаправление сервера в том, что он сохраняет ту же идентичность сообщения. Есть опасения по поводу отправителя конверта.[7]

Ручная переадресация на основе клиента

An конечный пользователь мочь вручную переслать сообщение, используя почтовый клиент. Пересылка в соответствии цитирует сообщение под основным текстом нового сообщения и обычно сохраняет исходные вложения, а также выбор выбранных заголовков (например, исходный От и Ответить на.) Получатель пересылаемого таким образом сообщения может все еще иметь возможность ответить на исходное сообщение; возможность сделать это зависит от наличия исходных заголовков и может означать ручное копирование и вставку соответствующих адресов назначения.

Пересылка как приложение готовит MIME вложение (типа сообщение / rfc822), который содержит полное исходное сообщение, включая все заголовки и никаких вложений. Обратите внимание, что включение всех заголовков раскрывает много информации о сообщении, такой как серверы, которые его передали, и любой клиентский тег, добавленный в почтовый ящик. Получатель переадресованного таким образом сообщения может открыть вложенное сообщение и без проблем ответить на него.

Такая пересылка фактически представляет собой пересылка с точки зрения отправителя конверта и получателя (ов). Идентификатор сообщения также изменяется.

Историческое развитие пересылки электронной почты

RFC 821, Простой протокол передачи почты, от Джонатан Б. Постел в 1982 г. прямой путь для каждого получателя, например, в виде @ USC-ISIE.ARPA, @ USC-ISIF.ARPA: [email protected] - необязательный список хостов и требуемый почтовый ящик назначения. Когда список хостов существовал, он служил исходным маршрутом, указывая, что каждый хост должен пересылать почту следующему хосту в списке. В противном случае, в случае недостаточной информации о назначении, но если сервер знал правильный пункт назначения, он мог взять на себя ответственность за доставку сообщения, ответив следующим образом: 

S: RCPT TO:  R: 251 Пользователь не локальный; перешлем на

Тогдашняя концепция предусматривала элементы прямой путь (исходный маршрут) переход к Обратный путь (отправитель конверта), когда сообщение было ретранслировано с одного SMTP-сервера на другой. Даже если система не одобряет использование маршрутизации от источника,[8]динамично строить Обратный путь подразумевает, что информация об отправителе конверта не может оставаться в исходной форме во время пересылки. Таким образом RFC 821 изначально не допускал простой пересылки сообщений.

Введение Запись MX[9] сделал маршрутизацию от источника ненужной. В 1989 г. RFC 1123 рекомендуется принимать исходную маршрутизацию только для обратной совместимости. В этот момент обычная пересылка сообщений[7] стало рекомендуемым действием для расширения псевдонима. В 2008, RFC 5321 все еще упоминает, что "системы может удалить обратный путь и перестроить [Это] по мере необходимости », учитывая, что невыполнение этого может непреднамеренно раскрыть конфиденциальную информацию.[10]Фактически, обычную пересылку сообщений можно удобно использовать для расширения псевдонимов в пределах одного сервера или набора координированных серверов.

~ / .forward файлы

Ссылка SMTP реализация в начале 1980-х годов была Отправить почту, который предусматривал ~ / .forward файлы, которые могут хранить целевые адреса электронной почты для данных пользователей. Такой вид пересылки на основе сервера иногда называют точка-пересылка.[11] Можно настроить какую-нибудь почтовую программу фильтры для автоматического выполнения действий по пересылке или ответу сразу после получения. Файлы пересылки также могут содержать сценарии оболочки, которые стали источником многих проблем с безопасностью. Раньше только доверенные пользователи могли использовать переключатель командной строки для настройки отправителя конверта, -f аргумент; некоторые системы отключили эту функцию по соображениям безопасности.[12]

Электронная почта предшествует формализации клиент – сервер архитектуры в 1990-е гг.[13]Следовательно, различие между клиент и сервер кажется обязательно вынужденным. Первоначальное различие противопоставлено демоны и управляемый пользователем программы которые работают на одной машине. Демон sendmail, используемый для работы с корень привилегии так что он мог выдавать себя за любого пользователя, чьей почтой ему приходилось управлять. С другой стороны, пользователи могут получить доступ к своим индивидуальным почтовым файлам и файлам конфигурации, включая ~ / .forward. Клиентские программы могут помогать в редактировании файлов конфигурации сервера данного пользователя, тем самым вызывая некоторую путаницу относительно того, какую роль играет каждая программа.

Виртуальные пользователи

Термин «виртуальные пользователи» относится к пользователям электронной почты, которые никогда не входят в систему почтового сервера и получают доступ к своим почтовым ящикам только с помощью удаленных клиентов. Программа почтового сервера может работать как для виртуальных, так и для обычных пользователей, или может потребоваться незначительная модификация, чтобы воспользоваться тем фактом, что виртуальные пользователи часто используют одну и ту же систему. мне бы. Последнее обстоятельство позволяет серверной программе более легко реализовать некоторые функции, поскольку она не обязана подчиняться ограничениям доступа к системе. Применяются те же принципы работы. Однако виртуальным пользователям сложнее получить доступ к своим файлам конфигурации, хорошо это или плохо.


Коммерческие продукты, облегчающие пересылку почты

Смотрите также

Заметки

  1. ^ а б В разделе 3.9.2 Список из RFC 5321, период, термин пересылка используется неоднозначно. Он отмечает, что "ключевое различие между обработкой псевдонимов (раздел 3.9.1) и пересылкой (этот подраздел) заключается в изменении параметра [Обратный путь заголовок]. "Эта формулировка, новый w.r.t. RFC 2821, можно интерпретировать как определение пересылка, если один и тот же термин не использовался в начале того же подраздела с противоположным значением. Как согласился участник RFC 5321, Тони Финч (2008-11-03). «Английские термины для переадресованных адресов». IETF. Архивировано из оригинал на 2008-12-11. Получено 2008-11-07. [пересылка является] нечетким (нетехническим) термином в SMTP
  2. ^ Главная Запись MX соответствующего домена обычно публикует имя почтовый сервер. В противном случае доменное имя должно иметь айпи адрес.
  3. ^ В конверт сообщения - это данные, передаваемые в SMTP транзакция перед передачей содержание сообщения. Конверт теряется при доставке сообщения, хотя некоторые из его полей могут быть сохранены принимающим сервером в заголовках сообщения. В частности, конверт содержит Обратный путь (a.k.a. адрес возврата, ПОЧТА ОТ аргумент почта, или м от) и один или несколько получатели (в том числе Скрытая копияs).
  4. ^ Дэйв Крокер (июль 2009 г.). «Посредники». Архитектура Интернет-почты. IETF. сек. 5. Дои:10.17487 / RFC5598. RFC 5598. Получено 19 марта 2013. Посредник пересылает сообщение через процесс повторной публикации. Посредник разделяет некоторые функции с базовой ретрансляцией MTA, но имеет большую гибкость как в адресации, так и в отношении контента, чем это доступно для MTA.
  5. ^ Джон Левин (2008-10-15). «Пользователи не любят пересылаемый спам». CircleID. Получено 2008-11-07.
  6. ^ RFC 2142, «Имена почтовых ящиков для общих служб, ролей и функций», 1997, упоминает также маркетинг, поддержка, злоупотребление, безопасность, веб-мастер, и больше.
  7. ^ а б c Рассмотрим следующий прямой путь:
    Домен B не должен напрямую пересылать сообщение из домена А в домен C, если он не контролирует политику А или фильтрация C. Действительно, если А публикует политику SPF, которая предотвращает B от использования А 'имя, и C применяет проверку политики отправителя, C может отклонить сообщение в соответствии с RFC 7208. Другими словами, нельзя формально отличить простую пересылку сообщений от незаконного злоупотребления доменным именем.
  8. ^ См. Примечание в разделе 6.2.7. Явная спецификация пути из RFC 822
  9. ^ Запись MX была введена с RFC 974. См. Исторический раздел в Запись MX # История отката к A.
  10. ^ Простая пересылка сообщения может раскрыть конечный адрес назначения независимо от намерения пользователя. См. Разделы 7.7 Раскрытие информации при пересылке сообщений, и 4.4 Информация о трассировке в RFC 5321.
  11. ^ Франк Мартин; Элиот Лир; Тим Дреген; Элизабет Цвикки; Курт Андерсен, ред. (Сентябрь 2016 г.). "Псевдоним". Проблемы взаимодействия между доменной аутентификацией сообщений, отчетностью и соответствием (DMARC) и косвенными потоками электронной почты. IETF. сек. 3.2.1. Дои:10.17487 / RFC7960. RFC 7960. Получено 14 марта 2017.
  12. ^ Хант, Крейг (2002). Сетевое администрирование TCP / IP. О'Рейли. п. 606. ISBN 0-596-00334-X.Электрический ток (версия 8.708 от 2006 г.) документация по sendmail не упоминает никаких ограничений в использовании -f переключатель и использует глагол набор скорее, чем отменять чтобы описать его действие с данными отправителя конверта.
  13. ^ Книга датируется клиент-сервер-часто задаваемые вопросы[постоянная мертвая ссылка] диапазон с начала 1990-х годов. Несмотря на то что вызовы удаленных процедур возникли в 1970-х годах, они не получили широкого распространения, пока сети не стали достаточно распространенными.