[BULK] Re: SORBS contact

Sat Jul 30 14:12:09 UTC 2011

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 at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110730/38b7fcf9/attachment.sig>