ietf-asrg
[Top] [All Lists]

Re: [Asrg] Economic model is borken. (sic.) Let's fix it

2003-03-07 14:09:27
On Fri, 7 Mar 2003, Kee Hinckley wrote:

At 11:40 PM -0800 3/6/03, Nate W wrote:
 > But fundamentally whitelisting fails without authentication.

Fails occasionally, and would be greatly improved without authentication,

It fails occasionally only because whitelisting is not widely used. 
Use it widely and the spammers will adapt.  I just had to reply to 
someone's damn challenge response system on this list.  

It may have been mine, and (if the message above is any indication) it was
probably because you addressed a reply directly to me (or whoever) while
CCing the list.  Sending replies to the list alone would make more sense,
but that's neither here nor there.

This may be optimistic, but I don't think spammers will adapt to
widespread whitelisting.  They'll try, but they'll fail.  Maintaining
"Millions" CDs of address pairs (recipient and a whitelisted sender known
to work for that recipient) is a big job.  First there's the problem of
finding a whitelisted address that actually works.  Then there's the fact
that a single spam gets through, the address pair ceases to work.  
Two-Millions CDs might get popular, but they won't make much difference in
the amount of spam actually seen by whitelist users.

Sending spam with a customized address in the "From" header of every
single outgoing message requires much more bandwidth than the usual relay
hijack approach of sending a single message with many enevelope
recipients.  It does happen now, but AFAICT it's unusual, I assume because
it requires enough bandwidth to get noticed and stopped.  I'm curious
about this though, if anyone has evidence to the contrary I'm all ears.

(Note that I see whitelisting as a way to address the problem of time
wasted by recipients.  It does not solve the bandwidth-waste problem, in
fact I acknowledge that it makes that problem worse.)

Any spammer wanting to hit people on this list need only browse the
archive, construct a list of who spoke to whom, and spam away.

That assumes that there's a lot of off-list conversation going on among
the list members.  Having an autoresponder&whitelist setup reduces that a
bit. :-)

Having usable addresses posted in mailing list archives strikes me as an
exceptionally bad idea, though.  It's rather ironic that an anti-spam
group would create such a resource for spammers.  There's plenty of ways
around this problem.

But the point is, and I think a large number of people have already
made it on this list, that solutions that require changing the MUA are
less likely to gain acceptance than systems at the MTA level.

True, but I doubt that there will be an effective MTA-level solution.  
The information the MTA has to work with just isn't enough to make a
reliable decision about consent. (Not to mention the number of MTAs
controlled or hijacked by spammers.)  We have DNSBLs and the like, and I
think that's about as far as MTA-only solutions will get.  Adding
information for the MTA to base the consent decision upon will require
changing the MUA at one end or the other.

I'd love to believe that there's an MTA-only solution out there, but it
seems to me that the MTAs don't have access to enough information to solve
this problem.  But again, I'd like to be persuaded to believe otherwise.

1. Initially ISPs only block bulk email that doesn't match the 
authorized domain standard.

Sounds like an authenticated MTA-based whitelist.  I like it.

2. Over time as companies move to protect their domains (and that is 
the incentive--protecting yourself from forgery), they can (or 
individuals can) block based on domain or personal authentication 
even for non-bulk email.  Note that at this point there is still no 
MUA change required unless you are sending email from a location 
other than one authorized by your domain.

How does one block email based on sender authentication information
without adding authentication information to the message with an
MUA?  Perhaps I misunderstand; please elaborate.

I think that meets the necessary requirements of placing changes in 
the locations where they are most likely to be made, and providing 
for a gradual path to greater and greater security.

What I don't know in that model, is how we deal with malicious ISPs.

I like that model a lot.  Two ideas come to mind for dealing with losers:

Revoke their certificates.  How this is accomplished is left as an
exercise for the reader.

Require member ISPs to join with a contract stating that they will:

a) pay cleanup costs associated with spam from their domain;
 
b) pay extra for their membership, with the extra cost paying for
 spam-control infrastructure;

c) pay all costs associated with legally persuing individuals or
organizations who send spam through that ISP (this should encourage the
ISP to create and enforce strict terms of service for their customers);

d) put a deposit in escrow upon joining, to be refunded if they
leave the origanization on good terms, to be forfeited it to pay for
expenses as above.  This would be an obstacle to smaller ISPs though so
I'm not real fond of this one.

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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