[Asrg] Re: bounces, and anit-spam principles

Perhaps it's a good time to step back again and take a 
look at some principles that hopefully we can recognize 
(and some of these seemed controversial when I first 
proposed them, but hopefully by now my reasoning is a 
little more apparent):
1.  Spam is any mail the RECIPIENT does not want, 
regardless of how much the sender wants to send it.
2.  Accordingly, the definition of what they do and do not 
want MUST be such that the RECIPIENT defines it... not the 
IETF, not the sender's ISP, not the recipient's ISP, nor 
some governmental body, nor anybody else.
3.  Systems which rely on the "reputation" or 
"certifications" of the (supposed) sender are not very 
helpful, because a user's machine can be compromised by a 
worm or virus, or because a purported sender's credentials 
can be forged.
4.  Spammers, regardless of what they claim about not 
wanting to send unwanted mails, or only sending to 
"opt-in" addresses, specifically do everything in their 
power to bypass filters set up by recipients to block 
mails just like what the spammer wants to send.
5.  Most recipients do not really want to have their 
machine turned into a spambot zombie.
6.  Antispam/antiworm approaches based on traditional 
signatures are not effective in the initial hours of an 
infection wave, when all worms and viruses are at their 
most prolific and most dangerous.
7.  (And this point is particularly timely given the 
current discussion here).... it is almost NEVER really 
helpful to bounce an incoming message which contained a 
worm or a virus, or even which contains spam, unless you 
can determine (how??) who the legitimate original true 
sender really was.
For example, one incredibly annoying thing that happens to 
me every month or so is that Yahoo will stop delivering my 
Yahooogroups list mails to me, because they got back a 
"hard bounce" message implicating one of my E-mail 
addresses.  Almost invariably, this hard bounce message 
got sent out by some idiot mail software which found a 
worm or virus in an incoming message (and NONE of these 
infected mails have actually been sent out by ME, of 
course) and the idiot software decided to send the bounce 
back to some third party (in my case, Yahoo), which (also 
not-cleverly) decides that since they got back a 
(completely bogus!) hard bounce message (and to a message 
that Yahoo didn't really send, either), they'd better not 
try to send any more mail to me.  :-(  The result is that 
I typically lose anything from a half day's mail to as 
much as several days' mail from the various Yahoogroups 
I'm subscribed to.  :-((
Whether an E-mail contains spam, or a virus, or just about 
ANYTHING, the ONLY time it should be rejected is during 
the time of the original SMTP session when it is coming 
in... UNLESS the entity generating the bounce can 
(somehow) be ABSOLUTELY CERTAIN of who the guilty party 
REALLY is.
It's especially outrageous when a bounce message goes out 
specifying a contained virus which is KNOWN to forge a 
counterfeit return address...!  What is it supposed to 
accomplish to tell someone, whose system is NOT infected, 
that some random one else's system is?  And then, worse, 
to couch that as a "hard" bounce, suggesting that no more 
mail should be sent to the address in question??  (When, 
in fact, a legitimate mail would presumably sail right 
through...)
Critical aspects of solving the spam problem require that 
we deny spammers and abusers the techniques they have come 
to so effectively use to bypass effective content 
filtering.  That includes HTML, text-as-image, ActiveX, 
scripting (Java etc), and things of that sort.
Therefore, as an initial default (which would apply to 
"unfamiliar" senders) I still insist that mail from 
unaccepted senders be passed into my Inbox ONLY IF it 
contains NO HTML, and NO attachments, and does not exceed 
some specified size (10K, 50K, 100K, 200K, whatever the 
recipient decides to set as a threshold).  Assuming the 
mail message gets through that initial qualifying 
gauntlet, then Spam Assassin or whatever other antispam 
content filter should be able to decide whether it looks 
reasonable for delivery or not.
(And as an additional comment, based on a statement in 
today's ASRG digest, let me point out that brain-damaged 
"regular expressions" type pattern matching is IMHO 
nowhere close to adequate for this kind of good textual 
spam recognition, and something closer to SNOBOL4 or 
SPITBOL-type pattern matching is far more appropriate and 
useful).
The (initial filtering!) approach that I believe will work 
is based on this fine-grained "permissions list" (with a 
ruleset adjustable on a per-sender basis) which combined 
with a suitable default behavior denies in one fell swoop 
nearly all the tricks and subterfuges that spammers use to 
evade and deceive content filters.
All of these DNS-based things based on "sender reputation" 
and the like are doomed to failure because a well-reputed 
sender CAN be infected and caused to send out spam.  And 
just because they DO, doesn't mean that the LEGITIMATE 
mail they might still be sending out ought to now be 
t-canned.
It is FAR more helpful to allow recipient machines to 
identify that the mail message supposedly coming from a 
legitimate and familiar sender INDEED 'LOOKS' THE WAY that 
E-mail from that particular sender is EXPECTED AND ALLOWED 
to look.
And meanwhile, not allowing (by default) incoming E-mail 
that contains HTML, scripting, attachments and the like 
unless they are from someone that we TRUST to send such 
stuff (and have whitelisted) will virtually eliminate 
E-mail as a transmission vector for worms and viruses.
We keep dancing around with these elaborate technical 
schemes that folks keep claiming will solve (parts of) the 
problem, but which will predictably not solve it very much 
or very well.  Meanwhile, relatively straightforward 
approaches (as I'm proposing), and in conjunction with 
good content filtering, will go a long way towards solving 
the REAL problems, and still allow receiving (simple, 
safe) mail from previously unknown "first contact" 
senders.  AMD take a big chunk out of worms and viruses 
(today's AND tomorrow's!) at the same time.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg