Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>Valdis has identified some of the technical issues associated with using 
>POP3 in this way.


I have refuted all of Valdis's technical points so far.


>   Let me step back and look at your proposal from another 
>angle.


Yes I think that is productive to discuss the end game (outside of technical issues).


>>From the standpoint of the bulk mailer/ poster of material, there is no 
>advantage (and some disadvantages) of doing that posting so that interested 
>users can "pull" it relative to just posting the material on a web page 
>somewhere.   Functionally, what you have proposed seems, to me, to be 
>roughly equivalent to:
>
>	* distributors of bulk materials are required to post them on
>	selected web sites.


It is an acceptable analogy, except I disagree that bulk posters of material favor web post over POP post.  I think they favor what ever their receiver favors, by the law of supply and demand and economics.  If receivers find it more convenient to get a copy in their InBox, then that will be accomodated (just as with mailing lists and archives now).

But in terms of the analogy, I will follow along...


>	* non-bulk materials may continue to go out via 	conventional email.

Agreed.


>Nice plan.  The problem is that spammers won't play


Agreed.


> and efforts to coerce 
>them into playing will largely fail due to international issues, lack of 
>adequate incentives, etc.... exactly the same problem we have today with 
>state laws prohibiting spam.


Here is where I *strongly* disagree.

Let me start with a story.  The genesis for this proposal came from the fact that our outgoing business email (not bulk but single emails sending a password to a customer, etc) is being blacklisted by SPEWS (etc) because Rackspace (our Host) allowed some other customers of theirs to send spam on the same C class IP range as ours.  SPEWS then blacklists the entire C class.  Well SPEWS is uncorrectable lately because they've been under DoS attacks (from spammers presumably), thus caches of blacklists are used and nothing can be done except for us to change our email IP address.  So in discussing this with the AUP manager and her boss at Rackspace, it became clear that Rackspace would never be able to guarantee the quality of a C class range of IPs, because "Rackspace can not determine what is legitimate bulk email and what is spam and thus can not terminate new customers until a very heavy proof of spamming has already occured, by which time the damage to C class has already been done".

So the lesson learned was that if Rackspace could automatically detect high quantities of bulk email in real-time, then with my proposed architectual change, Rackspace could in real-time shut off the spammer.

Okay so that is one example of how the architectual paradigm changes the rules and allows more effective actions against spammers.

Now take for example legislative combined with ISP.  For right now, spammers are avoiding open relays and many foreign IPs because of blacklists, so they get a dialup account and send from there.  Well if there was a law requiring USA ISPs to detect and shut these off in real-time, then spammers would need to revert back to open relays and foreign IPs which are effectively dealt with using blacklists.  Then blacklists would not have to be so draconian with IP C ranges in countries with strict enforcement, which would make the blacklists more effective and useable.

Then take anti-spam software like the DCC, BrightMail, or even our AntiViotic.com.  If we know all bulk is bad, the game gets simpler because no whitelist needed.  Since whitelists are data that is forgeable by spammer, this closes another hole.  No to mention that whitelists make current anti-spam less useable and realistic on wide scale.

I could go on... but I hope you begin to see how everything to fight spam depends circularly on the ability to architectually define it.

If you can't measure it, you can't do any thing about it.  That is a fundamental datum of science.


>More generally, you have just defined an "opt in" model that assumes that 
>anyone who has not explicited opted to receive particular messages will be 
>able to get them (or be sent them) only be some overt action on the 
>would-be recipient's part.


That is the definition of opt-in.


>  We know from experience that such a model won't 
>work without significant legal pressure and enforcement -- if you don't 
>believe me, sample any reasonable quantity of spam for messages that claim, 
>quite strongly, that, if you hadn't opted in, you wouldn't be receiving it.


What you are saying IMO, is that you can't force bulk emailers or spammers to use opt-in.  That has been because you can't measure the spam (UBE) from the legitimate.

It is a chicken and egg problem.  Once you have the egg (the architectural metric), then reasonable to make the chicken.  So comparing to before you had the egg, is not necessarily illustrative.


>Sorry, but no cigar.

I am smoking it (figuratively) right now :)

Thanks for getting to the crux of the matter and allowing me to make it clear.

Shelby Moore
http://AntiViotic.com




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]