Autore: W B Hacker Data: To: exim users Oggetto: Re: [exim] Exim OOMing on 800K spam messages
Russell King wrote: > Hi,
>
> I've recently started having a problem with exim causing the machine
> it's running on to OOM on some emails - of around 800K. I know this
> machine can normally accept messages of up to around 8MB or so
> usually without problems.
..obviously not if your AV / mime scanner unpacks a deeply nested archive bomb..
ClamAV and others have limits which can be set on that...
>
> My exim logs show:
>
> 2007-11-10 06:25:39 H=out01.wanadoo.es [62.36.20.201] I=[78.32.30.218]:25
> Warning: RBL: warn: (johnalfred@??? listed at abuse.rfc-ignorant.org)
> 2007-11-10 06:25:53 1Iqjmm-0002fp-80 H=out01.wanadoo.es [62.36.20.201]
> I=[78.32.30.218]:25 Warning: bad content type: text/html
>
rfc_ignorant is just that. Blacklisted the entire *.de namespace for around 2
years 'coz they, not the Deutsch, were ignorant. Still doing it with other
entire <tld>s.
But if you are bothering to query them at all, why not apply the response?
> which are produced by my ACLs. No other log lines are produced before
> the OOM.
>
> When the OOM occurs, I have a single file in the exim spool directory
> (eg, 1Iqjmm-0002fp-80-D, being the message body) and the unmime'd
> message in the scan directory, containing some 80 or so attachments
> most of which contain lots of blank lines and a bit of text in the
> middle. The mime headers for each attachment are:
>
> --eresmas.com_dam31.wnet_197d7378a2378829a24c9b41bf2be669
> Content-Type: text/html; name="LatinMailAttach"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment
>
Google 'LatinMailAttach' and go see why your AV isn't blocking it.
> I suspect the shere quantity of attachments are causing exim to gobble
> up all available VM -
Not exim, per se - it is your scanner that is doing the unpacking.
Unless told otherwise, Exim would just pass it unopened.
I have no way to obtain any data or proof of that.
Sure you do.
First 'nice' exim AND the scanner down to something that insures your ssh
session will have enough resources to maneuver well.
In exim:
log_selector = +all
Then tail /var/log/maillog or grep the time range to see what the scanner
was up to at the time.
Likewise /var/log/messages should have a kernel whinging about rude behaviour.
> (stracing exim for 24 hours waiting for their next attempt is not going
> to be nice given the huge quantities of spam already hitting the server.)
>
Needless overkill. See above for a more 'focused' approach.
> The question is how to stop this happening. One short term solution
> would be to block the sender, but I suspect that if one spammer's
> started this approach, more will eventually follow.
>
Been going on for years, but ordinarily blocked early-on.
Speaking of which - some folks just shouldn't be running public networks.
That message should never have been allowed to traverse 62.36.20.201
But is neither the first such, nor the last. For others.
