Subject: Re: [ietf-dkim] EAI and 8bit downgrades

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 9 Jul 2014 13:56:15 +0800

Is there any RFC which deals with EAI DKIM ?
how to deal with EAI message in the DKIM?
Do we have a decision about it?

Jiankang Yao

From: Douglas Otis
Date: 2011-05-22 22:47
To: ietf-dkim
Subject: Re: [ietf-dkim] EAI and 8bit downgrades
On 5/22/11 10:38 PM, John R. Levine wrote:

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Wed, 9 Jul 2014 06:50:01 -0400 (EDT)

> Do we have a decision about it?

According to RFC 6530, in-transit downgrading of messages (described
in detail in RFC 5504) is eliminated from EAI. Downgrading to an
ASCII-only form may occur before or during the initial message
submission, or after the delivery to the final delivery MTA.

Thus, instead of being downgraded in-transit, mail is returned as
undeliverable.

	Wietse

---

From: "John R. Levine" <[email-masked]>
Date: 9 Jul 2014 18:04:42 -0400

> Do we have a decision about it?

We had a small amount of discussion but I don't recall any conclusions.

Signing an EAI message should work the same as signing a non-EAI message. 
I suppose we might have conventions for things like whether the d= domain 
is a A-labels or U-labels, but those are pretty minor.

As Wietse noted, EAI no longer does any downgrading in transit, so that't 
not an issue.  Even if it did, DKIM decided long ago not to deal with it, 
and if people recoded, say, quoted-printable into base64, that would break 
the signature.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Wed, 9 Jul 2014 22:53:38 +0000

DKIM deals only with domains, so as long as you can convert the d= to puny code if needed, then you are fine…

I would also suggest that d= should contains only puny code (ASCII), i= could be problematic, you may want to ensure it does not have a local part in your implementation (e.g. i=@example.com)

If you use authentication-results header, for the DKIM part, the header.d= should be puny code too.