Re: Zmailer's automatic conversion to Q-P

[mea@nic.funet.fi]

> It appears that zmailer's 8bit to Q-P may be suboptimal.  Lines like
> this
> 	asdf asdf asdf ... asdf.
> can be converted to
> 	asdf asdf asdf ... asdf=
> 	.
> which means bad luck.
> 
> .
> 
> It won't necessarily break anything, as the previous line proves, but
> it does expose the message to MTA bugs.

	Yes, although previously I have (I recall) thought that
	those buggy systems get what they deserve, but as we can
	do it easily here, why not doing it.

> Perhaps the conversion logic (near line 2170 of transports/smtp/smtp.c)
> should be changed to
> 
> 	    /* Any other char which needs quoting ? */
> 	    if (c == '='  ||  c > 126 ||
> 		(column == 0 && c == '.') ||
> 		(c != '\n' && c != '\t' && c < 32)) {
> 
> or even to
> 
> 	    /* Any other char which needs quoting ? */
> 	    if (c == '='  ||  c > 126 ||
> 		(column == 0 && (c == 'F' || c == '.')) ||
> 		(c != '\n' && c != '\t' && c < 32)) {
> 
> to work around the >From problem too?

	Neither of these should matter in SMTP transport, but
	carrying forward to other transports and/or to the
	classical UNIX mailbox file, at least the "From " does
	matter (depending on your email client..)

> It's not pretty, but I think making QP output uglier and still valid
> is better than exposing mail to possible truncation.
> 
> --Arnt

	/Matti Aarnio

PS:	I have been silent lately as I finally got enough
	fed up with two to four kB per routed user memory
	consumption, and I resurrected the  libsh/listmalloc.c,
	and related machinery in the router script language.
	It does nearly work now; except for some aspects
	of script variable management.

	Also beside of doing my official work, I have been
	adding large-file-summit code to Linux 2.1/2.2.
	Now it supports files up to 16 TB at i386 without
	using too much of cumbersome 64-bit arithmetics at
	the register-starved processor...  For curious:
		ftp://mea.tmt.tele.fi/linux/LFS/