SecurityGateway for Email Servers v6.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 6.0.0 - February 12, 2019

SPECIAL CONSIDERATIONS

MAJOR NEW FEATURES

[9809] Message Archiving

[17480] 64bit Version

[18560] Improved Data Leakage Prevention

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 5.5.0 - May 8, 2018

MAJOR NEW FEATURES

[17479] IPV6 SUPPORT

Support for IPv6 has been added.  SecurityGateway will detect the level of IPv6 capability that your OS supports and dual-stack where possible; otherwise, SecurityGateway will monitor both networks independently.  If enabled, outbound SMTP connections will prefer IPv6 over IPv4 whenever possible.

A few options related to use of IPv6 can be found at Setup | System | IPv6.

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 5.0.1 - February 20, 2018

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 5.0.0

MAJOR NEW FEATURES

[18924] LOCATION SCREENING

A geographically based blocking system has been developed which allows you to block incoming SMTP and Remote Administration connections being attempted from unauthorized regions of the world. A new screen has been added at Security|Anti-Abuse|Location Screening to configure this.

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 4.5.1 - May 9, 2017

MAJOR NEW FEATURES

[15657] SecurityGateway now integrates with the RMail™ service from RPost®

RMail™ is intuitive to use and there’s no requirement for your recipients to have any special software whatsoever. RMail™ empowers email usage for consumers and businesses of all sizes, across all industries and departments.

The RMail™ service is powered by RPost's Registered Email® technology, the global standard for email delivery proof. The RMail™ service extends your email platform, providing:

Using a free RPost account, each user is limited to sending/receiving 10 encrypted messages per month. Additional messages can be purchased through RPost.  Click here for information on plans/pricing for increased message limits.

The RMail™ service may be enabled from the Security | RMail™ page or as an action of a message content filter rule.

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 4.5.0 - April 4, 2017

SPECIAL CONSIDERATIONS

[18161] The option "Honor CRAM-MD5 authentication method" found at Setup / Users | Mail Configuration | Email Protocol has changed to disabled by default for security and technical reasons. Using TLS is the preferred way to avoid transmission of passwords in the clear.

CHANGES AND NEW FEATURES

FIXES

 SecurityGateway 4.0.0 - June 14, 2016

MAJOR NEW FEATURES

[15999] Web Interface Updated to use a Mobile First Responsive Design

The web interface has been updated to use a mobile first responsive design.  Browser support is limited to IE10+, the latest Chrome, the latest Firefox, and the latest Safari on Mac and iOS.  Android stock browsers have been known to have issues with scrolling, but Chrome on Android devices works well.

This design is based entirely on the size of the window being used.  Whether the user is on a phone, tablet, or PC, the appearance is the same for the same window size.  The most important change here is the menu.  From 1024 pixels width on down the menu is hidden on the left side of the browser.  There are two methods that can be used to display the menu.  If a touch device is in use, swiping to the right will show the secondary menu.  Whether or not a touch device is in use, there is also a "menu" button in the top left corner that will display the secondary menu.  Tapping or clicking the menu title with the left arrow next to it at the top of the menu will display the primary menu.  The help, about, and sign out menu in the top right corner changes based on the width of the screen as well.  From 768 pixels up shows the words Help, About, and Sign Out, from 481 pixels to 767 pixels only displays the icons, and 480 pixels or less displays a "gear" icon which when clicked or tapped will display a drop down menu with the Help, About, Sign Out options.  List views with more than one column have column on/off buttons.

[11232] DMARC

Support for DMARC (Domain-based Message Authentication, Reporting, and Conformance) has been added. DMARC defines a scalable mechanism by which a mail sending organization can express, using the Domain Name System, domain level policies and preferences for message validation, disposition, and reporting, and a mail receiving organization can use those policies and preferences to improve mail handling. The DMARC specification and full details about what it does and how it works can be found here: http://www.dmarc.org/.

DMARC allows domain owners to express their wishes concerning the handling of messages purporting to be from their domain(s) but which were not sent by them.  Possible message handling policy options are "none" in which case SecurityGateway takes no action, "reject" in which case SecurityGateway refuses to accept the message during the SMTP session itself, and "quarantine" in which case SecurityGateway places the following header into each message for easy filtering into your user's Junk E-mail folder:  "X-SGDMARC-Fail-policy: quarantine".  This header is only added when the result of the DMARC check is "fail" and the resulting DMARC policy is something other than "none."  It is possible to configure SecurityGateway to accept messages even though DMARC requests that they be rejected.  In fact, this is the default operational mode.  In these cases SecurityGateway will place an "X-SGDMARC-Fail-policy: reject" header into the message in case you want to filter more seriously on that.

DMARC supersedes ADSP and the message disposition features of SPF.  However, you can still use all of them together with DMARC.   ADSP and SPF message rejection now takes place after DMARC processing if DMARC verification is enabled.

DMARC depends in part upon the use of a "Public Suffix List." A "Public Suffix" is one under which Internet users can directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us. A "Public Suffix List" is a list of all known public suffixes. SecurityGateway uses the one maintained for the community by the Mozilla Foundation that is found here: https://publicsuffix.org/. A copy of this list is installed into your \App\ folder as effective_tld_names.dat. There is currently no comprehensive or single authoritative source for such a list which is an issue the Internet community should address. Over time this file will grow obsolete and must be replaced by downloading it afresh from https://publicsuffix.org/list/effective_tld_names.dat and saving it to your \App\ folder. SecurityGateway will periodically and automatically download and install this file as part of the daily maintenance event approximately once every two weeks.  Various controls to govern this can be found on the new DMARC configuration screens.  The DMARC log and the new DMARC window within the Security tab inside the main UI will contain the results of the update and all other DMARC processing operations.  You can set a different file download URL if needed but the data downloaded must conform to the format specified by Mozilla for their file. You can read about this at the URL mentioned above.  SecurityGateway strictly follows the parsing algorithm specified by Mozilla. Create a (possibly empty) file called "PUBLICSUFFIX.SEM" and place it in SecurityGateway's \App\ folder if you replace or edit the effective_tld_names.dat file yourself and need SecurityGateway to reload it without a reboot.

To use DMARC as a mail sender you must publish a DMARC TXT record within your domain's DNS setup.  Information on how this record is defined and structured can be found at http://www.dmarc.org. When you publish a DMARC record to your DNS you may begin receiving DMARC reports from many different sources via email. These reports are provided as a compressed XML file whose format is governed by the DMARC specification. Consuming these reports is outside the scope of SecurityGateway's DMARC implementation. However, the data within these reports can provide important insight into a domain's mail flow, improper domain use, DKIM signing integrity, and SPF message path accuracy/completeness. The addresses to which these reports are sent is configured by you when you create your DMARC record.

When setting up a DMARC record for one or more of your domains take care with use of p=reject.  Take particular care if your domain provides email accounts for general use by human users.  If such users have signed up for any mailing lists, make use of a mail forwarding service, or expect to use common things like "share this article with a friend" you should know now that a DMARC p=reject policy could make those things entirely impossible and if so you'll hear about it.  DMARC p=reject is perfectly appropriate and useful but only when it is applied to domains that control how their email accounts are used (for example, transactional mail, automated (i.e. non-human) accounts, or to enforce corporate policies against use of the account outside organizational boundaries).

In order to support DMARC aggregate reporting SecurityGateway will store data which it will need later in order to generate aggregate reports according to the DMARC specification. SecurityGateway ignores the DMARC "ri="; tag and only produces DMARC aggregate reports that cover from 00:00:00 UTC to 23:59:59 UTC for a given day. At midnight UTC (which is not necessarily midnight local time) SecurityGateway consumes this stored data to generate the reports. SecurityGateway needs to be running at this time or the stored data could grow and grow and never be consumed. Therefore, if you do not run your SecurityGateway 24/7 you should not enable DMARC aggregate reporting.  DMARC aggregate reporting is disabled by default.

In order to support DMARC failure reporting RFC 5965 "An Extensible Format for Email Feedback Reports", RFC 6591 "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652 "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6651 "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", and RFC 6692 "Source Ports in Abuse Reporting Format (ARF) Reports" have been fully implemented.  Failure reports are created in real-time as the incidents which trigger them occur.  SecurityGateway implements DMARC AFRF type failure reports and not IODEF type reports.  Therefore, only values of "afrf" in the DMARC "rf=" tag are honored.  See the DMARC specification for complete details.  Multiple failure reports can be generated from a single message depending upon the number of recipients in the DMARC record's "ruf=" tag and upon the value of the "fo=" tag times the number of independent authentication failures which were encountered by the message during processing.  When the DMARC "fo=" tag requests reporting of SPF related failures SecurityGateway sends SPF failure reports according to RFC 6522.  Therefore, that specification's extensions must be present in the domain's SPF record.  SPF failure reports are not sent independent of DMARC processing or in the absence of RFC 6522 extensions.  When the DMARC "fo=" tag requests reporting of DKIM related failures SecurityGateway sends DKIM and ADSP failure reports according to RFC 6651.  Therefore, that specification's extensions must be present in the DKIM-Signature header field and the domain must publish a valid DKIM reporting TXT record in DNS and/or valid ADSP extensions in the ADSP TXT record.  DKIM and ADSP failure reports are not sent independent of DMARC processing or in the absence of RFC 6651 extensions.  See the various specifications referenced herein for complete details.  DMARC failure reporting is disabled by default.

Important Note:  A DMARC record can specify that reports should be sent to an intermediary operating on behalf of the domain owner. This is done when the domain owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by your privacy policy, terms of use, or other similar governing document.  You should review and understand if your own internal policies constrain the use and transmission of DMARC reporting and if so you should disable DMARC reporting as appropriate.

DMARC requires use of STARTTLS whenever it is offered by report receivers however there's no way to predict or police this.  However, you should enable STARTTLS if you haven't already (see Setup | System | Encryption).

The Authentication-Results header has been extended to include DMARC processing results. Note that Authentication-Results includes some data in comments for debugging purposes including the DMARC policy requested by the domain owner which is not necessarily the action taken on the message. For example, when the result of a DMARC check is "pass" it does not matter what the DMARC policy states as policy is only applied to DMARC checks which "fail". Similarly, when the result of a DMARC check is "fail" and the policy is "reject" the message may be accepted anyway for local policy reasons. Use of this header for filtering should take all this into account.  Alternatively, filter for "X-SGDMARC-Fail-policy: quarantine" or "X-SGDMARC-Fail-policy: reject" to filter these messages into spam folders or whatever you want to do.  SecurityGateway strips out the "X-SGDMARC-Fail-policy:" header from every incoming message.

Messages must conform to DMARC section 15.1 with respect to the RFC 5322 From header or they are not processed which basically means that the absence of a single (one and only one) properly formed (according to RFC specifications) RFC5322 From field renders the message invalid generally and therefore invalid for DMARC processing.

Several new screens have been added at Security | Anti-Spoofing where you can set various options related to DMARC use. 

DMARC requires SPF and/or DKIM verification to be enabled as it is based upon the verified identities that those two mechanisms provide.  You can't make productive use of DMARC for inbound mail without one or both of those technologies enabled. The UI will try to enforce this. 

[3961] Bind Domain to an IP address

 For servers that have multiple IP addresses assigned, each domain may be bound to a specific IP address.  Mail from the domain will be sent from this IP address.

A SMTP Hostname may also be specified for the domain. This value is the Fully Qualified Domain Name (FQDN) that will be used in the SMTP HELO/EHLO instruction when sending mail for the domain. For incoming connections, this value will be used unless multiple domains are bound to the IP address, in which case the FQDN used will be the one that is associated with the domain that is first in alphabetical order.

CHANGES AND NEW FEATURESS

FIXES

SecurityGateway 3.0.3

CHANGES AND NEW FEATURES

FIXES

 

SecurityGateway for Email Servers v3.0 Release Notes

Developed with over 10 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.

SecurityGateway 3.0.2 - September 9, 2014

CHANGES AND NEW FEATURES

FIXES

SecurityGateway 3.0.1 -  June 17, 2014

FIXES

SecurityGateway 3.0.0 - May 27, 2014

SPECIAL CONSIDERATIONS

CHANGES AND NEW FEATURESS

FIXES