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

hi peter,

> There's no way to do what you're describing in a net-friendly manner
> using Exim, or any other standard MTA, on the edge server. You can use
> callouts to reject invalid recipients at the edge, but in order to
> reject on invalid content (spam, malware etc), the edge server needs
> to perform the scanning.

ah. i think i may have understood prior the prior advice i'd gotten,

> ... 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).

iiuc NOW, that refers ONLY to the,

> reject invalid recipients at the edge

you mention, leaving me with the probelm on content scan, is that correct?

> Doing the scanning on the internal server implies that the edge server
> has already accepted the message.

ok. so i got that part right ...

> The only action the internal server
> can take if it finds bad content is to generate a bounce message -
> this is inappropriate and potentiall abusive behaviour, since the huge
> majority of bad content has forged envelope senders - you end up
> sending the bounce to an innocent bystander.

ok. that's well-explained. thanks. and, rats!

> 2 possible avenues for you to explore:
>
> - configure the content scan on the edge server, but have it call a
> scanner on an internal server. This might work depending what
> scanner(s) you're using.

i'm using CLAMAV & SPAMASSASSIN. both of which can listen on either
UNIX socket or over TCP.

> Then the edge server can reject inline when
> it finds bad content - this is the right way to do it.

my main worry with this approach -- which may be something I have to
live with if i choose to do it -- is that the message will make
multiple network traversals from "edge" to "core", even for an OK
message.

from a design standpoint that just "seems" inefficient use of
bandwidth, but i have no experience (yet) -- just a guess/sense -- of
the real effect/magnitude of the problem on network usability, etc.

> - use a SMTP proxy on the edge server instead of an MTA. This will
> make the internal server do all the work.

per an earlier recommendation, i'd looked at ASSP as an SMTP proxy ---
but my understanding was that if deployed ON the "edge" router, the
'work' would be done there as well ...

am i misunderstanding where the scanning load would be? is ASSP not a
good example/implementation of what you had in mind?

and, how is this setup (e.g. ASSP@edge + EXIM@core) really any
different in functionality, other than more complex to maintain?

thanks much!