ietf-mxcomp
[Top] [All Lists]

Re: Trouble with Sender Authentication

2006-11-06 13:11:43

On Fri, 3 Nov 2006, Douglas Otis wrote:


More than 70% of emails are spam, of which more than 70% are sent  
from compromised systems.  

Most of this isn't commercial, either. Commercial bulk email is no
longer a problem.

Doug, I've read a lot of your postings about SPF over the last
several years, and I can't say I can recall you ever trying to make
a *constructive* suggestion on how to improve SPF, other than to
throw it out.

"Throwing it out" is a constructive suggestion. Wasting time on schemes
that can't succeed is, well, a waste of time and resources.  This is how
perpetual motion schemes motivated the development of thermodynamics.  
SPF is just another perpetual motion scheme which is shown impossible by
information theory.  The promoters of perpetual motion was similarly
"urgently" interested in spending money to build their machines.  
Thermodynamics demonstrated the scam.

Likewise, certain people seem to be making a lot of money consulting on
such anti-spam schemes.  Or making money on blacklists, and other
schemes.  In my view, those people aren't solving spam problems. It is
questionable what interests those people have in solving spam problems,
given that a 'solution' would mean an end to their financial prosperity.  
It is very odd that non-commercial abuse continues to grow. Who benefits
from that?


The following may be helpful:

--------------

Subject: Re:  spam content filtering

Queueing and information theory is your friend.  Blacklists are
generally not your friends, even if well intentioned, DHCP changes
virus-infected IP addresses far faster than a human oriented blacklist
could keep up.  The ones that do keep up tend to be connected to the
abuse, and often those are also defamatory of someone.

I worked out several years ago, using information theory, that one
cannot stop spam with any technical means.  The info. theory argument is
easy to follow, if you have some little background. It is a known result
that one cannot prove the non-existance of a covert channel in a
communications system.  It is easy to establish that email is a
communications channel for information theory.  It is also easy to
establish that spam is an unwanted communication channel use, equivalent
to a covert channel. It then follows that one can't stop spam since that
would be the equivalent of proving that a covert channel couldn't exist,
which is a contradiction of a known result.

One can of course discover spamming, and temporarily stop it on some
parameter (e.g. IP address), but this is always a "whack-a-mole"  
operation. You can never fundamentally improve upon whack-a-mole. [Same
is true of spying]

What now? Quit? Not at all: Queues are your friend.  Place messages from
previously known senders in faster queues, while unknown messages are in
slower queues.

"known senders" can be identified in a variety of ways: email addresses, 
smtp server IP addresses, etc. 

Everyone actually gets their spam, and can search it for previously
unknown good senders.  It just doesn't show up so directly.  It just
winds up in a slower queue and a different mailbox.  These messages can
be expired, and/or used to to identify bad senders, and make complaints
as you like...  Known bad-senders can be expired quicker, etc.

One of the good things to happen was the CAN-SPAM Act. Genuine
commercial bulk emailers (CBE) are not the cause of abuse, and don't
need to be blocked. Genuine CBE's don't abuse open proxies, nor abuse
open relays, nor forge headers, nor use viruses to install proxies, etc.  
This leaves one to wonder who is doing those things. And that brings us
back to the certain of the blacklists who were previously found to be
doing that sort of thing.  It is telling that those same people really,
really hate CAN-SPAM, and really, really hate any distinction between
genuine CBE and abuse that isn't actually commercial.





-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



<Prev in Thread] Current Thread [Next in Thread>