Subject: [IMA] re: JET IMA meeting memo

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 31 Aug 2005 14:26:55 +0800

according to the proposals we discussed,
- pros and cons of 3 proposals
  (1) JET ACE@ACE
  (2) John+CDNC UTF8@UTF8 (no downgrade)
  (3) John+CDNC UTF8@UTF8 (w/ downgrade)

if proposal 2 is used with no downgrade, if sender smtp supports IMA, but receiver smtp doesn't support IMA, the IMA address is bounced by receiver SMTP? or Proposal 2 can only be used in the scenario where both sender smtp and both receiver smtp supports IMA?

if we consider the secenario that we can not upgrade all smtp servers to support IMA, proposal 3 with downgrade may be better.

YAO Jiankang
Best Regards
Tel:86-10-58813007
Fax:86-10-62559892
--------------------------------------------------
China Internet Network Information Center (CNNIC)
4, South 4th Street, Zhongguancun,
Haidian district,
Beijing 100080, China
POB: Beijing 349, Branch 6
http://www.cnnic.cn
Email: [email-masked]
[email-masked]

----- Original Message ----- 
From: "Yoshiro YONEYA" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 22, 2005 6:22 PM
Subject: JET IMA meeting memo

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: yangwoo ko <[email-masked]>
Date: Wed, 31 Aug 2005 16:17:25 +0900

YAO Jiankang wrote:
> if proposal 2 is used with no downgrade, if sender smtp supports IMA, 
> but receiver smtp doesn't support IMA, the IMA address is bounced by 
> receiver SMTP? 

The sender SMTP server comes to know that the receiver
SMTP server does not support IEmail via initial ESMTP
EHLO exchange.

> or Proposal 2 can only be used in the scenario where 
> both sender smtp and both receiver smtp supports IMA?

Yes. And even the intermediate servers should support IMA.

> 
> if we consider the secenario that we can not upgrade all smtp servers 
> to support IMA, proposal 3 with downgrade may be better.

It true when we consider the initial introduction phase.
What about next 10 years? Since many mails will be bounced
due to not-yet-upgraded servers, customers will;

(1) complain about the problem and these complaints
can urge mail server operators to upgrade

and

(2) learn when to use alternative ASCII only email addresses.

If we choose option 3, there are still complaints from users
because they should enter both Iemail address and ASCII only
email address for some users. And there will be far less
pressure from user side for providers to upgrade.

In addition to this, we should devise a way that deals with
"equality conditions." From the common user's perspective,
they want mails should be delivered to the same recipient
regardless of email address used actually. This will lead
to a new operation practice from the viewpoint of mail service
operators. AND, we need to consider which address should be
reflected to some header fields. AND we need to consider
the security issues when downgraded address is manipulated
to be delivered to other recipient.

> (snip)

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Aug 2005 03:32:14 -0400

--On Wednesday, 31 August, 2005 14:26 +0800 YAO Jiankang
<[email-masked]> wrote:

> if proposal 2 is used with no downgrade, if sender smtp
> supports IMA, but receiver smtp doesn't support IMA, the IMA
> address is bounced by receiver SMTP?

No, actually, it is bounced by the sender SMTP.  Since it is
very important that everyone understand how SMTP and the
extension mechanism actually works in this environment, let me
review the transaction flow, assuming that the relevant option
is called "IMA".  "S:" represents the sender SMTP, "R:" the
receiver.  

(1) S: opens connection
(2) R: 220 Ok
(3) S: EHLO sender-host.domain.name
(4) R: 250-receiver-host.receiver-domain.name
(5) R: 250-8BITMIME
(6) R: 250-EXPN
(7) R: 250 SIZE
(8) S: MAIL FROM:<[email-masked]>
(9) R: 250 OK
(10) S: RCPT TO:<[email-masked]>

Notes:
(2) Virtually any text can follow the "220 ", but the sender
will typically ignore it.

(5)-(7) indicate that 8BITMIME, EXPN, and SIZE are supported,
but IMA is not (since it is not listed)

(8) Since IMA is not advertised by the receiver, the sender MUST
NOT send any non-ASCII addresses in either MAIL or RCPT
commands, nor may the mail headers contain any internationalized
information except in encoded words where those are permitted.
Note that the argument to the MAIL command could, under proposal
(1), be an ACE: the sending host will understand its own naming
structure.  However,

(10) May not even contain an ACE unless the ACE was provided by
the sending user and obtained in some out of band way.
Otherwise, you have no way to be assured that the receiving host
will decode it, that it understands the ACE conventions, and
that the apparent ACE syntax is not really a special command in
disguise.

So, if the SMTP-sender does not have ASCII reverse and forward
path addresses available for use in steps 8 and 10, it SHOULD
send QUIT or RSET instead of step (8) above and notify the user
(or the SMTP that sent the message to it) and MUST do so before
sending any i18n information.

Within the normal definitions of Internet mail, that is a
success: the message has not gotten lost but has been properly
accounted for to the sender.  It was just not deliverable to a
host that did not support the addressing syntax.

> or Proposal 2 can only be
> used in the scenario where both sender smtp and both receiver
> smtp supports IMA?

Depends on what you mean by "can only be used".  Examine how the
above would work with IMA supported.  We would then have...

(1) S: opens connection
(2) R: 220 Ok
(3) S: EHLO sender-host.domain.name
(4) R: 250-receiver-host.receiver-domain.name
(5) R: 250-8BITMIME
(6) R: 250-EXPN
(7) R: 250-SIZE
(7a): R: 250 IMA
(8) S: MAIL FROM:<[email-masked]>
(9) R: 250 OK
(10) S: RCPT TO:<[email-masked]>
(11) R: 250 address ok
(12) S: DATA
(13) R: 354 Send data, 8bit permitted
(14) S: From: [email-masked]
     S: To: [email-masked]
     S: Date: Wed, 31 Aug 2005 14:26:55 +0800
     S: MIME-Version: 1.0
     S: Content-type: text/plain; charset=utf8
     S:    [...]
     S: 
(15) S: Message text
     S: more text
(16) S: .
(17) R: 250 Message received
(18) S: QUIT
(19) R: 250 Ok, quitting
(20) R: (closes connection)

And, with the IMA option advertised as a server capability in
line 7a, the sender would be free to use UTF-8 addresses in
lines 8 and/or 10.  If we do this as we have discussed, any of
the header fields in (14) could be specified as being in UTF-8
and, since an appropriate content type is specified, so could
the message text in (15).

Does that help?

> if we consider the secenario that we can not upgrade all smtp
> servers to support IMA, proposal 3 with downgrade may be
> better.

Note that proposal 3 does not change the above at all.    If we
have the first scenario (with IMA not advertised), the sending
SMTP server can get to the end of step 7 and then, rather than
sending the original non-ASCII address information that would be
contemplated in step 8, it must then transform the addresses and
headers into standard form and then send them as if it had never
heard of IMA.   

That "stop in the middle of the transaction and convert"
property is, incidentally, a major reason why 8BITMIME
downgrading was never widely supported.  Most good-quality SMTP
servers are designed to "get rid of" messages as quickly as
possible once the relevant TCP connection is opened.  Here, if
IMA (and 8BITMIME) are not supported, we expect the sending SMTP
server to stop what it is doing after receiving the EHLO
response, perform a moderately complicated conversion while
holding the connection to the receiver SMTP open, then send the
reconstructed message, hoping that the receiver does not time
out in the interval.

In at least one case, it was implemented in a different way, one
that is permitted by the specification but that may not be
desirable.   In this alternate method, the mail transaction was
terminated (a QUIT or RSET command sent) as soon after the EHLO
response appeared without the needed capabilities and it was
discovered that the capability was needed.  The original message
was then dropped into a special queue for
conversation/downgrading and subsequent queueing for a second
attempt without holding the TCP connection open.  That is fairly
efficient from the standpoint of the SMTP sending server, but
standard retry intervals could then result in a delay of some
hours before an attempt was made to deliver the downgraded mail.
>From the standpoint of the sending user, it might have been
preferred that the message be bounced so that it could be
immediately resent in compatible/ downgraded form, rather than
having it delayed in transit that way.

regards,
    john