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 thanks, Bill
-----Original Message----- From: [EMAIL PROTECTED] on behalf of Michael Thomas Sent: Sun 7/15/2007 1:42 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
