Re: Consensus Result on Issue #1 - Parameter on MAIL

> On Thu, 2011-02-03, John C Klensin wrote:

> > Remember that messages that are claimed to require EAI MUST NOT
> > be sent unless the server advertises the capability.  So, if a
> > relay receives a message that appears to require EAI (parameter
> > sent to it on the MAIL command) and the next hop doesn't
> > advertise the capability, that relay must either

> > 	- reject the message as stated to require EAI
> > 	functionality but having no host to which it can be
> > 	delivered
	
> > 	- scan the envelope and message to determine whether it
> > 	can safely drop the flag
	
> > 	- risk violating 5321/5322 by sending a message that
> > 	potentially requires the EAI extensions without getting
> > 	a server OK for using those extensions.

> It seems to me that this raises another concern for the maximum reliability
> of message propagation. The fact that, while the message itself will not
> change with respect to whether it requires EAI of not, The *envelope* may
> as it progresses from hop to hop.

And so can the header. List expanders routinely modify headers in various ways,
and this will include EAI material. (Purists don't like this of course, but
like it or not it's how things are done.) So a list expander may turn a non-EAI
message into an EAI message, or vice-versa, either through envelope
modification, header modification, or both.

> For instance, a mailing list message with ASCII only content is to be
> distributed to a number of subscribers, some of which have EAI addresses. A
> simple-minded mailer would send MAIL FROM: with the EAI flag set and then a
> bunch of RCPT TO: commands with a few containing EAI-requiring addresses.
> Note that as the message is forwarded to subsequent MTAs, eventually some
> of the message copies will have only recipients with ASCII addresses. Who
> is responsible for noting that the EAI flag is no longer needed?

The answer to that is ... nobody. Removing the EAI flag from a message that no
longer needs it should be legal, but not required. What does need to be
required, however, is setting the EAI flag when a non-EAI message is converted
to an EAI one.

> Maybe the correct way to handle this is to have the original mailer
> segregate the EAI-requiring recipients into a separate transaction. Is it
> appropriate for this spec to mention this advice?

As I tried to explain a couple of days back, I think the answer to this is
"no". The problem with trying to explain this particular tactic is it gets
really ugly really fast. For example, consider the case of a client attempting
to submit a message to a group of recipients, some EAI and some not, where
nothing in the message content requires EAI. The transaction part isn't the
problem - clients alreayd have to be able to split groups of recipients in
order to cope with recipient limits. No, the problem is what to put into the
header - if you list the EAI recipients in a recipient field, you've converted
the message to EAI irrespective of the type of recipient. So can you avoid
putting in the recipients? Well, that becomes a complex question of intent, of
what information the client has available, and even what sequence of operations
the client uses to constrcut the message (which varies wildly from one client
to another).

Issues with list expansion may be a little simpler, but nevertheless have the
same general flavor.

So I think the correct approach is to clearly define what the EAI flag means
and when it has to be set, and a suggestion as to when it should not be set.
The rest is going to be a matter of client quality. And if past experience in 
MIME is any indication, what we actually say about this behond the actual hard
restrictions is going to matter a lot less than we'd probably like to believe.

				Ned