PSE-L@xxxxxxxxxxxxxxxxxxxxx (Sean Straw / PSE) wrote: > At 20:53 2004-06-22 -0400, David F. Skoll wrote: >>A 5xx failure code is a lot more friendly than actually generating a DSN. > > Well, you're causing the sending/relaying host to generate the DSN. > Quite possibly back to some sod who has been joe-jobbed. Often enough, no. For instance, the virus on Joe's infected PC sends out 87 copies of itself forging me as the sender. They get rejected with 5xx. The virus isn't going to send me DSNs. (If there were a forwarding system involved that accepted then bounced, it might; but that's not the most common case.) >>Proposals like SPF can help a little. > > On the surface, SPF seems really nifty, but it poses a significant > implementation issue for listserves and forwarding services alike. Yes, it needs a little work done to address those cases. I see two general possibilities: 1. At the (final) receiving end, the configuration says "I set up domain X to forward to me, so check the Received header it added." This isn't the preferable choice, but it can be done unilaterally by the recipient. 2. Modify the protocol to specify that forwarders add a particular header, and SPF checks that header for the connecting machine, and possibly the included IP address for the actual sender. We'd need to be careful to handle multiple-forwarding gracefully, of course. >>One good thing is that spammers often use ratware that ignores >>failure codes. So a 5xx return code does *not* elicit a >>DSN, whereas having your anti-spam box actually generate a DSN >>is obviously bad. > > You're back to the problem that the Anti-Spam solutions are often > implemented post-SMTP, so those using them have the option of either > ditching the message or generating an (often undesired) DSN. The > anti-spam and virus solutions which are integrated at the SMTP level > pose DOS issues for the mailhost because the message MUST be > identified as spam or not spam right then and there. Even if the choices are bad/good/unknown, with the latter being handled post-smtp, moving possibilities earlier (that is, doing whatever amount of checking during smtp you can do) will only be helpful. Seth
