ietf-822
[Top] [All Lists]

Re: Regarding 8bitMIME support ...

2003-05-14 23:25:44

Hi Keith,
     Thanks a lot for reply.
     First of all, I can not get away with 7bit email servers by sending
8bit to them. I have to convert.

     So, I would need to convert each body part separately, based on its
CTE, and definitely I would need to choose between QP and base64 based on
the thumb rule as you specified.

      Now, consider a scenario where a mail client (supporting 8bit) sends
an email with a binary-converted-to-8bit attachment to my MTA, A. My MTA
connects to non-8bit remote MTA, B. Now, my MTA converts attachment from
8bit to base64, and sends it.
      Given this, when any mail client connects to MTA B, it downloads the
attachment and applies base64 conversion. Now, will that client be able to
retrieve original binary attachment, OR it will get 8bit attachment ?

       Also, could you please point out some mail clients dealing 8bit. I
could not find 8bit CTE configuration setting in outlook. It has just base64
and QP options.

       Any help is most appreciated.

Regards,
Dhananjay.


----- Original Message ----- 
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "dhananjay" <dhananjay(_at_)zlemail(_dot_)com>
Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>; <ietf-822(_at_)imc(_dot_)org>
Sent: Wednesday, May 14, 2003 8:33 PM
Subject: Re: Regarding 8bitMIME support ...



first, you cannot simply encode the entire message in quoted-printable or
base64.  each component of a message/rfc822 or multipart/* body part must
be
considered separately.

you should not re-encode a body part which is already 7-bit compatible
(i.e. you should not re-encode a 7bit, quoted-printable, or base64 body
part)

a binary or 8bit body part should be re-encoded.  as a rule of thumb,
if the content-type is text/* you can use quoted-printable; otherwise,
use base64.

Keith

p.s. these days almost all SMTP servers can deal with 8bit message bodies
(NOT
headers) even if they don't advertise the 8bitmime extension.  so there
are at
least a few  implementations that just send 8bitmime messages without
converting, and they mostly seem to get away with it.  it's certainly a
lot
simpler, and these days, it may even be less error-prone.  it's easy to
write
an 8-bit to 7-bit converter that corrupts messages.


Hi,
    I am working on enhancing MTA to support SMTP extensions (especially
8
bit MIME support). I am not clear about following issue :

    If remote MTA does not support 8bit MIME, then the sender MTA should
convert message from 8 bit to 7 bit and send the message. Now, there can
be
3 approaches (apart from perm error NDR generation) that I am aware of :
    1. The sender MTA should first convert whole message to original
encoding (octet stream), and then apply base 64 encoding on that to get
7
bit. But, this seems to be very length procedure and tedious processing.

     2. The sender MTA should apply quoted-printable encoding (one can
use
even base64 encoding also .. as final aim is 7bit output ?) directly on
8
bit MIME message. But, then we lose track of original message format
(say,octet stream). And, mail clients trying to retrieve message from
this
remote MTA will not be able to get original message format (octet
stream).
They will be able to decode the message to 8bit MIME, but not from 8 bit
MIME to octet stream (original message format), as we have lost track of
octet stream -> 8bit MIME encoding.

    3. The sender MTA should apply either quoted printable or base 64
encoding on whole message (except original headers), and send that as
attachment to original headers. But, this means, user will get original
message as a attachment.

     Now, I am not able to make out whether my approaches are right and
which way to go ?

Regards,
Dhananjay.