spf-discuss
[Top] [All Lists]

Re: New ideas for RFC2822 headers checking with SPF

2004-10-23 05:25:51

On Fri, 22 Oct 2004, Greg Connor wrote:

William-

Thanks for posting this.  I agree -- I would like to leave the door open 
for SPF2 to be able to do something in 2822 space.  (Not because I like PRA 
- I actually hate it -- but because I think domain owners will want to be 
able to control other uses of their domain)

Microsoft got one thing right - there are number of companies and people 
who want to stop phishing. They said that is their main "motivation" but
the way they go about it seems to indicate that is not and that was just
good excuse for trying to push proprietary solution to become a standard
even though they know its technically troublesome and politically directly 
again open-source software.
 
There was another idea that would allow SPF2 to cover other headers, and I 
think does so a bit more simply than eh=, though it is probably not 
compatible with SPF1 because it introduces a new macro.  The new macro is 
%{e} and expands to a keyword telling which header or identity is currently 
being checked.

For most domains, I believe the policy for From: or HELO or Sender: will be 
very similar to their policy for MAIL FROM, so probably most users will not 
have to change anything.  If for some reason the HELO policy is more 
restrictive, or the From: policy is less restrictive, or whatever, the 
domain owner can break out the %{e} macro and redirect to the appropriate 
record.

Macro requires new SPF protocol version to support it and also means you 
have to check header exactly as is instead of combination. As has been
discussed before making assertion for "From:" that it comes from certain
domain or making it by itself equivalent to MAIL FROM is easily possible
the number of errors would be too large.

Let me ask two questions to see if I'm on the same page as you are :)

1. Do we want to talk about v=spf1 or only about SPF2?

Your eh= proposed addition would be compatible with spf1 records, and is an 
opt-in affair, but it is still a code change (since no existing SPF parsers 
understand the modifier).  I am sensing an active and vocal segment of the 
list who don't want to mess with v=spf1 at all.

I think the way things are going, v=spf1 would stay for quite a bit longer
then SPF2 and in fact SPF2 may become an expansion of original concept with
new features that are all backwards compatible. That is exactly how I'd 
like it to be.
 
My position was (and still is) that we should check ANY or ALL headers and 
data items, but not in relation to one another.  That is, we should 
evaluate MAIL FROM by fetching the SPF info from the domain in MAIL FROM, 
and we should check the HELO against the domain in HELO, and From: against 
the domain given in From:, etc.

That position seems somewhat incompatible with UnifiedSPF concept which is 
that one identity can influence checks done on other identities and how its
combination that matters in decision if the mail is to be accepted or not.

I personally do not believe that its possible to enfore header checking 
based on single header, but the syntax provided will allow to make such
as assertion i.e. like that MAIL FROM should be equivalent to only one 
header (From:) if publisher believes that to be for all his email.
 
This was sort of the idea behind "unified spf" which I still think is a 
good idea.  Unified did not give any header more importance, or power to 
control other headers; it was just a way to check headers one at a time 
using the same process over and over. 

That is idea of scoping support for SPF (i.e. SPF records used for more
then just mail-from), but Unified SPF is in fact about making decision
based on combination of identities, making one identity dependent on
another especially if its close to current email practices is not bad.

             domain. IN TXT  "v=spf2 +mx +a +ptr  redirect=%{e}.spf.%{d}"
mailfrom.spf.domain. IN TXT  "v=spf2 +include:trustyisp.com 
?include:funkyisp.com ~all"
    helo.spf.domain. IN TXT  "v=spf2 -all"
    from.spf.domain. IN TXT  "v=spf2 +include:majordomo.spfaware.com ?all"
       *.spf.domain. IN TXT  "v=spf2 ?all"

I agree with Meng that we want to avoid having to make publisher have too 
many records. The more complex the system is the less likely the 
publishers to adopt it (in addition both publishers and recepients
would suffer from multiple dns lookups, number of lookups should be
kept to minimum for greater majority of cases). Redirects should be
avoided except with special circumstances. 

That is one of the reasons I never really liked scoping macro as the
only way to deal with records of multple scopes, although I'd like to 
have it as an option for those who really can use it (but that does 
require SPF2 which would allow for new syntax like that).
  
The main idea here is that I really do think that MOST domains will have 
the same policy for multiple headers (that is, a list of mailservers that 
they trust to some degree or another).

I don't think this is so, the email infrastructure has too many complexities
that do not make it possible to verify last-hop based on any single header.

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/