3
Postfix as a backup MX for SmarterMail
Question asked by Linda Pagillo - 5/21/2020 at 6:20 AM
Unanswered
Hey everyone! I hope you are all safe and healthy out there! I have been exploring lightweight backup MX solutions for SM so I went ahead and set up an Ubuntu 18.04 LTS server and configured Postfix as a backup MX for a few of my SM 17x test servers. It works beautifully so far. 

I was wondering if any of you out there are also using this solution and if you have come across any issues between Postfix and SM. I know lots of folks out there are against backup MX servers because of the spam issues they can cause. However, as you guys probably know, MBF knows how to combat that type of thing so it is not an issue for us. I'm looking forward to hearing your experiences with this. Thanks!
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 

8 Replies

Reply to Thread
1
echoDreamz Replied
We use postfix anti-spam gateways, that also function as our anti-spam gateways. Works great :) - We also use postfix now as our outbound gateways with IP rotation.
'
EDIT: Postfix handles the incoming SMTP connections, but we use rSpamd as the anti-spam portion.
2
echoDreamz Replied
I would sell my kidney though to allow SmarterMail to disable non-authenticated SMTP sessions (with the exception of whitelisted IPs) for incoming mail.
2
Employee Replied
Employee Post
Chris, I have added disabling non-authenticated SMTP sessions for incoming mail into our features request list. This idea could also be extended to include any binding. I believe you already have a different thread discussing that here.
0
Douglas Foster Replied
About your kidney...   

If you are trying to prevent incoming mail from the internet, I would think that this could be accomplished by using port 465 or 587 for authenticated SMTP, and disabling port 25.

If you are trying to prevent users from sending on behalf of someone else, the setting is System Admin...Global Settings...  Protocols...  SMTP In... Require Auth Match = Email Address

I was not aware of a limitation or vulnerability.   What am I missing?.
0
echoDreamz Replied
Tried disabling the port, the issue is that SM doesnt have a setting to require SMTP authentication, SM treats all SMTP ports as normal public incoming SMTP mail ports.

We disabled port 25, after a few days, though, some dedicated spammers updated their scripts to use 587 and the spam emails kept on coming.

The SMTP setting you are speaking of only applies to users who want to send mail (relay) it using your server, it doesnt apply to external users who want to deliver mail to a user on your user.

0
Douglas Foster Replied
That is a serious vulnerability.  Enabling IMAP or POP3 connections should not allow incoming mail to bypass your incomong email gateway(s).
0
Douglas Foster Replied
You made it sounds as if this has been a known issue for a long time.   I am surprised, since it has its biggest impact on hosting services, and hosting services seem to be an important part of the Smartertools customer base.

But to fix this now, rather than waiting for them to catch up, I can suggest the following fix:
  • Configure an incoming email gateway, if you do not have one already
  • Install Declude on your mail server, and create a filter to block traffic that is not for your domain(s), which need authentication because of the tests discussed previously, and not from your incoming gateway.   
  • I think the syntax works best if you create an allow rule and then block when the allow rule is not activated:.
    • (FILTER MAILALLOW, no action defined)
      • MINWEIGHTTOFAIL 1
      • SOURCEIP 1 IS <incoming gateway internal IP address>
      • MAILFROM  1 ENDSWITH  @yourdomain
    • (FILTER MAILBOCK, action=DELETE)
      • MINWEIGHTTOFAIL 1
      • TESTSFAILED 1 NOTCONTAINS MAILALLOW


2
echoDreamz Replied
We have a spool processing app that discards unauthenticated emails not received from our anti-spam gateways. It would be better if this was something that was handled by SM at the SMTP level.

Reply to Thread