Subject: Re: [IMA] re: JET IMA meeting memo

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Sep 2005 15:23:14 +0800

if utf-8@utf-8 is used, when the utf-8 for  the domain part is used to look into DNS to find the relative IP address, does the domain part have to be turned into ACE?

 Yao Jiankang
CNNIC  

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 31, 2005 3:32 PM
Subject: Re: [IMA] re: JET IMA meeting memo

> 
> 
> --On Wednesday, 31 August, 2005 14:26 +0800 YAO Jiankang
> <[email-masked]> wrote:
> 
> > 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?
> 
> 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
> 

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

---

From: yangwoo ko <[email-masked]>
Date: Thu, 01 Sep 2005 16:53:45 +0900

> if utf-8@utf-8 is used, when the utf-8 for  the domain part is used to look into DNS to find the relative IP address, does the domain part have to be turned into ACE?

In my understading, the step (1) of John's flow includes;
* converting domain part using ACE
* finding MX record using the ACE version of domain
* name resolution with returned mail server name/address
* open connection with the returned IP address

Regards

>>------------------------------------------------------------------------
>>

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 1 Sep 2005 08:19:29 -0400

To add a bit to that, if I am correct, I think the best way to think about it is that the sending SMTP at that point acts as the DNS client (i.e. application) and does the ToACE and DNS lookup as specified by IDNA.  Other IDN aware "domain slots" can remain in UTF8.
Edmon

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Sep 2005 14:52:42 -0400

--On Thursday, 01 September, 2005 16:53 +0900 yangwoo ko
<[email-masked]> wrote:

> YAO Jiankang wrote:
>> if utf-8@utf-8 is used, when the utf-8 for  the domain part
>> is used to look into DNS to find the relative IP address,
>> does the domain part have to be turned into ACE?
> 

Yes, exactly.  More generally, this work cannot change IDNA in
any way.  So, at any point at which a DNS query is required
--such as for an SMTP client to do an MX lookup to determine the
IP address to which a mail connection is to be opened -- any
internationalized domain must be converted to punycode as IDNA
specifies and then the punycode used in the DNS query.

    john