SecurityGateway for Email Servers v7.0 Release Notes

Developed with 20 years of proven email security expertise, SecurityGateway provides affordable email security. It protects against spam, viruses, phishing, spoofing, and other forms of malware that present an ongoing threat to the legitimate email communications of your business.

Click here to learn more about SecurityGateway for Email Servers.

SecurityGateway 7.0.1 - October 6, 2020

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 7.0.0 - August 18, 2020

SPECIAL CONSIDERATIONS

MAJOR NEW FEATURES

[22550] CLUSTERING

[17214] TWO FACTOR AUTHENTICATION

Administrators may allow and require two factor authentication (2FA) globally or per domain. If 2FA is required, the user is presented with a Setup 2FA page upon login. Otherwise the user can go to Main -> My Account -> Two Factor Authentication to setup 2FA.

[21602] CHECK FOR COMPROMISED PASSWORDS

SecurityGateway can check a user's password against a compromised password list from a third-party service. It is able to do this without transmitting the password to the service. If a user's password is present on the list it does not mean the account has been hacked. It means that someone somewhere has used the password before and it has appeared in a data breach. Published passwords may be used by hackers in dictionary attacks. Unique passwords that have never been used anywhere else are more secure. See Pwned Passwords for more information.

[21593] REQUIRETLS (RFC 8689)

The RequireTLS effort in IETF is finally finished. Support for this has been implemented. RequireTLS allows you to flag messages which MUST be sent using TLS. If TLS is not possible (or if the parameters of the TLS certificate exchange are unacceptable) messages will be bounced rather than delivered insecurely. For a complete description of RequireTLS see the RFC specification and especially the Abstract, Introduction, and Security Considerations sections.

RequireTLS is enabled by default. You can disable it with a new switch at Setup | System | Encryption. It's fine to leave the service enabled. Only messages specifically flagged by a rule you must create using a new Content Filter action or messages sent to <local-part>+requiretls@domain.tld (for example, arvel+requiretls@mdaemon.com) are subject to the RequireTLS process. All other messages are treated as if the service was disabled. Several requirements must occur before a message will be sent using RequireTLS. If certain of them fail the message will not be sent and will bounce back rather than be sent in the clear. The requirements are:

[21594] SMTP MTA-STS (RFC 8461) - STRICT TRANSPORT SECURITY

The MTA-STS effort in the IETF has finished. Support for this has been implemented. SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

MTA-STS is enabled by default. It can be disabled at Setup | System | Encryption.

[21596] SMTP TLS Reporting (RFC 8460)

TLS Reporting allows domains using MTA-STS to be notified about any failures to retrieve the MTA-STS policy or negotiate a secure channel using STARTTLS. When enabled, each day SecurityGateway will send reports to all STS-enabled domain that it has sent (or attempted to send) mail to that day.

TLS Reporting is disabled by default. It can be enabled at Setup | System | Encryption. Also make sure DKIM signing is enabled (at Security | Anti-Spoofing | DKIM Signing) because TLS Reporting emails should be signed.

[21072] DOMAIN ADMINISTRATORS CAN CREATE NEW DOMAINS

[22364] FIREBIRD 3 IS USED FOR NEW INSTALLATIONS

CHANGES AND NEW FEATURES

FIXES

Copyright ©2008-2020 MDaemon Technologies, Ltd.