[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:

  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>