Issue:

Messages that have ended up in an MSG quarantine folder are missing from the end user digest / end user web.
Examples of missing messages:

• Message that has been wrongly categorized as spam
• Message quarantined due to SPF fail

Resolution:

There are several possible explanations for this. The message could be exceeding a spam threshold for it to be included, or quarantine folders or MSG modules could be missing from what should be included in the digest.

In the case of spam, the digest can be set to include messages only up to a certain spam score threshold. If the message spam score exceeds this threshold, it will not be included in the digest. If a message has been quarantined due to a high spam score, it will be listed in the Reason-column in the Quarantine -> Messages-page.

To modify this threshold:

1. Log in to the MSG Web UI
2. Navigate to System -> End User Services -> Filters -> General using the left-side menu
3. Check if Enable Score Range is set to On or Off
4. If it is On, check the value for Only Include Messages With a Score Less Than or Equal To
   1. Compare this value with the spam score of the message missing from the digest
   2. If the message has a larger spam score than this value, everything works as intended. Consider whether you want to modify the threshold to a higher value. Remember that setting the threshold to 100 will have the same effect as not having the setting enabled at all. Another solution, if only particular messages are being affected by this, is to create a custom spam rule that detects these messages and assigns them a lower spam score so they end up below the threshold 
   3. To modify the threshold, use the Only Include Messages With a Score Less Than or Equal To drop-down menu to set a new value and click Save Changes in the top right corner
5. If it is set to Off, this will have no impact on the digest content

For a message to be included in the digest, both the quarantine folder and the module responsible for putting the message in the quarantine must also be included in the digest. When looking at messages in a quarantine folder, the Reason-column will give a clue of what module should be included for a message to show up in digests. The Reason-value might be for example "Spf: 0", meaning that the Sender Policy Framework module must be included. By default, only the Spam – Quarantine module is included in the digest

To verify that the quarantine folder where the message ends up is included in the digest:

1. Log in to the MSG web UI
2. Navigate to System -> End User Services -> Filters -> Folders using the left-side menu
3. Check if the relevant quarantine folder is listed under Include in Digest
   1. If it is not, mark it from the Available Folders-list and use the >>-button to move it over to the Include in Digest-list
   2. Click Save Changes in the top left corner

To verify and add modules to the digest

1. Log in to the MSG web UI
2. Navigate to System -> End User Services -> Filters -> Modules using the left-side menu
3. Check if the module that sent the message to the quarantine is listed under Include in Digest
   1. If it is not, mark it from the Available Folders-list and use the >>-button to move it over to the Include in Digest-list
   2. Select the module from the Include in Digest-list and click on Options… , a new window should open
   3. Click on the tab Digest Commands
   4. From Commands, select the commands you want to have available for digest messages that have been affected by this particular module and use the >>-button to transfer them over to Available in Digest
   5. Click Save Changes to close the window
   6. Back at the main Modules-page, click Save changes in the upper left to save the new settings

Issue:

Messaging Security Gateway (MSG) appliance is reporting the following alerts:

• crit eid.plinx.log.sel Battery ROMB Battery | Low | Asserted
• err eid.plinx.raid Raid is in Write-Through Mode, Performance will be degraded.

Resolution:

These alerts are related to the RAID battery relearning and are completely normal behaviour for the appliance.

Battery relearns occur every 90 days by Hardware default. During a battery relearn, the battery fully discharges and gains statistical information regarding its overall State of Health (SoH). When the battery charge drops below a charge threshold, the disk write-cache policy changes to Write-Through.

What does disk Write-Through mean? This means that the data writes occur twice (to Memory and Disk) to protect and preserve the data in the event of a critical hardware failure or disk failure.

The battery will fully discharge, and when the disk write-cache policy changes to Write-Through, the Appliance RAID is degraded and performance is affected. Any changes to hardware or something that will trigger an asserted failure (such as ROMB Battery failed (since it's discharged entirely)), will generate a PPS alert.

As the battery recharges, the disk write-cache policy changes to Write-back. As this is the normal state of the hardware, the alerts will cease as the battery is operational and the SoH is good.

As this happens every 90 days for each appliance where a RAID Controller is present, you should expect to see these alerts reoccur regularly. If the appliance doesn't recover (can be expected to happen in a few hours), open a support ticket.

Issue:

A mail targeted to multiple recipients returns with the message saying that "the following addresses had permanent fatal errors", followed by a list of all recipients. However when sending the same message to individual users it seems to work. It seems that if one recipient is invalid, all recipients get the same label, why is this happening?

When checking the message in Smart Search in the MSG Web UI, the MTA logs contains the following error:
relay=[], dsn=5.0.0, reply=550 5.1.1 User unknown, stat=Service unavailable

Resolution:

The entry from the MTA logs list a reply from a server relaying the mail to the final recipient, so the problem is not within MSG but coming from the relay server of the recipient.
This is something that the recipient needs to verify on their end. If the recipient causing these errors is a legit user, they might be missing from a user verification database on the receiving end and their relay server might be set up to reject messages where any of the recipients are unknown.

Issue:

Emails are blocked by the Messaging Security Gateway (MSG) or Protection Service for Email (PSE) maxsize firewall rule despite being seemingly smaller than the limit.

Resolution:

The maxsize firewall rule may include multiple criteria. Most likely one of the other criteria are being met by the message. Here is an example of the maxsize firewall rule criteria:

Message size greater than 52428800 Bytes
OR  Attachment count greater than 256
OR  Total Uncompressed Attachment size greater than 52428800 Bytes
OR  File count in archive greater than 256
OR  File depth in archive greater than 20

To check and modify the rule used in your appliance:

1. Log in to the MSG Web UI
2. Select the Email Protection-tab
3. Navigate to Email Firewall -> Rules using the left-side menu
4. Locate the rule called maxsize from the list of rules

• The settings of the rule can be checked directly from the list
• To modify the rule, click on Edit Rule, make the necessary changes and click Save changes

Issue:

Linux Security 64 failed to be installed successfully and the installation process is stuck at "Installing BaseGuard" stage

Resolution:

During the installation of Linux Security 64, it will connect to the Policy Manager Server and check for the latest database updates. If Policy Manager Server does not have the latest database updates and the internet connection is blocked for such update, then the installation of Linux Security 64 will fail. Therefore, it is important to enable the internet connection for Policy Manager Server so that the database update could be done successfully which contributes to the successful installation of Linux Security 64.

Other than that, make sure that the connection between Linux Security 64 and Policy Manager Server could be established successfully.

You could verify the connection to the Policy Manager Server is working successfully by using a web browser or command line as below.

In case of web browser:

1. Open any browser.

2. Enter the following URL with a hostname or IP address of Policy Manager Server.
    https://<name or IP address for the Policy Manager Server>:443

3. Check the result whether the following message is displayed.
    "If you see this message, Policy Manager Server is installed and is working fine."

In case of command line:

1. Run the following command on Terminal.
    curl –insecure https://<name or IP address for the Policy Manager Server>:443

2. Check the result whether the following message is displayed.
    "If you see this message, Policy Manager Server is installed and is working fine."

If you could see the message above, it means that the connection to the Policy Manager Server could be done successfully. 
If other message is displayed, you need to check your network or firewall settings as it is blocking the connection.

Issue:

Linux Security 64 failed to activate with error message "SELinux integration for F-Secure Linux Security 64 is supported only with the
'targeted' policy on this system (detected policy: '').

Installation is successful. 

Resolution:

Root cause is due to missing "SELINUXTYPE=targeted"

Example from /etc/selinux/config

# SELINUXTYPE= can take one of three two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Note that SELINUX can be any value, but SELINUXTYPE must be set to "targeted".

Reinstallation is required after fixing the value. 

1. Uninstall Linux Security 64
2. Remove Linux Security folders (rm -rf /opt/f-secure /etc/opt/f-secure /var/opt/f-secure)
3. Add SELINUXTYPE=targeted to the config file /etc/selinux/config
4. Reboot system (recommended)
5. Install Linux Security 64

Issue:

I launched a manual scan(fsanalyze) as a non-root user in Linux Security 64(LS64) and it fails with the following error:

fsanalyze: failed to connect to pmd:failed to connect to ctrl socket: /opt/f-secure/linuxsecurity/var/lspmd/run/socket: Permission denied

Resolution:

When a non-root user executes the fsanalyze command, “Permission denied” is output, the file will still be scanned by the fsanalyze tool.

Here is a sample output:

[azlaaz@ip-192-168-175-229 Desktop]$ /opt/f-secure/linuxsecurity/bin/fsanalyze --list test.txt
fsanalyze: failed to connect to pmd:failed to connect to ctrl socket: /opt/f-secure/linuxsecurity/var/lspmd/run/socket: Permission denied
test.txt: result=clean
 
Engine versions: F-Secure Corporation Aquarius/18.0.790/2021-08-25_02 F-Secure Corporation Hydra/6.0.391/2021-08-25_01 F-Secure Corporation FMLib/17.0.607.475  (cf1875a)/2020-04-07_01  fsicapd/2.0.202
 
1 files scanned

The impact of this error is that alerts (scan errors and detections) will not be sent to the Policy Manager and syslog. Therefore for example, if a non-root user scans an eicar file using the fsanalyze tool, the detection log will not be sent to syslog and Policy Manager. It will only be shown on the terminal for this non-root user to see.

The known issue is also being recorded in the LS64 changelog under the latest component update on 18 Aug.

Known Issues:
・Scanning files as a non-root user using fsanalyze command-line utility cause error message to be shown.
 

Issue:

Email messages are delivered but the sender gets an empty permerror email notification from MSG.

Resolution:

The PermError condition means the sender published SPF record could not be verified. Permerror are usually caused by an incorrect SPF syntax or format error in the SPF record.

You may advise the sender to ensure their SPF record is set up correctly and does not have any extra spaces or unrecognizable characters in the DNS TXT record.

To prevent the sender from getting the same message, please follow these instructions:

1. Logon to your MSG admin web user interface.
2. Click Email Protection tab.
3. Expand Email Authentication > SPF > Rules.
4. Click on the Edit Rule option of SPF Permanent Error.
5. Under Dispositions, untick the "Reply to sender based on detected language" check box.

By disabling the option, senders should not receive the e-mail notification. If you want to use that option, leave the check box ticked and write some message in the Subject and Message field.

Issue:

Linux Security 64 "Master-Switch" command cannot stop/start the process/service since after update, Linux Security 64 (12.0.222), BaseGuard (1.0.532) and FSBG (1.0.508).
This problem is not happening in PSB mode/Standalone mode.

Resolution:

This problem is happening due to policy setting in LS64.  

1. Login to Policy Manager.
2. Change "Allow users to unload products" to "Allowed always"
3. Deploy new policy to LS64.

Issue:

Linux Security 64: Installation failure with error "activate: No such file or directory" when mounted "/var/opt/f-secure" as separate filesystem

# bash f-secure-linuxsecurity/f-secure-linuxsecurity-installer
f-secure-linuxsecurity/f-secure-linuxsecurity-installer: line 68:
/opt/f-secure/linuxsecurity/bin/activate: No such file or directory
Failed to activate the product!

[df.txt]
/dev/mapper/cl-var                 2.0G  513M  1.5G   26% /var
/dev/mapper/cl-var_opt_f–secure   3.0G  164M  2.9G    6% /var/opt/f-secure

Resolution:

Mounting "/var/opt/f-secure directory" on a separate filesystem is not supported, thus failed to install Linux Security 64.
But alternatiely can consider to mount the whole "/var" directory on a separate filesystem, which is supported.