Re: [BULK] Re: SORBS contact

[Valdis.Kletnieks () vt edu]

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?

Attachment: _bin
Description: