[mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

[Victor Duchovni]

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.