David Lemson's WebLog

Product Unit Manager, Exchange

Blogs

The RFC 2821 "Covenant"

  • Comments 4
  • Likes

In a recent comment, Mark Hicks asks:

Is there a way to accept a message for an invlaid recipient and then delete it without generating an NDR to the (usually fake) sender? I still want to generate an NDR for my internal users when mail cannot be delivered to an external recipient. -Thanks.

No, Mark, Exchange doesn't have that built in. And while as a mail administrator, in certain circumstances, I can see why you might want to do that, in general that would be a feature that would let people “shoot themselves in the foot”.  The reason is that this would break a fundamental rule in the way that Internet mail works.  Quoting from RFC 2821, Section 3.7 - Relaying:

If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path).

Put a lot more simply: imagine your grandma was sending you a mail.  Instead of markhicks@hostname.com, she accidentally typed markhixks@hostname.com.  It gets to the right host, and with your request, that mail would just disappear.  RFC 2821 requires that your grandma get an error message telling her that her mail didn't get through. Either your server, or the machine that was trying to submit the message to you, needs to create that error notification.  Now, whether or not the error message is formatted so bizarrely such that your grandma has a hope in understanding that reason is another thing... but at least she's going to call you and ask you why you're refusing her mail!

Incidentally, the next line of that RFC is interesting for Exchange 5.5 aficionados:

Formats specified for non-delivery reports by other standards
(see, for example, [24, 25]) SHOULD be used if possible.

For reference, [24] is RFC 1891 and [25] is RFC 1894.  When Exchange 5.5 was the most prevalent version of Exchange out there, we got a fair amount of heat for the fact that Exchange 5.5 does not generate RFC 1894-compliant non-delivery reports, although it does support RFC 1891.  I won't debate whether or not that was the right thing to do, but I will point out that SHOULD in there.  Of course, we did support RFC 1894 reports fully starting in Windows 2000 SMTP / Exchange 2000, so we're all good now.  And, finally, I am proud of the fact that Exchange users who use Outlook or Outlook Web Access don't have to see the potentially-confusing format of RFC 1894 notifications, we have a nice readable non-delivery report error form, which in Outlook includes a “send again” button, which is mighty handy.

Comments
  • The only legitimate circumstance i can see for not wanting to generate an NDR is in the instance where the origniator of the original e-mail can be determined with a high level of certainty to be forged (e.g. when the message is generated by worm known to forge that information). In that instance the MTA is basically 'dumb' and the determination is properly handled by a content filter, such as an AV product. Sybari and other have intelligent worm handling and with Exchange Edge services I can imagine several other ways to educate the MTA to make more intelligent choices about what to do with a message (and any resulting NDR).

  • Exchange-faq.dk - Din portal til Microsoft Exchange Server information

  • PingBack from http://maxfeed.ath.cx/item_580777.html