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

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

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

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

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

Переадресация на базе сервера

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

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

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

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

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

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

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

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

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

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

Переадресация на основе клиента

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

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

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

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

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

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

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

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

S: RCPT TO:<[email protected]>
R: 251 User not local; will forward to <[email protected]>

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

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

`~/.forward` файлы

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

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

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

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

См. также

Цепочка писем
Электронный список рассылки
Псевдоним электронной почты
Письмо по электронной почте
Сокращения тем электронной почты
Спам по электронной почте
Почтовый пользовательский агент (MUA), также известный как почтовый клиент.
Агент передачи сообщений (MTA)
Электронный шторм
Схема перезаписи отправителя

Примечания

^ Jump up to: ^а ^б В разделе 3.9.2 Список RFC 5321 термин пересылка используется неоднозначно. В нем отмечается, что « ключевое различие между обработкой псевдонимов (раздел 3.9.1) и пересылкой (данный подраздел) заключается в изменении заголовка [ Return-Path ] ». Эту формулировку, новую по отношению к RFC 2821, можно было бы интерпретировать как определение пересылки , если бы тот же термин не использовался в начале того же подраздела с противоположным значением. Как согласился участник RFC 5321, Тони Финч (3 ноября 2008 г.). «Английские термины для пересылаемых адресов» . IETF . Архивировано из оригинала 11 декабря 2008 г. Проверено 7 ноября 2008 г. [ пересылка — это] расплывчатый (нетехнический) термин в SMTP.
^ Основная запись MX соответствующего домена обычно публикует имя почтового сервера . В противном случае доменное имя должно иметь IP-адрес .
^ Конверт транзакции сообщения — это данные, передаваемые в SMTP перед передачей содержимого сообщения. Конверт теряется при доставке сообщения, хотя некоторые его поля могут быть сохранены принимающим сервером в заголовках сообщения. В частности, конверт содержит путь возврата (он же адрес возврата , MAIL FROM аргумент , mailfrom или mfrom ) и одного или нескольких получателей (включая Bcc ).
^ Дэйв Крокер (июль 2009 г.). «Медиаторы» . Архитектура почты Интернета . IETF . сек. 5. дои : 10.17487/RFC5598 . РФК 5598 . Проверено 19 марта 2013 г. Посредник пересылает сообщение посредством процесса повторной публикации. Медиатор разделяет некоторые функциональные возможности с базовой ретрансляцией MTA, но обладает большей гибкостью как в адресации, так и в контенте, чем доступна MTA.
^ Джон Левин (15 октября 2008 г.). «Пользователи не любят пересылаемый спам» . ID круга . Проверено 7 ноября 2008 г.
^ RFC 2142, «Имена почтовых ящиков для общих служб, ролей и функций» , 1997 г., также упоминает маркетинг , поддержку , злоупотребления , безопасность , веб-мастеров и многое другое.
^ «Как пересылка электронной почты влияет на результат аутентификации?» . ПроДМАРК . 6 января 2023 г. Проверено 16 марта 2023 г.
^ Jump up to: ^а ^б ^с Рассмотрим следующий путь вперед:
${\ce {\mathit {A->B->C}}}$
Домен B не должен напрямую пересылать сообщение из домена A в домен C , если только он не контролирует политику A фильтрацию C. или Действительно, если A публикует политику SPF, которая запрещает B использовать A имя , а C применяет проверку политики отправителя, C может отклонить сообщение в соответствии с RFC 7208. Другими словами, невозможно формально отличить простую пересылку сообщений от незаконной. злоупотребление доменным именем.
^ См. примечание в разделе 6.2.7 «Явная спецификация пути» RFC 822.
^ Запись MX была введена в RFC 974. См. исторический раздел в записи MX#История перехода к A .
^ При простой пересылке сообщения может быть раскрыт конечный адрес назначения независимо от намерения пользователя. См. разделы 7.7 «Раскрытие информации при пересылке сообщений» и 4.4 «Отслеживание информации» в RFC 5321.
^ Франк Мартин; Элиот Лир; Тим Дреген; Элизабет Цвики; Курт Андерсен, ред. (сентябрь 2016 г.). «Псевдоним» . Проблемы совместимости между проверкой подлинности сообщений, отчетностью и соответствием на основе домена (DMARC) и косвенными потоками электронной почты . IETF . сек. 3.2.1. дои : 10.17487/RFC7960 . РФК 7960 . Проверено 14 марта 2017 г.
^ Хант, Крейг (2002). Администрирование сети TCP/IP . О'Рейли. п. 606. ИСБН 0-596-00334-Х . Электрический ток ^[update] (версия 8.708 от 2006 г.) в документации sendmail не упоминаются ограничения на использование -f switch и использует глагол set , а не override для описания своего действия над данными отправителя конверта.
^ Даты книги в client-server-faq. ^{[ постоянная мертвая ссылка ]} Диапазон с начала 1990-х годов. Хотя удаленные вызовы процедур возникли в 1970-х годах, они не получили широкого распространения до тех пор, пока сети не стали достаточно распространенными.

[forwarding-1] Jump up to: ^а ^б В разделе 3.9.2 Список RFC 5321 термин пересылка используется неоднозначно. В нем отмечается, что « ключевое различие между обработкой псевдонимов (раздел 3.9.1) и пересылкой (данный подраздел) заключается в изменении заголовка [ Return-Path ] ». Эту формулировку, новую по отношению к RFC 2821, можно было бы интерпретировать как определение пересылки , если бы тот же термин не использовался в начале того же подраздела с противоположным значением. Как согласился участник RFC 5321, Тони Финч (3 ноября 2008 г.). «Английские термины для пересылаемых адресов» . IETF . Архивировано из оригинала 11 декабря 2008 г. Проверено 7 ноября 2008 г. [ пересылка — это] расплывчатый (нетехнический) термин в SMTP.

[2] Основная запись MX соответствующего домена обычно публикует имя почтового сервера . В противном случае доменное имя должно иметь IP-адрес .

[3] Конверт транзакции сообщения — это данные, передаваемые в SMTP перед передачей содержимого сообщения. Конверт теряется при доставке сообщения, хотя некоторые его поля могут быть сохранены принимающим сервером в заголовках сообщения. В частности, конверт содержит путь возврата (он же адрес возврата , MAIL FROM аргумент , mailfrom или mfrom ) и одного или нескольких получателей (включая Bcc ).

[4] Дэйв Крокер (июль 2009 г.). «Медиаторы» . Архитектура почты Интернета . IETF . сек. 5. дои : 10.17487/RFC5598 . РФК 5598 . Проверено 19 марта 2013 г. Посредник пересылает сообщение посредством процесса повторной публикации. Медиатор разделяет некоторые функциональные возможности с базовой ретрансляцией MTA, но обладает большей гибкостью как в адресации, так и в контенте, чем доступна MTA.

[5] Джон Левин (15 октября 2008 г.). «Пользователи не любят пересылаемый спам» . ID круга . Проверено 7 ноября 2008 г.

[6] RFC 2142, «Имена почтовых ящиков для общих служб, ролей и функций» , 1997 г., также упоминает маркетинг , поддержку , злоупотребления , безопасность , веб-мастеров и многое другое.

[Email_Forwarding-7] «Как пересылка электронной почты влияет на результат аутентификации?» . ПроДМАРК . 6 января 2023 г. Проверено 16 марта 2023 г.

[forward_c_harmful-8] Jump up to: ^а ^б ^с Рассмотрим следующий путь вперед:
${\ce {\mathit {A->B->C}}}$
Домен B не должен напрямую пересылать сообщение из домена A в домен C , если только он не контролирует политику A фильтрацию C. или Действительно, если A публикует политику SPF, которая запрещает B использовать A имя , а C применяет проверку политики отправителя, C может отклонить сообщение в соответствии с RFC 7208. Другими словами, невозможно формально отличить простую пересылку сообщений от незаконной. злоупотребление доменным именем.

[9] См. примечание в разделе 6.2.7 «Явная спецификация пути» RFC 822.

[10] Запись MX была введена в RFC 974. См. исторический раздел в записи MX#История перехода к A .

[11] При простой пересылке сообщения может быть раскрыт конечный адрес назначения независимо от намерения пользователя. См. разделы 7.7 «Раскрытие информации при пересылке сообщений» и 4.4 «Отслеживание информации» в RFC 5321.

[12] Франк Мартин; Элиот Лир; Тим Дреген; Элизабет Цвики; Курт Андерсен, ред. (сентябрь 2016 г.). «Псевдоним» . Проблемы совместимости между проверкой подлинности сообщений, отчетностью и соответствием на основе домена (DMARC) и косвенными потоками электронной почты . IETF . сек. 3.2.1. дои : 10.17487/RFC7960 . РФК 7960 . Проверено 14 марта 2017 г.

[13] Хант, Крейг (2002). Администрирование сети TCP/IP . О'Рейли. п. 606. ИСБН 0-596-00334-Х . Электрический ток ^[update] (версия 8.708 от 2006 г.) в документации sendmail не упоминаются ограничения на использование -f switch и использует глагол set , а не override для описания своего действия над данными отправителя конверта.

[14] Даты книги в client-server-faq. ^{[ постоянная мертвая ссылка ]} Диапазон с начала 1990-х годов. Хотя удаленные вызовы процедур возникли в 1970-х годах, они не получили широкого распространения до тех пор, пока сети не стали достаточно распространенными.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]