Valdis.Kletnieks at Valdis.Kletnieks at
Sat Feb 20 17:53:21 UTC 2010

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <>

More information about the NANOG mailing list