[Mimedefang] set_reply returned MI_FAILURE (was Re: Multiplexor trouble)

Steffen Kaiser skmimedefang at smail.inf.fh-bonn-rhein-sieg.de
Mon Jun 20 03:50:53 EDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 19 Oct 2010, Steffen Kaiser wrote:

for the archives and in order to document the other trouble, here it is:

the problem:

> I've seen the following entries in the log, before this first line, there
> are only errors "no response from slave":
>
> Oct 15 00:10:47 ux-2s14 mimedefang[27529]: Error from multiplexor:
> .10.2010%2021:XX:%20IP%2087.230.54.44%20with%20name%20d [cut]
> Oct 15 00:19:27 ux-2s14 mimedefang[27529]: Error from multiplexor: ok 1 ok
> 250 2.1.0 0
> Oct 15 01:20:51 ux-2s14 mimedefang[27529]: Error from multiplexor:
> 10.2010%2020:XX:%20IP%2087.230.54.44%20with%20name%20ds87-230-54-44. [cut]

There were yet another error, which almost always preceeded the ones 
mentioned above:

mimedefang[32204]: set_reply returned MI_FAILURE

After I traced back every message that the particular slave had handled, 
beginning with the one producing such error, I found that filter_sender() 
returned a huge message back, about 1.5KB.

Checking sendmail v8.13's source, I found in libmilter/smfi.c:

"
/* for smfi_set{ml}reply, let's be generous. 256/16 should be sufficient 
*/
#define MAXREPLYLEN	980	/* max. length of a reply string */
#define MAXREPLIES	32	/* max. number of reply strings */

[cut]

 	if (message != NULL)
 	{
 		size_t ml;

 		/* XXX check also for unprintable chars? */
 		if (strpbrk(message, "\r\n") != NULL)
 			return MI_FAILURE;
 		ml = strlen(message);
 		if (ml > MAXREPLYLEN)
 			return MI_FAILURE;
 		len += ml + 1;
 	}
"

The problem with [\r\n], is already documented here: 
http://lists.roaringpenguin.com/pipermail/mimedefang/2006-January/029020.html

I sanitize all message texts returned to MIMEDefang like this now:

s/[\x00-\x1f\x7f]/ /g; s/\s+/ /g;
substr($_, 256) = '' if length($_) > 256;

Looks like that did the trick.

=============

Once such overlong reply poisons the connection, all next communication of 
that MIMEDefang slave fails, until it terminates (reasches its max number 
of requests or hits the idle timeout).

This is mimedefang v2.71 with sendmail v8.13.8, so more current 
implementations might not have this problem anymore.

Further error messages in log were:
Cannot chdir(/var/spool/MIMEDefang/...): No such file or directory
Cannot open COMMANDS file from mimedefang: No such file or directory
Cannot mkdir(Work): No such file or directory
couldn't open INPUTMSG: No such file or directory

Regards,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBTf773f41+pMevzVSAQIfiQf/Z5KkibY78EtXDBdoXyvLQzHiOBHeQy/r
nBjchw594tlmKgm8JcARKhcKo3NV44bzBb/Opp/+X4LiOCLJwBWxQBGvF7KIjzhT
9C+Bg0OF25Wz31DAGzmoEd02GrRQhN7yRYFBi0Z4P5lG8ZhxQ1mllwlbvCHb1a4P
dcABTMKq1fWvfR3PWPzEhGCHKKdQYuwRkx9x0tgJ10BJzQTZJ74NvzfnQdIFMYYc
Q7SPvZ4Ufsi3e8afakRzqP5R1+xXWRM6F7dOOHKYDwC1VVtSgfs02GQatlWYy3Wm
0sS5UhUXHThlEj+M2CLNEnM1At5ts/GvafO5zozQlr9O2TJwSZM4zw==
=tCs9
-----END PGP SIGNATURE-----



More information about the MIMEDefang mailing list