On Sun, Nov 23, 2008 at 05:51:03PM -0800, Murray S. Kucherawy wrote:
Is there a consensus about whether the "authserv-id" is a single id for
the whole ADMD, or a unique id for each MTA? If not, why the SHOULD in
Section 2.3?
The current draft simultaneously reflects current common practices and
enables other scenarios.
The SHOULD in 2.3 enables easy tracing, just like using the MTA's
hostname in a Received: header field. However, if an ADMD finds it
easier to use a single domain name throughout its organization, perhaps
for simplicity of MUA configuration, that is also supported.
Another variant I've seen in the wild is of the form "hostname/jobid",
so that two mail filters on the same machine are aware of each other's
addition of the header field and can filter or ignore accordingly. The
grammar deliberately allows this and variants like it.
I am concerned that making things easy for the MTA is at significant
expense to the MUA, and that a practical standard must first and
foremost be reasonably implementable on MUAs, and only then be not
unduly taxing on MTAs. Encouraging "authserv-id" diversity in MTAs
will I believe make scalable MUA deployment difficult. The draft SHOULD
IMHO encourage MTA developers and administrators to implement a single
ADMD-wide "authserv-id", leaving MTAs to judge its authenticity based
on a suitable trust mechanism between MTA client and MTA server.
If the "alternative 4" is just a hypothetical scenario, and uniqueness
per-MTA is to be taken seriously, it should be noted that only will MUAs
need to compare the "authserv-id" against the current list of active MTAs
in an ADMD, but when reading long-ago delivered mail, MUAs will need to
known which MTAs were trusted at the time the message was in transit.
Interesting point. It seems that a single universal authserv-id for the
ADMD makes sense in that scenario.
This and the problem of timely updates of disconnected MUAs, really
makes managing a dynamic list of trusted "authserv-id" values difficult.
Are there any strong opinions about encouraging a single authserv-id
throughout an ADMD, or is the current language sufficient?
In my view, the current language strongly encourages per-host values,
which I believe don't scale.
While we are looking at the above excerpts, it should I think be made
clear the "Authentication-Result" should go not *only* above headers
received from the previous hop, but also above locally added "Received:"
headers, and in 8.1 "alternative 5" the phrase "adjacent to" should be
"above".
Can you elaborate as to why?
In 8.1 "alternative 5" talks about expecting "Authentication-Result"
"adjacent to" the locally added Received header, but this makes its origin
ambiguous: was it prepended by the origin MTA or the Receiving MTA. Also,
if don't use hostnames in "authserv-id", it is again difficult to tell
which host added it, unless it occurs predictably above the "Received:"
header added by the same host. Once that's done, the diagnostic rationale
for using the hostname and not a site identifier gone, which is I believe
a good thing.
--
Viktor.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html