ZMailer 8BITMIME vs. Mercury

["Barry Bouwsma (Hacker in Košice)" <barryb@ccsun.tuke.sk>]

    I have been bouncing mail messages off the ZMailer machine in Finland 
to see how well it copes with talking with 8BITMIME ESMTP servers and 
those which do not support 8BITMIME.  I have a few interesting results...

    First, I am aware that ZMailer's support for 8BITMIME downgrading is 
pretty minimal and only works for text/plain with a 
Content-Transfer-Encoding: header in the initial header field.  This 
means that ZMailer would fail to recognize a MIME multipart/mixed 
message, one part of which is text/plain with 8BIT C-T-E, as a valid MIME 
message, and instead would add the Q-P header and convert the entire 
message, including parts, to Q-P, thus resulting in 
charset=3DISO-8859-1 headers within.
    Are there plans to improve the 8BITMIME awareness to correctly handle 
multipart messages, parts of which could have C-T-Es of 8BIT?

    Also, I was bouncing C-T-E 8BIT mails via ZMailer to other machines 
which claimed to speak 8BITMIME ESMTP to see how well their 
implementations are.  I found something interesting, sending mail to a 
machine running Mercury (for Novell LAN), which, even though it appears 
to support 8BITMIME ESMTP, ZMailer appears to believe it does not, and so 
ZMailer performs the transformation to Q-P encoding before passing the 
mail along.  Here's the headers of the bounce message I deliberately created:


Return-path: <@nic.funet.fi:bbouwsma@cap.gwu.edu>
Received: from nic.funet.fi by tdc.umtri.umich.edu (Mercury 1.11);
    Sat, 13 Aug 94 3:54:10 GMT-5
X-Warning: Original message contained 8-bit characters, however during
           the SMTP transport session the receiving system was unable to
           announce capability of receiving 8-bit SMTP (RFC 1425-1428),
           and as this message does not have MIME headers (RFC 1341) to
           enable encoding change, we had very little choices.
X-Warning: We ASSUME it is less harmfull to add the MIME headers, and
           convert the text to Quoted-Printable, than not to do so,
           and to strip the message to 7-bits.. (RFC 1428 Appendix A)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: QUOTED-PRINTABLE
Received: from cap.gwu.edu ([128.164.140.32]) by nic.funet.fi with SMTP id <91251-3>; Sat, 13 Aug 1994 10:55:15 +0300
Received: (from bbouwsma@localhost) by cap.gwu.edu (8.6.9/8.6.9) id DAA26131; Sat, 13 Aug 1994 03:55:37 -0400


    However, a manual port 25 connection with this Mercury machine 
appears to reveal nothing wrong which should cause ZMailer to need to 
perform the downgrade.  Can you explain why ZMailer and Mercury do not 
seem to see eye to eye when it comes to 8BITMIME ESMTP?  Thanks...


ccsun{1}% telnet tdc.umtri.umich.edu 25
Trying 141.211.187.26 ...
Connected to tdc.umtri.umich.edu.
Escape character is '^]'.
220 tdc.umtri.umich.edu Mercury SMTP server ready.
ehlo ccsun.tuke.sk
250-tdc.umtri.umich.edu Hello ccsun.tuke.sk; ESMTPs are:
250 8BITMIME
mail from: <barryb@ccsun.tuke.sk> body=8bitmime
250 Sender OK  - send RCPTs.
quit
221 tdc.umtri.umich.edu Service closing channel.
Connection closed by foreign host.
ccsun{2}% exit


    I haven't checked to verify that ZMailer will communicate with other
8BITMIME-compliant ESMTP servers, such as PMDF or other ZMailers without
downgrading.  As you might guess, I'm pushing to see that 8BITMIME ESMTP
gets adopted fairly widely and rapidly without any serious problems, but
if it's handed a multipart message with some 8-bit data by an MUA and
can't properly downgrade the message to Q-P, this could be a drawback...
Also, if ZMailer is performing unneeded conversions...


Barry Bouwsma, now in Switzerland
<barryb@ccsun.tuke.sk>
<bbouwsma@cap.gwu.edu>
<ag786@yfn.ysu.edu>