[Mimedefang] Milter failure processing Read and Delivery Receipts

[Michael Sims]

Kris Deugau wrote:
> Michael Sims wrote:
>> Your log files are showing the envelope sender, which is not always
>> the same as the address in the From header.  Read receipts (or
>> disposition notifications or whatever you want to call them) are sent
>> using a null (<>) envelope sender for the same reason that delivery
>> status notifications are sent with a null sender, to prevent mail
>> delivery loops.
>
> They may be sent with a null envelope if it's generated by the server
> (you *can* specifically request such a notification), but I checked
> on a few of the receipts I have in the support inbox I read here, and
> none of them use the null envelope- they ALL use the recipient's real
> email address.

A properly behaved MUA will send read and delivery receipts (aka Message
Disposition Notifications) with a null envelope sender.  This is required by
RFC's 2298 and 2821.  From 2298:

  The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
  null (<>), specifying that no Delivery Status Notification messages
  or other messages indicating successful or unsuccessful delivery are
  to be sent in response to an MDN.

I know that Outlook 2000 complies with this RFC by using the null sender,
since some of my end users insist on using them.  I also know that there are
many clients out there that do not (including some versions of Outlook
Express).  A quick search through google shows that even some of Microsoft's
own people consider this a bug in the MUA.

> I can't think of any reason an MUA should use a null envelope

The general idea behind the null envelope is so that systems that
automatically create and send a message in response to another (DSNs, MDNs,
vacation replies), don't end up in a feedback loop.  Sure, there are usually
tons of different ways to avoid that happening (such as not including a
"Disposition-Notification-To" header in a MDN, including bulk Precedence
headers, etc.), but there are so many different MTA's and MUA's that
interact in myriad (and potentially unforeseen) ways.  The presence of the
null sender is THE universal indicator which says to automatic response
systems: "Never send an email in response to this one".

> ends up stuck on your server, occupying resources.  IMHO, users should
> NEVER send email with a null envelope from a client system- bounces
> will never reach them.  (Instead, the bounce annoys their postmaster.)

Dave Null handles all of our double bounces here, unfortunately.  I reject
as much as possible at my MX during the SMTP conversation, but it has no way
of knowing the quota utilization for my users, so I invariably end up
accepting a message that I find out later cannot be delivered.  Even without
null senders there is far too much junk that can't be bounced back for me to
have a real human being look through it all...

___________________________________________
Michael Sims
Project Analyst - Information Technology
Crye-Leike Realtors
Office: (901)758-5648  Pager: (901)769-3722
___________________________________________