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 ___________________________________________ _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
