SMTP relaying misuse problems, and solutions

1. Introduction

Originally the Internet was a tool for scientists doing research, and computing resource sharing in open trusty environment. Unfortunately that is a thing from the past.

2. Relay hijacking

These days a few people who are determined to spew unsolicited junk to as many people as possible are finding ways to get systems, not their own, to do the actual work of distributing the messages:

That is, following things (may) happen:

  1. Host A is abuser's system, and is in no relationship with host B to use the latter as a relay.
  2. A message arriving to unsecured host B is relayed out on behalf of the (hit-and-run) abuser, and it may take either of the outbound routes:
    1. Directly out from B to the target E.
    2. Via a chain (one or more) of relays (C, D) which system B has right to use for outbound email.
  3. People receiving such unsolicited junk usually get mightily annoyed, and take their revenge often against the abused third parties (relays & gateways).

In all cases, if your system has the dubious honour of being a globally reachable open relay (which was all right before about 1995-1997!), your system resources are in danger of becoming abused.

If your host is a relay (B in the picture), you may either get your own host into several possible different relay-blocking lists, and/or you may drag your ISP's major email relay into those lists too!

Be not surprised, if in the latter case both your ISP, and ISP's other customers are getting somewhat mad at you when your open relay is causing trouble to them...

3. Relay-hijack prevention measures

You will in essence have following possibilities:

  1. Install and run software version which is secure against abusive third-party relaying.
    To do that successfully, you may need considerable amount of expertise.
    (And a software which really is secure - or securable, of course.)
  2. Install a firewall with anti-relay controls inside it, and force all incoming (and outgoing) traffic to go via it.
  3. Ask your ISP to change your network ingress router so that you get limited reachability from outside into your network's SMTP ports.
    That is, use your ISP's major relay as a cheap firewall for incoming email feeds.
    Then you can accept anything for local and/or relaying as long as it is coming from your ISP, or inside from your network.

You may have sensible reasons for having a fully reachable SMTP-protocol server in your network -- e.g. remote workers who need to reach the smtp-port for some purpose (usually no such reason is valid for very long.) However: In most cases your own people don't need to reach your own SMTP server with SMTP protocol when they are not within your own network! (But if you insist needing it, you hopefully also know how to run secure shop ?)

To have the email to work, when the limited access to the SMTP protocol servers in your network is enforced, you will need proper entries in the Distributed Domain Name Service (DNS) system. In this style: 

 TARGET.DOM.  IN MX  10  TARGET.DOM.
 TARGET.DOM.  IN MX  20  FIREWALL-OF.TARGET.DOM.
 TARGET.DOM.  IN MX  30  RELAY.ISP.DOM.

 TARGET.DOM.             IN A  11.22.33.44
 FIREWALL-OF.TARGET.DOM. IN A  11.22.33.55

The overall idea is that when email source is using DNS data for routing, lowest of the priority values (10/20/30 at above sample) is attempted first, and progressing upwards.

If the message has arrived for RELAY.ISP.DOM, it does notice that it is in the MX list, and it will drop off all possible entries which have same, or (numerically) higher priority value, as it in itself has.

After such MX list purging, the host RELAY.ISP.DOM will again attempt delivery to the lowest priority system (TARGET.DOM), and if it now can reach it, the message gets delivered, otherwise next system (FIREWALL-OF.TARGET.DOM) is chosen for delivery.

If none of the MX defined hosts are reachable, message is queued and retried latter (from minutes to hours latter).

4. Snafus

In implementing anti-relay measures many systems stumble at various snafus.

Many systems have static tables listing domains they are allowed to do inbound MX relaying for. Very often those datasets are incomplete...

... that is, with above MX example, if FIREWALL-OF.TARGET.DOM does not have explicit mention of TARGET.DOM as destination domain it will allow relaying for, it may reject the domain it has been given at the DNS datasets for relaying.

There exist also software which does this relaying control by checking that the destination domain has MX records, and that relaying machine is one of the servers listed at them.

However, in order to avoid abuse, those MX analysing systems may also have additional checks that they will do relay only if lowest precedence MX entry has their A record(s) at networks for which the server will do relaying. (E.g. an ISP system may check, that MX destinations really are at their customer networks.)

A. References

Blocking Lists
Other References
More Terms
xx

Matti Aarnio