At 17:52 19/01/2009 Monday, Alessandro Vesely wrote:
<snip>
I agree v=spf3 will annoy many hostmasters, but I see no other recipe
to unilaterally resolve the observed conflict, namely that rfc4406
attaches the unintended "pra" scope-id to version v=spf1.
However, we might avoid doubling the data. I expand on this in my next
message...
I agree with an adendum {my own observations ;) }
for this i'm excluding softfail and neutral as only discussing {to my mind}
important edge cases
first off between spf and sender-id there are 3 scopes
1 helo
2 mfrom
3 pra
1-2 spf 2-3 sender-id
for helo records now a simple pass/fail should be the only ever required
response
{but as many have both helo and mfrom for the one domain an additional "doesn't
exist anywhere" would be nice}
for mfrom in an ideal {everyone runs SRS} world it will only require pass/fail
but as ideal world not here it would be useful to have pass/fail/dosn't-exist
for pra even in an SRS only world many may have to go with neutral, but in
theory it also would be
nice to differentiate between fail-policy and address-dosn't exist
this edge case being domains where they use an existing spf of say
example.com txt "v=spfv1 redirect=%{l}._spf1.example.com"
example.com txt "v=spfv2 redirect=%{l}._spf2.example.com"
and then say has spf for each user that exists
example._spf1.example.com txt "v=spfv1 ptr:example.com include:gmail.com -ALL"
; note also allows gmails and example.com to forge helo of
"example._spf1.example.com" which is sub-optimal {but unlikely in this case due
to _ }
example._spf2.example.com txt "v=spfv2/mfrom ptr:example.com -ALL"
example._spf2.example.com txt "v=spfv2/pra ptr:example.com ?ALL"
;{example dosn't like pra and thus discourages}
and a
*._spf1.example.com txt "v=spfv1 -ALL"
*._spf2.example.com txt "v=spfv2 -ALL"
thus if example(_at_)example(_dot_)com sends an email via a non-SRS forwarder
to an isp that dosn't allow its users to whitelist their forwarders {gmx.de
springs to mind}
it is indistinguishable from an email with totalybogus(_at_)example(_dot_)com
{by return code}
now i propose if we were to combine into an spfv3 we would add the additional
limited use #/*/! or any other appropriate character for an extra return code
of "absolutly forgery" for use in the edge cases of
*._spf1.example.com txt "v=spfv3 #ALL"
and for ones like
www.example.com txt "v=spfv3 #ALL"
but adopt some of the granularity of multiple txt records in sender-id
so mx10.example.com can have
mx10.example.com txt "v=spfv3/helo A -ALL"
mx10.example.com txt "v=spfv3/mfrom,pra #ALL"
assuming it sends bounces from postmaster(_at_)example(_dot_)com {thus no valid
addresses in @mx10... domain}
and example.com can be
example.com txt "v=spfv3/helo #ALL"
example.com txt "v=spfv3/mfrom,pra redirect=%{l}._spf3.example.com"
additionally it doesn't seem to break any sender-id or spf-v1 client i have
tested so should be easy to early-deploy
and think the unifying of the 2 will make it faster to roll out to all those
currently having to deal with both
obviously use of the # with any exceptions placed previously breaks the point
so should cause a syntax error if pre-ceeded by anything other than redirects
in the chain
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com