Subject: Re: [EAI] ASCII tunneling hack standardization

From: Shawn Steele <[email-masked]>
Date: Fri, 1 Aug 2014 07:01:52 +0000

That may work by accident in some cases, but we did run into some fields that are more strictly ASCII, or worse something that explicitly uses the 8th bit for something else, like Latin-1.  Then it could be messy if you can't tell what was being used, but the xn-- is sort-of safe (sure, someone's local part could be xn--fred, but that seems rare).

-Shawn

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 11:55 PM
To: Shawn Steele
Cc: [email-masked]; Mark Davis ☕️
Subject: Re: [EAI] ASCII tunneling hack standardization

I've had the same discussion, although not with you. But the result was a different one: just send UTF-8 even if the channel doesn't say that's OK. 
It'll either work or it won't.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 1 Aug 2014 13:57:26 +0200

I've read the document now (a word document! how quaint!) and don't see why 
this concerns the IETF. IETF's domain is interoperation with strangers on 
the internet, and this document concerns local storage or interfaces.

Arnt

---

From: Shawn Steele <[email-masked]>
Date: Fri, 1 Aug 2014 16:10:05 +0000

The thinking was that sometimes strangers want to know how local storage is managed, and that sometimes such slots 'leak'.

However, since this was written (I should've been clear that it's a hack), it has come to my attention that people intend to do fallback of the actually SMTP addresses on their systems.  We didn't permit that, but people are rolling their own.  (Eg: just sending the whole thing, including local part, through IDN ToAscii, which will be lossy for the local part).  I still don't think that wise, but if people are doing it anyway, then I'd rather see something like this.

A paragraph could be added to cover that case:   "You shouldn't use this to downgrade EAI SMTP, but if you feel you must, here's a common way to do it so there's a chance of success".

-Shawn

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Friday, August 1, 2014 4:57 AM
To: Shawn Steele
Cc: Mark Davis ☕️; [email-masked]
Subject: Re: [EAI] ASCII tunneling hack standardization

I've read the document now (a word document! how quaint!) and don't see why this concerns the IETF. IETF's domain is interoperation with strangers on the internet, and this document concerns local storage or interfaces.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Aug 2014 13:43:18 -0400

--On Friday, 01 August, 2014 07:01 +0000 Shawn Steele
<[email-masked]> wrote:

> That may work by accident in some cases, but we did run into
> some fields that are more strictly ASCII, or worse something
> that explicitly uses the 8th bit for something else, like
> Latin-1.  Then it could be messy if you can't tell what was
> being used, but the xn-- is sort-of safe (sure, someone's
> local part could be xn--fred, but that seems rare).

Based on some probing around years ago, maybe not quite as rare
as one expects.  It would cause security nightmares today
unless, e.g., signed in some way, but there used to be embedded
devices around for which the interface involved transmitting
commands over SMTP, making odd uses of forward-pointing
addresses so as to avoid needing to use (or even having) 822
headers.  The one I was involved with years ago used SEND rather
than RCPT, but so few MUAs ever figured that SEND/SAML/SOML
existed that RCTP was a useful choice.   

Now, one could contend that anyone who did that today would
deserve whatever happened to them, but I suspect some of the
relevant devices are still in operation.

And yes, before EAI or even IDNA came along, I did see some use
of just-send-8 addresses.  In part because of the timing, far
more of them were EBDCIC leakage through bad gateways or some
Latin-1 flavor than UTF-8.  If there were also non-Latin-script
examples around, I didn't encounter them but probably wouldn't
have.

I think that, if I somehow needed to do this, I'd go ahead and
treat the local-part as an encoded word.  That syntax isn't
completely safe against someone using the local part to encode
control information or the like either, but it is probably no
worse than xn--, xl--, or some other member of the regex(..\-\-)
family.   It has the advantage that almost every contemporary
MUA has code to recognize the construction (and hence produce
plausible error or warning messages if it don't want to deal
with it or is concerned about doing so).  The charset is also
explicit rather than involving the recipient in a guessing game.

YMMD.

     john

   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 1 Aug 2014 20:27:55 +0200

On Friday, August 1, 2014 7:43:18 PM CEST, John C Klensin wrote:
> treat the local-part as an encoded word.

I've seen that done in to/cc fields. For odd and unusual 7-bit rather than 
你好, but that shouldn't make any difference.

I should probably note that the contexts where I chose just-send-utf8 
weren't SMTP-related, but rather channels such as forwarding to |program.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Aug 2014 16:01:19 -0400

--On Friday, 01 August, 2014 20:27 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> I've seen that done in to/cc fields. For odd and unusual 7-bit
> rather than 你好, but that shouldn't make any difference.
> 
> I should probably note that the contexts where I chose
> just-send-utf8 weren't SMTP-related, but rather channels such
> as forwarding to |program.

Of course, the more local the context, the more likely you are
to know enough about what is going on to be able to make really
good guesses (or better) about the odds of bizarre
misinterpretation.   In particular, if you know that the local
environment is mostly UTF-8-compatible with no older 8-bit
charsets floating around, then a just-send-utf8 plan is a lot
more reasonable than it might be on the public network.

   john