Murray S. Kucherawy wrote:
Dave CROCKER wrote:
Folks should be explicit about making and documenting this choice:
Is the information being provided about DKIM or about a validated
domain
name?
We want to validate the domain name. How that's done is less important,
although choosing something easily adopted is certainly preferable.
I hope the latter statement represents group consensus.
As for the former, I suspect, strictly speaking, this mailing list is about
reporting the results of validation, rather than actually doing it...
Rather than being petty nit-picking, I think it's important to use language
that
accurately and precisely states where this mechanism is in a processing
sequence
and what exact function it is performing (and why).
That DKIM seems the most obvious approach doesn't mean it's the only
one, or that it's the one this draft needs to recommend as a SHOULD.
Reality forces once to acknowledge that there are other domain name validation
methods widely extant. I doubt there is any good technical or operational
reason to exclude them. Rather, I suspect there are good operational reasons
to
*in*clude them.
I'd be fine being generic and saying the administrator has to find some
way to secure that channel. In fact, I think that's where we are now.
However, I suspect there are as many ways to do that as there are e-mail
architectures out there. Thus, saying the channel SHOULD be secured and
then simply suggesting DKIM as one way to do so would be sufficient for me.
+1
The remark about not complicating mail systems any further seems to be
where I'm focusing. Given that any participant in this system will need
to know which MTAs it can trust, any solution will have that problem to
solve. I don't think any of the proposed solutions I've seen are more
complicated than the next. So how do we go about picking one?
I think this is a question of defining and labeling trust boundaries and
deciding how to use them for this mechanism.
This is about the authserv-id field, isn't it?
The discussion in 2.3 probably needs to be a bit more precise and extensive. I
suspect that "refers to the authenticating service" is not quite right, while
"identifier is guaranteed by the mail administrative domain that generates it"
is, albeit without making clear that this means it defines a trust domain.
The current document pretty much starts with the notation and build up to an
explanation of semantics. I'm wondering whether there should not, in addition,
be an earlier discussion of the trust environment that permits operating this
mechanism. (I think the DKIM lacked this sort of service definition and that
we
have sometimes been hindered by confusion resulting from the lack.) While the
very first sentence of the Introduction sets the stage for the mechanism, I
think the rest of the scenery needs more explication than is provided.
--->
The Authentication-Results header fields permits a domain name validation
mechanism to communicate its output to a separate domain name reputation
(assessment) mechanism. These mechanisms MUST operate within a unified trust
boundary that defines an Administrative Management Domain (ADMD). An ADMD
contains one or more entities that perform validation and generate the field
and
one or more that consume it for some type of assessment. The field contains no
integrity or validation mechanism of its own, so its presence must be trusted
implicitly. Hence, use of the field depends upon ensuring that mail entering
the ADMD and having versions of the field claiming to be valid within this
domain removed, so that occurrences of such fields can be trusted by consumers.
The authserv-id can be used to label an entire ADMD or a specific validation
engine within an ADMD. Choice of labeling schemes is left as an operational
choice.
<---
I also suggest reviewing the document for opportunities to assert normative
requirements in normative language.
For example:
" The uniqueness of the identifier is
guaranteed"
is -> MUST be
"Additional result codes (extension results) may be defined"
may -> might
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html