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@??? 501-569-3345
http://ualr.edu/jbparker
