Filters relying on string matches in the raw body of an e-mail
message may be more general than intended. Text matches are no
replacement for a virus or spam filtering system.
Of course they aren't. Have we really reached the point where we
have to belabor obvious points like this in security considerations
sections?
There are several solutions our there that claim to solve the email
spam and virus problems with Sieve, encoding common spam and virus
signatures in Sieve scripts (some are offering online access to
updated Sieve scripts with new signatures). People are being told,
and believe, Sieve is the right tool for this. Looking only at RFC
3028, I can't blame them. It even contains examples on how to catch
spam.
Specific examples of how to catch a specific sort of spam message do not
a general filtering system make.
Every month Bruce Schneier has a "doghouse" section in his Cryptogram column
detailing one product or another he considers to be "snake oil security". In
many cases these systems try and gain credibility by claiming that they employ
one security standard or another. Yet we don't try and document this sort of
possible misuse in the security standards we write. Instead we focus on what
the system is good for and what its technical limitations are. We don't try and
deflect marketing pitches. It isn't a game that's appropriate to play in the
"once written never changed" context of an RFC.
Ned