Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt)

From: John C Klensin <[email-masked]>
Date: Sun, 08 Oct 2006 10:57:30 -0400

--On Sunday, October 08, 2006 14:48 +0300 Kari Hurtta 
<[email-masked]> wrote:

> "Yao Jiankang" <[email-masked]> writes in gmane.ietf.ima:
>
>> as you said, implementation of RFC 3030 is not common while
>> 8BITMIME is popular.
>>
>> So implementing EAI with 8BITMIME support is easier than
>> implementing EAI with BINARYMIME support.
>>
>> On my view, I still prefer 8BITMIME support while announcing
>> UTF8SMTP capability .
>>
>>
>> Yao Jiankang.
>
>
> My impression  is that most MTAs are lying when then announce
> 8BITMIME capacity.
>
> Announcement of 8BITMIME includes promise of downgrading
> message. I know some MTAs which can be configured to announce
> 8BITMIME although they newer will downgrade message.

Actually, it includes no such promise.  Read the spec carefully. 
8BITMIME can be announced/advertised if one can accept and 
handle it properly.  "Properly" includes either downgrading or 
bouncing when a next-hop is encountered that does not support 
the option.  If I'm an SMTP server and announce and accept 
8BITMIME content, I am obligated to not trash the bits.  But, if 
then become an SMTP client and the next hop does not offer the 
option, I may bounce as an alternative to downgrading.  In 
particular, the text says:

   A client SMTP has two options in this case: first, it may
   implement a gateway transformation to convert the message
   into valid 7bit MIME, or second, or may treat this as a
   permanent error and handle it in the usual manner for
   delivery failures.

> Effectively 8BITMIME is mutated to be "I'm 8-bit clean" but do
> not include promise that message can be delivered without that
> 8-bit is lost on rest of path.

It is a bit more than "8 bit clean", since meaningful MIME 
support is required.

> I'm thinking of idea that UTF8SMTP  itself (without 8BITMIME)
> includes promise of 8-bit clean implementation. Then without
> 8BITMIME it just means  bounce if next hop requires
> downgrading.

I don't see that, perhaps because you meant "with" in one of the 
two places where you wrote "without", but even then.  UTF8SMTP 
requires support for UTF-8 headers, which implies rather 
different parsing flags/ conditions than normal MIME/822 
headers.  It might even change the format of the trace fields 
inserted by the MTA, although I personally continue to resist 
that for other reasons.

> Hmm.  However that means problems if next hop announces
> UTF8SMTP without 8BITMIME and message was received with
> BODY=8BITMIME.  This means that message body must be converted
> (otherwise MTA is laying about 8BITMIME announcement) but
> headers can be kept on utf-8.

You are identifying some, but only some, of the reasons why the 
initial specs suggested that 8BITMIME was a requirement. 
Without it, not only does one have to face this problem, but a 
whole series of header encoding problems as well.

But let's turn this around, using the principle that having more 
different options and way of doing things is typically a threat 
to interoperability, not a help.  Do you have a strong argument 
for _not_ requiring that 8BITMIME be supported if UTF8SMTP is? 
It is pretty easy to demonstrate why having them linked makes 
things easier... I think that demonstration has been provided 
already.

     john

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

---

From: Kari Hurtta <[email-masked]>
Date: 09 Oct 2006 16:36:24 +0300

John C Klensin <[email-masked]> writes:

> <[email-masked]> wrote in gmane.ietf.ima:
> 
> Actually, it includes no such promise.  Read the spec
> carefully. 8BITMIME can be announced/advertised if one can accept and
> bouncing when a next-hop is encountered that does not support the
> option.  If I'm an SMTP server and announce and accept 8BITMIME
> content, I am obligated to not trash the bits.  But, if then become an
> SMTP client and the next hop does not offer the option, I may bounce
> as an alternative to downgrading.  In particular, the text says:
> 
> It is a bit more than "8 bit clean", since meaningful MIME support is
> required.

Following is one example of mailer. Quote from documentation:

  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.

This either do not mention that it will bounce message.

Another example of mailer: http://cr.yp.to/smtp/8bitmime.html
( http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html )

/ Kari Hurtta

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Oct 2006 15:38:04 -0400

--On Monday, 09 October, 2006 16:36 +0300 Kari Hurtta
<[email-masked]> wrote:
 
>...
>       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.

I did not claim that there were no stupid, lying, non-conformant
systems out there.  Of course there are.  The assertion here
that "the modern Internet is completely 8-bit transparent and
clean" is just nonsense... unless, of course, one defines any
system that doesn't meet their criteria for "8-bit transparent
and clean" as "not modern".  The rule is exactly as I stated it:
if they advertise the option, they are required to either
downgrade or bounce.  The advice above is equivalent to "'just
send 8' and advertise the 8BITMIME option so as to give
permission for that".  It _will_ cause problems and, certainly,
it is not an excuse for encouraging similar things in
eai-smtpext.
 
> This either do not mention that it will bounce message.

See above.

> ( http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html )

And that particular system is widely known to be non-conformant
with 2821 as well as with many of the associated
options/extensions.

    john

---

From: Kari Hurtta <[email-masked]>
Date: 10 Oct 2006 07:44:33 +0300

> > Following is one example of mailer. Quote from documentation:
<...>
> systems out there.  Of course there are.  The assertion here

My text was:
     8BITMIME capacity

Other was just explanation. But perhaps that "most" is incorrect.
Perhaps it is just "some" ?

/ Kari Hurtta