On Dec 3, 2008, at 8:08 PM, Scott Kitterman wrote:
On Wednesday 03 December 2008 20:13, Douglas Otis wrote:
Stating Sender-ID or SPF as the method applied does not
sufficiently define the scope of the path registration. There was
never an agreement reached as to the scope of the SPF record. The
authentication-results header fails to return an implied or
expressed scope statement that may have been deduced from the path
registration records, or that remains in an unknown state. Without
an implied or expressed scope, a process can not know what an
authorizing domain intended to ensure, the MailFrom or the PRA.
Just in case anyone else is confused by this (I was the first
several times I read it), this is not about anything in the draft.
+------------+----------+--------+----------------
+--------------------+
| Method | Defined | ptype | property |
value |
+------------+----------+--------+----------------
+--------------------+
| senderid | RFC4406 | header | name of header | value of
header |
| | | | field used by | field used by
PRA |
| | | | PRA | with comments
and |
| | | | | local-part
removed |
+------------+----------+--------+----------------
+--------------------+
| spf | RFC4408 | smtp | mailfrom | envelope
sender |
| | | | | with local-
part |
| | | | |
removed |
| | +--------+----------------
+--------------------+
| | | smtp | helo | HELO/EHLO
value |
+------------+----------+--------+----------------
+--------------------+
The relevant scopes used for obtaining the result are included in
the auth-result header. I was afraid he was saying they were not
(and that would be a significant problem, IMO).
You have missed the point about overstating authorization as
authentication. The danger is in regard to what can be safely assumed
of proprietary restrictions imposed upon PRAs, or those imposed upon
MailFroms.
Per RFC 4406 section 3 SPF 2.0 Records:
,---
Domains declare which hosts are and are not authorized to transmit e-
mail messages on their behalf by publishing Sender Policy Framework
(SPF) records in the Domain Name System. [RFC4408] defines a format
for these records identified by the version prefix "v=spf1". This
section defines an amended format, identified by the version prefix
"spf2.0", that allows sending domains to explicitly specify how their
records should be interpreted, and provides for additional
extensibility. Sending domains MAY publish either or both formats.
'--
Per RFC 4408 IESG note:
,---
Participants relying on Sender ID experiment DNS records are warned
that they may lose valid messages in this set of circumstances.
Participants publishing SPF experiment DNS records should consider the
advice given in section 3.4 of RFC 4406 and may wish to publish both
v=spf1 and spf2.0 records to avoid the conflict.
'---
Per RFC 4406 section 3.4 Compatibility
,---
Administrators who have already published "v=spf1" records SHOULD
review these records to determine whether they are also valid for use
with PRA checks. 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 4408 section 3.1 Publishing
,---
Domain owners wishing to be SPF compliant must publish SPF records for
the hosts that are used in the "MAIL FROM" and "HELO" identities.
'---
In other words, RFC 4406's defined scope is proclaimed by the IESG to
trump that of RFC 4408. This means _any_ SPF can be assumed to
support PRA authorizations! Many will be surprised by this assumption.
People will be harmed by confidence artists exploiting this draft's
header that misleads recipients into seeing an authorization as being
an authentication check. Many senders have failed to impose
necessary, and likely impractical, restrictions needed to prevent the
many avenues of access that would be able to exploit the deception
made possible by this header!
What prevents the inclusion of the SMTP client IP address, other than
providers not wanting this essential identifier of theirs included?
This IP address is the essential element authorized by either Sender-
ID or SPF. By including this IP address, MUA plugins and recipients
will be able to check the reputation of the IP address, in addition to
that of a vast and likely nebulous domain.
As IP address space becomes more complex with a growing amalgam of
IPv4 and IPv6 address space that must be listed as path registration,
together with the prevalence of compromised systems, any reliance upon
path authorizations is likely to lead to disaster. There is a
practical safety measure missing from this header. Those responsible
for allowing an exploit, or for having an compromised system, will not
have been identified by this deceptive header. The header fails to
capture the SMTP client IP address when assessing path registration,
and there is no sure means in which to determine the culpable entity.
Unchanged, this draft will indeed be a boon for both confidence
artists, and vendors selling pathway protections. This draft will also
be a stain on the IETF and the IESG.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html