Sophos Email customers using IP-based mailflow rule connectors must migrate to certificate-based configuration by March 31st. To see if you're affected Click Here.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 18 subscribers
  • Views 4366 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Mail Advanced - Enforce TLS and optional Push encryption

Steffen Graf

Hello community,

we have migrated from Sophos UTM to Sophos Mail Advanced.

On our UTM, we could configure transport encryption to TLS 1.2. Additionally, each internal user could choose to send an email using Sophos SPX for end-to-end encryption.

While the rule set in Sophos Mail Advanced is straightforward, I am having difficulty understanding how to replicate our UTM configuration there. What I want to achieve:

- Sending with TLS 1.3/1.2
- Receiving with TLS 1.3/1.2
- Optional: Utilizing Push Encryption when a keyword is mentioned.

What is the best pracitise for doing this?

Thank you



This thread was automatically locked due to age.
Parents
  • +1

    Central Email essentially gives you the option to use TLS everytime and fallback, if TLS is not available.

    So you can use the "Fallback" option here.

    Push means essentially SPX / PDF Encryption. 

    This secures the encryption way everytime, if triggered. 

    You can decide based on Subject line here or via a DLP Rule when to trigger an encryption event.

    Then CEMA will try to perform TLS Encryption, to send the Email, and if TLS is not available, it will fallback to Push. 

    You can also switch around and say, you only want to use Push when triggered. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hello Lucar Toni,

    Thank you for your response.

    I'm aware of the fallback mechanism. However, for various reasons, it is not desired in this case. The client in question occasionally sends many newsletters, and TLS 1.2/1.3 is mandatory. However, there are likely still receiving mail servers, for example, with TLS 1.0. In such cases, the fallback mechanism would kick in, and a newsletter might be sent using PDF encryption, which is not what we want.

    Our plan is not achievable with Secure Message Policies. I appreciate your pointing out that DLP can trigger Push Encryption. That was the information I was looking for!

    This way, I can ensure that transport encryption is always TLS 1.2/1.3. If needed, our users can still manually activate end-to-end encryption via Push.

    Best regards

Reply
  • 0 in reply to LuCar Toni

    Hello Lucar Toni,

    Thank you for your response.

    I'm aware of the fallback mechanism. However, for various reasons, it is not desired in this case. The client in question occasionally sends many newsletters, and TLS 1.2/1.3 is mandatory. However, there are likely still receiving mail servers, for example, with TLS 1.0. In such cases, the fallback mechanism would kick in, and a newsletter might be sent using PDF encryption, which is not what we want.

    Our plan is not achievable with Secure Message Policies. I appreciate your pointing out that DLP can trigger Push Encryption. That was the information I was looking for!

    This way, I can ensure that transport encryption is always TLS 1.2/1.3. If needed, our users can still manually activate end-to-end encryption via Push.

    Best regards

Children
No Data
Unfiltered HTML