mail-vet-discuss
[Top] [All Lists]

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

2008-11-24 00:26:05
At 13:18 23-11-2008, Victor Duchovni wrote:
So, on the one hand, the draft strongly suggests that each MTA in a
multi-MTA environment should generate a unique (per-host) "authserv-id",
and suggests that MUAs somehow keep a current list of suitably trusted
MTAs. On the other hand as afterthought in "alternative solution" 4,
we see a reference to *the* "authserv-id" in use within and ADMD.

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 SHOULD is about having a unique identifier such as the hostname 
as the "authserv-id".  During the discussion of this I-D, it was 
pointed out that some operators prefer to have a "authserv-id" which 
is unique to their administrative domain.

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.

I am at a loss to see how one can in practice keep tens of thousands of
installed MUAs configured correctly with the full history of the trusted
MTA set.

That's a consideration to take into account during deployment.  The 
authserv-id is there for the MUA or mail filter to determine whether 
the header can be trusted (see Section 5 for a discussion of trust 
boundary).  If you have tens of thousands of MUAs which are going to 
use this header and you don't want to keep a full history of trusted 
MTA identifiers, you can select an identifier that is long lived 
instead of using FQDNs.  There's still the problem with long-ago 
delivered mail as the MUA may not have identified which authserv-id 
was valid at that time.  In such a case, the results from the header 
would be ignored.

At 17:51 23-11-2008, Murray S. Kucherawy wrote:
Are there any strong opinions about encouraging a single authserv-id
throughout an ADMD, or is the current language sufficient?

The reason for choosing FQDNs was because it would be easier for 
implementors to generate a unique identifier.  By using a single 
authserv-id throughout the administrative domain, we are loosening 
the requirement.  I'll err on the cautious side and leave it to the 
operator to decide based on their environment.

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>