[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ZMailer 8BITMIME vs. Mercury
- To: zmailer@cs.toronto.edu
- Subject: ZMailer 8BITMIME vs. Mercury
- From: "Barry Bouwsma (Hacker in Košice)" <barryb@ccsun.tuke.sk>
- Date: Tue, 23 Aug 1994 15:02:10 +0300
- Keywords: semtex assassinate NSA kibo AK-47 Marxist Saddam smuggle
- Organization: David Rhodes Rehabilitation School for the Criminally Insane
- Reply-To: Barry Bouwsma <barryb@tuke.sk>
- Summary: In which I prove that Time == Money
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>