John L wrote:
Having had some experience(bad) with what the definition of unique
is, lets attach the domain to the unique identifier so clearly it
will be in all cases unique.
Something similar to the rules for generating a Message-ID should do
the trick, the name can be arbitrary so long as it's in a domain you
control.
I think we're in violent agreement here.
I think the consensus is that: it must contain somehow the name of the
domain that you control and it must be unique within that domain.
The difference between this and what's expressed in the draft is that
the above it has the *form* of an FQDN (ala message IDs) rather than
actually *being* an FQDN.
Suggested text is below.
Tony Hansen
tony(_at_)att(_dot_)com
Change to section 2:
The decommented value of the header consists of an authentication
identifier, some whitespace, ...
New section somewhere:
Authentication Identifier fields
Every Authentication-Results header MUST have an Authentication
Identifier field, which is a single result identifier. The
authentication result identifier (auth-res-id) is similar in syntax to a
fully qualified domain name.
auth-res-id = dot-atom-text
where dot-atom-text is defined RFC2822.
The authentication results identifier field provides a unique
identifier that refers to the authentication checking service within a
given mail administrative domain. The uniqueness of the authentication
results identifier is guaranteed by the mail administrative domain that
generates it and must pertain to exactly that one mail administrative
domain. This identifier is intended to be machine readable and not
necessarily meaningful to humans. The mail administrative domain's
unique domain name MUST be used as the last portion of the
authentication results identifier.
Examples of valid authentication results identifiers are
mail.example.org, engineering.example.edu, and ms1.newyork.example.org.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html