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

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

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

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

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

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

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

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

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

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

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

Ролевые адреса

info , sales , postmaster и подобные имена ^[6] могут появляться слева от @ в адресах электронной почты. Организация может пересылать сообщения, предназначенные для определенной роли, на адрес лица(лиц), в настоящее время работающего в этой роли или офисе.

Псевдоним-адреса

Большинство хостинговых услуг доменных имен предоставляют возможности пересылки почты на другой адрес электронной почты, например, на почтовый ящик интернет-провайдера пользователя ; существуют также отдельные поставщики услуг пересылки почты. Это позволяет пользователям иметь адрес электронной почты, который не меняется при смене провайдера почтового ящика.

Множественные или недействующие адреса

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

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

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

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

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

В Sender Policy Framework (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  Пользователь  не  местный;  перешлет на <[email protected]  >  

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

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

~/.forwardфайлы

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

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

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

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

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

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

Примечания

1. В разделе 3.9.2 Список RFC 5321 термин пересылка используется двусмысленно. В нем отмечается, что « ключевое различие между обработкой псевдонимов (Раздел 3.9.1) и пересылкой (этот подраздел) заключается в изменении заголовка [ Return-Path ] ». Эта формулировка, новая в соответствии с RFC 2821, могла бы быть интерпретирована как определение пересылки , если бы тот же термин не использовался в начале того же подраздела с противоположным значением. Как согласился один из участников RFC 5321, Тони Финч (2008-11-03). «Английские термины для пересылаемых адресов». IETF . Архивировано из оригинала 2008-12-11 . Получено 2008-11-07 . [ пересылка ] — нечеткий (нетехнический) термин в SMTP
2. Первичная запись MX соответствующего домена обычно публикует имя почтового сервера . В противном случае доменное имя должно иметь IP-адрес .
3. Конверт сообщения — это данные, передаваемые в транзакции SMTP перед передачей содержимого сообщения. Конверт теряется при доставке сообщения, хотя некоторые его поля могут быть сохранены принимающим сервером в заголовках сообщения. В частности, конверт содержит Return -Path (он же адрес возврата , аргумент MAIL FROM , mailfrom или mfrom ) и одного или нескольких получателей (включая Bcc ).
4. Дэйв Крокер (июль 2009 г.). "Посредники". Архитектура интернет-почты. IETF . раздел 5. doi : 10.17487/RFC5598 . RFC 5598. Получено 19 марта 2013 г. Посредник пересылает сообщение через процесс повторной отправки. Посредник разделяет некоторые функции с базовой ретрансляцией MTA, но обладает большей гибкостью как в адресации, так и в содержании, чем доступно MTA.
5. Джон Левин (15.10.2008). «Пользователи не любят пересылаемый спам». CircleID . Получено 07.11.2008 .
6. RFC 2142, «Имена почтовых ящиков для общих служб, ролей и функций» , 1997, упоминает также маркетинг , поддержку , злоупотребления , безопасность , веб-мастеров и многое другое.
7. «Как пересылка электронной почты влияет на результат аутентификации?». ProDMARC . 6 января 2023 г. Получено 16 марта 2023 г.
8. Рассмотрим следующий прямой путь:

   ${\displaystyle {\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 record#История отката к A.
11. Пересылка простых сообщений может раскрыть конечный адрес назначения независимо от намерения пользователя. См. разделы 7.7 Раскрытие информации в пересылке сообщений и 4.4 Информация трассировки в RFC 5321.
12. Франк Мартин; Элиот Лир; Тим Дрэген; Элизабет Цвики; Курт Андерсен, ред. (сентябрь 2016 г.). "Псевдоним". Проблемы взаимодействия между аутентификацией сообщений на основе домена, отчетностью и соответствием (DMARC) и косвенными потоками электронной почты. IETF . раздел 3.2.1. doi : 10.17487/RFC7960 . RFC 7960. Получено 14 марта 2017 г.
13. Хант, Крейг (2002). Администрирование сетей TCP/IP . O'Reilly. стр. 606. ISBN 0-596-00334-X.Текущая ^{[обновлять]}(версия 8.708 от 2006 года) документация sendmail не упоминает никаких ограничений по использованию -fпереключателя и использует глагол set вместо override для описания его действия над данными отправителя конверта.
14. Даты книг в client-server-faq ^{[ permanent dead link ]} находятся в диапазоне от начала 1990-х годов. Хотя удаленные вызовы процедур возникли в 1970-х годах, они не получили широкого распространения, пока сети не стали довольно распространенными.