On Fri, Jul 29, 2011 at 11:22 AM, <valdis.kletni...@vt.edu> wrote: > On Fri, 29 Jul 2011 09:48:44 EDT, William Herrin said: >> Correction: It's a standard way to denote that "this mail is a bounce >> report." > > It's *not* just "bounce reports" (in particular, DSNs and MDNs are not > non-delivery (bounce) messages in the sense of section 3.7, and both > can be generated in response to *successful* deliveries). > generated for *successful* deliveries).
Hi Vladis, Point taken. Bounce reports, temporary failure reports and successful delivery reports. Nevertheless, it still isn't for "other programmatically generated mail." In fact, the next paragraph in RFC 5321 4.5.5 says: "All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path." Contrary to your claim, it's perfectly reasonable for an spam filter in a symmetric routing scenario to discard a null return path message that isn't unambiguously responsive to one it previously sent. On Fri, Jul 29, 2011 at 5:52 PM, Michelle Sullivan <matt...@sorbs.net> wrote: > Umm no... As has been pointed out by others, but in another section > (maybe another RFC) it says that the null return path should be used > when a return message is not required, not desired, or it is from an > automated system or you wish to avoid mail loops (with particular > reference to bounce messages and mailing lists.) Michelle, Is your web site registration message required by a standards track RFC to use a null reverse path? Regards, Bill Herrin -- William D. Herrin ................ her...@dirtside.com b...@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
