[Mimedefang] 0-byte attachments

Stewart mimedefang at f8.com.au
Mon Nov 28 03:24:21 EST 2005

[Apologies for being flustered and hitting send before i'd added some  
proper diagnostification :-) let's start again]

Hi List..

mimedefang 2.51-2 on debian with sendmail 8.13.1-16, clamav 0.85.1-2  
and spamassassin 3.0.2-1 on a 2.4GHz Celeron with 2G RAM is working  
like a charm, until....

All of a sudden in the last week or so i'm getting complaints of 0- 
byte attachments* appearing from various senders via various relays.  
I haven't changed my MD config in months so initially i blamed sender- 
side virus activity generating fake messages. Furthermore i can't see  
anything in my logs that would indicate mimedefang has suddenly  
decided to remove attachments without warning - lots of sober-killing  
activity but the regular messages aren't being logged irregularly, so  
far as i can see.

but still. something untoward is happening and it involves missing  
mime parts, as per this example message body:

Content-Type: multipart/mixed;
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Scanned-By: MIMEDefang 2.51 on

This is a multi-part message in MIME format.

Content-Type: multipart/alternative;

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Content-Type: application/vnd.ms-excel;
         name="IN - 2006 1POS order form 112505.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IN - 2006 1POS order form  



..so MD would have to be under suspicion at this stage - well perhaps  
it's MD/Sendmail and the unusually high number of simultaneous  
connections caused by the sober attack.. but md-mx-ctrl seems happy:

# md-mx-ctrl  msgs
# md-mx-ctrl  status
Max slaves: 10
Slave 0: idle
Slave 1: stopped
Slave 2: idle
Slave 3: stopped
Slave 4: stopped
Slave 5: stopped
Slave 6: stopped
Slave 7: stopped
Slave 8: stopped
Slave 9: stopped
# md-mx-ctrl  load
Load:             Msgs:       Msgs/Sec:    Avg ms/scan:   Avg Busy  
10 Sec               0            0.00             0.0            1.00
1 Min               1            0.02          2171.0            1.00
5 Min               6            0.02           792.8            1.00
10 Min              15            0.03           589.1            1.00

The only clue i can find from the mail log is thus:

> Nov 25 17:09:35 myserver sm-mta[28204]: jAP69Y0C028204:  
> from=<person at isp.net.au>, size=78548, class=0, nrcpts=2,  
> msgid=<000501c5f186$c1626550$0800000a at computer>, proto=ESMTP,  
> daemon=MTA, relay=04.mx.isp.com [ip.ip.ip.ip]


> Nov 28 16:23:20 myserver sm-mta[3206]: jAS5NJWx003206:  
> from=<person at isp.net.au>, size=185514, class=0, nrcpts=2,  
> msgid=<000501c5f3db$c6facdc0$0800000a at computer>, proto=ESMTP,  
> daemon=MTA, relay=02.mx.isp.com [ip.ip.ip.ip]

which is the exact same message - first time it came through with an  
empty attachment but when resent the attachment came through  
unharmed. (fwiw, a .zip file but other file types have also gone  
missing including .pdf and .jpg which aren't in MD's list of bad  
filenames either) I can see the size= difference there but is that  
log entry before or after it's been through mimedefang, i'm not sure?

Anyway after some more forensics i'm starting to think that i may  
have inadvertently solved the problem on the weekend when i did a bit  
of a disk-space-juggle to free up some room on the /var and /  
partitions.. it would seem when the users were complaining to me  
earlier today they were neglecting to mention this all happened last  
week and doesn't seem to have happened today.

So right now my panic subsides, just slightly, but i'd like to know  
why mimedefang might be passing on messages without their attachments  
and not warning the users inline, or me via syslog, that there's some  
sort of problem ... that wouldn't be an approved behaviour i'm sure! :-/

lastly fwiw here's the md.conf (the filter is pretty much the default  
slightly tweaked for local needs)

KEEP_FAILED_DIRECTORIES=yes  #no sign of any failed directories  
either now you mention it

many thanks for your time again and (hopefully) suggestions. :)


More information about the MIMEDefang mailing list