Re: [exim] handling reject/deny comms in a 2-exim setup

Top Page
Delete this message
Reply to this message
Author: snowcrash+exim-users
Date:  
To: Graeme Fowler
CC: exim-users
Subject: Re: [exim] handling reject/deny comms in a 2-exim setup
hi graeme,

> So calling out to a network socket forces Exim to send the content -
> which in older versions of Exim was the unpacked MIME container, but now
> doesn't have to be (it depends on your config) - across the network.


Iiuc, that dependence is defined by whether or not whatever's
'listening' @ that network socket is capable of unpacking MIME itself,
yes?

In the case of ClamAV/clamd, even not-so-recent versions do the
unpacking nicely.

So, does Exim determine automagically (from the socket comm, perhaps?)
that it does not need to unpack first? If not, what option in the
calling ACL needs to be set/defined to prevent it?

> guess in the case of most MIME emails that means the entire email will
> be scanned, but it isn't really that expensive in terms of network
> traffic given that the mean message size for most installations is
> fairly small.

(snip)
> I did go on to say that the only time a message will get passed to the
> AV scanner is if it contains MIME parts; re-reading the code makes me
> question that assumption. Still, the question remains: why are you so
> concerned about your internal network traffic?


With repeated questioning from the list on this -- and especially
given your good point abt *mean* message size, I'm deciding to use
this solution.

I think I was naively reacting to the idea of a 50Mb mail (yes, I
occassionally get those ...). But, tbh, that's *very* occassionally.

Thanks.

> Reducing the amount of stuff getting through to your AV/AS is easy:

(snip)
> That way you reduce - greatly - the amount of cruft getting through to
> your AV/AS scanner, and you might find you can then run one (or both) of
> them on your edge box anyway.


Yup. I've got variations -- long as well :-) google is my friend! --
of these in place already.

And, I believe you, and others that have commented, are quite correct
in the effect that these should/will have on the volume of non-legit
mail ever hitting the AV/AS ...

> Also, if you "turn down" the AS rules a bit - turn off Bayes checking,
> for example - you'll reduce your CPU usage dramatically.


True.

Though, over time, I've developed a ruleset & Bayes DB that, for me on
my server(s), have a virtually-zero FP rate. Happy with that! And, I
like to watch SA's "blinken' lights" ;-)

For this current scenario, I'll keep the AV/AS scanners on the LAN
box, where CPU's cheap/available. My edge box is "filling-up" ...
_trying_ to keep it lean(er). At somepoint, I'll deploy beefier edge
boxem, and yes, the issue will go away.

Now, to figure out how to get "edge" Exim to store/queue to disk a
message in the instance any of AV/AS/LMTP-over-socket is
non-responsive and resubmit when up again ... yes, a different issue
:-)

Thanks for all the help!