Есть ли законная причина, по которой поле SMTP «MAIL FROM:» не соответствует полю «From:» в разделе DATA сообщения, помимо списков рассылки?
«Но, продолжая метафору обычной почты, большинство профессиональных писем будут содержать адреса отправителя и получателя, напечатанные на самом письме. Эти адреса не нужны почтальону, они просто вежливы по отношению к получателю. Поэтому разумно, чтобы электронная почта работала так же ».
Проблема с этой логикой заключается в следующем: «вежливость по отношению к получателю». Включение адреса «От:» в электронное письмо через SMTP не является любезностью; он необходим, если получатель должен иметь возможность отправить ответ.
Из: Как ограничить заголовок From, чтобы он соответствовал MAIL FROM в postfix?:
«Но если вы действительно хотите убедиться, что From: и MAIL FROM, тогда вам нужно применить header_checks, чтобы Return-Path: совпадал с From:»
Каковы последствия этого? Списки рассылки, очевидно, будут проблемой. Существуют ли другие законные способы использования различающейся информации заголовка «MAIL FROM:» и «From:»?
Есть много причин, по которым адреса заголовка и конверта могут не совпадать. Большинство из них касается автоматизированных процессов отправки почты, когда о проблемах доставки необходимо сообщать на адрес, который не является репрезентативным для того, кто отправил письмо, или от имени которого оно было отправлено, или кому следует отвечать. Списки рассылки, как вы отметили, являются хорошим примером.
Основная причина, по которой сообщение, отправленное из почтового клиента пользователя, может отличаться от адреса, - это пересылка почты. В этом случае содержание письма должно быть в разумной степени точным с оригиналом, но в случае ошибок доставки о них следует сообщать пользователю, пересылающему электронное письмо, а не исходному отправителю.
Помимо заголовка SMTP, существует множество заголовков MIME, которые различные программы используют, чтобы попытаться различить исходного отправителя и промежуточного отправителя и / или предпочтительный адрес для сообщения об ошибках, например, Reply-To, Sender, Originally-From , Errors-To и т. Д. И т. Д. У каждого своя семантика. Некоторые из них поддерживают стандарты, а многие нет, но все равно могут использоваться. На практике разные почтовые программы ведут себя по-разному.
Целесообразен ли способ адресации почты - это другой вопрос, чем то, является ли она «законной», как вы спрашиваете. Если вы рассматриваете здесь законность с точки зрения чего-то вроде политики обработки потенциального спама, то нет, я не думаю, что вы сможете провести простое различие таким образом.
Подумайте о DKIM-подписи электронной почты и SPF-аутентификации почтовых серверов для почтовых доменов. Если вы отправляете много писем, может быть важно иметь возможность аутентифицировать вашу почту этими способами, и это может иметь последствия для адресации почты из заголовков, поскольку вы можете аутентифицировать только почту, относящуюся к доменам, для которых у вас есть полномочия. .
-
Расширено по запросу:
Заголовок MIME «Reply-To» предписывает MUA (почтовому агенту пользователя, обычно почтовому клиенту пользователя) отправлять ответы на другой адрес вместо адреса «От» MIME. Он не используется агентом MTA (Mail Transport Agent) для таких вещей, как ошибки.
Обычно MTA использует адрес SMTP Envelope «MAIL From» для отправки сообщений об ошибках. IT может быть отменен заголовком MIME «Errors-To», который является инструкцией MTA. Не все MTA соблюдают его, поэтому это менее эффективный механизм для установки адреса конверта SMTP, но есть много обстоятельств, когда можно установить заголовки MIME в сообщении, но не адрес SMTP Envelope From. Например, программное обеспечение, работающее в среде виртуального хостинга, может оказаться в этой ситуации.
«Отправитель» гораздо более двусмысленно в качестве инструкции программным агентам, но указывает, кто или что отправил электронное письмо, причем это отличается от адреса «От», который больше похож на то, от имени кого было отправлено письмо. Например, когда вы заполняете онлайн-форму «mail-your-policy», было бы очень уместно, чтобы полученное электронное письмо использовало вашу почту в заголовке «От», но имело адрес отправителя, связанный с организацией, создавшей форму.
«Первоначально-от» используется некоторым программным обеспечением MUA при пересылке почты, при этом адрес пересылки используется для заголовка «От». Другие MUA оставят адрес «От» в покое и будут использовать заголовок «Resent-From». Независимо от того, будут ли MUA, получающие эти письма с различными заголовками, правильно интерпретировать заголовки или даже отобразить их, весьма варьируется. Кому должен быть отправлен ответ по умолчанию при ответе на письмо, которое было переадресовано вам? Может, лучше установить заголовок «Ответить»?
Поведение MUA изменчиво, плохо определено, хотя, похоже, со временем оно улучшается. Напротив, семантика конверта гораздо более определена. Обычно существует сильная позиция, согласно которой MTA никогда не должны интересоваться заголовками MIME, но поскольку MTA все чаще несут ответственность за содержание почты (например, см. SPF и появляющиеся стандарты DMARC), существует давление, требующее снижения ясности этой позиции. Давние механизмы, такие как Errors-To, также вступили в противоречие с понятием MTA, не просматривающим содержимое заголовка, что является частью того, почему эти механизмы всегда применялись непоследовательно. Философия авторов программного обеспечения различается.
Возможно, вам будет полезно просмотреть http://tools.ietf.org/html/rfc4021#section-2 , но помните, что реальная практика множества почтовых программ варьируется, что не обязательно соответствует стандартам.
Это нормально - попытаться сформулировать четкую философию того, как, по вашему мнению, следует использовать почту, но не ожидайте, что все остальные будут делать то, что, по вашему мнению, им следует.
Автоматическая обработка - большая причина. Вы хотите иметь возможность отправлять любые отказы / автоответы / ошибки, которые будут обрабатываться отдельно, иначе эти сообщения исчезнут или будут проигнорированы, или какой-то бедный сок должен их раскопать. Да, добавление X-заголовка для обработки возможно, но в большинстве случаев возникает ошибка и т. Д. не будет включать исходное электронное письмо или только его искаженную часть, и вы не сможете получить источник.
Например, предположим, что кто-то зарегистрировался на вашем веб-сайте, и вы отправляете ему электронное письмо с благодарностью за регистрацию. Ваш MAILFROM и От могут выглядеть так:
MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>
Таким образом, пользователь увидит в почтовом клиенте «дружественный от». Но если пользователя не существует, его MTA отправит сообщение о недоставке по адресу:
user-signup-123123123@bounces.example.com
а автоматизированный процесс может легко извлечь идентификатор пользователя (часть 123123123) и часть системы, которая создала возврат (часть -signup-) из заголовка, и легко удалить / пометить этого пользователя как отключенного.
Почта from: в диалоге smtp предназначена для того, чтобы быть местом, куда будут отправляться отказы. Заголовок From: в теле сообщения используется для отображения получателю и в качестве адреса ответа, если заголовок Reply-to: не установлен.
В электронных письмах, которые не должны вызывать отказов, в конверте должен указываться пустой отправитель, например, квитанция о возврате обычно содержит: mail from:<> с именем пользователя в заголовке from :.
Другая ситуация - когда почтовый сервер использует BATV для отклонения ложных отказов. Письмо от: будет иметь вид prvs=tag-value=mailbox@example.com.
Если я не читаю свои заголовки или вопрос правильно, электронные письма от моего BlackBerry отправляются с сервера BlackBerry, и в основном ни одно из полей не совпадает. Я понимаю, что это небольшой процент пользователей. Я недавно смотрел на это при оценке своего почтового сервера. Ниже приведено анонимное электронное письмо, отправленное с моего BlackBerry на мою учетную запись Gmail:
Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
for <recipientusername@gmail.com>;
Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0
Test
Sent via BlackBerry by AT&T