On Mon, Nov 9, 2009 at 2:45 AM, Chris Wilson <chris+exim@???> 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@??? 501-569-3345
http://ualr.edu/jbparker
