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 [email protected] 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/
