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.
Nonetheless, the document has quite a number of apparently normative
statements -- including some in uppercase -- such as:
2.2. Email Infrastructure Agents
It is expected that the most common venue for a DKIM implementation
will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA.
...
Outbound: An MSA or Outbound MTA should allow for the automatic
verification of the MTA configuration such that the MTA can
...
An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps
...
Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the
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
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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html