Subject: Re: [EAI] non-EAI messages

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 03 Jan 2011 10:21:19 -0000

On Fri, 31 Dec 2010 21:01:55 -0000, Troy Starr <[email-masked]> wrote:

> Hi Shawn -
>
>> > The reason it's a terrible idea is that only some subset of the  
>> messages a given MTA handles will be EAI messages.
>>
>> I'm not sure how this is interesting?
>
> Assuming that all of the future MTAs in the message delivery chain  
> support UTF8SMTPbis, then I agree, it's not interesting.  But what  
> happens if the previous MUA/MSA/MTA applied a UTF8SMTPbis flag to the  
> entire session rather than on a per-message basis, then the current MTA  
> wants to deliver one of those messages to an MTA which doesn't support  
> UTF8SMTPbis?  I see the following possibilities:

But surely it is obvious, and certainly so after your examples, that is  
there is to be a UTF8SMTPbis flag sent to a server by a client, then it  
HAS to be a per message flag rather than a session flag? Where did this  
idea of a session flag come from?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: John Levine <[email-masked]>
Date: 3 Jan 2011 15:31:28 -0000

> Where did this idea of a session flag come from?

>From me, I suppose.

There are clearly two ways to tell whether a message to be relayed
needs an EAI server.  One is what we might call Deep Message
Inspection, scrutinize the message body and envelope to see if they
contain anything that classic SMTP can't handle.  The other is
Assertion, use whatever EAI flag the sender used.

My advice is simply to document the two possibilities and move on.
They both work, for plausible albeit different definitions of work.
Whatever we do, some people will do one, some will do the other.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 03 Jan 2011 07:47:27 -0800

> Whatever we do, some people will do one, some will do the other.

The characters set of a message is a property of the message.

The encoding of the message is a property of the message.

Consecutive messages could -- and likely will -- have different character sets 
and/or encoding.  A single user speak to many different recipients.  A single 
email environment often supports many different users.  This combination means 
that the transport service needs to impose as few session limitations as possible.

A "session" flag would require establishing a new session in order to change 
character sets and/or encodings.  That makes it a highly sub-optimal choice.

Making character and encoding declarations work at a per-message level, rather 
than a per-session level is by far the better choice.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Bill McQuillan <[email-masked]>
Date: Mon, 3 Jan 2011 08:52:13 -0800

> than a per-session level is by far the better choice.

I seems to me that two different client assertions are being discussed
here, "I understand UTF8SMTPbis" and "The current message has non-ASCII in
the header".

Originally the idea was that Deep Message Inspection was able to determine
the value of the second assertion without a flag or command. However the
issue of allowing UTF-8 in responses to VRFY and EXPN raised the issue of
the first assertion in the absence of any message to be inspected.

I fear the only clean solution is both a session state setting command and
a per-transaction flag.

-- 
Bill McQuillan <[email-masked]>

---

From: [email-masked]
Date: Mon, 03 Jan 2011 09:31:54 -0800 (PST)

> here, "I understand UTF8SMTPbis" and "The current message has non-ASCII in

Correct, but it is also important to note that they are essentially disjoint in
terms of usage - the former is applicable to VRFY/EXPN, the latter to message
transfer transactions. So these are really two different problems.

> the value of the second assertion without a flag or command.

Which is still true. It's not that deep inspection doesn't work - it does - but
rather that it's not good choice operationally.

> However the

> I fear the only clean solution is both a session state setting command and

Actually, while a session flag solution for VRFY/EXPN is nowhere near as sucky
as it is for MAIL FROM, it's not the cleanest solution either. The problematic
case would be some sort of lookup proxy, where sometimes the operation being
performed is amendable to a utf-8 return value and sometimes it is not. Such an
agent would have essentially the same issue with global state complexity.

Now, I'm by no means sure such agents - assuming they even exist - would be
worth catering to if it meant messing things up in some way. But it's not like
having either a command argument or a  separate set of commands are themselves
problematic for other reasons. So I'm inclined to stick with the VRFY/EXPN
parameter as the cleanest overall approach.

				Ned

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 05 Jan 2011 11:54:42 -0000

> agent would have essentially the same issue with global state complexity.

+1. I think session flags are a Bad Thing in themselves, and would much  
prefer to cover the VRFY/EXPN case with some UTF* parameter for that  
command (indeed, we could allow that parameter for ALL commands, though  
MAIL/VRFY/EXPN are the obvious beeficiaries).

Note that a client MUST NOT send that parameter unless it is aware, from  
and earlier EHLO, that it is allowed. I think that solution was gaining  
consensus in John's recent poll.