除了邮件列表以外，是否有合理的理由使SMTP“ MAIL FROM：”字段与邮件的“ DATA”部分中的“ From：”字段不匹配？
来自/programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean：
“但是，为了继续您的蜗牛邮件比喻，大多数专业信件将包含打印在信件本身上的发件人和收件人的地址。这些地址对于邮递员来说不是必需的，而是对收件人的礼貌。因此，明智的做法是电子邮件将以相同的方式工作。”
这条逻辑线的问题就在这里：“对接收者的礼貌”。通过SMTP在电子邮件中包含“发件人：”地址不是礼貌；如果收件人能够发送回复，则是必需的。
发件人：如何限制发件人头以匹配后缀中的MAIL FROM？：
“但是，如果您真的想确保发件人：和邮件发件人，则必须应用header_checks，以便Return-Path：匹配发件人：”
这样做的含义是什么？邮件列表显然是一个问题。头信息“ MAIL FROM：”和“ From：”是否还有其他合法用途？
Answers:
标题和信封发件人地址可能不匹配的原因有很多。最关注的是自动发送邮件的过程，在该过程中，传递问题需要报告给一个不代表发送邮件的人，代表发送邮件的人或应该答复谁的地址。正如您所指出的，邮件列表就是一个很好的例子。
从用户的邮件客户端发送的邮件可能与地址不同的主要原因是转发邮件。然后，邮件内容应合理地忠于原始内容，但如果出现传送错误，则应将其报告给转发电子邮件的用户，而不是原始发件人。
除了SMTP标头外，还有各种MIME标头可供各种程序用来区分原始发件人，中间发件人和/或向其报告错误的首选地址。 ，Errors-To等，每个都有不同的语义。其中一些具有标准支持，而更多则没有，但是无论如何仍可能在使用。实际上，各种邮件程序的行为方式都相差很大。
是否建议使用一种寻址方式与您所问的是否“合法”方式不同。如果您在考虑诸如处理潜在垃圾邮件的政策之类的合法性，那么不，我认为您无法以这种方式做出简单区分。
不过，请考虑一下电子邮件的DKIM签名和电子邮件域的邮件服务器的SPF身份验证。如果您要发送大量邮件，则可以通过以下方式对您的邮件进行身份验证可能很重要，因为这可能仅对与您拥有权限的域相关的邮件进行身份验证，这可能会对从标头中寻址邮件产生影响。
-
根据要求扩展：
MIME“答复至”标头指示MUA（邮件用户代理，通常是一个人的邮件客户端）将答复发送至其他地址，而不是MIME“发件人”地址。MTA（邮件传输代理）不会将其用于诸如错误之类的事情。
通常，MTA将使用SMTP信封“邮件发件人”地址向其发送错误。可以使用MIME'Tos-To'标头（它是MTA指令）来覆盖IT。并非所有的MTA都会接受它，因此设置SMTP信封地址是一种劣等的机制，但是在许多情况下，可能可以在邮件中设置MIME标头，但不能设置SMTP信封发件人地址。例如，在共享主机环境中运行的软件可能会遇到这种情况。
“发件人”作为给软件代理的指令更加含糊不清，但它指示谁或什么向谁发送了电子邮件，而发件人地址与发件人地址截然不同，而发件人地址更像是代表谁发送邮件。例如，当您填写在线“您的邮件政治家”表格时，生成的电子邮件非常适合在“发件人”标头中使用您的邮件，但具有与设置该表格的组织相关的发件人地址。
一些MUA软件在转发邮件时会使用“原始发件人”，转发器的地址用于“发件人”标头。其他MUA将不理会发件人地址，并使用“ Resent-From”标头。接收这些不同标题电子邮件的MUA是否有用地解释标题，甚至显示它们都是非常可变的。回复转发给您的邮件时，默认情况下回复给谁？也许最好设置“ Reply-To”标题？
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
自动化的过程可以轻松地从头文件中提取用户ID（123123123部分）和创建反弹的系统部分（-signup-部分），并轻松地将该用户删除/标记为已禁用。
smtp对话中的from：邮件被设计为将被退回的位置。邮件正文中的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