[122724] in North American Network Operators' Group
Re: Spamhaus...
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Sat Feb 20 12:54:54 2010
To: William Herrin <bill@herrin.us>
In-Reply-To: Your message of "Sat, 20 Feb 2010 11:36:37 EST."
<3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com>
From: Valdis.Kletnieks@vt.edu
Date: Sat, 20 Feb 2010 12:53:21 -0500
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--==_Exmh_1266688401_18123P
Content-Type: text/plain; charset=us-ascii
On Sat, 20 Feb 2010 11:36:37 EST, William Herrin said:
> They didn't exactly fix it. What they did is reinforce the importance
> of generating a bounce message by keeping the existing "must" language
> from 2821 but adding:
>
> "A server MAY attempt to verify the return path before using its
> address for delivery notifications"
OK, let's run with that. It is *permitted* to check the address for validity
before bouncing to it. So you can do one of two things:
1) Blindly bounce without bothering to verify first. One of two things will
happen: a) it doesn't point at a valid mailbox, and it double-bounces and
pisses off your postmaster or b) they actually point at some innocent person's
mailbox and it pisses them off. To quote Dr Phil, "How's that working out for
you?" (And if you're dropping the double-bounces because they're of zero worth
to *your* posthamster, there's a special place in Hell for you. If you find
them of zero value when they double-bounce, why do you insist on inflicting
them on innocent bystanders when you successfully backscatter?
2) We can attempt to verify it first. Now, if it's spam or a virus, what do we
know about it? We know a priori that the return path is bogus and should not be
used. OK, that was quick. We've tried to verify it, and we've found it's
invalid. Want to use a known-invalid address for the bounce? Not if you want
to have a reputation as a good network neighbor.
Either way, you shouldn't be bouncing spam.
They also added this text in section 6.2
Conversely, if a message is rejected because it is found to contain
hostile content (a decision that is outside the scope of an SMTP
server as defined in this document), rejection ("bounce") messages
SHOULD NOT be sent unless the receiving site is confident that those
messages will be usefully delivered. The preference and default in
these cases is to avoid sending non-delivery messages when the
incoming message is determined to contain hostile content.
Spam is hostile, by definition. If you get spam, you should not bounce unless
it will be "usefully delivered". The only thing you can usefully deliver to a
spammer is a fully armed and operational tactical nuke, set to detonate in
4...3...2...
Since an NDN isn't a tactical nuke, you shouldn't be bouncing spam.
So we've looked at it from 2 different aspects, and in both cases, the
RFC says you shouldn't be bouncing spam to where it came from.
--==_Exmh_1266688401_18123P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFLgCGRcC3lWbTT17ARAnjHAKC4b5Udx1jbC576WqF8gIdoWzaaFgCg0yEv
IN8zS2KNHuyqulDiWwDYr90=
=8b+P
-----END PGP SIGNATURE-----
--==_Exmh_1266688401_18123P--
