[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZMailer 8BITMIME vs. Mercury
> 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...
(Yeah, against 'not quite the lattest transports' system..
There is a genuine bug or two too, though.)
> 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=ISO-8859-1 headers within.
I think this is/was due to a bug in EHLO-feature recognizer.
(The new code is not yet at nic.funet.fi, and oj287.utu.fi
isn't very active at routing anything.. router bombs with
XMEM+MALLOC_TRACE but that is another story entirely.. )
> Are there plans to improve the 8BITMIME awareness to correctly handle
> multipart messages, parts of which could have C-T-Es of 8BIT?
Yes, and now that I have spent some time at looking really
deeply "under the hood", it becomes apparent that old approach
of using buffer-oriented state-machine structure can't easily
accomodate MIME-converters. Too bad, that buffer-stuff is
REALLY powerfull at pushing SMTP.. (Old benchmark: Sun3->Sun3
ran SMTP at 300 kB/s.. I guess SPARC-10 -> SPARC-10 could kick
it close to 1 MB/s, which means saturated ethernet..)
I appears I need to rewrite it in line-oriented fashion..
(For easy recognition of multiple bodyparts.)
> 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:
Yeah, the BUG..
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
PMDF, and Zmailer answers with a lot more feature-stuff, and thus
I never spotted that the last line ("250 " -- 2 5 0 space) is not
tested for ESMTP-feature token..
....
> 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...
At my home-site (nic.funet.fi is nobody's "home", it is popular
network server..) we have about half of our users on VAX running
PMDF, and I sure would have noticed problems in there :)
It is lucky that I have "Serious Science" machines with which
I can do oddball tests so that my users won't notice buggy
intermediate cases -- usually...
> Barry Bouwsma, now in Switzerland
> <barryb@ccsun.tuke.sk>
> <bbouwsma@cap.gwu.edu>
> <ag786@yfn.ysu.edu>
/Matti Aarnio <mea@utu.fi> <mea@nic.funet.fi>