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

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 8 Oct 2006 15:10:23 +0800

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.

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 03, 2006 1:59 AM
Subject: Comment about draft-ietf-eai-smtpext-01.txt

> 
> draft-ietf-eai-smtpext-01.txt:
> 
> |   6.  Servers offering this extension MUST provide support for, and
> |       announce, the 8BITMIME extension [RFC1652].
> 
> 
> |   Support and use of this extension requires support for 8BITMIME.  It
> |   means that 8BITMIME MUST be advertised by the UTF8SMTP capability
> |   SMTP server.
> 
> 
> Perhaps also using of BINARYMIME (RFC 3030) is possible ?
> 
> At least both BODY=8BITMIME and BODY=BINARYMIME  are theoretically
> possible to occur with international mail.
> 
> ( Althoug implementation of RFC 3030 is not common. )
> 
> / Kari Hurtta

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

---

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

> On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability .

It occurs me that it is somewhat unclear what BODY -values can be on EAI mail.

If non-ascii characters is only on envelope, can it be:

MAIL FROM:<[email-masked]> BODY=7BIT ALT-ADDRESS=[email-masked]
RCPT TO:<[email-masked]>
DATA
From: [email-masked]
To: [email-masked]
Subject: Ticket #XYC-234-VNC

Ticket closed.
.

In other hands if it is required to use  BODY=8BITMIME, then also BODY=BINARYMIME
is forbidded.

/ Kari Hurtta

> > / Kari Hurtta_______________________________________________
> IMA mailing list
> [email-masked]

---

From: Kari Hurtta <[email-masked]>
Date: 08 Oct 2006 14:48:01 +0300

> On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability .

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.

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.

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.

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. 

/ Kari Hurtta

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 08 Oct 2006 23:34:56 +0200

> On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability .
The current text says that 8BITMIME is REQUIRED for conformant UTF8SMTP 
implementations.
They are free to implement BINARYMIME if they want to, but it's not 
required.

I think that's a wise choice.

                      Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 09 Oct 2006 15:37:49 +0100

> EAI with BINARYMIME support.

I doubt that any server that ofers BINARYMIME fails to offer 8BITMIME as  
well, so the question hardly arises.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 09 Oct 2006 15:46:51 +0100

> they newer will downgrade message.

Yes, it is well known that happens, and it usually works because nearly  
all servers support 8BITMIME, so downgrading is almost never needed. But  
it is not our job to get involved in the rights and wrongs of that.

OTOH, is is NOT true that bearly all servers are 8-bit clean as regards  
the headers (sendmail is the most notable one that isn't). Therefore we  
need to write our standard so that downgrading (or maybe rerouting) is  
REQUIRED. Perhaps in 15 years time when all servers can be considered  
8-bit clean in the headers, people will start omitting the downgrade code  
even if they announce UTF8SMTP (maybe some future standard may even make  
that official). But again it is not our job to take that decision now.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 10 Oct 2006 17:32:11 +0900

I agree.     Regards,   Martin.

At 06:34 06/10/09, Harald Alvestrand wrote:
>The current text says that 8BITMIME is REQUIRED for conformant UTF8SMTP implementations.
>They are free to implement BINARYMIME if they want to, but it's not required.
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Kari Hurtta <[email-masked]>
Date: 11 Oct 2006 22:49:43 +0300

"Charles Lindsey" <[email-masked]> writes in gmane.ietf.ima:

> OTOH, is is NOT true that bearly all servers are 8-bit clean as
> regards  the headers (sendmail is the most notable one that
> isn't). Therefore we  need to write our standard so that downgrading
> (or maybe rerouting) is  REQUIRED. Perhaps in 15 years time when all

Yes.

Sendmail drops characters 128-159 from headers. This allows ISO-8859-* 
on headers, but not UTF-8.

/ Kari Hurtta

sendmail/collect.c:

                       if (c >= 0200 && c <= 0237)
                        {
#if 0   /* causes complaints -- figure out something for 8.n+1 */
                                usrerr("Illegal character 0x%x in header", c);
#else /* 0 */
                                /* EMPTY */
#endif /* 0 */
                        }