Re: RFC 1426 problem and solution

["Harald T. Alvestrand" <Harald.T.Alvestrand@xxxxxxxxxx>]

The problem is the case where you go

sender -> MTA (8BITMIME) -> MTA (7BIT) -> recipient.

If the message is refused by the first MTA, the user gets a pretty
quick idea of what is going on, and can take appropriate action,
such as selecting another C-T-E.
If the interaction is well-defined, it is easy to configure the
mailer to do it automagically, without the user (who probably
doesn't even know what a C-T-E is) being aware of it.

If the message is refused at the second MTA, the user will see this
as "if I send with C-T-E 8BIT, the message will bounce at random
times; better not use this", and, in my belief, 8BITMIME will
not become established except within a few enclaves - NOT a
solution that I would want.


The relevant part of RFC 1426 should be:


   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.

That is, if you accepted it using SMTP, bouncing it is NOT
an option.
John, Ned, do you think that even stronger language can be put into
place in the Draft Standard phase, since, obviously, this is not
strong enough to be seen by all people? Something like adding

   If the server relays it to another SMTP server, and this
   server does not support 8BITMIME, the server MUST implement
   a gateway transformation to 7bit MIME

I know this was a contentious issue in the WG, but I thought we
had settled it.

              Harald Tveit Alvestrand