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 Central migrated SMIME EMAIL security policies do not work any longer

Dear community,

in our Sophos Central administration we noticed since 10.02.23 in EMAIL SECURITY, that Sophos migrated the SMIME policies for users, grouops and domains to a new section / category.

since 10.02.23 the SMIME policies do not work any longer, although we have activated the basic SMIME settings in "Settings".
The result is that the inbound Emails from partners are not recognized as SMIME and decrypted any longer . 
the EMAIL smtp logfile shows no SMIME Activity any longer when email is processed.

does anyone else in Europe have this error ?

We are quite in need of a solution for this, because we would have to inform all partners to turn off their automatic attachment of our SMIME public certs until Sophos Central starts to work again...

best regards

Matthias Edler

IT Dept. / hamburg



This thread was automatically locked due to age.
Parents
  • Hello Matthias,

    Thank you for contacting the Sophos Community.

    This would need to be investigated, I checked under your account, but I couldn't find a case for this issue, can you open a ticket with Support and share the Case ID so we can escalate this to our DEV team?

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • update for this case today - we have opened a ticket with sophos already but they were not able to solve this problem until today.
    ticket #  06184316  started on 14th Feb 2023

    your sophos support collegues have been given detailled EMail envelope logs 
    regarding the email address that is failing.


    I can share some new background  information regarding this case -

    1. we have some email recipients, for whicht the SMIME engine is turned on , when they receive. These are marked as "personalMailbox" in sophos central
    2. but we still have recipients, for which the SMIME engine is never used, even if there is an SMIME cert connected to the specific email inbound address used. this address is marked as "shared mailbox" in the sophos Central.
    3. we have licensed the full package Sohpos XGS onsite <-> Sophos Central EMail gatewway <-> Sophos Endpoint Protection including the MS Azure connected for users and groups.
    the named failing email address is used in the MS Azure as "group mailbox address" and - i suppose - has been imported to Sophos Central automatically as " shared mailbox" 

    It seems to me that the support team is now researching the difference between the "personal" mailbox and the "shared mailbox" type of address.
    but no new results yet on this since 3 weeks now.

    the point is , the type of mailbox did _not_ matter UNTIL Sohpos decided to make changes to the SMIME Policy 4 weeks ago. 
    So it seems to be an error that happened at the sophos Backend.

    My internal customers are quite upset now and question the SMIME to be a good system to secure their emails.
    This is the opposite of what we wanted to achieve when purchasing this feature.

    So it would be great of the 3rd level support to come up with some solution / workaround for this issue.
    I have only 5 internal Email address activated for global SMIME now. 
    i cannot imagine for organizations having the same erorr for 100dreds of mailboxes.

    best regards , 
    the local IT crowd

Reply
  • update for this case today - we have opened a ticket with sophos already but they were not able to solve this problem until today.
    ticket #  06184316  started on 14th Feb 2023

    your sophos support collegues have been given detailled EMail envelope logs 
    regarding the email address that is failing.


    I can share some new background  information regarding this case -

    1. we have some email recipients, for whicht the SMIME engine is turned on , when they receive. These are marked as "personalMailbox" in sophos central
    2. but we still have recipients, for which the SMIME engine is never used, even if there is an SMIME cert connected to the specific email inbound address used. this address is marked as "shared mailbox" in the sophos Central.
    3. we have licensed the full package Sohpos XGS onsite <-> Sophos Central EMail gatewway <-> Sophos Endpoint Protection including the MS Azure connected for users and groups.
    the named failing email address is used in the MS Azure as "group mailbox address" and - i suppose - has been imported to Sophos Central automatically as " shared mailbox" 

    It seems to me that the support team is now researching the difference between the "personal" mailbox and the "shared mailbox" type of address.
    but no new results yet on this since 3 weeks now.

    the point is , the type of mailbox did _not_ matter UNTIL Sohpos decided to make changes to the SMIME Policy 4 weeks ago. 
    So it seems to be an error that happened at the sophos Backend.

    My internal customers are quite upset now and question the SMIME to be a good system to secure their emails.
    This is the opposite of what we wanted to achieve when purchasing this feature.

    So it would be great of the 3rd level support to come up with some solution / workaround for this issue.
    I have only 5 internal Email address activated for global SMIME now. 
    i cannot imagine for organizations having the same erorr for 100dreds of mailboxes.

    best regards , 
    the local IT crowd

Children
No Data