[ietf-dkim] ISSUE: dkim-overview -- normative statements
Bill.Oxley at cox.com
Bill.Oxley at cox.com
Sun Jul 15 08:50:01 PDT 2007
Its not a conflict, the document in question states an intermediate MTA MAY remove broken sigs. The RFC states "Signers SHOULD NOT remove any DKIM-Signature header" an intermediate MTA may or may not be a signer, its not the issue being addressed
From: ietf-dkim-bounces at mipassoc.org on behalf of Michael Thomas
Sent: Sun 7/15/2007 1:42 AM
To: dcrocker at bbiw.net
Cc: ietf-dkim at mipassoc.org
Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements
Dave Crocker wrote:
> 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
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,
>> + 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.
>> 18.104.22.168. 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.
NOTE WELL: This list operates according to
More information about the ietf-dkim