Jeff Lasman wrote:
> On Sunday 16 November 2008 01:18 pm, John Hall wrote:
>
>> You want to set the Ironport box as a smarthost:
>> http://www.exim.org/exim-html-current/doc/html/spec_html/ch47.html
>
> That would be great, John, and I appreciate your suggestion.
>
> But ...
>
> According the the link you suggested:
>
> <snip>
> If you want to send all mail for non-local domains to a “smart host”,
> you should replace the default dnslookup router with a router which
> does the routing explicitly:
> </snip>
>
> The ironport machine is cleaning the emails and then sending them to our
> exim-running box for final delivery. So all the domains ARE local
> domains. What I'm trying to figure out is how to handle the domains
> which need to use the Ironport machine through smarthost on the first
> route, and then deliver them locally when they're sent back from
> Ironport.
>
> So I need to send email originating on the server for email to only
> certain domains which are in the list ironport_domains.
>
> Can I use more than one list as a condition in a router? You've given
> me some suggestions to try; I'll be back with news on whether or not
> they work.
>
> Jeff
ISTR that you may need a manual router and acl_not_smtp flags to get
on-box originating traffic (shell accounts, daemons, web-thingies, et
al) to head for the Ironport on the first go, but not once returned from
it. Likewise, not all of those will necessarily pass thru Exim.
It may also simplify life w/r telling which is what if you can get the
Ironport to return all of its output over a bespoke port OTHER THAN port
25 (eg - port 24, and/or over an internal-only-IP, *IF* it is colocated).
Not to put too fine a point on it, but we would be more likely to use
Exim to front-end protect the Ironport (just the reverse of your goal),
leaving the Ironport in a milter/content-scanning-only role. Or powered
down.
;-)
Exim is about as good as it gets at 'qualifying' based on the nature,
behaviour, rDNS & RBL character, HELO forgery, etc of a connecting
server/zombot.
That's about 80 - 90% of 'offered' spam & malware here, leaving ClamAV
and a stripped-down SA with much less work to do.
Conversely, once the Ironport has been placed upstream, Exim can no
longer 'see' those characteristics of the originating connection, nor
can it reject 'in-session' so as to avoid out-of-session DSN with
attendant risk of backscatter.
All that up to the skill level of the Ironport admin, of course, but I'd
suspect you will be doing content-scanning AND delivery, albeit with
unfavorable spam scores, of traffic you might not have had to deal with
*at all* in an environment where Exim+ClamAV+SA do the whole thing 'in
band'.
YMMV,
Bill
