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.