Mailing List Archive: exim: users

exim front-end to barracuda

Index | Next | Previous | View Threaded

jbparker at ualr

Nov 8, 2009, 10:54 PM

Post #1 of 7 (1070 views)
Permalink

exim front-end to barracuda

I am working through some problems with a new email routing
arrangement on our campus. We have been using a Barracuda spam
appliance delivering to a local mail system, and are migrating to
hosting user email with Google Apps. We will be migrating users
gradually, and rather than forward all users' email through the
Barracuda to the local system and then forward some of them on to
Google Apps, we (naively!) decided to point our MX records to a
"front-end" exim box that could do LDAP lookups for recipient
addresses and send email either directly to Google Apps or to the
local system via the Barracuda.

The problem with this arrangement (obvious to you, and now to me, but
unanticipated) is that the Barracuda doesn't get the chance to reject
the spam until after the front-end system has already accepted it,
making me a potential source of backscatter unless I do something
clever. The truly clever answer is a redesign, and I'm working on
that, but I also have a number of specific questions about dealing
with bounce messages within exim that I haven't been able to answer
from the manual or with the help of my smart friend Google. (I'm
using exim 4.63 that comes with RHEL 5.4, in case that makes a
difference with any of these issues.)

Again, I understand that these sorts of things are not substitutes for
rejecting during the SMTP connection, and I'm redesigning things to be
able to do that. Most of these were ideas that I had while coming to
grips with the problem, and even if they're bad ideas I want to
understand how exim works better than I do now.

QUESTION 1: How can I prevent bounce messages from being generated
locally, without truncating the envelope sender for successfully
generated messages?

Setting errors_to="" is the only way I've managed to turn off bounce
messages for a router, but it sets the sender to <> for any successful
messages, which just seems inelegant and causes some unintended
effects further downstream.

QUESTION 2: How can I configure different bounce behavior depending on
the code or text string returned by the remote SMTP server?

The closest thing I've found to this are the retry configurations that
can be made specific to certain SMTP return codes, but I didn't see
any way to have them throw the message away after it finally gives up
instead of generating a bounce. The only idea I have left for this is
using a system filter, but I feel like I might be missing something
simpler.

QUESTION 3: How can I identify locally generated bounce messages in a
router or ACL?

I've tried using "senders = :" , but that catches all bounce messages
passing through, whether they were generated by the localhost or not.
The log file doesn't have a host listed; just something like
"1N6aoX-0001tA-9R <= <> R=1N6aoX-0001t2-3c U=exim P=local S=4046".
I've tried using "hosts = :", which signifies local smtp in the
default ACL, but that doesn't seem to pick them up either. What am I
missing here?

QUESTION 4: Is there any way to require stronger sender verification
for responding with a bounce message than for the original receipt?

SPF records come to mind here. I may not be requiring SPF
verification to receive a message, but could I require it to return a
bounce? I suppose this is probably doable with the right router, if I
had the answer to the previous question.

QUESTION 5: This is philosophical instead of technical, but I'm still
trying to get my head wrapped around all the implications of the
backscatter problem. Are there *any* sorts of bounce messages that
are still practical to send out these days?

My reading has indicated that bounces for non-existent users or
over-quota conditions are frowned upon. What about network-level
problems that extend beyond the retry period... is bouncing for those
acceptable, or am I obligated to check if the host that eventually
needs to accept the message is currently reachable and defer at the
gateway if it isn't? It starts to seem as if in order to completely
avoid the possibility of backscatter, I'd have to avoid any sort of
tiered SMTP design and have all MX records pointed directly to the
final destination mail servers, which sounds like overkill.

QUESTION 6: Are there any options for doing this right that still
allow me to front-end the Barracuda with the exim box?

I'd love to be able to keep that box there for doing ad-hoc email
archiving, doing the LDAP-based split routing I described earlier,
doing more advanced rate-limiting than I can do in the Barracuda, and
just generally having the full power of exim as my gateway from the
internet. Running spam/virus filtering inside exim instead of using
the Barracuda is not really an option at this point. I've
experimented with doing callouts to the Barracuda, but it doesn't
reject the messages as spam until after it's received the message
body, which I don't see any way to do in the callout (after all, if it
succeeds, then at that point the message has been delivered). Is
there any way to practically use a Barracuda as the spam filter behind
exim?

Thanks to all for any insight you can provide.

-jbp

--
Jay Parker, Systems Manager, UALR Computing Services
jbparker [at] ualr 501-569-3345 http://ualr.edu/jbparker

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

chris+exim at qwirx

Nov 9, 2009, 12:45 AM

Post #2 of 7 (955 views)
Permalink

Re: exim front-end to barracuda [In reply to]

On Mon, 9 Nov 2009, Jay Parker wrote:

> We have been using a Barracuda spam appliance delivering to a local mail
> system, and are migrating to hosting user email with Google Apps. We
> will be migrating users gradually, and rather than forward all users'
> email through the Barracuda to the local system and then forward some of
> them on to Google Apps, we (naively!) decided to point our MX records to
> a "front-end" exim box that could do LDAP lookups for recipient
> addresses and send email either directly to Google Apps or to the local
> system via the Barracuda.
>
> The problem with this arrangement (obvious to you, and now to me, but
> unanticipated) is that the Barracuda doesn't get the chance to reject
> the spam until after the front-end system has already accepted it,

Why not ask Barracuda to forward some of the emails they receive to
Google, and skip the local router?

> making me a potential source of backscatter unless I do something
> clever.

Not much clever about it except disabling bounces (unless your antispam
is at least as good as Barracuda/Gmail). I'm afraid I don't really know
how to disable bounces, but you could try excluding them from your
outbound SMTP router:

dnslookup: (or smarthost:)
driver = dnslookup
domains = ! +local_domains
transport = remote_smtp
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
*! senders = :*
no_more

(add the line marked with *...*)

> QUESTION 4: Is there any way to require stronger sender verification
> for responding with a bounce message than for the original receipt?

BATV.

> QUESTION 5: This is philosophical instead of technical, but I'm still
> trying to get my head wrapped around all the implications of the
> backscatter problem. Are there *any* sorts of bounce messages that are
> still practical to send out these days?

Yes, local bounces TO local users, i.e. that don't leave your mail system.

I would prefer not to accept bounces over the net, but I'm afraid that
falls foul of postmaster checks at least.

> gateway if it isn't? It starts to seem as if in order to completely
> avoid the possibility of backscatter, I'd have to avoid any sort of
> tiered SMTP design and have all MX records pointed directly to the
> final destination mail servers, which sounds like overkill.

It's OK to have tiered servers as long as your inbound
(Internet-reachable) servers can guarantee delivery of all mail that they
accept. Ideally, they would verify recipients and not forward email to
third-party systems that you cannot force to accept all mail.

> QUESTION 6: Are there any options for doing this right that still allow
> me to front-end the Barracuda with the exim box?

I don't think you'll keep the efficacy of the Barracuda service if it
can't check the sender's IP address, so I woulnd't like to try if I were
you.

Cheers, Chris.
--
_ ___ __ _
/ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jbparker at ualr

Nov 9, 2009, 10:48 AM

Post #3 of 7 (964 views)
Permalink

Re: exim front-end to barracuda [In reply to]

On Mon, Nov 9, 2009 at 2:45 AM, Chris Wilson <chris+exim [at] qwirx> wrote:
>
> On Mon, 9 Nov 2009, Jay Parker wrote:
> >
> > We have been using a Barracuda spam appliance delivering to a local mail
> > system, and are migrating to hosting user email with Google Apps. �We
> > will be migrating users gradually, and [...] decided to point our MX records to
> > a "front-end" exim box that could do LDAP lookups for recipient
> > addresses and send email either directly to Google Apps or to the local
> > system via the Barracuda.
>
> Why not ask Barracuda to forward some of the emails they receive to
> Google, and skip the local router?

The Barracuda appliance can't do routing based on the local-part, only
based on the domain. So whatever it does, it does for our whole email
domain (subject to individual user preferences). Hence my desire to
front-end it with something more flexible...

> I'm afraid I don't really know
> how to disable bounces, but you could try excluding them from your
> outbound SMTP router:
>
> dnslookup: (or smarthost:)
> � �driver = dnslookup
> � �domains = ! +local_domains
> � �transport = remote_smtp
> � �ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
> � �*! senders = :*
> � �no_more
>
> (add the line marked with *...*)

I've tried this, and it skips *all* bounce messages, whether they
originated from the local exim system or not. I only want to trigger
on (and potentially delete) outgoing bounces from me to you, not
incoming bounces from you to me.

In the log file, locally generated messages are very clearly logged as
being "local", not "smtp", but I don't know how to filter on that
difference in a router.

> > QUESTION 4: Is there any way to require stronger sender verification
> > for responding with a bounce message than for the original receipt?
>
> BATV.

Again, there's an issue of polarity here. My understanding is BATV
allows me to protect *my* users from backscatter coming from you; I
want to protect *you* from backscatter coming from me by, for example,
refusing to send a bounce message if SPF records indicate the sender
was probably spoofed.

I could enforce that at receipt time, of course, but it looks like I
could afford to be more strict about what I bounce than what I
receive, so I'm wondering if implementing such a policy is possible.

> > QUESTION 6: Are there any options for doing this right that still allow
> > me to front-end the Barracuda with the exim box?
>
> I don't think you'll keep the efficacy of the Barracuda service if it
> can't check the sender's IP address, so I woulnd't like to try if I were
> you.

Actually, the Barracuda device has a nice feature in which you can
configure a server as a "trusted forwarder", which will be ignored
when evaluating SPF, Rate Control and IP Reputation spam checks. It
is definitely less *efficient*, since it now has to accept the message
headers and pull the real IP address from the Received headers, but in
our environment the overhead does not appear to be a problem, and the
spam checks appear to be just as effective.

Thanks for your time and comments,

-jbp

--
Jay Parker, Systems Manager, UALR Computing Services
jbparker [at] ualr 501-569-3345 http://ualr.edu/jbparker

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim-users at lists

Nov 9, 2009, 11:05 AM

Post #4 of 7 (940 views)
Permalink

Re: exim front-end to barracuda [In reply to]

Jay Parker wrote:

>>> We have been using a Barracuda spam appliance delivering to a local mail
>>> system, and are migrating to hosting user email with Google Apps. We
>>> will be migrating users gradually, and [...] decided to point our MX records to
>>> a "front-end" exim box that could do LDAP lookups for recipient
>>> addresses and send email either directly to Google Apps or to the local
>>> system via the Barracuda.
>> Why not ask Barracuda to forward some of the emails they receive to
>> Google, and skip the local router?
>
> The Barracuda appliance can't do routing based on the local-part, only
> based on the domain. So whatever it does, it does for our whole email
> domain (subject to individual user preferences). Hence my desire to
> front-end it with something more flexible...

Why don't you just switch the two servers around so mail hits the
Barracuda box first, which then passes it on to the Exim box, which then
decides if the mail should end up at Google Apps or your local mail
system...?

--
Mike Cardwell - IT Consultant and LAMP developer
Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/
Technical Blog: https://secure.grepular.com/blog/

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jbparker at ualr

Nov 9, 2009, 11:43 AM

Post #5 of 7 (947 views)
Permalink

Re: exim front-end to barracuda [In reply to]

On Mon, Nov 9, 2009 at 1:05 PM, Mike Cardwell
<exim-users [at] lists> wrote:
>>>> We have been using a Barracuda spam appliance delivering to a local mail
>>>> system, and are migrating to hosting user email with Google Apps. �We
>>>> will be migrating users gradually, and [...] decided to point our MX records to
>>>> a "front-end" exim box that could do LDAP lookups for recipient
>>>> addresses and send email either directly to Google Apps or to the local
>>>> system via the Barracuda.
>>>
>>> Why not ask Barracuda to forward some of the emails they receive to
>>> Google, and skip the local router?
>>
>> The Barracuda appliance can't do routing based on the local-part, only
>> based on the domain. �So whatever it does, it does for our whole email
>> domain (subject to individual user preferences). �Hence my desire to
>> front-end it with something more flexible...
>
> Why don't you just switch the two servers around so mail hits the
> Barracuda box first, which then passes it on to the Exim box, which then
> decides if the mail should end up at Google Apps or your local mail
> system...?

That is very likely what I'm going to end up doing.

I was trying to avoid it so that email for users who have been moved
to Google wouldn't be spam-filtered twice (by the Barracuda and then
by Google), using different policies and with different procedures for
quarantine maintenance. My current thinking is to do as you suggest,
and see if there is any way to script an nightly update of the
Barracuda user preferences so that users who have been moved to Google
are individually exempted from the spam scanning. Not having to build
that nightly process seemed to justify the hassle of running the
front-end Exim box, but that was before I appreciated the backscatter
implications.

Most of my other questions about identifying and filtering bounce
messages are intended, at most, as a temporary workaround for a few
days while I test this new configuration. Even if they have no
practical application, Exim is such an incredibly flexible tool that I
was surprised to find something relatively simple that I couldn't
figure out how to make it do. I'm assuming the fault is mine and not
Exim's, and I'd love to correct my ignorance.

Thanks,

-jbp

--
Jay Parker, Systems Manager, UALR Computing Services
jbparker [at] ualr 501-569-3345 http://ualr.edu/jbparker

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim-users at spodhuis

Nov 9, 2009, 6:45 PM

Post #6 of 7 (933 views)
Permalink

Re: exim front-end to barracuda [In reply to]

On 2009-11-09 at 13:43 -0600, Jay Parker wrote:
> I was trying to avoid it so that email for users who have been moved
> to Google wouldn't be spam-filtered twice (by the Barracuda and then
> by Google), using different policies and with different procedures for
> quarantine maintenance. My current thinking is to do as you suggest,
> and see if there is any way to script an nightly update of the
> Barracuda user preferences so that users who have been moved to Google
> are individually exempted from the spam scanning. Not having to build
> that nightly process seemed to justify the hassle of running the
> front-end Exim box, but that was before I appreciated the backscatter
> implications.

If you have one trusted IP which is sending email, be sure to whitelist
it in the Google Apps control panel email settings, so that it doesn't
get treated as a spam-source when you turn off the spam-filtering of the
Barracuda.

-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

wbh at conducive

Nov 9, 2009, 6:57 PM

Post #7 of 7 (936 views)
Permalink

Re: exim front-end to barracuda [In reply to]

Jay Parker wrote:
> On Mon, Nov 9, 2009 at 1:05 PM, Mike Cardwell
> <exim-users [at] lists> wrote:
>>>>> We have been using a Barracuda spam appliance delivering to a local mail
>>>>> system, and are migrating to hosting user email with Google Apps. We
>>>>> will be migrating users gradually, and [...] decided to point our MX records to
>>>>> a "front-end" exim box that could do LDAP lookups for recipient
>>>>> addresses and send email either directly to Google Apps or to the local
>>>>> system via the Barracuda.
>>>> Why not ask Barracuda to forward some of the emails they receive to
>>>> Google, and skip the local router?
>>> The Barracuda appliance can't do routing based on the local-part, only
>>> based on the domain. So whatever it does, it does for our whole email
>>> domain (subject to individual user preferences). Hence my desire to
>>> front-end it with something more flexible...
>> Why don't you just switch the two servers around so mail hits the
>> Barracuda box first, which then passes it on to the Exim box, which then
>> decides if the mail should end up at Google Apps or your local mail
>> system...?
>
> That is very likely what I'm going to end up doing.
>
> I was trying to avoid it so that email for users who have been moved
> to Google wouldn't be spam-filtered twice (by the Barracuda and then
> by Google), using different policies and with different procedures for
> quarantine maintenance. My current thinking is to do as you suggest,
> and see if there is any way to script an nightly update of the
> Barracuda user preferences so that users who have been moved to Google
> are individually exempted from the spam scanning. Not having to build
> that nightly process seemed to justify the hassle of running the
> front-end Exim box, but that was before I appreciated the backscatter
> implications.
>
> Most of my other questions about identifying and filtering bounce
> messages are intended, at most, as a temporary workaround for a few
> days while I test this new configuration. Even if they have no
> practical application, Exim is such an incredibly flexible tool that I
> was surprised to find something relatively simple that I couldn't
> figure out how to make it do. I'm assuming the fault is mine and not
> Exim's, and I'd love to correct my ignorance.
>
> Thanks,
>
> -jbp
>

Not your ignorance so much as overlooking something very basic.

OF that I am, I sometimes DO wear both 'belt and braces'. But never two belts or
two sets of braces at the same time.

Both Barracuda and Exim need to be 'first in line' at the point incoming traffic
arrives to do their best work. Both also benefit from being 'last in line' as to
final disposition, though that part is more flexible.

As they cannot BOTH be first, putting either one behind the other cripples a
portion of the best features of whichever comes second and increases your
admin/configuration complexity by more than you can gain in effectiveness.

Putting wheels on a boat, so to speak. It is done, but the result suffers by
comparison to either parent.

Better to pick the ONE that is the closest match to your overall needs, learn
all that you can about how to most appropriately deploy it, and keep your focus
on that expertise.

Bill

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads