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 <lear(_at_)klapsmühle(_dot_)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?<lear(_at_)klapsm=FChle(_dot_)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