Opinions on inbound/outbound gateways?
Question asked by W. Troy Leaver - June 2, 2015 at 11:26 AM
I'm reworking our SmarterMail setup and thinking about putting both inbound and outbound gateways into play. I'm thinking I can probably have a single inbound and single outbound server serve as gateways for 2 hefty SmarterMail servers and offload some processing.
I see a post talking about DMARC issues with incoming gateways. Anything else I should be wary of that folks have experienced?

6 Replies

Reply to Thread
Here's my experiences with using Smartermail Gateways for both Inbound and Outbound traffic:
  • If you have users that use Mailing Lists the bounce-backs will not be able to be delivered, rendering the Mailing List Bounce Removal feature unusable. You will have to manually parse the Delivery logs on your Outgoing Gateway and manually remove bad subscriber addresses from your primary Server.This is my #1 pet-peeve and has been broken since v8 of Smartermail.
  • Bounce-backs from emails that are routed to an external forwarding address will be undeliverable. These will fill up your Outgoing Spool fast (especially Facebook, LinkedIn, Twitter, Yahoo!, and UPS emails that can't be forwarded due to DMARC) and render any Event Notifications for your Spool size effectively useless. If you don't let users use Forwarding, then this won't be an issue (otherwise you'll be spending 5 min every morning cleaning up all the hundreds of blank sender NDRs from your Spool).
  • Although it has a huge benefit offloading all your Spam Filtering to your Inbound Gateway, there is no way to use Bayesian filtering on your Inbound Gateway. Disable it on the Gateway and enable it on your primary Smartermail Server and it will work as intended.
  • If your Incoming Gateway is doing all the Anti-Spam tests then your users cannot override the weights of individual Anti-Spam tests, or exempt their domain or accounts from a particular Anti-Spam tests. This can be a good thing or a bad thing depending on your perspective.
  • If you can help it, do not Whitelist any IPs on your Incoming Gateway as User Verification will not occur for email from those IPs. If email is sent to a non-existent user it will be accepted anyway and sit in your Spool until it reaches the max number of retries before being bounced. This prevents Mailing Lists (like Constant Contact, MailChimp, MailGun, SendGrid, etc) from removing non-existent users from their lists as they are receiving a soft-fail NDR instead of a hard-fail "rsp 550: No Such User Here" upon delivery. This will eventually, over time, cause them to constantly trigger your IDS thresholds, blocking them from delivering *ANY* email to your users.
  • If you routinely use the Smartermail Blacklist and SMTP Blocking to block Harvesters, DDoS, and Spammers then you will have to do this on all servers, which can be tedious (to say the least).
  • Most Reputation based Anti-Spam vendors and Whitelists will base your email's reputation on your Outgoing Gateway IP, not on your primary Server IP Address. If your primary Server IP is already Whitelisted and has a Good reputation, you'll have to start all over at building up that reputation on your Outgoing Gateway IP.
Despite the little (and big) problems running Smartermail this way, we can't imagine going back to one Mail server does it all ever again. Having separate Gateways to handle processing email is too much of a necessity if you have medium to high email traffic.
Great response, Scarab!
Bruce Barnes
ChicagoNetTech Inc

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
Maybe it's our email gateway that is not set-up correctly  but the one issue, reported by Scarab:
If email is sent to a non-existent user it will be accepted anyway and sit in your Spool until it reaches the max number of retries before being bounced. 
...    We haven't experienced or seen that,    Ours bounces back  with 550 no such user...
Maybe we have something else set incorrectly?
Totally un-related to the question.. but if you are interested... we have written a couple of programs, that get "started" via Event scheduler; read the SM INI's and do some daily maintenance.
There is one more thing with outgoing gateways and it is related to IDS block possibilities. Gread IDS solution Bounces Indicate Spammer will not work on them.
"Bounces Indicate Spammer - Enabling this rule in SmarterMail will block or quarantine an account from sending out mail, as well as alert an administrator, after receiving a certain number of bounce messages in the specified time frame."
so if message is bounced on outgoing gateway then there is no way to block user account since it is located in primary SM. I would love to have this in scenario where outgoing gateways are used.
A follow up to many of the problems we have been experiencing with Smartermail Gateways.

We have been using Smartermail Gateways as both Incoming *AND* Outgoing Gateways to our Smartermail Enterprise server. The reason we had this configuration was to offload Spam & Antivirus checks on both Incoming and Outgoing email to another server(s). As we used Declude and HijackThis, which are both CPU and Memory intensive, at the time we felt this seemed like a smart move...and it worked relatively well with the exceptions I noted in my posts in this thread.
Recently, after upgrading to Smartermail v14, we had the need to stop using our Smartermail Gateways for Outgoing (having to do with one of our hosted domains being a split domain that has email hosted both at Google Apps and on our Smartermail Enterprise server), and use our Smartermail Gateways only for Incoming . In the two days since almost all of our problems that we had experienced when using Smartermail Gateways cleared up.
The moral of this cautionary tale is that Smartermail Gateways work great as *EITHER* an Outgoing Gateway or an Incoming Gateway, but things may begin to work not as intended when you try using Smartermail Gateways as both.
There is one thing I ran into with the Outgoing Gateway. Using webmail, the Outgoing gateway does not work for local deliveries. Deliveries within domains on the Smartermail webmail interface do not use the Outgoing Gateway. All deliveries are done internally. If you use a client, it works fine. So if you need to pass all traffic regardless of the address to an Outside SMTP server, you will have this restriction. I have been on Smartertools back for over a year about this and they won't change it. I have not renewed my license because of this and moved to another software. Shame since I liked Smartermail better in all other features.

Reply to Thread