On Sat, 30 Jul 2011 09:46:13 EDT, William Herrin said:
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."
tl;dr: 4.5.5 says SHOULD instead of MUST for a *reason*. RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I know for a fact that the LSoft guys thought long and hard about it, and decided that "Yes, 99.998% of the mail will go out with a non-null reverse path. But the other 0.002% of administrivia and confirmation mail will best serve the network interests if they are sent with a null reverse path so they are treated similarly to bounce messages, even though they aren't an RFC-blessed bounce message". Hint: If somebody forges a subscription request from 'nosuchuser@herrin.us', do you want the resulting "Somebody has requested this email address to be added to the foobar-l list, please click or reply within 48 hours to confirm" mail to show up with a <> so you can skip generating the bounce, or do you want it to have a non-null return path so you're forced to generate a bounce that will be ignored at the other end anyhow? Does your answer change if some skript kiddie forges 10,000 requests?