Robert G. Brown <rgb(_at_)phy(_dot_)duke(_dot_)edu> 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(_at_)jlc(_dot_)net>