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

[Franck Martin]

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.

On Jul 9, 2014, at 3:50 AM, Wietse Venema  wrote:

> Jiankang Yao:
>> 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?
> 
> 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.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[John R. Levine]

On Wed, 9 Jul 2014, Jiankang Yao wrote:
> 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?

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, jo...@iecc.com, 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

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

[Wietse Venema]

Jiankang Yao:
> 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?

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Jiankang Yao]

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

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

[Douglas Otis]

On 5/22/11 10:38 PM, John R. Levine wrote:
>> Specify MUST, but clarify that this is just for now and may be revisited
>> at a later time -- for example, if the SMTP protcol design community ever
>> backs down and accepts DJB's approach to the 8-bit message problem
>> (, essentially that it is OK to break
>> any remaining 7-bit enforcing servers).  They probably won't ever, but
>> just in case...
> If you were following the EAI work, you'd know that they probably will do
> that within the next couple of months, albeit with an SMTP flag so servers
> and clients can tell whether a hop is 8-bit UTF or legacy.  They
> specifically do NOT provide any downgrade mechanism -- if a path isn't EAI
> from end to end, the message can't be delivered.  (Please read the many
> years of archives of the EAI list, in which they tried every imaginable
> approach via many experimental RFCs and a lot of running code, before
> commenting on the wisdom of this approach.)
>
> I beseech this group to refrain from hypothetiecal guesses about what some
> of us might think would be a good idea to address some anticipated
> problem, even though nobody has tried it. It was a mistake in the mailing
> list so-called BCP, and it would be a mistake here.
>
> There will be DKIM signatures on EAI messages.  It is pretty obvious how
> to do it, and in the few corners where it's not obvious, we won't know the
> right answer any better than anyone else until we've tried it and seen
> what happens.
Agreed.

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

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

[John R. Levine]

> Specify MUST, but clarify that this is just for now and may be revisited
> at a later time -- for example, if the SMTP protcol design community ever
> backs down and accepts DJB's approach to the 8-bit message problem
> (, essentially that it is OK to break
> any remaining 7-bit enforcing servers).  They probably won't ever, but
> just in case...

If you were following the EAI work, you'd know that they probably will do 
that within the next couple of months, albeit with an SMTP flag so servers 
and clients can tell whether a hop is 8-bit UTF or legacy.  They 
specifically do NOT provide any downgrade mechanism -- if a path isn't EAI 
from end to end, the message can't be delivered.  (Please read the many 
years of archives of the EAI list, in which they tried every imaginable 
approach via many experimental RFCs and a lot of running code, before 
commenting on the wisdom of this approach.)

I beseech this group to refrain from hypothetiecal guesses about what some 
of us might think would be a good idea to address some anticipated 
problem, even though nobody has tried it. It was a mistake in the mailing 
list so-called BCP, and it would be a mistake here.

There will be DKIM signatures on EAI messages.  It is pretty obvious how 
to do it, and in the few corners where it's not obvious, we won't know the 
right answer any better than anyone else until we've tried it and seen 
what happens.

Regards,
John Levine, jo...@iecc.com, 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