Dave Crocker wrote:
Folks,
The overview document states that it is seeking Informational RFC
status. Further, it does not include the usual citation and statement
that normative vocabulary is used to assert normative requirements.
I'd say that this is a poor idea as it becomes rather unclear who is
authoritative
when you have potential conflicts as in:
sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary
+ SHOULD deploy abuse filtering measures on the inbound mail,
and
+ MAY remove all signatures that will be broken
and RFC4871 which sez:
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified.
I really don't see why we should be setting ourselves
up for this kind of conflict.
To my mind, this document has been ever chomping at the
bit to be a BCP. I'm all in favor of a BCP, but only when
we really know those B's, C's, and P's are. Inserting
new normative language about how one should use DKIM beyond
what's in 4871 seems rather premature to me.
Mike
and
2.5.3.3. Boundary Enforcement
In order for an assessment module to trust the information it
receives about verification (e.g., Authentication-Results headers),
it MUST eliminate verification information originating from outside
the ADMD in which the assessment mechanism operates. As a matter of
This seems anomalous and raises a line of questions:
If the apparently normative statements are actually trying to be
normative and are reasonable, has the intent of the document changed?
Even though I've written some portion of the language in the
document, I have mixed feelings about this issue. Some of the
apparently-normative statements I like and some I don't -- and I don't
know which ones I wrote, so that's not the issue.
Beyond being a summary of DKIM, the document also has become
something of a higher-level "system specification". As such, some of
the normative language really pertains to the higher-level integration
of DKIM into an operational email service and well could be extremely
useful for guiding design, implementation and deployment of DKIM. I
think that's a good thing, but I think we need to resolve whether this
document is making architectural, normative specification or whether
it is providing tutorial exemplars.
Unfortunately I don't think this can be resolved by a simple assertion
of an underlying principle.
I think we need to look at the actual language in the document and
decide what is important for the current work.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html