即使只是简单地看一下SMTP协议，您会注意到除了通常的HELO之外，还有EHLO，这使得 扩展 SMTP服务器宣传其功能超出原始标准。其中之一是DSN。 DSN？ DNA和滴滴涕还不够吗？
认为电子邮件不可靠，有人应该“ …更好地提供服务器;它吃了我的邮件…… “并不少见。但没有太多理由支持这些怀疑。
交货 小号 tatus ñ 自从RFC 821（1982年）以来，语言化已经存在。一旦SMTP协议的DATA部分完成并且服务器已接受电子邮件以进行传递，它就负责它。如果由于任何原因无法将其传递给收件人，则必须将错误通知发送回原始发件人。这导致了一些不起眼的电子邮件。
除此之外，这个旧约定意味着要么你得到了错误信息，要么得到了 没有 在这种情况下，你知道 没有 ：电子邮件可能已经到达，也可能没有。在许多情况下，错误消息与没有错误消息一样有用。随着电子邮件变得越来越重要，这已不再令人满意（就像之前一样）。
DSN对SMTP的扩展
RFC 1891提出了对SMTP协议的一些扩展，这些扩展应该会产生更可靠和更可用的DSN系统。它是MAIL和RCPT命令的一组扩展。
没有EHLO，没有乐趣
首先，我们必须确保服务器支持DSN。因此，我们必须对他说EHLO并仔细聆听。如果它在功能列表中的某处响应DSN，我们可以假设它能够满足我们的请求。如果没有，那么不是：我们可以尝试其他服务器或只是回到没有DSN的电子邮件。例如：
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6;太阳，1997年8月24日18:23:22 +0200EHLO localhost250-larose.magnet.at Hello localhost 127.0.0.1，很高兴见到你250 EXPN250动词250-8BITMIME250-SIZE250-DSN250 ONEX250-ETRN250 XUSR250帮助 幸运的是，我们找到了DSN。 下一个命令通常是MAIL FROM。使用DSN，这没有什么不同。但是您可以发出两个额外的选项：RET和ENVID。 RET选项相当任意地放在MAIL命令中，但它适用于此处以及其他任何地方。目的是指定在传递失败的情况下应返回多少原始邮件。有效参数为FULL和HDRS。前者表示完整的消息应包含在错误消息中，HDRS指示服务器仅返回失败邮件的标头。如果未指定RET，则由服务器决定如何操作。在大多数情况下，HDRS将是默认值。 ENVID确实属于发件人，因为她或（更确切地说）她的电子邮件客户端将是唯一一个使用它的人 信封标识符 。其目的是告诉发件人哪个电子邮件可能发出错误消息对应。此ID的格式基本上留给发件人的想象力。我们不会在我们的示例中使用ENVID： 邮件来自：[email protected] RET = HDRS250 [email protected] …发件人确定 显然，我们只想在DSN中获取标题。 RCPT TO：获得其公平的扩展份额：NOTIFY和ORCPT。 NOTIFY是DSN的真正核心。它告诉服务器 什么时候 发送传递状态通知。第一个可能的值是NEVER，这意味着在任何情况下都不得将DSN返回给发件人。没有DSN，这是不可能的。然后是SUCCESS，它将在您的邮件到达目的地时通知您。失败是SUCCESS的对应物：如果在交付期间发生错误，DSN将到达。最后一个选项是DELAY：如果交货有异常延迟，您将收到通知，但实际交付的结果（成功或失败）尚未确定。决不 必须 如果它指定了唯一的参数，其他三个可能出现在列表中，用逗号分隔。成功和失败弥补了一个非常强大的团队，告诉你（几乎）任何情况你的邮件发生了什么。 ORCPT的目的是保护 原版的 电子邮件的收件人，例如，如果它被转发到另一个地址。此选项的参数是原始收件人的电子邮件地址以及地址类型。首先是地址类型，然后是分号，最后是地址。例如： RCPT TO：[email protected] NOTIFY = FAILURE，DELAY ORCPT = rfc822; [email protected]250 [email protected] …收件人确定（将排队） 接下来是我们所知道的数据，并最终希望通知交付状态通知您成功。 当然，所有这些美丽和它只有在从发件人到收件人的邮件传输代理支持DSN时才有效。总有一天他们会。 DSN发件人扩展
DSN收件人扩展程序
DSN有用吗？
