> From: "Robert G. Brown" <rgb@xxxxxxxxxxxx>
> ...
> I agree. However, all of the observations made so far regarding
> spam/virus filtering in general still apply to filtering at the SMTP
> level. I would say that NO keyword filtering could take place. The
> best that one could do at the protocol level would be to reject messages
> that fail to meet a tighter criterion than is currently required.
What is "the SMTP level"? Is that during SMTP transactions between MTAs?
Is "the protocol level" the same or something else?
If both of those "levels" refer to SMTP transactions between MTAs, then
the conclusion is wrong. Except for local administrative hassles, all
spam and virus filtering that can be done later can instead be done
during SMTP transactions between MTAs. Your SMTP server may need to
wait to until the end of the DATA command to object to messages
containing viruses, missing or bad SMTP headers or other objectionable
content, but that works fine. I know of many millions of spam that
are filtred during the DATA command every day, and I don't claim to
know about any really big sites.
The only problems are:
- local administrative choices that keep bastion SMTP servers ignorant
of per-user filter preferences
- filtering at the DATA command requires either (1) rejecting for
all or no targets or (2) accepting for all targets and siliently
discarding the message for those targets that want it filtered.
In theory the second problem could be fixed if the DATA command could
accept a vector of 250-OK/4yz-try-later/5yz-fatal responses, one for
each target named with a Rcpt_To command. In practice the spam problem
will be solved one way or another long before such a protocol change
would be sufficiently widely deployed to matter.
Vernon Schryver vjs@xxxxxxxxxxxx