On 08/Nov/10 10:20, Barry Leiba wrote: > As participant: > [...] > Proposal: > > 1. The DKIM spec is responsible for describing the problem in terms of > how it relates to signed and unsigned versions of the fields. That's > the stuff in 8.14.
+1. IMHO, 8.14 may avoid giving any advice, if we are unable to agree on any. However, in such case, I'd recommend to take Julian's suggestion[1] of replacing "Comments" with "From" in the note that exemplifies the "ugly hack". [1] http://mipassoc.org/pipermail/ietf-dkim/2010q4/014683.html > 2. The DKIM spec should probably say that signers need to sign valid > messages, and, therefore, SHOULD NOT sign things like this. Text > along the line of this might work well: > "Signers SHOULD take reasonable steps to ensure > that the messages they're signing are valid according to [RFC 5322, > etc]." Leaving the definition of "reasonable" out allows flexibility. It > may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. Perhaps this is an issue about MTA configuration, rather than specifically for the signing module. For example, I'm quite happy that such tweaking occurs before signing, so that the signer signs the revised version. However, since also the verifying filter is invoked after any optional modifications, I've had to enable them for MSA only. > 3. It'd be reasonable for the DKIM spec to remind verifiers that > signers aren't supposed to sign stuff like this, so they might > consider that when deciding what to do with it after verification. > It'd be reasonable to remind them of this particular case. But > I think that all ought to be informative text. This is again a question of roles. John has (correctly) recommended that verifiers don't tamper with the message content, except for possibly adding an A-R field. However, a DKIM verifier does not /have/ to act as a verifier only. An additional role is the umbrella under which a filter module may discard suspicious messages, suppress unsigned singleton fields that occur more than once, or anything it deems cool. I agree it should be informative, w.r.t. DKIM. > 4. We should agree to this or some variant of it, and then move on. > This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, > if I had my full choice. But it takes care of the problem in a way > that I think is sufficient, and allows us to resolve the issue. +1. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
