On Jun 22, 2009, at 1:13 PM, Dotzero wrote:
Doug,
I'd take your discussions of SPF more seriously if you would stop
conflating SPF and Sender-ID. They are two different animals. SPF
(the specification) does not include anything called PRA. Sender-ID
includes the concept of PRA. PRA is broken in the spec so there
isn't any purpose in spending time discussing it. All one needs to
do is look at the paragraph that states that if a sender field
exists you set the PRA to that. This bypasses any SPF record
published for the Mail From (envelope sender) domain. End of
discussion.
The SPF (RFC 4408) lacks a means to constrain the scope of
authorization records to just Mail-From. Sender-ID (RFC 4406) section
3 allows SPF (RFC 4408) records to authorize MTAs based upon PRA
headers, and perhaps failing that, upon the Mail-From parameter. RFC
4406 section 3.1 modifies RFC 4408 versioning and adds a scope
parameter. Per RFC 4406 section 3.4, the unmodified SPF record is to
be considered the same as spf2.0/mfrom,pra. :^(
Section 3.4 of RFC 4406 also states:
,---
If the information in a "v=spf1" record is not correct for a PRA
check, administrators SHOULD publish either an "spf2.0/pra" record
with correct information or an "spf2.0/pra ?all" record indicating
that the result of a PRA check is explicitly inconclusive.
'---
Per RFC 4406, when PRA authorization fails, an attempt to verify Mail-
From authorization might be attempted. When only RFC 4408 has been
relied upon, the Mail-From domain may inadvertently offer
authorization based upon PRA headers. In this case, how SPF records
are used is uncontrolled. From an overhead standpoint, RFC 4406
potentially doubles the overhead related to SPF record resolution.
Although RFC 4406 recommends against use of MTAs that "lie" about
local-parts, it failed to exclude macro use, or to consider what
happens when providers do not restrict the use of domains in
originating headers, in addition to the use of local-parts.
Email would have likely faired much better by recommending immediate
rejection, use of RFC 3464, and minimal DSN content with"multipart/
report" content types.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg