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.
---
Not including this additional requirement removes recipient assurances a
sender may have expected to be offered by DKIM. Without this additional
requirement, confidence in DKIM can be lost when injected From headers
are both displayed and used to make incorrect folder placements. ADSP
or ISP imposed acceptance criteria for likely phished originators can be
easily foiled by this tactic upon which a recipient may depend.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html