Re: possibilities for 2822 (was SPF implementations)

Stuart D. Gathman wrote:
> On Wed, 17 Aug 2005, Seth Goodman wrote:
>
>
> > The only things we've lost by insisting that the From: or Sender: domain
> > matches the MAIL FROM domain is one anonymizing mechanism and a clear chain
> > of remailing events in the rare case that intervening MUA's or MTA's
> > actually support this.  We still have the Received: headers, so the path
> > information is not lost.  In a time when we have to authenticate the origin
> > of messages in order to assign responsibility for abusive behavior,
> > trivially achieved anonymity may be a necessary casualty.
>
> This is actually a good idea.  It could be called 'Sender-ID Lite'.
> By matching only domain, MAIL FROM signing techniques continue
> to work.  I would suggest that MTAs should not reject based on From/Sender
> domain not matching MAIL FROM, but that MUAs should simply highlight 
> a From or Sender that doesn't match with "POSSIBLY FORGED" warnings.
> If MUAs don't do that, an MTA could add "[POSSIBLY FORGED]" to the Subject,
> or otherwise flag the mail without rejecting it in a manner visible via
> the MUAs behind it.
>
> Question: do we require an *exact* domain match?  What about 
> MAIL FROM <foo(_at_)mx1(_dot_)bar(_dot_)com> and From: <baz(_at_)bar(_dot_)com>?
> I will start doing your proposed check in pymilter and logging possible
> forgeries.  This should give us an idea of how feasible it is.
I had been thinking along these lines too.  The problem is that any 
proper mailing list will fail this test.
While Mail From: checking and how it works is pretty well a done deal, 
we still have the potential to add new modifiers to SPF records in order 
to deal with new situations.
IIRC, Mail From == From ~ 80% of the time and so if you've checked one, 
you've checked the other.
Most of the legit messages out of the remaining 20% are from mailing 
lists.  I'm interested in input on other legit sources.  The question is 
how to deal with this 20%.
One chunk of illegit messages in the 20% are phishers who use one Mail 
From to get past SPF and another From: to pretend to be somebody.
Now it seems to me that the exact domains the are primary phishing 
targets (e.g. ebay, paypal, banks) are exactly the ones the don't really 
care if their messages survive mailing lists.
So my thought is that if we have a message that has survived our SPF 
checking and we go to data, we check to see if From: == Mail From:.  If 
it does, cool.  If not, we have to decided what to do....
So I'm thinking that we invent a new modifier called 'from='.  BTW, I 
think someone else has suggested this before, so I make no claim of 
originality here.  The idea is that you look for an SPF record in the 
domain of the From:.  If there is no record or if it's a regular SPF 
record, then you move on.  If the record has a 'From=' modifier in it, 
then we know that the domain owner has made a statement that only 
messages that have a Mail From: == From: are legit.  I would limit this 
to the domain part since that's what SPF is designed to do.
This would give an easy method for domain owners to opt in to message 
body checks based on their SPF records that is limited to high value 
phishing targets.  We avoid all the SID complexity by declaring that we 
don't WANT to survive all the manipulations that SID is meant to survive 
(but doesn't).
It seems to me that this would be a simple way to extend SPF to provide 
some anti-phising benfits without all of the complexity of SID or DKIM.
Comments?

Scott K