Subject: [EAI] Mail to legacy servers

From: Shawn Steele <[email-masked]>
Date: Thu, 8 Mar 2012 16:51:30 +0000

WRT the downgrade stuff, I had an accidental experiment that was somewhat interesting.  Someone sent a link to a server that has a partial implementation.  Sent as a UTF8 mail to a non-UTF8 aware server, the mail shouldn’t have been setn, but it was.  It ended up being received with a ??????? local part (one ? for each UTF-8 byte).  Clearly I wasn’t able to reply to it.  OTOH, I *did* receive the mail, which is better than never getting a mail.  Presumably, if it were important, I could find a different reply route. (pick up the phone).  Mail implementations might find that behavior worth considering.  If everything else fails, it violates the standard, but if the mail gets through maybe it’s better than nothing?…

-Shawn

 
http://blogs.msdn.com/shawnste

---

From: SM <[email-masked]>
Date: Thu, 08 Mar 2012 09:36:24 -0800

Hi Shawn,
At 08:51 08-03-2012, Shawn Steele wrote:
>a mail.  Presumably, if it were important, I 
>could find a different reply route. (pick up the 
>phone).  Mail implementations might find that 
>behavior worth considering.  If everything else 
>fails, it violates the standard, but if the mail 
>gets through maybe it's better than nothing?…

If something is important, the question of 
violating the standard would be less 
important.   At the end of the day, it is about 
getting the message which the recipients wants to read through.

Regards,
-sm

---

From: Shawn Steele <[email-masked]>
Date: Thu, 8 Mar 2012 17:54:40 +0000

I was sort of thinking that a mail client could choose to do something like this.  (I'm not necessarily advocating for it, more along the lines of "Neither snow nor rain nor heat nor ASCII-only..." thinking).

A) Try SMTPUTF8 route.  
B) If not available, see if it can be resent using ASCII addresses.  (Eg: if the user has registered such an address).
C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses.

B & C become harder (impossible) if you start having multiple hops.

-Shawn

-----Original Message-----
From: SM [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 9:36 AM
To: Shawn Steele
Cc: [email-masked]
Subject: Re: [EAI] Mail to legacy servers

Hi Shawn,
At 08:51 08-03-2012, Shawn Steele wrote:
>a mail.  Presumably, if it were important, I could find a different 
>reply route. (pick up the phone).  Mail implementations might find that 
>behavior worth considering.  If everything else fails, it violates the 
>standard, but if the mail gets through maybe it's better than nothing?...

If something is important, the question of violating the standard would be less 
important.   At the end of the day, it is about 
getting the message which the recipients wants to read through.

Regards,
-sm

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Mar 2012 19:43:34 +0100

Code can do many things, but RFCs cannot say "ignore what RFCs say", so this kind if thing is really not very interesting in the context of this WG.

Arnt

---

From: SM <[email-masked]>
Date: Thu, 08 Mar 2012 11:05:35 -0800

Hi Shawn,
At 09:54 08-03-2012, Shawn Steele wrote:
>I was sort of thinking that a mail client could choose to do 
>something like this.  (I'm not necessarily advocating for it, more 
>along the lines of "Neither snow nor rain nor heat nor 
>ASCII-only..." thinking).
>
>A) Try SMTPUTF8 route.
>B) If not available, see if it can be resent using ASCII 
>addresses.  (Eg: if the user has registered such an address).

(c) is like throwing a bottle in the ocean. :-)  From a specification 
perspective, we might consider (c) as an option which is undefined; 
we don't have any basis to say that it will work.  From an 
operational perspective, we found out that it worked once or more.

I would look this in terms of whether the average user should choose 
to do (c).  It's easier to say no.

Regards,
-sm

---

From: Shawn Steele <[email-masked]>
Date: Thu, 8 Mar 2012 19:13:52 +0000

I don't think it's a spec thing at all, more of a potential implementation curiousity.

-----Original Message-----
From: SM [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 11:06 AM
To: Shawn Steele
Cc: [email-masked]
Subject: RE: [EAI] Mail to legacy servers

Hi Shawn,
At 09:54 08-03-2012, Shawn Steele wrote:
>I was sort of thinking that a mail client could choose to do something 
>like this.  (I'm not necessarily advocating for it, more along the 
>lines of "Neither snow nor rain nor heat nor ASCII-only..." thinking).
>
>A) Try SMTPUTF8 route.
>B) If not available, see if it can be resent using ASCII addresses.  
>(Eg: if the user has registered such an address).

(c) is like throwing a bottle in the ocean. :-)  From a specification perspective, we might consider (c) as an option which is undefined; we don't have any basis to say that it will work.  From an operational perspective, we found out that it worked once or more.

I would look this in terms of whether the average user should choose to do (c).  It's easier to say no.

Regards,
-sm

---

From: [email-masked]
Date: Fri, 09 Mar 2012 08:55:30 -0800 (PST)

> (c) is like throwing a bottle in the ocean. :-) 

Actually, it's more like poking a stick into a wood chipper.

For example, if the EAI stuff shows up in the outer header, there are two
possible outcomes for sites using our software, depending on configuration
settings: (a) The message will be bounced as invalid or (b) It will be
delivered but all of the EAI stuff in the main header will depending on it's
location, be removed or encoded (and if it is encoded it may or may not be
marked as utf-8).

As for EAI stuff appearing in inner headers, that again depends on
configuration settings. In most cases option (b) above will probably apply.

We don't tolerate invalid crap in the outer header. Period. Too many clients
are known to barf on it. And that's a support call generator. Our customers
really don't like support calls.

And modifying messages so the client won't barf but the addresses are trashed
doesn't generate nearly as many calls. For better or worse, people are used to
funky crap showing up in headers. As long as they can get at the content - and
nothing in the modifications we perform will affect that - they generally don't
call. In fact it's the other way around: If utf-8 appears in a Content-type
field, clients may not handle that well and encoding it may actually prevent a
support call.

All this also applies to submission as well as delivery, BTW.

Of course this may change if EAI gets widely deployed. If we see a need we may,
and I emphasize MAY, provide an option to promote an EAI message that isn't
marked as such to EAI status. But any such option is years away from being
implemented, let along deployed, and besides, there's a bit of a
chicken-and-egg problem here, isn't there?

> From a specification
> we don't have any basis to say that it will work.

See above. There actually a pretty good basis to believe it's a bad idea, just
like just-send-8 was a bad idea 20 years ago.

> From an

> to do (c).  It's easier to say no.

Well, that's another thing. It won't be up to the user. The overwhelming
majority of users don't run their own MSA or MTA, and don't have any control
over whether or not any of this happens. So the question really is "what will
mainstream clients and other mail software do"? I think the days of the brash
"I'll do what I please and standards be damned" software developers being in
control are pretty much over.

				Ned

---

From: Joseph Yee <[email-masked]>
Date: Wed, 14 Mar 2012 02:37:26 -0400

> B & C become harder (impossible) if you start having multiple hops.

Other than C (and others replied about C), RFC6531 section 3.2 covered part of it, with different wordings/terminology where it's more of MSA than mail client.  I had a feeling that you say mail client, but not meaning MUA literally.

Joseph

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima