hi graeme,
> > is this 2-box config, with one Gateway "front-ending" one/many other
> > servers a fairly common implementation scenario?
>
> Yes, it is. It's also a well-documented way to generate backscatter,
> assuming that the "edge" Exim instance doesn't have full knowledge of
> the valid recipients of the "core" Exim. The fact that you are running
> Exim in the first place makes this less likely, as you can share
> userlists trivially (or "on demand" with recipient verification callouts
> from your "edge" server to the "core" server).
set LIGHTBULB = "ON"
aha. i've got some sense of what you're suggesting (a little foggy on
CALLOUTS ...), but, atm, no inkling as to how to do rcpt verify across
boxes -- yet!
> > mostly, yes. AND, an attempt to let the router/fw box do its job and
> > keep as much 'noise' off my LAN as possible. once an inbound email
> > passed all the non-content-scanning filters & incremental delays @ the
> > gateway, it' odds of being rejected "just" on virus/spam content would
> > be significantly lower -- not zero, i know.
>
> As long as you have consistent configuration on each machine, the
> likelihood of an AV/AS hit on the "core" machine is zero.
the two boxes, "edge" & "core", ARE consistently configured, _except_
that EDGE has no AV/AS scanning. i.e., data acl is simply
'empty/accept'.
iiuc, that still allows for an email -- e.g. from an 'infected' friend
-- that passes all non-content scans @ "edge" to make it to "core" and
GET a 'hit' on AV ...
no?
> > i'd considered this, but decided against because i thought i'd be
> > significantly increasing network/lan traffic due to "multiple passes"
> > of the offloaded message.
> >
> > which _seems_ to me a 'bad' way to do things.
>
> ...and is also not correct.
>
> The reality would be:
> Data Flow Type
> Message edge -> core AV scan
> Result core -> edge Hit/Not hit
> Message edge -> core SA Scan
> Result core -> edge SA report
> Message edge -> core Message delivery
>
> Note that the "Result" data is far smaller, in most cases, than the
> message itself; and that the first pass will only take place for
> messages with MIME parts of an appropriate type anyway (the malware
> condition is quite choosy, as it should be).
i understand, but am surprised by this ...
if, e.g., the AV scanner adds/modifies a header, then, since the
_message- is not passed BACK, rather just the RESULT, how does exim
get at the 'new' header.
hm. unless, it becomes SOLELY the responsibility of Exim to add/mod
headers based on the scan result. that actually makes some sense, and
i think i have answered my own question. :-}
> > am i just better off avoiding the gateway altogether, and passing the
> > message to the lan-based server in the first place? if so, that seems
> > counterintuitive ...
>
> Nope.
>
> Make sure your gateway has knowledge in some way of the valid recipients
> on your lan-based server, as previously mentioned. Run ClamAV on both
> machines (this way you will catch *outbound* virus infections, too), but
> SA on only one and call it accordingly from the gateway.
in my current scenario, i'm NOT using the "edge" exim as an OUTBOUND
gateway, only inbound.
i.e.,
mail from net -> edge (non-content scanning) -> core (inbound AV/AS
content scanning) -> core (imap delivery)
mail from LAN -> core (outbound AV scanning) -> net
the goal is _also_ to avoid ClamAV &/or SA processing loads on the
edge router (poor little thing is 'just' a headless 266MHz
geode/i586w/ 256 MB RAM)
thoughts?
> To reduce the load further, make use of Exim's ability to reject based
> on avrious other criteria. I have a number of machines at my fingertips
> which use fairly complex tests, but the first one - which is the most
> effective - is a logic test to check the incoming IP against three DNS
> blocklists, and reject the connection if 2 or more are hit. That stops
> your AV/AS being triggered in the first place.
my plan is to do the same (although, personally, i've found
checks/reject @ "edge" based on _just_ zen.spamhaus.org to be 100%
accurate ... 4 me & so far), in addition to calculated, incremental
delays for 'wonky' non-content hits.
if/when "core" IS hit, then AS DNSBL (non-"zen") checks score
incrementally, rejecvt over a set threshhold.
so, my 'homework' is to understand/figure-out-how-to:
> share userlists trivially (or "on demand" with recipient verification
> callouts from your "edge" server to the "core" server).
and understand its effect/gotchas.
any wiki/other references you might share? if not, off to google ...
thanks!
