Robert G. Brown <rgb@xxxxxxxxxxxx> wrote: > > THIS IS NOT A MATTER OF PROTOCOL! This is not the business of the IETF! > Tools exist to help you filter spam. Some, like spam assassin, are very > good and quite sophisticated. However, there is ALWAYS a tradeoff with > using this sort of tool -- too narrow a criterion for acceptance and you > lose real mail, too broad and you get all the spam anyway. I can choose > my level of tradeoff, and be fully aware of the risks. While the parameters of individual spam-filtering _should_ not be the business of IETF, there is a very real issue raised by filtering _after_ the SMTP session: During the SMTP session, it is quite possible to give an error which is likely to reach the right person; after the SMTP session, you have to "trust" the various header fields -- which are routinely forged by spammers. In fact, we are now facing a _second_ denial-of-service problem (the first being spam itself clogging your mailbox): excessive bounce messages automatically directed to mailboxes forged by spammers. And this by its nature is a distributed-denial-of-service problem, even harder to protect against. Spam-filtering _after_ the SMTP session _should_ be deprecated by IETF, IMHO. While there is no question that any recipient has the right to ignore any message, SMTP was intended to either deliver the message or send back an error; and the loss of this feature reduces the utility of e-mail. -- John Leslie <john@xxxxxxx>