在我们的邮件应用程序中，我们发送带有以下标题的电子邮件：
FROM: [email protected]
TO: subscri[email protected]
Return-PATH: [email protected]
我们面临的问题是，某些电子邮件服务器会立即退回邮件并使用发件人或反向路径（[email protected]）而不是我们的退回管理服务器。我们想知道如果我们能够捕获所有退回邮件，我们是否可以在标头中将回复修改为与返回路径相同。
还有其他想法欢迎吗？
我们使用以下文档作为参考：VERP
RFC
退回邮件
解析 SMTP 日志以获取退回邮件
编辑1：更多一些信息，看看我们是否可以得到这个解决方案。
我们想知道中继消息的电子邮件服务器在什么时候会选择使用回复路径而不是返回路径。我们注意到，当中继邮件的第一个 SMTP 服务器被拒绝时，它会将其发送到回复，但当它在一跳之后发生时，它会将其发送到返回路径。
让我们从一个简单的例子开始。假设您有一个电子邮件列表，它将发送以下内容RFC2822内容。
From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <coolstuff-thre[email protected]>
This is a very simple body.
现在，假设您要从邮件列表发送它，该列表实现了VERP（或其他一些使用不同返回路径的反弹跟踪机制）。假设它的返回路径为[email protected]。 SMTP 会话可能如下所示：
{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<[email protected]>
{S}250 2.1.0 [email protected] OK
{C}RCPT TO:<[email protected]>
{S}250 2.1.5 [email protected]
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>
This is a very simple body.
.
{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel
其中{C}和{S}分别代表客户端和服务器命令。
收件人的邮件将如下所示：
Return-Path: [email protected]
From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <coolstuff-thre[email protected]>
This is a very simple body.
现在，让我们描述不同的“FROM”。
- 返回路径（有时称为反向路径、信封发件人或信封发件人 — 所有这些术语都可以互换使用）是 SMTP 会话中使用的值。
MAIL FROM命令。正如您所看到的，该值不需要与消息标头中的值相同。只有收件人的邮件服务器才应该在电子邮件顶部添加 Return-Path 标头。这会记录 SMTP 会话期间的实际返回路径发件人。如果邮件中已存在 Return-Path 标头，则该标头将被删除并由收件人的邮件服务器替换。
SMTP 会话期间发生的所有退回邮件都应返回到返回路径地址。某些服务器可能会接受所有电子邮件，然后在本地对其进行排队，直到有空闲线程将其传递到收件人的邮箱。如果收件人不存在，则应将其退回到记录的 Return-Path 值。
请注意，并非所有邮件服务器都遵守此规则；有些邮件服务器会将其退回到发件人地址。
-
FROM 地址是在 FROM 标头中找到的值。这应该是消息的发件人。这就是您在大多数邮件客户端中看到的“发件人”。如果电子邮件没有 Reply-To 标头，则所有人工（邮件客户端）回复都应返回到 FROM 地址。
-
Reply-To 标头由发送者（或发送者的软件）添加。这也是所有人类回复都应该得到解决的地方。基本上，当用户单击“回复”时，回复值应该是用作新撰写的电子邮件的收件人的值。 Reply-To 值不应被任何服务器使用。它仅供客户端 (MUA) 使用。
然而，正如您所知，并非所有邮件服务器都遵守 RFC 标准或建议。
希望这有助于澄清问题。但是，如果我错过了什么，请告诉我，我会尽力回答。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
