Re: when spoofing isn't

On 3/19/2004 10:37 AM, Gordon Fecyk sent forth electrons to convey:

> From: "PHB" Hallam-Baker, Phillip
>  
>
> > Mark wrote:
> >    
> >
> > > I agree completely.  I'm firmly on the side of "let's not 
> > > break things."
> > >      
> > I don't think that there is much value in envelope from[2] alone. It has
> > to be matched to either an accreditation or to one of the 
> > other headers _that_the_user_will_see[1]
> >    
I agree.  I would like to hear from draft writers (none of whom 
addressed this issue in their drafts but probably spent a bunch of time 
thinking about it) whether they put this off to deal with later/in a 
different spec, or whether they felt it was undoable.
> There are a whole mess of content filtering issues arising from going beyond
> the RFC 2821 envelope previously stated.
>  
I believe we must tackle them.  Previously stated on this list, or 
where?  Did anyone make a list that appeared to be pretty comprehensive?
If all we aim to achieve by this work is to eliminate bounces due to 
email forged to come from us, then I regret my efforts to move LMAP et. 
al. forward.
We must do more.

> Who was over from AOL that commented they could possibly be banned from
> filtering on content by certain governments?  That, costs of running said
> accreditations and an unwillingless to pay for said accreditation, mailing
> lists that use different envelopes than headers as Dave pointed out, are all
> liabilities caused by going beyond the RFC 2821 envelope.
>  
I don't give a shit about hearsay that unnamed gov'ts are allegedly 
considering shooting themselves in the foot.  I remember hearing a rumor 
that the US Congress was going to pass a strong anti-spam bill.  

> I have to agree with Dave that matching RFC2821 envelopes to RFC2822 headers
> is better off in the hands of the user, as in the final recipient of a
> message.  
Yes, but:

> I would not want pan-am.ca as a domain doing this, but I'd show my
> users how to do this.
>  
I think you _would_ be happy with a sieve script on pan-am.ca that you 
wrote doing this!  I have a sieve script on fastmail.fm that does 
roughly what I want it to do.  I can't make it refuse spam instead of 
accept and then bounce it, so I wrote what will soon be 
<http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt> 
(-00 is out, already).  It doesn't support SPF yet, but it will soon, 
and it does support SpamAssassin, and all the things that implies - RHS 
lists, reputation services, etc.
> [1] <mantra>I won't say it, it's too easy.</mantra>
>
> [2] Be specific. Do you mean the RFC 2821 envelope MAIL FROM: ?
>  
It's clear to me that he does.

***

In the messages below (from smtp-verify), Alan and Meng defend LMAP.  My 
view:
John's cost-benefit analysis is correct.  He's saying that if all LMAP 
does is prevent a small subset of forgeries, specificially the bounces 
that those forgeries currently cause, then it's not worth it.  And he's 
right!  **BUT** LMAP can accomplish more than that, AND we need to talk 
more about how, and get it in the specifications!  [PHB's outline looks 
good to me.]
First of all, we shouldn't pretend that reputation services (blacklists 
and whitelists, free and otherwise) won't be part of the solution, or 
that scoring systems (like SpamAssassin) won't be part of the solution.  
They must be.  With this in mind, LMAP can accomplish a lot.  We should 
be talking about this now, figuring out if/how we are tightening the 
noose tight enough to strangle all the spammers.  IP Blacklists already 
do a very good job with IPs that send nothing but spam.  IP whitelists 
haven't really caught on much, but they can do a good job too, to help 
tighten the noose a bit further.  Blacklists have done only a fair job 
with "grey" IPs that send spam and ham.  Fair isn't good enough.
1) LMAP can take a big chunk of the mail from these grey IPs and 
classify it as ham.  This chunk would be the P2P mail where the header 
From: is the same as the envelope FROM and is LMAP authorized, and the 
domain is not in a RHSBL (right hand side blacklist) that lists domains 
with LMAP records that spam, and is in RHSWL that says how long its been 
registered and sending mail (something SpamCop/Senderbase do), and it's 
not new.
2) LMAP can take a big chunk of the mail from these grey IPs and 
classify it as spam. This would be the stuff that's specifically 
unauthorized by LMAP.
3)For most users, the remaining chunk will go into a suspect/grey mail 
folder that senders will not want their email going into.  They will 
come under increasing pressure to get with the program.
The fact that 1) is leaving much less ham in the grey mail folder will 
mean that spam score threshold can be much more agressive!  This will 
improve filter accuracy dramatically.
Let's enumerate the categories of email that are still left in the grey 
area, and discuss how to move as much of it as possible into the very 
likely spam or very likely ham buckets.
On 2/27/2004 11:14 PM, Meng Weng Wong sent forth electrons to convey:

> On Sat, Feb 28, 2004 at 02:24:37AM -0000, John Levine wrote:
> | 
> | I would argue that the biggest weakness of all the LMAP systems is
> | that the domain they test, the one in the envelope bounce address,
> | isn't one that means anything to recipients.  If I were a bad guy, I'd
> | register some throwaway domains, or I'd forge some badly managed
> | third-world domains with no LMAP data, use them in the bounce address
> | to pass LMAP checks, and forge like crazy in the From: and Sender:
> | lines that people see.
>
> That's fine by me as long as I stop getting the bounce messages.
What an idiotic thing to say!

On 2/28/2004 7:29 AM, Alan DeKok sent forth electrons to convey:

> John Levine <johnl(_at_)iecc(_dot_)com> wrote:
>  
>
> > If I were a bad guy, I'd register some throwaway domains, or I'd
> > forge some badly managed third-world domains with no LMAP data, use
> > them in the bounce address to pass LMAP checks, and forge like crazy
> > in the From: and Sender: lines that people see.
>  There are many ways of getting around the problem of forged LMAP
> entries.
>
>  
>
> > The first problem is the biggest, whether preventing envelope forgery
> > will in practice deter spammers.  If not, the whole LMAP exercise is
> > pointless.
> >    
>
>  There is no magic bullet.  
>
>  But I don't see people doing cost/benefit analysis. 
>  
I do.

>  Can we please agree that there is no one perfect magic bullet, and
> stop wasting our time denigrating solutions because they're *not* the
> magic bullet?
>  
I think you misread John's comments completely.  Looked like 
constructive criticism to me.
>  Alan DeKok.
>  
--Matthew Elvey