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