Subject: [EAI] SMTPUTF8 for non EAI messages

From: John Bucy <[email-masked]>
Date: Tue, 24 Mar 2015 17:16:30 -0700

This is a spillover from a discussion on dmarc@
http://www.ietf.org/mail-archive/web/dmarc/current/msg02239.html

Has the wg considered the case of using SMTPUTF8 as a means to avoid
2047/2231 encoding for messages that don't contain any eai addresses? I
understand eai avoids downgrading since it doesn't really work for
addr-spec but it seems like it should be harmless for places where
encoded-word is allowed along the lines of the "gateway transformation"
described in 6152.

cheers
john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 25 Mar 2015 08:58:20 +0100

A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only 
about to the formal grammar. Just like for 822 mail, just a From and a Date 
field is enough. Subject, message-id, body text, all those things are 
optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and 
the first 3-4 paragraphs of 6532 section 3.

The restriction is rather a practical one: If you're sending from an ASCII 
address to an ASCII address, then restricting yourself to all-SMTPUTF8 
paths is chancy. Too chancy to bother with, IMO, since MIME encoders and 
parsers are ubiquitous.

Arnt

---

From: John Bucy <[email-masked]>
Date: Wed, 25 Mar 2015 12:45:58 -0700

On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen <[email-masked]
> wrote:

> paths is chancy. Too chancy to bother with, IMO, since MIME encoders and
Well, what I was more interested in is how do people feel about
downgrade/gateway-transformation in cases not involving addr-spec, where
the result is within the bounds of 2047 that pre-eai MUAs already expect to
receive. As far as I can tell, the EAI RFCs don't speak to this directly
- 6530 says roughly "there's really no good way to downgrade addr spec so
we don't do it"
- 6531 says a non-msa relay SHOULD reject/bounce if the next hop doesn't
support SMTPUTF8

---

From: Franck Martin <[email-masked]>
Date: Wed, 25 Mar 2015 19:59:55 +0000

On Mar 25, 2015, at 12:45 PM, John Bucy <[email-masked]> wrote:

> 
> On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only about to the formal grammar. Just like for 822 mail, just a From and a Date field is enough. Subject, message-id, body text, all those things are optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and the first 3-4 paragraphs of 6532 section 3.
> 
> The restriction is rather a practical one: If you're sending from an ASCII address to an ASCII address, then restricting yourself to all-SMTPUTF8 paths is chancy. Too chancy to bother with, IMO, since MIME encoders and parsers are ubiquitous.
> 
> 
> Well, what I was more interested in is how do people feel about downgrade/gateway-transformation in cases not involving addr-spec, where the result is within the bounds of 2047 that pre-eai MUAs already expect to receive. As far as I can tell, the EAI RFCs don't speak to this directly
> - 6530 says roughly "there's really no good way to downgrade addr spec so we don't do it"
> - 6531 says a non-msa relay SHOULD reject/bounce if the next hop doesn't support SMTPUTF8
> 

It seems fine for the MSA portion of your mail server to convert the message to have it better transmitted (if the MSA portion of your Mail Client does not optimize the message for better transmission), but it is not fine for the MTA portion of your mail server to do this operation.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 25 Mar 2015 21:17:43 +0100

> downgrade/gateway-transformation in cases not involving 
> addr-spec, [...]

I know about no implementations of that so far. But maybe someone will come 
along and feel that this is something that needs doing for some MTA.

Arnt

---

From: [email-masked]
Date: Wed, 25 Mar 2015 15:08:03 -0700 (PDT)

> paths is chancy. Too chancy to bother with, IMO, since MIME encoders and

+1.

There may come a time when EAI support is ubiquituous and it makes sense to
"just send UTF-8" rather than depend on what will then be creaky old encoding
support. But we're a long way away from that.

				Ned

---

From: [email-masked]
Date: Thu, 26 Mar 2015 11:18:17 -0700 (PDT)

> along and feel that this is something that needs doing for some MTA.

My problem with it is it's tricky to implement correctly, and requires
some compromises in message handling I'm not ready to make.

In particular, if I know that a given recipient isn't capable of handling an
EAI message - never mind why or how - I'd much rather report that in resonse to
the RCPT TO. (I trust I don't need to explain why this is better than bouncing
the message later.)

More generally, I have to have the message in hand and perform a MIME analsysis
before I can determine whether or not it can be safely downgraded. If at
that point I find EAI addresses in the header or whatever, I have to
bounce the message, with all that implies.

And waiting until I have the message in hand gets into the usual thicket of
issues surrounding handling of partial failures after the DATA. As it happens
we have a fairly general architecture in place for handling this sort of thing,
but it's not something I rush to apply to every problem that comes along.

Since the design philosophy of EAI is that bounces are better than
dowangrading, I must say that at this point I have no concern with this
happening.

				Ned