[Mimedefang] Re: Mimedefang sending huge return via socketmap

David F. Skoll dfs at roaringpenguin.com
Fri Apr 25 10:43:24 EDT 2008


Hi,

I found the reason that MIMEDefang chokes on large map replies.  Any
map reply larger than MAX_CMD_LEN (4kB) will cause desynchronization in
the multiplexor protocol and all map lookups will mess up after that.

The following patch allows replies up to 64kB; you can probably
increase MAX_MAP_REPLY_LEN if you need to handle larger replies.

Unfortunately, a reply larger than MAX_MAP_REPLY_LEN will cause protocol
desynchronization; I have to add code to guard against that.

This patch is against "git master", but it should apply somewhat
cleanly to the current stable version.

Regards,

David.


diff --git a/mimedefang-multiplexor.c b/mimedefang-multiplexor.c
index c368773..eb6c33f 100644
--- a/mimedefang-multiplexor.c
+++ b/mimedefang-multiplexor.c
@@ -52,6 +52,7 @@ static void limit_mem_usage(unsigned long rss, unsigned long as);
 #endif
 
 #define MAX_CMD_LEN 4096	/* Maximum length of command from mimedefang */
+#define MAX_MAP_REPLY_LEN 65536 /* Maximum length of a map reply */
 #define MAX_DIR_LEN  512        /* Maximum length of working directory */
 #define MAX_STATUS_LEN  64      /* Maximum length of status tag */
 #define MAX_UNPRIV_CONNS 20     /* Maximum number of simultaneous unprivileged connections */
@@ -4021,7 +4022,7 @@ handle_slave_received_map_command(EventSelector *es,
     }
 
     /* Slave has been given the command; now wait for it to reply */
-    s->event = EventTcp_ReadBuf(es, s->slaveStdout, MAX_CMD_LEN, '\n',
+    s->event = EventTcp_ReadBuf(es, s->slaveStdout, MAX_MAP_REPLY_LEN, '\n',
 				receive_slave_map_answer,
 				Settings.busyTimeout, 1, s);
     if (!s->event) {



More information about the MIMEDefang mailing list