Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM

From: Shawn Steele <[email-masked]>
Date: Mon, 31 Jan 2011 02:53:38 +0000

> if mail from [email-masked]  header=eai, it indicates that the client supports EAI;
> if mail from [email-masked]  header=ascii, it indicates that the client supports EAI too;

I really don't like anything with the =eai/ascii type thing.  AFAIK mail doesn't do this anywhere.  If we really, really, really had to have this, then i'd prefer:

if mail from [email-masked]  UTF8SMTP ASCIIONLY, supports EAI, but message is only ASCII.
if mail from [email-masked]  UTF8SMTP, supports EAI, but message is UTF-8.

I have no clue when I'd ever use the 1st though.  It's not worth the client's effort to parse the message to figure it out (or remember it), and there're going to be errors when the client was forwarding the message and somehow the ASCIIONLY (or UTF8) flag got forgotten.

-Shawn

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

---

From: E-mail Address Internationalization <[email-masked]>
Date: Mon, 31 Jan 2011 13:51:46 -0800

Hi Shawn -

> > if mail from [email-masked]  header=eai, it indicates that the 
> > client supports EAI; if mail from [email-masked]  header=ascii, it 
> > indicates that the client supports EAI too;
> 
> I really don't like anything with the =eai/ascii type thing.  AFAIK mail doesn't do this anywhere.

Could you elaborate on why you don't like it?  I'm trying to think of the reasons why, but I'm not sure what I'm coming up with matches what you're thinking.  Here are the possibilities that I've come up with:

1. You don't think that MAIL parameters are allowed to have values, so we'd be modifying the MAIL parameter extensibility mechanism.  However, that's not the case.  Section 4.1.2 of RFC 5321 defines the syntax of "Mail-parameters", which points to "esmtp-param", which allows parameters to have values.

2. You don't think there are any previous extensions that use values with parameters, so we'd be doing something unusual.  However, that's also not the case.  Both the SIZE parameter (RFC 1870) and the BODY parameter (RFCs 1652 and 3030) for the MAIL command can and do take values.

3. You find specifying the "legacy" behavior and "new" behavior via parameter values to be unusual.  However, this has also happened before, again with the BODY parameter defined in RFC 1652.  The 7BIT value signifies legacy behavior, while the 8BIT value signifies new behavior.

Is there some other underlying reason to your objection that I haven't thought of?

> If we really, really, really had to have this, then i'd prefer:
> 

To be honest, I don't like this. :-)  The reason why is that ASCIIONLY is another way of saying NOTUTF8, and it feels awkward to me from a protocol design point of view to announce that you're not using a feature via a standalone parameter.  (And to head off any potential tangents that ASCII != NOTUTF8, I get that, but from a 10,000 foot view that's basically what we're saying.)

In addition, I feel that parameters that we come up with should be easy to parse and understand from both a computer and human point of view.  I wouldn't immediately understand what ASCIIONLY implies unless I was familiar with this RFC.  We could make it more easily understood by calling it ASCIIHEADERS or something similar, but that still feels awkward to me for the reason I gave above.  Using a parameter=value convention of HEADERS=ASCII/UTF8 (or UTF8SMTPbis if you'd prefer) seems to elegantly and succinctly communicate both that the client is EAI-capable should that be important, and whether this specific message requires that capability.

> I have no clue when I'd ever use the 1st though.  It's not worth the client's effort to parse the message to figure it out (or remember it), and there're going to be errors when the client was forw…

When you say the message, do you mean the original message that the user is trying to send or potential responses from the SMTP server?  If it's the former, I'm having trouble following this line of reasoning.  I agree that it's unclear to me what situations communicating EAI capability but not actually using EAI is necessary.  The one I've heard of on this list is if the SMTP server notifies the client of an EAI forwarding address with the expectation that the client will then send the message to that address instead of the SMTP server forwarding it on the client's behalf.  I don't have a good feel for whether that actually happens, though.  My gut tells me it doesn't, but I'm happy to be proven wrong.  In terms of whether it's worth the client's effort to parse this message, I fundamentally disagree.  The point of having a MAIL parameter at all is to move the "heavy lifting" of determining whether this is an EAI message to the MUA (and possibly the MSA) and away from the MTA.  I know that you prefer always adding this parameter if both the client and server support EAI regardless of whether the message requires it, but that would be more likely to cause messages to be returned undeliverable if the first hop on the SMTP chain supported EAI, but the next hop didn't, even if EAI wasn't necessary for that message.  This model depends on the client making that determination so that it can give the message the best chance of successful delivery if EAI is not required.  I also have a hard time believing that the ASCII/UTF8 flag would be forgotten, although we could include text to remind implementers of the forwarding possibility so that they don't forget.

If it's the latter, the possibility is returning human readable text with the response codes in the native language for that SMTP server via UTF-8, whatever that language may be.  Enhanced status codes hopefully make this less of an issue, but I can see some value in communicating that human readable text back to the user, but it's up to the SMTP server and mail client to actually communicate that response text back to the user.

In the end, it's still unclear to me that we need to indicate EAI capability if we're not actually sending a message that requires EAI.  If we don't need this capability, then I would be fine with a valueless parameter such as UTF8SMTPbis.  However, if the WG ends up deciding that it is important for the client to communicate EAI capability even if a specific message doesn't require it, then I would far prefer a parameter with a value that succinctly communicates this than a multitude of parameters.

- Troy Starr

---

From: Troy Starr <[email-masked]>
Date: Mon, 31 Jan 2011 14:49:36 -0800

Hi folks -

> From: E-mail Address Internationalization

Sorry about that - I had renamed the display name of my address for the EAI mailing list for easier sorting and forgot that it would also change my display name on e-mail that I send out.  I've corrected this so my actual name will appear from now on.

- Troy Starr