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