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

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

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

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

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

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

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

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

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

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

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

info , sales , postmaster и подобные имена ^[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  Пользователь  не  локальный;  перешлем на адрес  < [email protected]>  

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

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

~/.forwardфайлы

Эталонной реализацией SMTP в начале 1980-х годов была sendmail , которая предоставляла ~/.forwardфайлы, в которых могли храниться целевые адреса электронной почты для определенных пользователей. Этот вид пересылки на базе сервера иногда называют точечной пересылкой . ^[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, Тони Финч (03.11.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 г., также упоминает маркетинг , поддержку , злоупотребления , безопасность , веб-мастеров и многое другое.
7. «Как пересылка электронной почты влияет на результат аутентификации?» ПроДМАРК . Проверено 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#История перехода к 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-Х.Текущая ^{[обновлять]}документация sendmail (версия 8.708 от 2006 г.) не упоминает никаких ограничений в использовании -fпереключателя и использует глагол set , а не override для описания его действия над данными отправителя конверта.
14. Даты книги в client-server-faq ^{[ постоянная неработающая ссылка ]} относятся к началу 1990-х годов. Хотя удаленные вызовы процедур возникли в 1970-х годах, они не получили широкого распространения до тех пор, пока сети не стали достаточно распространенными.