Hi Dave, > > Maybe other folk are tracking this, but I'm now confused. > > DKIM does not affect other email header-fields, other than doing a > hash on them. For example, DKIM has nothing to do with any of the > address fields, whereas I believe that is EAI's focus. > > Since DKIM has /lots/ to do with a domain name (in d=, most > importantly), it really does have to pay attention to IDNA. But I am > not understanding how DKIM relates to the EAI work. > > Eliot, can you clarify?
Certainly. In a nut shell, the problem is at the implementation end between the MUA and the signer. The common signers out there will only do so for certain domains, and they will generally only do so, based on the From: line. Here is where the confusion sets in. If an MUA sees an address, such as the following: From: Eliot Lear <l...@klapsmühle.ch> What is the right conversion? In the 7-bit world, you might see something like the following: From: Eliot Lear =?iso-8859-1?Q?<l...@klapsm=fchle.ch>?= When the signer sees this, it could upgrade to get klapsmühle.ch, and then check the punycode version of that. Things get more confused in EAI, because there 8-bit MIME floating around. If you sign 8-bit MIME and a downgrade occurs, the game is over, and the signature is invalidated. But suppose you instead decide to downgrade first. You may not be able to downgrade, according to the RFC 5504. If an implementation cannot downgrade it must return an error to the user. In practice, this will mean that your MTA in the middle must do the downgrade, adding Downgraded headers, and rewriting various others before handing the message to DKIM for signing. Some clarification here would at the very least be useful. Perhaps this is as much an update to RFC 5585 as anything else. A clear warning that the domain found in the From: line may not appear in punycode seems like good advice, if nothing else. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
