[Mimedefang] Using values in X- headers for filtering

Ole Craig olc at cs.umass.edu
Wed Aug 20 19:49:00 EDT 2003


On 08/20/03 at 13:25, 'twas brillig and Kelson Vibber scrobe:
[...]
> This is not a good idea.  AFAIK, this will also trigger on any mail that 
> really is scanned by MailScanner and is found to be clean.
> 
> It's kind of like bouncing everything that claims to be sent by Outlook 
> based on the fact that a virus impersonates Outlook.

	You say that like it's a bad thing.

	</troll>

ObMD: 

	Had lotsa fun today after an upgrade; we went from MD 2.30/SA
2.50/RedHat 7.3 to MD 2.36/SA 2.55/RH9. We actually copied the system
disk, carefully upgraded the OS on the new disk whilst it resided in
another box, built sendmail and all the mail-handling packages, and
then changed the hostname and slapped the new disk into the old box.
(all non-OS stuff was on the RAID array on the actual server; only the
system disk was changed.)

	All this care didn't save us from the multiple-upgrades
gremlins. For quite a while after the cutover, I was tearing my hair
out over this:

mimedefang[16256]: Error from multiplexor: ERR No response from slave
sendmail[16255]: h7KFmNJk016255: Milter: data, reject=451 4.7.1 Please try again later
mimedefang-multiplexor: Slave 4 stderr: Out of memory!
mimedefang-multiplexor: Slave 4 ran out of memory -- possible DoS attack due to complex MIME?
mimedefang-multiplexor: stats 1061394518.539 EndFilter slave=4 nslaves=4 nbusy=2 numRequests=56
mimedefang-multiplexor: Reap: Idle slave 4 (pid 14887) exited normally with status 1 (SLAVE DIED UNEXPECTEDLY)
mimedefang-multiplexor: Slave 4 resource usage: req=56, scans=27, user=22.210, sys=2.440, nswap=0, majflt=16135, minflt=143056, maxrss=0, bi=0, bo=0
mimedefang-multiplexor: stats 1061394518.670 ReapSlave slave=4 nslaves=3 nbusy=2
mimedefang-multiplexor: stats 1061394518.671 EndFilter slave=6 nslaves=3 nbusy=1 numRequests=5
mimedefang[16313]: Error from multiplexor: ERR No response from slave
sendmail[16294]: h7KFmYJk016294: Milter: data, reject=451 4.7.1 Please try again later


	All of my mimedefang slaves were dying on OOM errors under
load, despite having tested correct on the alternate system. Now, I
*had* ported a hack to mimedefang.pl itself from the previous version,
so that of course was my first instinct for where the trouble lay. (my
hack instantiates TWO spamassassin objects per slave, one which will
do RBL/network lookup tests and one which won't. Slaves choose which
one to use based on whether the connecting system is "local"; we have
reasons for not wanting to disable spamscanning entirely for local
hosts but the SMTP transaction delay caused by the network tests is
unacceptable for someone connecting directly to port 25, e.g. a local
Pine user.)
	
	I cranked up the milter logging on sendmail and even rebuilt
mimedefang with debugging enabled, and was still mystified -- until I
looked at /etc/sysconfig/mimedefang. I had MX_MAX_RSS and MX_MAX_AS
set to 12000 and 35000, respectively; on a hunch, I cranked them both
waayy up, to 20000 and 400000. All of a sudden, my slaves were
expiring normally after 100 requests, instead of dying prematurely
(sometimes with as little as one request!) No more tempfailing, and
the load went down to sane levels.

	The same hack had been running fine under the previous system,
so it must be that one of the SW upgrades catalyzed enough bloat in a
single mimedefang slave footprint to push us into Alzheimer's
territory. (SA seems a likely bet, since its impact is doubled by my
hack, but I've no desire to run a controlled experiment to find out
for sure.) 

	Just thought I'd pass this along, in case anyone else runs
into the same stumbling-block.

	Cheers,
		Ole
-- 
Ole Craig * UNIX, linux, SMTP-ninja; news, web; SGI martyr * CS Computing
Facility, UMass * <www.cs.umass.edu/~olc/pgppubkey.txt> for public key
[...] Oh, shed thy mercy and thy grace / On those who venture into space.
			(R. A. Heinlein)



More information about the MIMEDefang mailing list