rootaction.net

We block traffic from bad actors

By design, the mail server at rootaction.net blocks non-compliant traffic, as well as traffic from hosts known to propagate spam. We regularly review this design according to best practices, and we monitor blocked mail statistics for aggregated anomalies.

A typical 10-day period of all blocked traffic is categorized below.  This amounts to 85% of all mail traffic to our server. 

blocked by |  count |  percent
-----------+--------+---------
hostcheck  |   8015 |    85.88
greylist   |    964 |    10.37
spamrbl    |    349 |     3.75
smtpauth   |      0 |     0.00
-----------+--------+---------
total      |   9328 |   100.00

We use a variety of automated tools to screen mail traffic for spam.  This permits us to keep your inbox relatively clean without having to manually curate (and read!) your email.  Mail that passes all of these checks will be delivered.  The checks are applied in the following order, with the first failed check preventing delivery:

1. A hostname compliance check. This inspects Sender Policy Framework and Domain Keys entries, if applicable, and ensures that the sender’s mail gateway has a compliant address.
2. Greylisting.  This asks the sender’s mail gateway to try again in a short while.  Compliant mail gateways will honor the request, retrying a short while later from the same gateway address.  Most spammers don’t operate compliant mail gateways.
3. Real-time Block Lists.  These are evidence-based lists of gateways known to send spam.  The lists are maintained by third parties.
4. SMTP authentication.  This requires that mail purporting to be from one of our hosted domains is sent by a user that possesses appropriate credentials.
5. Automatic filtering, including anti-virus and spamassassin.

My legitimate mail is blocked! Help!

These are the unpalatable facts:

• No automated method can identify and block 100% of spam
• All automated methods to block spam have false positives
• Manually curated e-mail doesn’t scale and brings privacy concerns

The best practice, then, is to automate checks such that “not too much” spam gets through and “not too much” legitimate email is blocked.

When legitimate mail is blocked, there are different mitigations for the different reasons.  Let’s look at the checks our server does one by one.

Hostname compliance check

If your sender’s traffic is rejected due to a hostname compliance check failure, their ISP has grossly mis-configured their server and your sender should notify them so they can fix it.  It is extremely unlikely to be a false positive, and there is no action that we can take on the receiving side to fix this.

Greylist

Unfortunately, a few big tech companies and niche ISPs operate non-compliant gateways, too.  The only mitigation that we apply on the recipient side comes from the vendor of our OS, in the form of a list of known non-compliant sources of “legitimate” mail.

We recommend that the sender get in touch with their ISP to bring their mail gateway into compliance. Alternatively,  the sender can lobby the upstream package maintainers to add an exception for their ISP.

Real- time block lists

Real-time block lists are evidence-based. This means that a mail gateway on such a list is known to be sending spam, or has very recently sent spam. If your sender’s ISP is on any of the real-time block lists that we consume, they (the ISP) must resolve the issue.  The lists we use automatically remove entries some number of hours after the spam has stopped.

SMTP Authentication

Your sender is using a mail gateway that requires authentication, but has not provided credentials.  If (and only if) your sender is using a mail account hosted on rootaction.net, they should configure their mail client to authenticate as described here.

Automatic Filtering

To protect you and the internet at large, all traffic that passes through our server (inbound, outbound, or through any mailing lists we operate) is automatically filtered by several antivirus tools and by SpamAssassin. These automatic filters are deployed with the standard tuning provided by our OS vendor, and get regular updates. Since we don’t tune these filters locally, we believe they are unlikely to cause many false positives. If you believe your message has been blocked by anti-virus or spam filtering running on our server, please reach out and we will look into it.

My sender’s ISP won’t fix it, can’t you dial this back a notch?

Disabling just one of the described compliance checks would permit between 3.75% and 85.88% more spam to reach your mailbox. In brief, when these checks fail it is an originating-side issue:

• A gateway failing the hostname compliance check is broken and probably isn’t successfully sending mail to anyone.
• A gateway failing the greylist check is not compliant with relevant internet standards and there’s really nothing we can do about it.
• A gateway on the RBLs we consume is compromised by bad actors at worst and is permitting its own authorized users to send spam at best.
• An SMTP authentication issue experienced by the holder of an account on rootaction.net can be resolved by using your provided credentials to login.

We get around 1000 messages a day of spam. You wouldn’t want us to curate each message by hand: it would delay all of your mail and it would be a violation of your privacy.

I’m still getting too much spam, can you dial it up a notch?

Best practices for blocking spam are constantly evolving, and we regularly take advantage of new developments in this area. In the meantime, you can use SpamAssassin to filter spam from your inbox and train it to be more aggressive for your account(s). This requires running spamassassin a second time, as configured in your user account. The training is reasonably simple once you can sort samples from your inbox into known ham (desirable messages) and known spam (undesirable messages). It can take a quite a lot of samples to make a difference, though.