At 15:44 09-01-2009, Douglas Otis wrote:
It states that only _authenticated_ information should be included
within the "Authentication-Results" header for either Sender-ID or
SPF. At the same time, the draft defines Sender-ID and SPF as being
an authorization method and _not_ the authentication of the domain.
In fact, there is no way to know whether Sender-ID results were based
upon SPF version 1 records in its current form, or whether a domain
even intended positive results to affirm its identities, or whether
just negative results of a Mail From were intended to mitigate back-
scatter. This leaves the issue of authentication itself clearly in
the rough.
Section 1.5.2 of the draft explains why Sender-ID and SFP is
supported by this header field. In a nutshell, it's about using a
single header field instead of creating separate header fields for
each mechanism. According to the IESG Note in RFC 4406, Sender-ID
participants should consider the advice given in Section 3.4 of that
RFC to avoid the interoperability problem you mentioned.
It's nearly two years since these two specifications have been
published. If you believe that these two experiments are a failure,
then post your observations so that a decision can be taken. In my
opinion, this would be through a Sender-ID and SPF discussion and
not one about this header field.
In addition, there is also the matter of encouraging the use of
dangerous local-part macros when one wishes to obtain email-address
annotations. At least the Sender-ID specification states local-parts
are _not_ verified. What is providing the authorization remains
unknown for SPF, even though the local-part is ignored in Sender-ID.
In addition, there is no consensus between either Sender-ID or SPF as
to which elements of a message are to be used to access version 1
records. Clearly, scoping issues are also in the rough.
Section 2.4.3 of the draft covers SPF and Sender-ID Results. I don't
see any encouragement for the use of local-part macros in there.
The remedy being sought is to replace the local-part of the
"authorizing" email-address with a converted string representing the
IP address of the SMTP client that is being authorized. This allows
the authenticated origin of a message to be vetted, in addition to
what _might_ be an authorizing domain. A fair compromise.
Are there any implementations of the technique you are
suggesting? The feedback received from other implementors showed
that they neither use the above technique nor do they support your
point of view.
While there are influential proponents of this draft, this draft and
the experimental SPF and Sender-ID RFCs remain dangerous as written.
With a few minor modifications, the Authentication-Header draft would
become much safer. Satisfying those that represent influential
special interests should not cause the IETF to dismiss their
stewardship role. We all know there is money to made picking up the
pieces, but there are more productive ways to make a living.
Getting back to draft-otis-auth-header-sec-issues-00, Section 1 of
the document encourages blocking the SMTP client IP address instead
of blocking all mail from a domain. This can lead to more than one
domain being blocked when there are several domains hosted on the
same IP address.
In discussions on the mail-vet discuss mailing list, some of your
comments could, maybe erroneously, be interpreted as saying that the
proposed header field is a barrage of marketing efforts for Sender-ID
and SPF even though the proposal for the header field was spurred
during the Domainkeys and DKIM work. The proposed header field was
discussed at IETF 70 during the DKIM Working Group session [1]. If
there was any push to satisfy those that represent special interests,
I am not aware of it.
As for your concerns about the IESG (I gather that you meant IESG and
not IETF) stewardship role, I'll point to the fact that the IESG did
not rubber stamp the specification for the proposed header during
their evaluation. The record shows that they raised several
questions about it.
Regards,
-sm
1. http://www.ietf.org/proceedings/07dec/slides/dkim-0/dkim-0.ppt
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf