[143136] in North American Network Operators' Group
Re: [BULK] Re: SORBS contact
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Sat Jul 30 10:13:20 2011
To: William Herrin <bill@herrin.us>
In-Reply-To: Your message of "Sat, 30 Jul 2011 09:46:13 EDT."
<CAP-guGWNtnrpzR=3cK8ORysKGcEiutp33RLmuw_YAU0MNWHnSw@mail.gmail.com>
From: Valdis.Kletnieks@vt.edu
Date: Sat, 30 Jul 2011 10:12:09 -0400
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--==_Exmh_1312035129_23760P
Content-Type: text/plain; charset=us-ascii
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?
--==_Exmh_1312035129_23760P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFONBE5cC3lWbTT17ARAnY6AJsGCUC3+vTOk8Hv4cKFEQ3eqwFs2QCfa0IB
nH9xzpGqn2B8qjBgytbTyfQ=
=RcXr
-----END PGP SIGNATURE-----
--==_Exmh_1312035129_23760P--
