Subject: [EAI] UTF8 and ESMTP extension parameters

From: Tony Finch <[email-masked]>
Date: Mon, 7 Aug 2006 21:35:05 +0100

ESMTP extensions that want to have interesting values in their MAIL or
RCPT parameters generally use the xtext syntax to encode them. (I hope I
haven't missed any extensions that don't do this.) There are three uses of
xtext in ESMTP extension parameters: ORCPT, AUTH, and ENVID. Of these we
probably do not need to worry about ENVID, since it can remain ASCII-only,
the same as has been decided for Message-ID header fields.

The AUTH parameter [RFC2554] on MAIL FROM does not have any provision for
gatewaying between different message transport systems. However it is only
of use within a group of mutually authenticating MTAs so perhaps we can
punt and assume that such a group will be upgraded to UTF8 en masse, or
perhaps that when one of these gateways is downgrading that it knows
enough about these addresses to be able to downgrade them without further
information.

I think ORCPT is easier to handle within the framework of the existing
specifications, though there are some awkward areas.

I suggest that we should consider UTF8 addresses to be a different type
from ASCII addresses, i.e. that they use an addr-type tag of (say)
utf8smtp instead of rfc822. This means that we can use the DSN gatewaying
framework to preserve information about UTF8 addresses even when downgrade
occurs.

There are two interesting cases for the outbound message, one of which
might be removed from the specs. In both cases I think it makes sense for
the ORCPT parameter to contain just the original UTF8 recipient address,
without the downgrade metadata.

(1) A message is sent to a UTF8 address which is aliased to an ASCII
address, and the message gets downgraded during the second leg of its
journey. On the first leg,

  MAIL FROM:<[email-masked]>
  RCPT TO:<[email-masked]>

On the second leg:

  MAIL FROM:<[email-masked]>
  RCPT TO:<[email-masked]> ORCPT=utf8smtp;d+f6t@dot+e4t.at

(2) A message is sent to a UTF8 address which does not have proper
UTF8SMTP infrastructure, so the message gets downgraded. (We might
not support this.)

  MAIL FROM:<[email-masked]>
  RCPT TO:<[email-masked]> ALT-ADDRESS=[email-masked]

After downgrade it is the same as before:

  MAIL FROM:<[email-masked]>
  RCPT TO:<[email-masked]> ORCPT=utf8smtp;d+f6t@dot+e4t.at

There are two problems with this model:

(a) RFC 3461 does not allow non-ASCII characters in an xtext

(b) the message/delivery-status content-type is restricted to 7bit
content transfer encoding

Is it worth updating the DSN specs to allow 8bit CTEs? Would we still have
to specify how to downgrade an 8bit DSN into 7bit? RFC2047 encoding? UTF7?
or something else?

We could define that 8bit DSNs are allowed within the UTF8SMTP network,
and then define how to downgrade 8bit DSNs to 7bit, including how to
downgrade UTF8 ORCPT parameters to 7bit.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 27 Aug 2006 13:50:13 +0100

Tony Finch wrote:

>Is it worth updating the DSN specs to allow 8bit CTEs?
>
After our off-list conversation I think changing message/delivery-status 
to at least allow for quoted-printable CTE would be highly desirable.

>Would we still have