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