Subject: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt

From: Kari Hurtta <[email-masked]>
Date: 11 Nov 2006 14:17:23 +0200

Now this draft seems to be on Internet-Drafts directories.

This is perhaps already handled?

Anyway John Klensin was strongly encouraging
to me write this draft.

This draft specified aone kind encapsulation. Of course
there is also other kind encapsulations available.

If email header field is put to Downgraded: -header fields
and original header field is removed, that is also just 
encapsulation.

Also on some cases encapsulation is required (downgrade is
not available) or message must be bounced.

This draft provides handling of two cases:
   - signed email messages
   - attaching utf8smtp email message to non-utf8smtp
     email message

Of course there may be other usages. DSNes was discussed?

/ Kari Hurtta

Subject: I-D ACTION:draft-hurtta-eai-encapsulation-00.txt
Date: Tue, 07 Nov 2006 18:50:01 -0500
Newsgroups: gmane.ietf.announce
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Encapsulation mechanism for Email Address Internationalization (EAI)
	Author(s)	: K. Hurtta
	Filename	: draft-hurtta-eai-encapsulation-00.txt
	Pages		: 42
	Date		: 2006-11-7
	
   The Email Address Internationalization (EAI) is implemented by
   allowing UTF-8 characters in SMTP envelope and mail headers.  To
   deliver email which uses UTF-8 on email headers through EAI
   incompliant environment converting (i.e downgrading) or encapsulation
   mechanism is required.  Some of UTF-8 email may sign email headers or
   email header fields.  This document describes mechanism for
   encapsulation when converting can not be used because of signed email
   headers.  Encapsulation may also used to forward EAI email through
   EAI incompliant environment that way that original EAI email can be
   recovered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hurtta-eai-encapsulation-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-hurtta-eai-encapsulation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hurtta-eai-encapsulation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Kari Hurtta <[email-masked]>
Date: 11 Nov 2006 14:22:14 +0200

Kari Hurtta <[email-masked]> writes in

>    - attaching utf8smtp email message to non-utf8smtp

  I forgotten one case:

     - It also provides tunneling between two isolated utf8smtp
       isslands via non-utf8smtp environment.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 11 Nov 2006 14:51:14 +0200

> there is also other kind encapsulations available.

Open issue is what to do when content-transfer-encoding is
changed between non-identity encodings during transport.

That means conversion quoted-printable <-> base64.

If that conversion happens, it is impossible to return
exactly same original email message. Of course reverse
conversion is possible, but it is not possible to know 
exact quoted-printable or base64 encondig what was used.

However this is also problem for S/MIME if it happens.

draft-hurtta-eai-encapsulation-00 may however make it
worse, because multipart/signed is often handled specially
indication that "no conversions".  That draft hidens
multipart/signed  (multipart/mixed is used instead on
encapsulated message.)

( Conversions from identity (7bit, 8bit, binary) to
  quoted-printable or base64 are OK. )

RFC 2045 allows that kind conversions:

| 6.5.  Translating Encodings
| 
|   The quoted-printable and base64 encodings are designed so that
|   conversion between them is possible.  The only issue that arises in
|   such a conversion is the handling of hard line breaks in quoted-
|   printable encoding output. When converting from quoted-printable to
|   base64 a hard line break in the quoted-printable form represents a
|   CRLF sequence in the canonical form of the data. It must therefore be
|   converted to a corresponding encoded CRLF in the base64 form of the
|   data.  Similarly, a CRLF sequence in the canonical form of the data
|   obtained after base64 decoding must be converted to a quoted-
|   printable hard line break, but ONLY when converting text data.

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Nov 2006 15:55:46 +0100

> Of course there may be other usages. DSNes was discussed?

Whatever else happens, IMO we need text/utf8-header for the
purposes of text/rfc822-headers (RFC 3462).

It's one of those ugly "bounces-to" effects:  Normally I'd
think if somebody can send UTF8SMTP (s)he can also handle
UTF8SMTP DSNs later.  But the MAIL FROM mailbox address can
be an ordinary mailbox, hopefully behind a downgrade relay.

Do we need MUSTard somewhere that senders are supposed to 
know how to eat their own dogfood if it's rejected ?  I-D
ietf-eai-smptpext-02 says in 2.7.6 that DSNs are addressed
in I-D.ietf-eai-dsn-00 later (?)

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 11 Nov 2006 13:51:45 -0800

> in I-D.ietf-eai-dsn-00 later (?)

If rejected (at SMTP level), the sender is assumed to know what to do; 
after all, he sent the message.

I don't think we can require that all MX records (or A if no MX) for the 
domain in the MAIL FROM address be to MTAs that handle the UTF8SMTP 
extension; that would be the requirement for saying that "senders must eat 
their own dogfood if a non-delivery report is returned".

              Harald

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Nov 2006 00:21:38 +0100

Harald Alvestrand wrote:
 
> I don't think we can require that all MX records (or A if no MX)
> for the domain in the MAIL FROM address be to MTAs that handle
> the UTF8SMTP extension; that would be the requirement for saying
> that "senders must eat their own dogfood if a non-delivery report
> is returned".

Yes, not REQUIRED, nobody's forced to accept / read NDNs.  But a
warning in the form of a SHOULD maybe, otherwise they won't get
error reports, and could as well (or better) send MAIL FROM:<>

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 12 Nov 2006 09:38:00 +0200

Harald Alvestrand <[email-masked]> writes
in gmane.ietf.ima:

> I don't think we can require that all MX records (or A if no MX) for
> the domain in the MAIL FROM address be to MTAs that handle the
> UTF8SMTP extension; that would be the requirement for saying that
> "senders must eat their own dogfood if a non-delivery report is
> returned".
> 
>               Harald

There is some nasty situations.   I made following assumtions.

1)  RET=FULL     is asked by sender  so full mail need to 
    be returned on failure (just returning only header part on 
    text/utf8-header is not option.)

2)  Addresses gived on RCPT TO   _and_ MAIL FROM point to some 
    MX which do not announce UTF8SMTP. There may be other MXes
    which announce UTF8SMTP, but all MXes are not available on
    all points of delivery   (for example tcp connectivity
    between some host/MX  are limited by firewall or some host
    is down.)

    Ad             is sender

    A              is Ad's mailstore supporting UTF8SMTP

    Ao             is Ad's outgoing mail relay supporting UTF8SMTP

    Ai             is MX for domain of Ad which do not announce
                   UTF8SMTP

    Ri             is MX given for domain given on RCPT TO

    on picture

                                 +----------+
                                 |          |
                                 |   Ai     |
    +----------+ <-------------- |          |
    |          |                 +----------+
    |          |                      ^
    |   A      |                      |
    | utf8smtp |                 +----------+
    |          | ------------->  |          |
    +----------+                 |          |
                                 |   Ao     |
                                 | utf8smtp |
                                 |          |
                                 +----------+
                                      |
                                      |
                                      v
                                 +----------+
                                 |          |
                                 |          |
                                 |   Ri     |
                                 |          |
                                 +----------+

3) DSN   format uses message/utf8   for returning original email.
          
4) When message leaves utf8smtp, embedded message/utf8 are
   downgraded to message/rfc822 with same rules which apply
   utf8smtp message downgrading.

5) Message uses
        header-type:  UTF8

6) Ao    detects that it can not downgrade message

Now

a) Ao   generates DSN    which incudes original messgae inside of 
        message/utf8

   because DSN includes message/utf8, it DSN itself must include
       Header-type:  UTF8  

   RCPT TO      for DSN is A

then

b) Ao detects that next MX for A (ie. Ai) do not announce
   UTF8SMTP

then

c) Ao tries downgrade DSN.   

     - Downgrading DSN includes downgrading message inside of    
       message/utf8

     ->  But that was not possible to downgrade message inside of
         message/utf8  (after all that was reason why DSN was generated)

        -> So next option is generate DSN because downgrade fails

           but now there is MAIL FROM:<> 

           no DSN

So with these assumptions end result is that sender will not get
warning that downgrade of original mail fails.

So some assumption must be changed.    Which one?

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 12 Nov 2006 09:59:08 +0200

> Of course there may be other usages. DSNes was discussed?

On draft there is no mentioned usage on DSN notify.  
On this case it is

    5.3.  Attaching internationalized email message 

chapter which mostly apply.    It is NOT

    5.2.  Downgrading of internationalized email message 

chapter.

This 
   5.3.  Attaching internationalized email message

may perhaps need some additional text if it used on DSN.
However that do not assume that attaching is done on MUA
so on itselft it works.

Chapter 

    5.3.  Attaching internationalized email message

seems not mention handling of error conditions as

    5.2.  Downgrading of internationalized email message

does. Seems that I forgot add that text (anyway that 
must differentiate MUA and attaching message to DSN on MTA. )

Chapter

    5.1.1.  Encapsulation of recursive part 

defines output also on several cases where input is illegal,
but mentions that these are error conditions. Handling
of these error conditions are then defined on other chapters
which refer to that chapter.   Clearly on DSN case best
handling is just produce output and otherwise ignore error 
condition.

However using 
       multipart/utf8-encapsulated; type=message; ...

on DSN for attaching original message is not very good
on situation when everyone supports UTF8SMTP.

/ Kari Hurtta