Re: New ideas for RFC2822 headers checking with SPF

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)
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.

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.
My thought is that v=spf1 (Classic) works fine for MAIL FROM and HELO and 
we will probably get some resistance if we try to apply it to other things. 
Let me assume for the purposes of this message that we are talking about 
v=spf2 records and leaving v=spf1 alone.

2. Do we want to relate headers to each other, or consider each one alone?

One of the reasons I objected to PRA loudly and often in MARID was that it 
was not really an identity - it was a made-up value that chose a certain 
header, if it appeared in the correct order, etc.
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.
I would rather not see us associate one header with another, which is I 
think where you were trying to go with the "d"/"l" operands.  I don't want 
to check Sender: to see if it is permitted by the From: domain or MAIL FROM 
domain, or anything.  I want to check Sender: against only the Sender: 
domain.  I think trying to relate multiple headers together and make one 
"control" the others leads to more complexity without adding much value.
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.  You may of course use the same 
domain in multiple headers, but if two headers have different domains, they 
would be checked one at a time against different SPF records.  Does that 
make sense?

If we are mostly on the same page with regard to 1 and 2 above, then 
consider the %{e} scope macro.  An example might look like this.  (I am 
using v=spf2 on purpose here so I don't get yelled at by the hardcore 
classic people ;)
            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"

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).  For MOST domains, we will just 
check whatever headers we want, as long as we are checking them against the 
right domain.
(The mailfrom line also includes one way to deal with the HARDPASS issue... 
I feel that a PASS should always mean "this is coming from a server we 
trust not to abuse our name".  If you have to use comcast cable but don't 
trust their outgoing server to check AUTH, don't give them a + and use a 
?include instead.  That means "the mail coming from comcast might be from 
me but check it against other tests anyway".  We should reserve + for 
situations where we trust the sending server not to spoof our domain, and 
we should complain loudly to our service providers if they don't do AUTH 
checking against the return address.)
Let me know what you think?

gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>