5.7.1 Relay access denied on auto forwarded messages when using outbound relay through ProofPoint

Question asked by Chad Killion - 6/11/2021 at 5:28 AM

Unanswered

Good morning-

We recently turned out outbound relay for all our mail on our SmarterMail server. This feature works great for 90% of things in Smartermail and allows us to give our users peace-of-mind that their incoming and outgoing mail is filtered for SPAM/Virus and that our server has no way to be used as an open relay.

This does create a problem, however, which I can't find a creative way to solve. Since ProofPoint is a closed relay system, it only allows outbound sending by email addresses which also have an existing ProofPoint account. So if user@mydomain.com exists in SmarterMail and sends out an email, that email is sent through the PP gateway and that gateway checks to see if there is a valid user@mydomain.com PP account as well. If there is, it relays, if not, it bounces. Works great when a SmarterMail users sends email. Where it fails miserably is when a SmarterMail user has an auto-forward setup. In this case, the user at smartermail recieves an email, and then that auto-forward tries to forward that message on through to the destination of the forward through the outbound relay as the original sender of the email. This, obviously, fails the PP check since that user isn't a PP user.

I haven't been able to find a way to get this working. I would love the option to either choose not to send the email through the outbound gateway (PP in this example), but rather send it using SmarterMail, or to forward the message from the SmarterMail user to the forward address (like an outlook rule.)

Has anyone else run into this issue, and did you find a solution other than turning off outbound relay?

Chad

4 Replies

Reply to Thread

Douglas Foster Replied

6/11/2021 at 8:48 AM

I have a couple of ideas, depending on the rules used by Proofpoint:

1) (easier)
Turn on SRS rewrite, so that the SMTP MailFrom domain is the forwarding user. If ProofPoint is only checking for SPF PASS, this should allow the message to be forwarded.

2) (ugly, but seems likely to work)
Turn off SRS rewrite, and configure two outgoing gateways with Declude to do custom magic.

SmarterMail forwards to gateway#1.

Declude checks whether the message is an auto-forward (SMTP domain not a local domain.)

If this is not the case, Declude does nothing and the message is forwarded to Proofpoint.
If the message is an autoforward, Declude copies (moves) the message over into the PROC folder of the second gateway, removing it from the first gateway. SamrterMail on the second gateway picks up the message and forwards it to the Internet, bypassing ProofPoint.

Sébastien Riccio Replied

6/11/2021 at 9:01 AM

Yes, basically you will want to turn on SRS as not doing so will often lead to rejects or forwards being flagged as SPAMs because of the SPF checks.

Also be sure that you don't auto forward SPAMs as it will probably flag your server as a spam source quite quickly.

Nowadays mail autoforwarding to external domains is a real pain and should be avoided.

If it's a personal forward to a gmail, hotmail or other account you have you should configure your external account to retrieve mails from your SmarterMail mailbox instead of the other way.

If it's a forward to someone else external account, well 1) SRS 2) Configure autoforward to skip spams.

Sébastien Riccio System & Network Admin https://swisscenter.com

Chad Killion Replied

6/11/2021 at 10:32 AM

Thanks for the suggestions. ProofPoint actually checks the sending address against its' user database, so turning on SRS alone doesn't allow the autoforwards to work since the user wouldn't be valid even though the domain name now is. The other idea about using 2 gateways may be our only option, but I would hate to have to burn another smartermail license to just act as a forwarder for non-local user auto-forwards. I will look into this option and see what is feasible. Thanks for the suggestions!

Douglas Foster Replied

6/11/2021 at 11:44 AM

Licensing is not an issue Gateways use the SmarterMail Free license. You have to create a placeholder domain to get it configured, such as junk1.local, but you don't use it. Support helps with gateways as long as your primary server is licensed.

Another issue with auto-forwards: If your spam filtering process adds an content to the message, it will break DKIM signatures. Then when you auto-forward, the message will fail DMARC validation for any domains that have DMARC policy set to reject or quarantine. Your options are (a) never modify the message, or (b) rewrite the From address, using something like fromdomain=fromuser@localdomain. You could even make the rewrite conditional based on a test of whether the From domain has an enforceable DMARC policy. There is no off-the-shelf way to do the From rewrite in SmarterMail+Declude, but you could write a custom script to do so.

As has been said, auto-forwarding is an inherent security problem. Your spam filter will be different from the final recipient, so any spam that you let through is either (a) detected by the recipient and damages your reputation, or (b) is not detect by the recipient and damages them. If you ensure that your spam filtering is stricter than the recipient, then you will probably have enough false positives to make the end-user angry. Anyway I look at it, you lose.

Since auto-forwarding hides the reputation of the originator, and since auto-forwarding is hard to detect, the necessary solution is to scan the entire header chain for domains or IP addresses with negative reputation. Unfortunately, this is not part of most spam filters, including SmarterMail+Declude.

Back to Community Threads

Please leave this box unchecked

4 Replies

Reply to Thread

Tags

Related Knowledge Base Articles