Sophos Central migrated SMIME EMAIL security policies do not work any longer

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,

Yes I also tried this today and have the same problems you described

We have the same issue. 

Hello Daniel,

As mentioned to Matthias, please get a case open to get this investigated, once you have the Case ID please share it with me.

Regards, 

Hello Denis,

As mentioned to Matthias, please get a case open to get this investigated, once you have the Case ID please share it with me.

Regards,

06202546

Hello Denis,

Thank you for the Case ID, I have added a note in the case.

Just a question checking in your Sophos Email account, I am able to see that today still some emails were S/MIME signed:

My understanding is that after the email at 8:32 AM with no changes made in your Sophos Email policies, you were expecting the 8:57 am, 9:01 am, and 9:03 am posts to be also sMIME signed?

Regards,

Yes without any changes on our site SMIME decryption for incomming mails dosnt work anymore. 

Please check my emails from    Feb. 20   5:14:48 PM    and    Feb. 20   5:13:37 PM

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

Dear admins, Dear Sophos support,

I would llike to close this topic  -  Meanwhile we have been created a Sophos Ticket which has been sent to 3rd level support / Developers, which has been closed already.

It was reported by Sophos support,  that any SMIME policies do not work against EMail accounts marked as "Distribution List" any longer.
Last support msg (09.05.2023) was that SMIME should work against Distrubtion lists as well now, but we never got to test this scenario.

Our final solution was to re -create all email accounts which were marked as "Distribution List" and make new "User" related mailboxes and entries.
Even for our shared mailboxes / team email we were creating user-based  "People" and "EMail inbox".  Since Sophos wants a license per Mailbox, disregarding if it is a real user or a shared mailbox, it did not matter anyway to have these Email inboxes.

this issue we have seen since the changes in the policy adminstration -  separation of Data / Security / Content policies in the admin dashboard.

We were facing this issue, because we imported User / Email lists from Active Directory one-time,  to make our migration to Sophos cloud protection easier.
While doing this , Sophos recognized some addresses as "Distribution Lists" from Acttive Directory and left them on this status.
In the beginning, we were not aware of this and - did not know howto properly delete and re-create user accounts / mailbox in Sophos Central and after the Policy change in February we faced this failures.

we wanted to share our gained knowledge with the community.
Thanks everyone for contributing solutions, feedback and input to these forums.


Summary
From what we learned now,  Mailbox protection is best to have on "User mailbox" (shown by the icon in front of the email list) 
If you need to change this, you need to first delete and recreate the user account + mailbox 
All policies will work , either basic or self-generated.  If one policy is hit by an emali , other policies below in the list will not be executed.

EMail Aliases per mailbox are used by sophos protection fully transparent, but if you want to catch Alias addresses your target system (if there exists) must handle the incoming alias adress as well , sophos does not automatically translate this.

you definitely need 1 license per email address, disregarding if a team address / shared mailbox or single user.
Email address  that is not licensed, will appear in the reports -> license report list on the right side and will not be protected ( please correct me if i am wrong here )
this means it will have no policies applied either, including SMIME policies.
the list of EMail Addresses in this report  is like a  "live" monitoring from Sophos Central and represents the real set of your incoming and outgoing EMail . it is updated every xx hours.  (did not find clear KB information about this )