(if this doesn't belong on this list, please let me know) RFC 4871 states:
> h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to > allowing all algorithms). A colon-separated list of hash > algorithms that might be used. Signers and Verifiers MUST > support the "sha256" hash algorithm. Verifiers MUST also support > the "sha1" hash algorithm. We have a DKIM-signed mail stream that is "passing" with Receiver1 but failing with Receiver2 and it's Receiver2 who has a "new" interpretation of the requirement above. Here are the two interpretations, please let me know which is generally considered correct (of if both are wrong): Interpretation #1: The sender must support both, but doesn't need to use both. It could be h=sha1, h=sha256, h=sha1:sha256, or h=*. The receiver however MUST support either. Therefore the receiver should be not fail verification just because the explicit tag in the DNS record says "h=sha1" instead of the "h=sha1:sha256" which is expected. Interpretation #2: The sender must support both, which means the sender must either not have an h= tag in the DNS record (defaulting to h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore the sender should adjust their public key records vs. the receiver adjusting their infrastructure to verify "h=sha1" (btw, this is for messages that contain "a=rsa-sha1" in the DKIM-Signature header). I may have provided both too much and too little information, but this is the interoperability problem we are facing at the moment. Comments? Many thanks! -- Brett _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
