-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Tuesday, April 19, 2011 12:56 PM
To: DKIM
Subject: [ietf-dkim] Issue: Repeated headers
Yes indeed. We discussed lots of wording for all of this, and the one that
has got into the document is about the worst.
Where is your proposed alternate text? Complaining without it isn't especially
helpful during a WGLC.
It is Absolutely Pointless to check for minor infringements of 5233 et al,
and so to say that implementors SHOULD check for some "reasonable" subset
of infringements is ridiculous, unless you spell out what "reasonable"
really implies. Now AFAICS, minor infringements in the format of
particular headers etc, "naughty" as they might be, have no impact on
DKIM. The "naughtiness" will be signed, so you can see whether it was
present at signature time, if you happen to care about it.
I believe the added text adequately addresses this problem, especially the new
Section 8.15. I also believe that the chair has said we have rough consensus
on this point.
So if we are going to have normative language (such as SHOULD or MUST),
then let us address it to the known problem, rather than to some vague
"reasonable" test that might lead people to waste time on things that are
not broken, and omit the one case that is broken.
We do have normative language, in 3.8. And the text in 8.15 makes it clear
what the attack is, and therefore what the "reasonable" defenses are.
1. What exactly do we really REALLY want implementors to do in this
matter.?
I believe Sections 3.8 and 8.15 make this clear to anyone that's designing and
implementing software in this area.
2. Is it to be a SHOULD or a MUST?
Given the RFC2119 definition, I think we've appropriately settled on SHOULD.
I don't want to re-hash all the arguments. What we have is a compromise
between two hard-argued positions, and I think reopening it now will just drag
everything out even longer.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html