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

[Michiel Brandenburg]

On 20-6-2011 9:50, Steffen Kaiser wrote:

> 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.

This sounds like something we both ran into sometime back handeling 
socket map features.  Looks like master - slave communication 
desyncronizes.  I don't think it has to do with the way the 
smfi_set{ml}reply code works (although we can have another potential 
problem there)

This is probably what's happening, the custom perl code is sending back 
[from filter_sender] a message that is larger than the maximum message 
size allowed between the perl code and the multiplexor.  Sometime back 
we had this issue when the socket map reply was larger:

http://lists.roaringpenguin.com/pipermail/mimedefang/2007-June/032936.html

The code used in mimedefang.pl looks like this

print_and_flush("ok -1 $msg $code $dsn $delay\n");

If the combined string is larger than the internal buffer things go 
sideways, and that will desyncronize that slave.

To bypass the problem in the past the buffer size made bigger but the 
potential for the problem still exists.  Looking at the proposed change 
from

http://lists.roaringpenguin.com/pipermail/mimedefang/2008-April/033974.html

Was this patch ever applied or reverted ? I can't find the altered 
buffer size anywhere in the new code and it seems MAX_CMD_LEN is 4k 
MAX_MAP_REPLY_LEN is not used.

Although this might not explain the 1.5K message sent back from 
filter_sender as that would still be smaller than the 4k limit even if 
combined in print_and_flush.

BTW as side note .. smfi_set{ml}reply will only accept messages that are 
980 chars or smaller per line, if larger errors occur and mimedefang 
does not check the returned size in do_reply.

Hope it helps
--
Michiel Brandenburg