Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

[SM <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf