[EAI] UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp (Re: Not a good reason? (Re: Minutes from Prague (fwd)))

["Kari Hurtta" <[e-mail]>]

Harald Alvestrand <[e-mail]> writes in gmane.ietf.ima:

> Charles Lindsey wrote:
> > On Fri, 11 May 2007 23:28:21 +0100, Chris Newman
> > <[e-mail]> wrote:
> >
> >> Charles Lindsey wrote on 5/11/07 16:59 +0100:
> >>> And since it is the case that any message/utf8smtp that is
> >>> invented will
> >>> not interoperate with the existing network, because many existig (and
> >>> compliant) MTAs will fail to downgrade it when sending it to
> >>> non-8BITMIME
> >>> agents, I do not see how any such beast could be defined.
> >>
> >> I question the claim that an MTA which passes material outside the
> >> US-ASCII octet range to a non-8BITMIME server is standards
> >> complaint.
> >
> > Indeed. Correct behaviour for an MTA that finds it has 8bit data
> > that it cannot downgrade to send to an non-8BITMIME system is to
> > bounce the message back to the sender. However, it is known that
> > some MTAs do, in fact, attempt to send the 8bit stuff as-is in that
> > situation, and some truncate the 8th bit, which is worse IMO.
> >
> > But, given that the 'correct' behaviour is to bounce, in this case
> > this means bouncing a DSN back to the Reporting MTA, which is not
> > really in anybody's interest. Therefore, it would be quite wrong for
> > us to define the EAI DSN extension in such a way that bouncing of
> > the DNS was inevitable in such situations - especially as there are
> > two other ways in which it could be defined (using
> > application/message-utf8smtp or message/rfc822) which  entirely
> > avoid the problem.
> The correct behaviour when sending a DSN is to use a MAIL FROM of <>.
> 
> The correct behaviour when bouncing a message with MAIL FROM <> is to
> discard the message.
> 
> Next question?

Yes.   And therefore DSN on lost, if it reaches 8BITMIME to
ASCII gateway.

Of course it is unlikely that it reaches 8BITMIME to
ASCII gateway when original message, which caused DSN, was 
UTF8SMTP message.  To avoid these border cases, UTF8SMTP to 
8BITMIME gateway is better downgrade this DSN. 

Specially many MTAs exists which do not support 8BITMIME. They
can configured announce 8BITMIME, but then they just-send-8bit.
More about that on later on this message. Therefore that border
case where next host do not announce 8BITMIME is quite possible
and common.


Equal important case is when UTF8SMTP message is attached to 
some message and message is sent to ASCII user. 

Possible downgrade alternatives for UTF8SMTP to 8BITMIME gateway is 
discussed later on this message.   Frank Ellerman is saying that that 
downgrade must be done on 8BITMIME to ASCII gateway. But there is problem:
   When mail is leaved UTF8SMTP universe, there is no any guarantee
   that next 8BITMIME to ASCII gateway knows anything about
   these message/utf8smtp and other new message/* types. Therefore 
   correct place handle this is on  UTF8SMTP to 8BITMIME gateway.


  +---------------------------------------------------------+
  | ASCII universe                                          |
  |                                                         |
  |   +--------------------------------------------------+  |
  |   | 8BITMIME universe                                |  |
  |   |                                                  |  |
  |   |   +-------------------------------------------+  |  |
  |   |   | UTF8SMTP universe                         |  |  |
  |   |   |                                           |  |  |
  |   |   |                                           |  |  |
  |   |   |                                           |  |  |
  |   |   |                                           |  |  |
  |   |   +-------------------------------------------+  |  |
  |   |                                                  |  |
  |   +--------------------------------------------------+  |
  |                                                         |
  +---------------------------------------------------------+



Seems that currently that (subset of) WG wants that message/utf8smtp 
is sent as is from UTF8SMTP universe to 8BITMIME universe; that is 
with content-transfer-encoding 8bit.


That itself does not violate RFC 2045 "EXPRESSLY FORBIDDEN"
rule.  However if that is specified that way, it is saying:

   * 8BITMIME universe to ASCII universe gateways must
     violate standards, otherwise that does not work.


I do not think that this is wise message to be sent.
Of course it is possible that actually all implementations
violate standards, but that is hard to prove.

I oppose that attached 8BITMIME messages are sent as 
message/utf8smtp to 8BITMIME universe.


UTF8SMTP universe is that area which knows these new types.
UTF8SMTP extension for SMTP is defined so that experient can 
be compatible with existing software.


When message/utf8smtp type with 8-bit content-transfer-encoding 
is sent from  8BITMIME universe to ASCII universe, there is 
following possibilities for gateway:

      (1) "bounce" message instead (or discard on case of DSN) 
           -- that is case where can be said that this 
              experiment does  not work.

      (2) convert 8-bit to quoted-printable or base64 --
          on that case it is violating standards (A2)

      (3) send 8-bit as is -- on that case it is
          violating standards (A3)

      (4) downgrade message/utf8smtp. This is corresponding
          that RFC 2045 says that encoding must be done
          at the innermost level.  However most of 8BITMIME
          to ASCII universe gateways knows nothing about
          message/utf8smtp. If it knows about message/utf8smtp,
          it is from UTF8SMTP to ASCII universe gateway instead.

      (5) strip 8-bit to 7-bit  -- on that case it is violating 
          standards (A5)       


A2: RFC 2045 "EXPRESSLY FORBIDDEN" rule:

   Certain Content-Transfer-Encoding values may only be used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded.

A3: RFC 1652 "under any circumstances" rule:

   If a server SMTP does not support the 8-bit MIME transport extension
   (either by not responding with code 250 to the EHLO command, or by
   not including the EHLO keyword value 8BITMIME in its response), then
   the client SMTP must not, under any circumstances, attempt to
   transfer a content which contains characters outside the US-ASCII
   octet range (hex 00-7F).

A5: RFC 1652 "preserve data" rule:

   Once a server SMTP supporting the 8bit-MIMEtransport service
   extension accepts a content body containing octets with the high-
   order (8th) bit set, the server SMTP must deliver or relay the
   content in such a way as to preserve all bits in each octet.



There is several possible alternatives which UTF8SMTP to 8BITMIME
gatewaty may use when downgrading message which includes message/utf8smtp
mime type as on subpart.

 
      (1) Type message/utf8smtp can be replaced with message/rfc822 and
          content downgraded same way than top level UTF8SMTP message.

      (2a) Type message/utf8smtp can be replaced with application/message-utf8smtp
           and content is keep unaltered.

      (2b) Type message/utf8smtp can be replaced with 
           applicate/message; type=" message/utf8smtp" and content is keep 
           unaltered.

      (3)  Type message/utf8smtp can be replaced with 
           multipart/utf8-encapsulated and content is generated
           as on draft-hurtta-eai-encapsulation have specified
           (chapter "5.  Encapsulation").

      (4)  Type message/utf8smtp can be replaced with 
           multipart/alternative and content is generated as
           following:

           (4.1) First body part is type message/rfc822 and
                 content of that body part is downgraded from
                 original message/utf8smtp  same way than top level 
                 UTF8SMTP message.

           (4.1) Second body part is type application/message-utf8smtp
                 and content is form original  message/utf8smtp
                 unaltered.

           This alternative duplicates space usage, but is quite
           easy to handle for exiting MUAs.



On past discussions following MTAs are at least found which
do not support 8BITMIME (but can be configured to announce
8BITMIME):

     Communigate Pro:
          http://www.stalker.com/CommuniGatePro/SMTP.html

          Advertise 8BITMIME

          If your Server does not report the 8BITMIME capability, some mailers 
          and servers will MIME-encode all non-ASCII messages that they send to 
          your Server . This server-side encoding can cause troubles for many 
          old mail clients. To avoid these troubles, your Server should report 
          the 8BITMIME capability.

          Note:The CommuniGate Pro SMTP module never converts non-ASCII messages 
          into the MIME form itself, and (according to RFC1652) it should not 
          advertise the 8BITMIME capability. But the modern Internet is completely 
          8-bit transparent and clean, so it is safe to enable the Advertise 
          8BITMIME option, preventing other servers from doing unneeded 8bit-to-MIME 
          message conversion.

    Exim:
          http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo

          accept_8bitmime	Use: main	Type: boolean	Default: false

          This option causes Exim to send 8BITMIME in its response to an SMTP EHLO 
          command, and to accept the BODY= parameter on MAIL commands. However, 
          though Exim is 8-bit clean, it is not a protocol converter, and it takes no 
          steps to do anything special with messages received by this route. 
          Consequently, this option is turned off by default. 

    Qmail:
          http://cr.yp.to/smtp/8bitmime.html


http://en.wikipedia.org/wiki/8BITMIME lists also following MTAs which do not announce
8BITMIME:

    * Microsoft Exchange Internet Mail Service (through version 5.5)
    * Netscape Messaging Server 4.15
 

 
/ Kari Hurtta


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