Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Support

Technical Note: Configuration of M-Switch to Counter Junk E-Mail (Spam)

The purpose of this Technical Note is to provide system administrators with the configuration steps which may be of assistance in countering junk e-mail, sometimes known as spamming.

The reasons for doing this include:

• To stop your users being the target of junk e-mail.
• To stop your site being used as a relay for junk e-mail messages.

The Isode Message Switch contains a number of features which can be useful in achieving these goals. This version of the note relates to the features available in Isode release R4.1v2, although there is some discussion of features relevant to R4.0v3.

This note deals exclusively with Internet/SMTP mail as it is in this environment that junk e-mail is a particular nuisance. Many of the techniques are also applicable to other mail protocols including X.400. The configuration mechanisms used are documented in Administrator's Guide: Message Handling Services (IC-1103).

This note does NOT cover the content filtering capabilities, introduced in R7.3, which are the most powerful and effective spam elimination capabilities provided by M-Switch.

Capabilities

This note describes mechanisms which can be used to counter junk e-mail. The selection of mechanism will depend on the site. The mechanisms deal with the following four types of capability. The choice of mechanisms will depend on the total system configuration and the problems being addressed.

• Prevention of use of the site for relaying e-mail. This is recommended for use by all sites. The mechanism is described in item (1).
• Dealing with techniques where the identification of the source host is hidden or faked (item (2)).
• Blocking mail from identified hosts (item (3), item (6), item (9)).
• Blocking mail from specific message originators or originators matching a specific pattern (item (4), item (5), item (7) & item (8)).

Rejection Mechanisms

There are three basic ways in which SMTP e-mail can be rejected by the Isode message switch:

• By rejection of the SMTP connection.
• By rejection of a message at the SMTP protocol level.
• By use of the generation of a non-delivery report. If the non-delivery report cannot be delivered, which is common with junk e-mail, it is likely that the local postmaster will get the resulting report.

And there are two primary keys which drive these:

• The true domain name of the calling SMTP host.
• The address of the sender as given in the SMTP 'MAIL FROM:' command.

These are summarized in the following table:

	Reject SMTP connection	SMTP-level message rejection	Non-delivery report  (R4.0v3 and earlier)
Calling SMTP host	item (2), item (3)	item (1), item (6), item (9)	item (1), item (6)
Sender address		item (4), item (5), item (7), item (8)	item (7), item (8)

Requirement for good DNS reverse lookup

Several of the techniques (1, 2, 3, and 5) in this note rely on getting good results from reverse lookup of IP addresses in DNS. For this the resolver in use must verify that the result of a reverse lookup (IP address -> domain name) is actually satisfied by a corresponding forward entry (domain name -> IP address list). Recent release from most major UNIXT manufacturers have resolver libraries which meet this requirement (including Sun Solaris 7) but it is worth checking. We believe that there are several systems which have problems.

Otherwise an originator of junk e-mail could create a reverse entry in the DNS for one of his own IP addresses which resolves to fake-host.naive.example.net and then get mailhost.naive.example.net to relay the message believing it to come from an internal host, even if external relay is blocked (see item (1)).

(1) Prevention of undesirable message relay

It is often the case that an unsuspecting site will be used as a relay for junk e-mail. This is particularly undesirable as many sites on the Internet are implementing a policy of blocking e-mail which comes from a site from which they have received junk e-mail. It can be prevented by blocking external SMTP to external SMTP relay.

The actions to be taken depend on the requirements for SMTP traffic that is to be local. There are three cases:

1. No local SMTP traffic

2. SMTP used locally for submission only (e.g. from local POP or IMAP user agents)

3. SMTP used locally for submission and delivery.

In the latter two cases a new SMTP channel should be setup. The existing SMTP channel should be renamed, for instance, to external-smtp. The steps are:

1. Use authorization to block relay from external-smtp to external-smtp by entries in the auth.channel table:

You may wish to allow some use of this route for particular users or hosts. In this case use the channel policy block, rather than none.
 

2. Unless there is no local-SMTP traffic, setup the channel to be used for local traffic. This should be of type in for the submission-only case, otherwise of type both. If your MTA sends local traffic out using SMTP, you will also need to ensure that this local traffic uses the local SMTP channel for transfer out. This can be done either using the channel table, for table based routing, or by using the mtatable with the directory names of the local hosts for Directory based routing.
 

The smtpsrvr program should use the channel key value ("smtp" in the following example) as the channel name when invoked.

The following example illustrates a submission-only local SMTP channel:

3. The contents of the table localhosts determines which calling hosts will use the local-smtp channel. The structure of the table is like a domain table used for routing. However, the value associated with a domain or wild-card domain is not important, as long as it is valid. If the calling hostname matches the entry in the table, then the associated channel will be used for authorization.
 

The hostname that is used will be the name found by reverse lookup of the IP address. If no such reverse lookup is possible, then the name that is used here is derived from the IP address by reversing its components. Thus the IP address 193.133.227.43 would be looked up as 43.227.133.193. This is not true for R4.0v3 and earlier, which uses the forward IP address in these cases.

(2) Blocking connections from hosts not registered in the DNS

A common tactic of people sending junk e-mail is to make the messages come from, or appear to come from, hosts which are not properly registered in the DNS and for which it is not possible to perform an IP address reverse lookup. Unless the SMTP channel is configured with
then such calls will be rejected. Note that this will reject mail from badly configured systems and it will not reject mail from well-configured ones. It seems that such badly configured systems are commonplace on the Internet today and consequently this mechanism should be used with caution.

Note that, strictly speaking, this and some of the other techniques below are in contravention of the Internet hosts requirements (RFC1123). These requirements are probably too weak to help deal with abuses of the Internet such as junk e-mail.

It is possible to determine if the call is rejected permanently or temporarily by configuring in the ininfo value a string which gives the SMTP return code followed by a text message (not R4.0v3):
 

 

(3) Blocking connections from hosts in the Real Time Blackhole List

The Real Time Blackhole List is a globally maintained database of hosts which are known to send unsolicited bulk email. It is maintained dynamically. Access can be made using DNS. See <URL:http://maps.vix.com/rbl/> for more details. This can be configured in R4.1v2 and later.

If the calling IP address is found to in the list, then the call is rejected as for item (2). The reject message can be configured in the same way. To configure this, you include the key 'rbl' in the ininfo for the channel, for instance:
 

You can also setup your own list in a local DNS server. The reversed IP address has a domain added to it for lookup. This is configured by adding a value to the rbl key:
 

 

(4) Checking sender domains in DNS

If the policies dns-tbl or dns-ds are used, the domain of the sender of the mail is checked in the DNS. If the domain is invalid, then the mail is refused.
 

(5) Known bad sender domains

Another technique which can be used for specific domains if tables are being used for routing (that is, the inlookup for the SMTP channel starts with table or dns-tbl) is to deliberately misconfigure the domain by placing an entry like in the domain table and no entry for nowhereland in the channel table. Some logging messages from submit complaining about the misconfiguration will occur but these are harmless.

A related technique can be used if using Directory based routing (policies ds or dns-ds) . The domain is added to the routing tree used by the MTA. The MTA information is set pointing to the local MTA or MTAs. Then the domain is treated as local, and as there are no local-parts beneath the domain, routing will fail.

Note that both of these techniques prevent you sending mail to these domains as well as receiving mail from them.

(6) Blocking traffic from specific hosts

If specific hosts are identified as being the source of junk e-mail then all traffic from them can be blocked by use of the auth.channel and auth.mta tables.

In the auth.channel table set the default policy to negative so that the auth.mta table (and possibly the auth.user table) may be used to block specific hosts. 

In the auth.mta table block those hosts from which messages are not desired by only allowing outbound traffic.

For R4.1v2 and following, this will result in rejection at the SMTP protocol level. For earlier releases, a non-delivery report will be generated.

(7) Blocking traffic from specific users

A similar technique can be used if it is found that specific sender addresses are being used. In this case use the auth.user table instead of auth.mta.

(8) Blocking bad addresses from good hosts

Sometimes a generally good host is used as the source of messages but the local-part of the mailbox address is invalid and follows a particular pattern: for example, all digits. In this case the sender-excludes facility of the auth.mta table can be used.
 

 

(9) Blocking traffic from specific hosts - alternative method

An alternative technique to block traffic from specific hosts is to define another SMTP channel for bad domains and use its MTA table to determine those domains. This can include domain-table wildcarding, which gives greater flexibility over item (6). All relay from this channel can then be blocked in the auth.channel table. Another option is to configure this channel with routing tables which will result in all addresses being unroutable. This should be inserted in the tailor file before the (default) external-smtp channel described earlier.
 

This will cause messages to be rejected at the SMTP level.

Relation to the Recommendations in RFC 2505

RFC 2505 "Anti-Spam Recommentations for SMTP MTAs" has recently been published.  This section discusses the capabilities of the Isode Message Switch in relation to this document.

RFC 2505 does not discuss blocking calls from certain hosts (Items (2) and (3)).

The following summary of recommendations is taken from Section 2 of RFC 2505, with comments added relating to the behaviour of the Isode Message Switch

1) MUST be able to restrict unauthorized use as Mail Relay.

Possible using item (1)

2) MUST be able to provide "Received:" lines with enough information to make it possible to trace the mail path, despite spammers use forged host names in HELO statements etc.

If the name given the the HELO differs from the name found by reverse lookup, both names are given in the Received: header.

3) MUST be able to provide local log information that makes it possible to trace the event afterwards.

The stat log contains the real host name.

4) SHOULD be able to log all occurrences of anti-relay/anti-spam actions.

These are logged at exceptions level.

5) SHOULD be able to refuse mail from a host or a group of hosts.

Possible using item (2), item (3), item (6) and item (9)

6a) MUST NOT refuse "MAIL From: <>".

6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".

The sender does not override controls based on host name, so it is possible to block such mail from sites which are deemed unfriendly.

7a) SHOULD be able to refuse mail from a specific "MAIL From:"user, <foo@domain.example>.

Possible using item (7)

7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.

Possible using item (4) and item (5),

8) SHOULD be able to limit ("Rate Control") mail flow.

Not possible

9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).

Possible, see item (4) and item (5)

10) SHOULD be able to verify <local-part> in outgoing mail.

This is normally done

11) SHOULD be able to control SMTP VRFY and EXPN.

No control possible. EXPN only expands Directory based lists

12) SHOULD be able to control SMTP ETRN.

Not applicable, ETRN is not supported.

13) MUST be able to configure to provide different Return Codes for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).

Only possible for the call rejection mechanism