Re: [Asrg] 2 - Solving Spam By Establishing A Platform For Sender Accoun

Vernon Schryver wrote:

> > From: Matthew Elvey <matthew(_at_)elvey(_dot_)com>
> >    
> >
> > Boy, it seems like an increasing number of the posts I've seen since 
> > this list started come from posters who seem to be gravely misinformed 
> > or deliberately spreading misinformation. [...]
> > It seems like the discussion of the most promising proposals is 
> > exceedingly rare.  :-(
> >    
> We agree about some of that, but we may disagree about which is
> the information and which is the misinformation. [...]
>
> The most reasonable ASRG thread concerned Graylisting.  That report
> was of measured results from real code in the real world, unlike
> the white papers about RMX, consent, and the rest.
>
> Various spam filtering is done on at least 50% of all mailboxes.
> (Doesn't Brightmail claim 40%?)  If those filters are at least 50%
> effective, then more than 25% of all spam in the Internet is already
> being handled.  That's consistent with the reports of many that
> their personal spam loads are lower than they were years ago.  Many
> mailboxes are like mine, suffering an entirely tolerable load of
> spam of fewer than 1-4 spam/week.
Your <4/week number must be net (after applying good antispam measures, 
and not counting the spam folder you need to scan for false positives) 
or you are an  outlier.  Are you saying that the claims of Postini, 
Brightmail, Hotmail, (and a bunch of nanae posters) all showing that 
around half of email is spam are wrong?  (73%, 2/5, 80%, various, of all 
email, respectively, for their systems; URLs available; just ask here)
Your DCC seems to be a very good system, but it causes false positives, 
so you have to go through what it thinks is spam, (or bounce it) right?  
What are average DCC user false positive rates?  Do you think DCC alone 
is a solution that works well for now (like bayesian filtering), or one 
that will also work well in the long term without needing to participate 
in a continuing arms race?   I use SpamAssassin (not the latest version, 
and w/o custom weights, or SMTP-time 4xx/5xx bouncing unfortunately; my 
ISP isn't perfect; I've complained), and I get a couple dozen spam a day 
that have lower scores  than my non-spam.  I don't even know how much 
really spammy spam I get, because I delete or bounce it.  It's so much 
that I couldn't reasonably go through my spammy spam looking for false 
positives. That's not a tolerable load, IMO.  I should keep it for a few 
days to check.
> Contrast that fact with the positions of advocates for various silver
> bullets.  They talk as if public, long term mailboxes like mine must
> receive many spam/day and about stopping practically all of that spam
> with their wonderful solutions.  None advert to the fact that at least
> half of the field has alreading been taken by others who range from
> silent (e.g. Postini, and SpamPal) to practically silent (Brightmail
> and Cloudmark) to extremely quiet (SpamAssassin).[...]
What do you mean by silent?  That they silence the noise that is spam?  
I am skeptical that SpamPal (which is purely DNSRBL-based), today, is 
gonna eliminate all my spam, or work w/o a ton of false positives.  
"SpamPal will not be able to detect all of your spam. However, I think 
it will detect enough to make a considerable difference!" - the spampal 
site
BTW, what RBLs does SpamPal currently use by default?  Anyone?

>  
>
> > ...
> >                                     Result: the Internet is RMX ready 
> > for any domain that wishes to do so to roll out and have it be highly 
> > effective.  
> >    
> Effective in what way?  
Effective in preventing abuse 'from' their domain.

> The most commonly used sender domain names in
> spam are those of the free providers.  (My measurements on ~30K recent
> spam imply >40% of spam currently involves free provider sender
> domains.)  Please offer some evidence that the major free mail providers
> would go along any sort of RMX system. 
But having that evidence ahead of time is not a realistic possibility, 
even if RMX were a mathematically proven silver bullet (it's not a 
silver bullet at all, but it could be a component of a silver bullet, 
IMO).   They're not gonna come out in favor of this stuff ahead of time.
Hotmail and Yahoo are pro-spam (they are on record as opposing 
California's SB 12, which is going to be voted on tomorrow, BTW.)
They would only do so under pressure.  Pressure that would build, as 
email sent 'from' domains that don't implement RMX gets to be a 
progressively more reliable indicator of spam.  That pressure would 
largely come from their own users, whose email would be getting filtered 
because they hadn't implemented RMX.
> Outblaze is widely seen as
> one of the most anti-spam free providers.  Please point out the words
> in a web page (perhaps starting at http://outblaze.com/index.php )
> where the owners of the 30,000,000 Outblaze mailboxes are told to send
> only through Outblaze's servers.  Feel free to point out such words
> in Hotmail's, Yahoo's, or some other major free (or non-free) mail
> service provider's terms of service.
flamer.  chill.  Your tone is so unpleasant I'm tempted to just ignore 
you completely.  Tone it down if you want to continue the conversaion, 
please.
Ask Suresh yourself if he thinks Outblaze would be up for this.  
Outblaze ALREADY makes this difficult: any mail sent 'from' an outblaze 
account not through their servers that bounces gets filed in /dev/null.  
So I suspect they may be up for it.  Besides, there are a lot of major 
providers who utterly fail to enforce their TOS, such as Verio, so what 
TOS say or don't say is of little import.
>  
>
> >            Trying to get the majority of the world's MUA end users to 
> > upgrade is much more difficult, IMO.
> > I had cisco.com and some other major domains whitelisted for a while, 
> > but had to remove 'em due to repeated spam 'From' them. 
> > abuse@<trademark>.com seemed uninterested in pursuing abuse of their 
> > trademark.
> >    
> That's interesting when you think about it.  Please offer some evidence
> other than your personal assurances that Cisco would restrict employees
> from sending mail with cisco.com sender addresses from random locations
> including their homes, customer sites, hotels, and even airplanes in
> order to stop that abuse of their trademark.
Chill.  Any Cisco employee who is going to be connecting to the 'net for 
work will connect to cisco over a VPN from said random locations and 
would have full access to cisco SMTP servers.  Ok, so it's unlikely, but 
perhaps they can't send from cisco.com from their cellphones without 
some work (some cellphones support SMTP already, and probably some 
support smtp-auth as well).  It's unlikely, but perhaps a VPN or 
smtp-auth connection won't be practical from 30,000 feet.  If so, so 
their mail in these very rare cases comes from airline.dom or 
cellphonecompany.dom.  Big deal?
>  
>
> > ...
> >    
> >
> > > The issue is that people send mail "from" one domain while using the 
> > > mail servers of another.  This is done all the time for perfectly 
> > > legitimate reasons.  Not only is it done on an individual level, it is 
> > > also done regularly in mass commercial mailings (which are sent by one 
> > > company on behalf of another).  Using the "reply to" to authenticate 
> > > breaks all of that.  Yahoo users can only send mail using Yahoo's web 
> > > mail.  Macromedia can't send mail from "support(_at_)macromedia(_dot_)com" using 
> > > mx0's mail servers, and so on. 
> > >      
> > This capability is NOT broken with the RMX proposal.  Any legitimate 
> > users WILL be able to use the domain of their choice.  There are at 
> > least 3 ways yahoo users could continue to use their own servers in an 
> > RMX-compatible world.
> >    
> That is so wrong that it qualifies as what you called "misinformation."
> Why didn't you touch on those three ways Yahoo uses could use "their
> own servers"?  
Chill!
1)Yahoo doesn't implement RMX on its domain.  Anyone can still send 
'from' yahoo.com from any server.  This is the easiest solution.  RMX 
isn't mandatory for all domains, remember?  Or did you not actually read 
the proposal that you so harshly criticize?
2)They modify the 'to' addresses from user(_at_)example(_dot_)com to 
user(_at_)example(_dot_)com(_dot_)yahoo(_dot_)com, and yahoo resends it for them using the RMX- 
authorized servers, after checking that it's 'from' a yahoo user.  How 
good this check is  is up to yahoo*, and would impact their reputation 
if they employed this scheme.
3)People can ask/pay yahoo to list their servers.  (Ok, so this doesn't 
scale, but solutions 1 and 2 would work, realistically.  I think I had 
another scheme, but seem to have forgotten it.)
B)Of course Yahoo could also implement RMX on its domain and allow yahoo 
mail users to use an SMTP server they've set up, with security of their 
choice*.
*e.g. The security could be smtp-auth, or a variant of POP before SMTP, 
or allowing users to approve an SMTP server that can relay for them, or 
just a check on whether it's a valid user, or whatever.
> Was it because expecting users to adjust the DNS
> records for the IP addresses from which they are sending mail at
> the moment would sound so completely unrealistic?
Dammit, you're antagonistic.  It seems you don't understand the protocol 
at all (or at least the RFC I read).  How it normally works:  Nearly 
everyone sends mail through their ISP's SMTP server, whether that be an 
earthlink, or their employer.  It's the IP of that server that needs to 
be in the RMX records!  Not the user's IP.  If they're doing that, then 
there's some level of security on the SMTP server, allowing them to use 
it, or it's an open relay, and is already broken, as many servers are 
already blocking it for that reason.  So there are no DNS records for 
users to update!  Just the ISP admin, IF they want to protect their 
domain name from abuse, can CHOOSE to set it up, adjustments would be 
needed very infrequently. 

> Some RMX-like proposals require adjusting among the RRs of the SMTP
> client based on its IP address.  Those are merely grossly implausible.
> Other RMX-like proposals that use RRs in the envelope sender zone
> domain are worse, given the fact that free providers show no signs of
> objecting to their users sending from elsewhere.
>
>
>  
>
> > ...
> > In an RMX world, domain-based DNSRBLs can be highly effective, with low 
> > false positives and low false negatives.
> >    
> Domain and IP address based DNS based blacklists can be highly effective
> with quite low false positive and a usefully low false negative rates
> outside RMX worlds.
They're useful (especially with scoring systems like SpamAssassin), but 
standard IP based blocklists alone will never be highly accurate in 
terms of positives and negatives.
> The reason that there are so few domain based DNS blacklists is
> that the easy choices fairly static, and because the legal liabilities
> sound worse.
I think it's mainly because IP addresses can't be forged and domains 
can.  SpamPal doesn't support them yet, either. With RMX, domain-based 
blocklists can have much lower false rates than IP-based blocklists.  
Abuse desks and IP-based blocklists are better off as well, because an 
abuse desk can identify a joe-job/forged abuse report a bit more easily, 
and have more evidence to show it to be a forgery. 
A little work implementing RMX would allow a lot of abuse desk work to 
be eliminated.


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