Additional Security Measures for MAX MailProtection

In our continued efforts to ensure high availability of our MAX MailProtection (formerly ControlEmail) solution, we have implemented some additional security measures that are designed to help secure our customers from the risk of emerging large-scale spam attacks.

Within our inbound message handling architecture, we have implemented a rate limiting system, similar to that used already for the outbound message processing. This will limit the number of messages each individual mail handling server will accept from a given sending IP address based on a configurable threshold of messages that if exceeded, will trigger a temporary deferral message. The risk of deferring legitimate mail by this technique is low.  With rare exception, the only servers that send large volumes of email from a single IP address are either large-scale marketing systems, compromised systems used to disseminate spam, or other spam sources.

In addition, each inbound handler will track – based on each individual sending IP address – the percentage of suspicious mail (including spam, viruses, or blacklisted mail) detected, and will defer those senders with a very poor recent history.

These additional security measures are a reflection of our ongoing efforts to protect customers from email-borne threats.

Thanks for your attention.

Update on Inbound Message Processing

11:30 AM Pacific / 7:30 PM GMT —  The spike in overall traffic volume has declined, and message processing times have improved; our monitoring is showing operating levels close to normal in both the California and Amsterdam datacenters.  We are continuing to look into the source(s) of the issue, and are working on additional measures to help secure our customers from these threats.

Spike in Traffic Volume for MAX MailProtection

7:45am Pacific / 3:45pm GMT —  Our monitoring has detected a large spike in traffic volumes beginning a few minutes ago, that may be impacting inbound message processing for at the California datacenter, and to a lesser extent the Amsterdam datacenter.  As a result some customers, mostly in North America, may experience delays with inbound mail. Our engineers are investigating this now, and we will post updates here as more information becomes available.

Handling of Messages to Unknown Addresses

Large-scale spam runs can impact inbound message processing. To ensure it does not impact you, our customer, we have made a configuration change by which we will now apply greylisting to unknown recipients at domains that are configured to pass through (e.g. not filter) unknown addresses at those domains.

This change is designed to help protect our infrastructure and the infrastructure of our customers. This approach will reduce the processing, network bandwidth, and mail server utilization involved with handling large volumes of messages sent to unknown and unfiltered email addresses.

Greylisting messages to unknown addresses will trigger the issue of an initial temporary failure to the sending server, similar to our typical greylisting response but containing an “R22” message instead of an “R8” message.

As with typical greylisting, legitimate senders will retry a few minutes later, and our service will use the same remote recipient checks as in the past.

Note that there is no change for domains that are configured to block or drop messages to unknown users, or that are configured to automatically add new mailboxes based on inbound mail flow.

We recommend that customers add all valid mailboxes for their domain(s) to the service, via LDAP synchronization or other method, and configure our service to automatically block messages sent to invalid addresses at the domain.  This allows our service to block the many messages sent to bogus addresses at a domain, without the need to initiate a connection to the customer’s mail server to try to verify each potentially bogus address.

This change is another positive step in our ongoing efforts to block email-borne threats.

Thank you.