Subject: Re: [EAI] [dmarc-ietf] I18ndir last call review of draft-ietf-dmarc-eaiauth-03

From: Martin J. Dürst <[email-masked]>
Date: Wed, 20 Mar 2019 03:09:09 +0000

Hello John,

Thanks for your followup to the I18N directorate's review of your draft.

Copying the EAI mailing list, since they might have some ideas.

On 2019/03/20 05:57, John Levine wrote:
> In article <[email-masked]> you write:
> 
> Here's a terminology question.
> 
>> "Since a policy record can
>>     be used for both internationalized and conventional mail, those
>>     addresses still have to be conventional addresses, not
>>     internationalized addresses."
>> ->
>> "Since a policy record can
>>     be used for both internationalized and conventional mail, those
>>     addresses still have to be ASCII-only addresses, not
>>     internationalized addresses."
>> (We don't want to give the impression that addresses with non-ASCII characters
>> are non-conventional.)
> 
> What do we call mail that's not EAI mail?

Maybe just that, 'non-EAI mail'? Or something like "mail that needs the 
SMTPUTF8 extension for transmission"? Or "mail with non-ASCII addresses"?

> It's not ASCII mail, since
> non-EAI messages can contain any character sets you want in the
> message body.

And in comments in headers, if properly encoded.

> Some people call it legacy mail which seems kind of jumping the gun.

I wish we could use that term, but I agree it's a bit early. Also, even 
if it were appropriate now, it's not precise enough.

Regards,   Martin.

---

From: "John R Levine" <[email-masked]>
Date: 19 Mar 2019 23:14:13 -0400

> SMTPUTF8 extension for transmission"? Or "mail with non-ASCII addresses"?

Non-EAI seems simple enough.

>> It's not ASCII mail, since non-EAI messages can contain any character 
>> sets you want in the message body.

> And in comments in headers, if properly encoded.

With 8BITMIME, which is supported by pretty much every MTA in the world, 
UTF-8 message bodies don't need to be encoded.  They can include literal 
UTF-8 or any other character set that interprets ASCII CR/LF as CR/LF.

I have an updated version of the draft, will post it once the window 
reopens.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 20 Mar 2019 04:17:44 +0000

> UTF-8 or any other character set that interprets ASCII CR/LF as CR/LF.

Yes, I know of course.

> I have an updated version of the draft, will post it once the window 

Great, looking forward to it.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 22 Mar 2019 00:15:10 +0000

Hello John, others,

Just a small followup. [removing the [email-masked] mailing list]

>> With 8BITMIME, which is supported by pretty much every MTA in the 
>> world, UTF-8 message bodies don't need to be encoded.  They can 
>> include literal UTF-8 or any other character set that interprets ASCII 
>> CR/LF as CR/LF.
> 
> Yes, I know of course.

By chance, I needed to look at the source of some of my mails, and 
discovered that they used
Content-Transfer-Encoding: base64
for content that's simply
Content-Type: text/plain; charset="utf-8"

This happens even if it's just a mail to myself. It may be a setting on 
my side (in Thunderbird on Windows, but I don't remember any such 
setting). It happens even if the actual mail body is US-ASCII only. Any 
explanations, anybody?

Regards,   Martin.

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2019 22:03:53 -0400

> setting). It happens even if the actual mail body is US-ASCII only. Any 

Thunderbird on my Mac sends unencoded 8bit UTF-8.  So it's likely some 
local setting but I have no idea where to look.

Regards,