Victor Duchovni 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.
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. Are there any strong opinions about encouraging a single authserv-id throughout an ADMD, or is the current language sufficient?
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?
Speaking of "Received" headers in C.4 the names of the "from <host>" and "by <host>" parts of the relevant Received header are accidentally reversed.
Good catch; fixed. Thanks! _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html