Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

[[e-mail]]

> Thanks a lot for  all comments from the wg members.
> Here are some clarifications:

> 1) my intention is to help the deployment of eai protocols.
> 2) In Feb. 2012, I talked with many email software and service providers in China.  some software providers in China have promised to implement and deploy rfc6531 and rfc6532.
> 3) the idea in the draft was discussed during Feb. 2012 when I takled with them. They thought that some mechanisms with an early indicator of whether the destination server support SMTPUTF8 would help the deployment of RFC6531 and RFC652 during the early deployment of EAI.
> 4) this draft is mainly for discussion about how we can help the deployment of EAI. If the WG thinks that it is not good idea, we can just discard it.
> 5) the scenario which the email software or service providers would like to address is that eai users send the eai message to many users including eai user and ascii user.

>  For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have
>    to say EHLO 10 times before deciding to reject the message.

Say what? I would expect in this case for the message to be delivered to the
first 9 recipients and for the 10th to generate a DSN. That's the only sensible
outcome, and moreover, the idea of having to get responses from multiple
systems before deciding whether or not to reject the message in toto is both an
implementation nightmare as well as operationally infeasible.

What if one of the systems you have never talked to before is down for a
prolonged period longer than the MSA or MTA's queue timeout? Do you seriously
think it's a good idea to have a message sit in the queue for a week and then
time out and bounce for all recipients because of that?

I also note that nothing in the EAI document set requires, or for that matter
even encourages, such behavior.

>    This
>    procedure of judging whether the SMTP server is SMTPUTF8-aware is
>    time-consuming.

No, it really isn't. Modern MTAs at a minimum split such messages by
destination host and perform deliveries in parallel. (Note that this is the
minimum they do; there are many additional optimizations that can be performed,
with varying degrees of effectiveness.)

> [e-mail] sends the eai message to

> 1) [e-mail]
> 2) [e-mail]
> 3) [e-mail]
> 4) [e-mail]
> 5) [e-mail]
> 6) [e-mail]
> 7) [e-mail]
> 8) [e-mail]
> 9) [e-mail]
> 10) [e-mail]


> if all ten users support smtputf8 and the MSA know it in advance, the message
> will be sent one by one from 1) to 10).

Again, your understanding of how modern MTAs work is incorrect. It is very
likely, in fact nearly certain, that the message will go out with some degree
of parallelism. And the results of delivery to one recipient are not
coupled to the results of others.

I will also point out that as a practical matter, you cannot possibly guarantee
these sorts of results no matter what implementors do. What if one of the
systems says it supports EAI but then rejects the recipient during the SMTP
dialogue because that _recipient_ doesn't support it? Or what if the system
accepts the message but decides to reject it later because that recipient is
later determined to not support EAI? Either way you've lost your "all succeed
or all fail" capability. And having such behavior in some cases but not others
violates the least astonishment principle.

> if user 10) [e-mail] does not support smtputf8, but other nine users
> support smtputf8, the MSA may say ehlo to  the destination server one by one
> from 1) to 10),   and finally decide to reject it.

I doubt very much any MSA will implement that strategy, for reasons given
above. And it certainly isn't required that they do so.

> of course, there are many solutions to this issue such as John levine's
> cached mechanism.

I'm afraid most of the problems you're attempting to address here are based
on a misunderstanding of how this is going to work.

As for caching EHLO repsonses, that actually makes me a little nervous. Caching
positive responses is fine but not particularly useful, caching negative  ones
OTOH for any length of time risks the the possibility that the system will be
upgraded and messages will get bounced for no good reason. 

				Ned