ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue: Repeated headers

2011-04-25 13:40:34
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles 
Lindsey
Sent: Monday, April 25, 2011 3:46 AM
To: DKIM
Subject: Re: [ietf-dkim] Issue: Repeated headers

Well the message I was replying to contained a wording from Doug. But here
is my suggestion for 3.8:

3.8.  Input Requirements

    DKIM's design is predicated on valid input.  Therefore, signers and
    verifiers SHOULD (?MUST?) ensure that the messages they are processing
    are valid, at least to the extent that no header field occurs more than
    once where such is forbidden by [RFC5322], [RFC2045], or any other
    relevant message format standards.  See Sections 8.14 and 8.15 for
    additional discussion and references.

Essentially, that replaces "reasonable steps" by "at least <doing the
duplicate header check>". It also adds a reference to 8.14.

The chair has declared this particular topic closed, so I defer to him about 
this proposal.

My understanding (as a WG chair, though not of this WG) is that the 
presentation of working group consensus is presumed to have taken technical 
facts into account, so the assertion of a "Hard Technical Fact" does not 
automatically trump working group consensus.

Besides, there is no debate about what the attack is.  The issue is whether or 
not this is the right place to make normative assertions about how to deal with 
it.  The text we have now is a compromise between two hard-fought views of the 
answer to that question.  It is a path forward, and (as one of the antagonists 
of that debate) I think it quite reasonable.

There is much duplication and confusion between 8.14.and 8.15 (e.g. the
technique of using "h= ... from:from: ..." is described in both, though it
is only really applicable to 8,15. So here are some proposals:
[...]

Those all look okay to me, and as they're largely editorial I'll include them 
in the next version unless someone objects.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html