OK, I'll brave the storm of broken autoresponders one more time.... >> IMHO 3: If user Joe gets 10 delivery failures of messages that he >> has not sent and one delivery failure of message that he has >> actually sent, it is worse than if he gets nothing. > This is indeed a problem, and it's a loophole that needs to be > closed. Unfortunately it's difficult for most people to close. > There needs to be a way for an SMTP server to correlate a bounce > message with a sent message, and reject the bounce message if it > wasn't caused by a validly-sent message. Proposals like SPF can help > a little. A little. But there also is a need to _identify_ bounce messages. A few years back, I got joed - some lamer forged my address into the from-line of what appears to have been an entire spamrun. I got some small number of thousands of bounces before I taught my mailer to pick apart multipart/report bounces and reject them if the bounced message doesn't show certain signs that all messages I send show. This helped immensely, and when the modern crop of from-line forging malware showed up, my defenses were already in place and functioning. Today, I occasionally get bounces for malware with my address forged into the fromline. I respond to them with a more or less stock response that goes something like If you _must_ do accept-and-bounce (something which is increasingly "part of the problem" in today's net), please at least make sure your bounces are proper multipart/report bounces, so they can be mechanically identified and treated appropriately. (See RFC 3462 for more on multipart/report.) I've been doing this only a little while. If there comes to be a site which is a persistent source of bounces and also persistently ignores that request, I'm prepared to block it entirely. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@xxxxxxxxxxxxxxxxxxxxxx / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
