It appears that passwords of a certain length or containing certain characters are not properly handled by Sophos when it attempts to authenticate with a smarthost. The result is that Sophos cannot authenticate with the smarthost and outbound e-mails remain stuck in the spool, showing as failed. There is no indicating in the logs accessible in the GUI that the problem is an authentication error.

It might save users some frustration if Sophos were to either include validation logic to reject problematic passwords when they are entered and/or including a note or tip in the GUI indicating the applicable parameters for such passwords.

I should perhaps note that this only applies to versions after 17.1.4. I encountered this issue as I previously had used a long, complex password (35 characters) for the smarthost, which resulted in authentication errors when I updated to a later version of the firmware. It worked just fine in 17.1.4 and previous versions.

Sophos SPX Outlook Add-in - improved user friendliness

Problem/issue:
The Sophos SPX add-in for outlook enables a user to encrypt outgoing emails. This add-in works just fine from a technical point of view, but it is not as user-friendly as it could and should be. When a user clicks on the Encrypt-button and enables encryption, it turns grey to indicate that it is enabled. But this is not easy to see for the user. This is not a clear indication showing that encryption is enabled, and especially if a user has enabled the dark or grey themes in newer versions of Outlook. This can potentially cause problems and confusion for users, and in a worst-case scenario cause data loss, if a user thinks that he has enabled encryption on a confidential email, but in fact he has NOT.

Suggestions:
1) More clearly show that the button is enabled, perhaps by using a brightly-colored outline on the button.
When the user clicks the button, a dialogue box pops up, asking the user to confirm if he wants to send encrypted or not.

2) After confirming Yes, and encryption is enabled, it would also be very useful to get a written confirmation in the email that encryption is enabled. This would be especially useful for people who are color-blind.

3) If technically possible, perhaps the Outlook Mail-tip field above the recipient-field can be used for this, simply stating that "Encryption is enabled".

4) It should be possible for Sophos partners, selling the solution to their endpoint-clients, to brand the installer/add-in as well as the SPX Secure Reply Portal with the partners own logo and company name. An example of such a solution is Teamviewer Quicksupport, which can be branded. Another example is SolarWinds Max Focus Management agent for MSP's, which also can be branded.

See mock-up screenshot for an illustration of the above: http://www.filedropper.com/2019-03-21104936-featurerequest

This is more of a bug than an actual idea. However the tech support for ticket #8659892 insists this is a new idea .
When creating Exceptions in MTA mode , it allows us to create an IP List object when we want to define a new object to be selected. However This IP List object couldn't be selected at all.
This behaviour is more of a bug than a new feature especially considering that it took them to find out for themselves that IP List is not supported (else they would have replied me that right away instead of attempting to show me how to create the IP List object and add it into the exceptions.
As a reseller with many Cyberoam units and providing similar e-mail protection policies that involves IP List objects (with many many IP addresses involved) , it will be difficult to convince my customers to upgrade to SFOS if this functionality doesn't work with IP List objects.

Currently the Sophos XG and UTM Mailfilter seem to make a difference on Outgoing and Incoming Mails.

An incoming Mail seems to be determined by checking the protected Domains. All Domains that are not protected Domains are incoming Mails.

An outgoing Mail seems to be dtermined by checking the protected Domains. All Protected domains are incoming Mails.

That could lead to several problems, because only the Domains are taken into account in this decision.

1. In my opinion when "Scan outgoing mails" is not checked there is no check on "outgoing" mails. That could lead to problems with spoofing mails not being scanned by anti virus. (Please correct me if I'm wrong)




2. No SPF Check is carried out on "Internal Domains" even if the mail is a spoofing mail from a foreign server (for example when sende rand recipient are the same)

Other Checks like RDNS / Greylisting / Strict RDNS can filter out some of those spoofing mails but not all. On all other Domains SPF is working fine but not on internal domains which I think is a severe flaw.

So it would imho be necessary to not only determine a outgoing mail by it's domain and by other factors (for example additionally through a list of hosts that may send outgoing mails)

This is absolutely necessary to prevent furhter confusion and make the spam filter more secure and like anyone would expect it to work.