正确的原因SMTP“MAIL FROM：”与DATA中的“From：”标题不符

标题和信封发件人地址可能不匹配的原因很多。 大多数情况下，涉及自动化的发送邮件的过程，在这些过程中，需要将发送问题报告给不代表谁发送邮件的地址，发送邮件的人或者应该回复的地址。 邮件列表，你已经指出是一个很好的例子。

从用户的邮件客户端发送的消息可能与地址不同的主要原因是转发邮件。 邮件内容应该合理忠实于原件，但在发送错误的情况下，应该向转发邮件的用户报告，而不是原始发件人。

除了SMTP头之外，各种程序还使用各种MIME头来区分原始发件人和中间发件人，和/或首选地址以报告错误。回复发件人最初来自，错误等，等等，每个不同的sematics。 其中一些有标准的支持，而更多的则不支持，但反正可能会被使用。 各种邮件程序在实践中的performance方式差异很大。

处理邮件的方式是否可取是一个不同的问题，不同于你问的是“合法的”。 如果您在这里考虑处理潜在的垃圾邮件的政策方面的合法性，那么不，我不认为您可以通过这种方式做一个简单的区分。

想一想DKIM电子邮件签名，以及电子邮件域的邮件服务器的SPFvalidation。 如果您发送的邮件太多，以这种方式validation邮件可能很重要，而这可能会影响邮件头信息的寻址，因为您只能validation与您拥有权限的域相关的邮件。

–

根据要求扩展：

MIME'Reply-To'标题指示MUA（邮件用户代理，通常是一个人的邮件客户端）将回复发送到不同的地址，而不是MIME“发件人”地址。 这不是由MTA（邮件传输代理）用于错误等事情。

通常情况下，MTA将使用SMTP信封“MAIL From”地址向其发送错误。 IT可以通过MIME'Errors-To'头来覆盖，这是一个MTA指令。 并非所有的MTA都会遵守它，所以这是设置SMTP信封地址的不良机制，但是在很多情况下可以在邮件中设置MIME邮件头，而不是SMTP信封发件人地址。 例如，运行在共享主机环境中的软件可能会遇到这种情况。

“发件人”对于软件代理人的指示要模糊得多，但是指出发送电子邮件的人或发送的地址与“发件人”地址不同，“发件人”更像是代表发送邮件的人。 例如，当你填写一个在线的邮件或者政治家的表格时，最后的电子邮件在From标题中使用你的邮件是非常合适的，但是有一个与设置表单的组织有关的发件人地址。

转发邮件时，某些MUA软件使用“原始发件人”，转发者地址用于“发件人”标题。 其他的MUA将单独离开From地址，并使用“Resent-From”头。 接收这些不同头文件的MUAs是否有用地解释头文件，甚至显示它们都是相当可变的。 当回复已经转发给你的邮件时，默认情况下应该回复谁？ 也许最好设置“回复”标题？

MUAs的行为是可变的，并且定义不明确，尽pipe似乎随着时间的推移正在改善。 相比之下，信封的语义更加明确。 一般来说，MTA绝对不应该关注MIME头文件，但是随着MTA越来越多地对邮件内容负责（例如参见SPF和正在出现的DMARC标准），这个位置的清晰度会有降低的压力。 像错误这样的长期机制也与MTA的概念相冲突，而不是看标题内容，这是这些机制总是被不一致应用的部分原因。 软件作者的哲学各不相同。

您可能会发现浏览http://tools.ietf.org/html/rfc4021#section-2是有用的，但请记住，大量邮件软件的实际操作方式并不一定符合标准。

试图提出一个明确的理念来说明如何使用邮件，但不要指望别人会按照自己的想法去做。

自动化处理是一个很大的原因。 你希望能够发送任何反弹/自动回复/错误分开处理，否则这些消息消失，或被忽略，或者一些可怜的SAP必须挖掘他们。 是的，添加一个X头来处理是可能的，但很多时间反弹/等。 将不会包含原始电子邮件或只包含原始邮件的一部分，您将无法获得源代码。

例如，说某人在您的网站上注册，并向他们发送一封电子邮件，表示感谢您注册。 你的MAILFROM和From可能是这样的：

MAIL FROM: <[email protected]> From: Website X <[email protected]> 

这样，用户在邮件客户端看到“友好的来源”。 但是，如果用户不存在，他们的MTA会发送退回消息到：

  [email protected] 

一个自动化的过程可以很容易地从标题中拉出用户标识（123123123部分）和创build反弹的系统部分（-signup-部分），并轻松地将该用户删除/标记为禁用。

来自：在smtp对话中的邮件被devise为反弹的地方。邮件正文中的From：标题用于向收件人显示，如果未设置Reply-to：标题则显示为回复地址。

不应该产生反弹的电子邮件应在信封中设置空发件人，例如，回执通常将：： mail from:<> ，用户名称mail from:<>头。

另一种情况是邮件服务器使用BATV拒绝伪装的反弹。 来自：的邮件将采用[email protected]的forms。

除非我没有正确地阅读我的标题或问题，否则我的BlackBerry的电子邮件将从BlackBerry服务器发送，基本上没有任何字段匹配。 我意识到，用户比例很小。 我最近在评估我的邮件服务器时一直在看这个。 以下是从我的BlackBerry发送到我的Gmail帐户的匿名电子邮件：

 Delivered-To: [email protected] 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 <[email protected]>; 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 <[email protected]>; 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 <[email protected]>; 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: [email protected] X-Priority: Normal Sensitivity: Normal Importance: Normal Subject: Test To: "Recipient Name" <[email protected]> From: [email protected] Date: Wed, 14 Aug 2013 07:18:45 +0000 Content-Type: text/plain MIME-Version: 1.0 Test Sent via BlackBerry by AT&T