This one time, at band camp, John Pearson said: > <groan> it's obviously not my week for mail systems. > > I submitted this to BTS thinking you'd get a copy; the autoreply said > you didn't, so I forwarded you a copy. Thunderbird's default forwarding > style is as an attachment, which it labelled as 'inline > filename=<subject line>' which, of course, was rejected with > SMTP error from remote mailer after end of data: > host mail.lobefin.net [216.158.52.98]: 550 contains com file > (blacklisted).
Hmm - I didn't realize that that simple minded check would cause problems with real mail :( Well, that pending upgrade to a newer exim may be in order, to deal with mime stuff smarter. Sorry about that. > Please accept my apologies for this short-sightedness; I did (briefly, > just for a moment) consider the effect on the BTS itself, but my > understanding was that the debian mail server(s) used Sophos; I didn't > get as far as realizing that it would (of course) be mailed to you, and > wasn't aware that it would be also copied to the clamav list. > > I'll be more careful in future :) No - as far as I know the BTS does not do any sort of A/V scanning at all (maybe I'm wrong, I have to admit I've never really checked). Yah - I just ended up with a stuck exim process and a _really_ slow clamav. It was still processing some mail, though. And don't worry - it's better to have access to the file, even if it caused some momentary breakage, than to not be able to debug the problem. > As for DOS possibilities we're using exim4 + exiscan and > lists.us.dell.com are using sendmail; I ended up with a clamd process > and 'open' exim SMTP connection for each delivery attempt, eventually > resulting in our server rejecting all connections when it reached the > configured maximum number of simultaneous SMTP sessions; > lists.us.dell.com's logs show the issue as a timeout waiting for a > response to their DATA, and sendmail simply left the message on the > queue for next time. If the remote server delivers multiple messages in > a session and uses the same order each time (e.g., delivering in the > same order they were received), then they may be unable to deliver other > messages to us regardless of our SMTP session limit. > > BTW, is it possible to characterise what it is about the email which > triggers the bug? It looks like all linux-kernel digests from > lists.us.dell.com since 4-70 have a similar effect; at the moment I'm > 'whitelisting' their IP so they don't get scanned but I'd be happier if > there was some simple rewriting I could do to avoid the issue, and make > it practical to scan them. Basically, the problem is a bug in the parser/unpacker of the library. When you scan an email, you first break it down into component parts, and then scan the files individually. The problem is apparently the parser keeps reiterating over the same parts, breaking it apart over and over. Since it unpacks into $TMPDIR, for me this resulted in a basically full /tmp partition, which was what really hampered my ability to receive email (I could only get small ones :/ ) Right now, the only workaround is disabling the ScanMail directive in clamd.conf (which turns off the unpacker). Either that, or grab a CVS snapshot, or backport the (rather large and non-trivial) patch to fix it. All of these options kind of suck, but I am slowly working on #3. If upstream releases 0.84 before I work my way through the backport, I will of course just upload that. Since there has been no commit activity for almost a week, I am relatively hopeful :) Take care, and I will get this fixed and out as soon as I can. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
pgp5U4j4UlHeW.pgp
Description: PGP signature
