Re: [exim] using exim with ironport preprocessor

Top Page
Delete this message
Reply to this message
Author: Jeff Lasman
Date:  
To: exim-users
Subject: Re: [exim] using exim with ironport preprocessor
Sorry for the delay in responding; the project has been on the back
burner for about three weeks <frown>.

On Sunday 16 November 2008 05:22 pm, W B Hacker wrote:

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


I'll look into that. Thanks.

> Likewise, not all of those will necessarily pass thru Exim.


I understand and my client understands. It's going to be his problem
for now.

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


We can do the port change easily; I'm not so sure of the separate IP.
So we'll go with a different port. Thanks again.

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


Yes, but it's not my system; we're only doing what the client has
requested. And what we've quoted a price on, unfortunately <smile>.

> Or powered down.


I like that <smile>.

But the client gets extra money from his clients.

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


I understand that fully and have a good exim.conf file which most of our
clients use.

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


Yes, our client knows he has to do all that Ironport; everything that
comes from Ironport will be whitelisted for delivery; if it can't be
deliverred it'll go to a catchall (ugh, I know).
>
> 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'.


I won't argue that.

I'm still moving forward.

Thanks!

Jeff
--
Jeff Lasman, Nobaloney Internet Services
P.O. Box 52200, Riverside, CA 92517
Our blists address used on lists is for list email only
voice: +1 951 643-5345, or see:
"http://www.nobaloney.net/contactus.html"