The Spamhaus Project

blog

A misuse of Spamhaus blocklists: PART 2 - How to limit outbound spam

If you’ve skipped the first part of this series, we strongly recommend you go and read this blog first (link below), to understand the misuse of Spamhaus blocklists to block outbound mail. However, if you provide a mail service and want to learn specifically how to limit your outbound spam, read on.

by The Spamhaus TeamAugust 28, 20245 minutes reading time

Jump to

Introduction

As mentioned above, here is the first blog to help understand the misuse of Spamhaus blocklists to block outbound mail.

There are two types of email service providers: dedicated email service providers, and ISPs that provide a mail service to users they connect to the internet. Let’s start with email service providers:

I am not an ISP, I only supply a mail service

You have customers connecting from all over the world. They use your mail service using SMTP authentication, and your goal is to prevent them from abusing your service. Of course “them” may include malware hosted on “their” devices, or, even more commonly, by a criminal that stole their login credentials to access your service.

The key here is that - in this case - any action occurring on your system has an associated account, so that you can monitor activity on a per-account basis.

The problem of spam through hacked accounts has been plaguing the internet for years. Over 12 years ago we shared some ways to control this kind of abuse; some suggestions that we still recommend today:

  • Implement default per-account limits on numbers of outgoing emails.
  • Log the authenticated user account for each email sent.
  • Include the authenticated user account name (or a hash of it) in the email headers.
  • Monitor the email flow from each account; take action when this changes suddenly
  • Check for and reject weak passwords
  • Limit the rate of authentication attempts to prevent password cracking.

You may also consider disallowing sending from domains whose mail you do not host and sign all mails using DKIM.

So, are Spamhaus datasets useless for outbound mail?

No, AuthBL - available via Spamhaus Technology’s Data Query Service (DQS) can be very useful in this situation. It lists IP addresses known to host bots using brute force or stolen SMTP AUTH credentials to send spam, phishing and malware emails.

Still, AuthBL is a XBL subset and outright blocking listed IPs attempting to submit mail may generate false positives. You could use it for blocking submissions if you closely monitor the issue and contact the customer where there is a hit. Otherwise, an AuthBL hit may add points to a scoring system (such as SpamAssassin) applied at submission to possibly block the message if a number of criteria are simultaneously met, or just to bring suspect activity to your attention for analysis.

Some mail providers maintain two different platforms for outbound mail, a “high reputation” one and a “low reputation” one. Messages that build up a negative score due to an injecting IP in AuthBL or spammy content may be routed through the low reputation platform. This usually allows you to operate with some spam getting through without affecting the majority of the legitimate traffic.

What if I am an ISP, supplying a mail service to users I connect to the internet?

If you are an ISP connecting users, all the considerations above will still apply for your mail service, but there are a few more options to consider. Your mail service will receive connections coming from internal and external IPs, with the former probably being the majority, and you may be a little more aggressive on the policies adopted for the latter (“travelling users” but also abusers).

If you use a scoring system, you may slightly penalize submissions coming from external IPs. At the same time, you should monitor regular listings (CSS - Combined Spam Sources, XBL - Exploits Blocklist) on your internal IPs and investigate what happens. A good tool to discover more signal relating to listed IPs is Spamhaus Technology’s Intelligence API (SIA).

Furthermore, if you are an ISP connecting many end user devices, we recommend that as a first step, you limit port 25 outbound access to mail servers only, and deny it to all others. This basically achieves the same result of PBL, but in a cleaner way and without requiring the remote site to use our data. Users sending legitimate mail should not be affected because they will submit mail using authentication (using other ports such as 587 or 465) to their SMTP service supplier.

Blocking port 25 is a strategy that has been used in the ISP industry for years and has proven to be highly successful in decreasing the emission of spam. You can find more details on it in a document prepared by the M3AAWG working group: (https://www.m3aawg.org/Port25_IPNetworks)

Will this stop all abuse from your network?

No, it will only stop direct mails from your end user pool, which is usually a sizable and important chunk. If you have CSS listings in the range they will disappear because they are related to direct SMTP traffic. Spam sent through third party servers using hacked credentials and other abuse related with malware will continue as it does not use port 25.

Finally, we urge network owners and ISPs to submit PBL ranges in order to maintain control of their network's IP space that does not host mail servers by policy.

Sign up for a PBL ISP account here and ensure full control and correctness of PBL data - you can manage your IP space in bulk, and as you prefer.

Help and recommended content

See below for helpful articles and recommended content