Michael Deutschmann wrote:
On Fri, 16 Oct 2009, Ian Eiloart wrote:
(Incidentally, anyone have a better name for this policy?)
"dkim=all" If you read ADSP in conjunction with section 3.1 of RFC 5016,
then "dkim=all" means exactly that: "Domain Alice provides information that
it signs all outgoing mail, but places no expectation on whether it will
arrive with an intact first party signature."
You're endorsing the Thomas interpretation, here.
I'd just note that the following, from RFC 5617, section B.1:
# In this situation, it might be appropriate to publish an ADSP record
# for the domain containing "all", depending on whether the users also
# send mail through other paths that do not apply an Author Domain
# Signature. Such paths could include MTAs at hotels or hotspot
# networks used by travelling users, web sites that provide "mail an
# article" features, user messages sent through mailing lists, or
# third-party mail clients that support multiple user identities.
... seems to endorse the Levine interpretation. "user messages sent
through mailing lists" is explicitly listed as a contraindication to
an "all" policy.
But whatever, we may need a straw poll followed by a clarification RFC,
to settle once and for all whether Levine or Thomas is canon.
My leaning is that Levine is more faithful to the RFCs as published, but
Thomas would be more useful. I favor my "except-mlist" as a third option,
allowing us to gain the benefits of Thomas while yielding to Levine.
I believe it is important to note the evolution of this, as least as I
lived it:
What you call as Thomas's Interpretation based on a SSP model that had
clear and direct semantics about 3d party signatures. RFC 4686
(Threat Analysis) and RFC 5016 (SSP Requirements) included consensus
on discussions regarding optimization, DNS scalability and threat
entry point resolutions.
I can surmise this with the following key point which was a heated
debate but one that everyone on all sides compromised on:
The only time POLICY is important is when a 1st party fails
(including lack of 1st party signature)
The consensus was to codify in RFC 4686 Thread Analysis and in RFC
5016 SSP Requirements in section 5.3 item 9:
5.3. Practice and Expectation Requirements
9. SSP MUST NOT be required to be invoked if a valid first party
signature is found.
Refs: Deployment Consideration, Section 4.2.
You have to understand the importance of this from an implementation
standpoint. The goal here was to help prevent redundant SSP lookups
first before DKIM was evaluated. This conflicted with implementation
ideas that allowed for POLICY to be looked up at all times. The DSAP
proposal was based on the existence of SSP related policies that
included 3rd party considerations.
If you check the archives, there was deep discussions surrounding this
point.
The issue then and what continues today is HOW do we authorized 3rd
party signers in an optimized, scaled fashion. This is where we could
not agree with ideas on the table.
So when SSP was taken over by John and replaced ADSP, its intent was
to 100% removed the 3rd party considerations and make it only a 1st
party policy protocol.
But as I stated the moment ADSP was introduced in January 2008, (check
the archives):
With ADSP, many of the consensus developed with RFC 4686 and
5017 are not invalidated or in conflict.
From my perspective, Levine really meant only ADSP is for 1st party
signatures and domains who are not going to be part of mailing list,
etc. The believe was that it target market is so low, that it wouldn't
be used and more importantly it would not interfere with 3rd party
signers. Check the archive, he clearly say this in more ways than one.
All I am been saying is that ADSP and the promotion to not use it
conflicts with the written RFC developed over the 3-4 years
specifically addressing 1st vs 3rd party considerations.
So if you go back to RFC 5016 section 5.3. item 9, with the item that
ADSP replaces SSP,
9. ADSP MUST NOT be required to be invoked if a valid first party
signature is found.
You have a framework that allows implementators to support ADSP when
they are is no valid 1st party signature.
All the above is the essence of the issue we have before us from my
POV. Its my opinion as an long time and active participant in WG.
ADSP removed years of discussion and work that help mold the RC 4686
threat analysis and RFC 5016 guidelines regarding SSP/ADSP.
Finally, the Deployment Guide (RFC pending) came later. It didn't
even bother to mention SSP in its first draft. That changed with WG
notes (namely by me). Its current rendition is a total revamp of the
original and now has detail information about ADSP. I don't think I
would be off base that by design, it was left open ended to not tie
section 6.1/7.4 (ADSP) and 6.5 (Forwarders) together.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html