On Sat, 16 Apr 2011 01:05:02 +0100, Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org>
wrote:
http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8
,---
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322
<http://tools.ietf.org/html/rfc5322>], [RFC2045
<http://tools.ietf.org/html/rfc2045>], and
any other relevant message format standards. See Section 8.15
<http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15>
for
additional discussion and references.
'---
Should change to:
---
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322
<http://tools.ietf.org/html/rfc5322>], [RFC2045
<http://tools.ietf.org/html/rfc2045>], and
any other relevant message format standards. See Section 8.15
<http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15>
for
additional discussion and references. In addition, verifiers MUST
ensure the presence of multiple singleton originating header fields
do not provide a valid signature result.
Yes indeed. We discussed lots of wording for all of this, and the one that
has got into the document is about the worst.
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.
But there is just ONE breach of 5322 (so far as we know) that is serious
enough to break DKIM completely. And that is repeated headers that should
not be repeated. A number of scams involving repeated From headers have
been described, and one can well imagine there may be scams with repeating
Subject, Content-Type, Message-ID and whatever else (and if you are going
to catch one, then catching the others with the same code has negligible
additional cost).
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.
Moreover, when it comes to a choice between SHOULD and MUST, the narrower
the test you are asking for, the easier it is to justify a MUST wording.
So there are just two questions to ask:
1. What exactly do we really REALLY want implementors to do in this
matter.?
2. Is it to be a SHOULD or a MUST?
Note that I have escalated this to as Issue. DKIM is broken if we do not
get this right.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html