[EAI] Comments on the DSN draft (draft-ietf-eai-dsn-00.txt)

["Charles Lindsey" <chl at clerew.man.ac.uk>]

There have been discussions on some aspects of this draft, but no overall  
review, and in particular no discussion of exactly which new media types  
need to be defined. I apologise for not respondig earlier.

Abstract

   Delivery status notifications (DSNs) are critical to the correct
   operation of an email system.  ...

DSNs and mentioned here but not MDNs, which are also covered by this  
draft. OTOH:

1.  Introduction

Mentions MDNs but not DSNs. Both places should mention both, and their  
full text versions and RFC refs at least here.

3.  UTF-8 Address Type

Our documents seem divided upon whether we speak of "UTF8" or "UTF-8".  
Please can we have a consistent usage throughout the whole series? I don't  
mind which, but I note that the charset registered with IANA is "utf-8"  
(though it could do with "utf8" as an alias). OTOH, I think most of our  
present drafts tend to use "utf8", and certainly use of "utf-8" in this  
document has lead to a proliferation of hyphens, as in  
"utf-8-delivery-status".

   utf-8-type-addr     = "utf-8;" utf-8-address

   utf-8-address       = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">"
          ; The first  occurrence of 'Mailbox' is defined in [utf8smtp]
          ; The second occurrence of 'Mailbox' is defined in RFC 2821

This has already been discussed. We should always look to [utf8headers]  
for the syntax of bits and pieces inside messages ([utf8smtp] is for stuff  
that goes in the envelope - OK, some syntactic objects, as this one, can  
occur in both). Moreover <Mailbox> (in RFC 2822 terminology) includes the  
<display-name>, which I don't think we want here. So what you actually  
need to say is:

   utf-8-address       = angle-addr ; as defined in [utf8headers]

4.  UTF-8 Encoded Address Type

We discuused this. It is unfortunate that we cannot use <xtext>. I think  
we more-or-less agreed that a "%hex" encoding of the UTF-8 was the best  
solution. Sadly, this format will often turn up in message/delivery-status  
and in whatever/utf-8-delivery-status, and it is an open question as to  
whether user agents will be able to restore it to its UTF-8 form.

5.  UTF-8 Delivery Status Notifications

In order to discuss this, I am going to introduce various scenarios that  
we need to cope with.

Scenario 1
----------

Envelope contains MAIL FROM: utf-8 at utf8, but with no ALT-address.

If this message gets downgraded, a DSN can never be returned to the  
originator. Therefore the downgrade process MUST generate a "relayed" DSN,  
even though the next hop does advertise DSN.

Scenario 2
----------

Envelope contains MAIL FROM: utf-8 at utf8 with ALT-address ascii at ascii.

A DSN may then sometimes be sent to ascii at ascii, which may or may not be  
able to render any utf-8-enc within it (and might even not reach the smae  
person/site as utf8 at utf8 - though that could be regarded as the Sender's  
fault).

Scenario 3
----------

The message gets downgraded before it reaches the Reporting MTA (which may  
or may not be the final delivery MTA). In this case

   RCPT TO: contains to-alt-ascii at to-alt-ascii
   ORCPT contains utf-8-enc: to-utff8 at to-utf8 (%hex encoded)

The Reporting MTA will now generate a DSN with
   a message/delivery-status containing
      ORCPT: utf-8-enc;  to-utff8 at to-utf8 (%hex encoded)
      ENVID: whatever. but %hex encoded
      Reporting-MTA: dns; r-ascii.example
   plus either
      a text/rfc822-headers containing the downgraded headers
   or
      a message/rfc822 containing the full message as downgraded.

The DSN is sent to to ascii at ascii. It is an open question whether  
ascii at ascii can display the %hex material, or the text/rfc822-headers or  
message/rfc822 in an upgraded form.

Scenario 4
----------

The message arrives at a Reporting MTA which understands UTF8SMTP.

I am going to intropduce several versions of this scenario.

Version 4a, following the draft as currently written.
-----------

The Reporting MTA will now generate a DSN with
   a message/utf8-delivery-status containing
      ORCPT: utf-8; to-utff8 at to-utf8 (still as utf-8)
      ENVID: whatever, still in utf-8
      Reporting-MTA: dns; r-utf8.example
but Oops! RFC 3461 does not allow that, so instead use
                     utf-8-dns; r-utf8.example
or alternatively
                     dns; r-utf8-in-punycode.example
   plus either
      a message/utf-8-headers containing the original headers
   or
      a message/utf-8 containing the full original message

The DSN is sent to utf8 at utf8 plus ALT-ascii at ascii (if an ALT return  
address is available).

But, as we have already discussed, all that doesn't work because this DSN  
may go via a route which needs to downgrade it to non-8BITMIME. And sadly  
you cannot use a C-T-E of Q-P or Base64 on a message type. Moreover the  
only message type that current 8BIT downgraders know how to deal with is  
message/rfc822.

And why use message/utf-8-headers when the obvious extension of the  
current DSN mechanisms would have been text/utf-8-headers.

Version 4b, using the simplest fixes, as already dicussed.
-----------
The Reporting MTA will now generate a DSN with
   an application/utf8-delivery-status containing
      exactly the same as above
   plus either
      a text/utf-8-headers containing the original headers,
      and specifying charset=utf-8
   or
      an application/utf-8 containing the full original message
and delivered as before.

The two application types are opaque as far as current agents are  
concerned (being treatable as application/octet-stream), but may be  
unwrapped by UTF8SMTP-capable agents (and in particular displayed sensibly  
by UTF8-capable user agents).

The text/utf-8-headers will come to no harm since existing agents will  
treat it as text/plain (and could even display ir correctly as such).

But can we do better than this?

Version 4c.
-----------

Recall that there will be two types of email message in future:

   "ASCII" messages as defined in RFC 2822 plus the MIME standards
   "UTF8SMTP" messages, as defined in [utf8headers] which _extends_ RFC  
2822,
      and could as easily extend the MIME standards

BUT there is a strict requirement that UTF8SMTP messages are allowed ONLY  
in the UTF8SMTP Universe, and MUST NOT be seen in the current ASCII  
Universe. So at the boundary between those Universes there must be either  
downgrading or bouncing.

I think we are already agreed that the only way to detect that a given  
message is or is not a UTF8SMTP one is to recursively descend through its  
MIME structure looking for UTF-8 headers, and that downgrading will  
involve such a (and probably the same) recursive descent. Also that  
mesasage/utf8 objects (as extended) will contain UTF8SMTP messages (that  
is going to happen whether we like it or not, so we may as well ensure  
that it works, and is covered in the downgrading rules).

So let us take that principle a little further, and try to extend the  
existing DSN media types. There are three of them to consider, and we may  
or may not be able to fix them all.

The Reporting MTA will now generate a DSN with

4c(i)  a message/delivery-status (extended) containing
      ORCPT: utf-8;  to-utff8 at to-utf8
      ENVID: whatever. in utf-8
      Reporting-MTA: dns; r-utf8.example (we seen to have extended "dns"
                        as well, or else we use "utf-8-dns")
PROVIDED a downgrade of message/delivery-status to what you saw in  
Scenario 3 is defined;

   plus either
4c(ii) a text/rfc822-headers (extended to allow a charset=utf-8 parameter  
and
      using C-T-E: 8bit) containing the downgraded headers
HMMMMM! Can we get away without a downgrade there? It would almost  
certainly pass unscathed through the existing network, though existing  
user agents might baulk at displaying it. For sure, existing 8BITMIME  
downgraders would handle it correctly.

   or
4c(iii) a message/rfc822 (extended) containing the full original message
PROVIDED a downgrading is defined. But we are almost certainly going to  
define that downgrading anyway.

So, of those three cases, I think (iii) is the easiest to achieve (and  
also the most desirable to achieve) and (i) is the hardest. But they  
should all be thought about.

Scenarion 5
-----------

The message arrives at a Reporting MTA which understands UTF8SMTP which  
generates a DSN as in (some version of) Scenario 4 above.

Subsequently (perhaps even at that same Reporting-MTA) it needs to be  
downgraded (because the Return-Path may follow a different sequence of  
MTAs than simply the reverse of the original path).

What happens here has largely bee discussed already under Scenario 4.

But there still remains the open question of whether it can all be  
displayed neatly when it gets back to the original sender.

6.  UTF-8 Message Disposition Notifications

I have not considered this is detail, but whatever we do regarding the  
scenarios for the DSN cases could equally well be applied here.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;                      
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima