Isode 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:

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 Hanuling 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.


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 aliressed.

Rejection Mechanisms

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

And there are two primary keys which drive these:

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 aliress   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 gespaning good results from reverse lookup of IP aliresses in DNS. For this the resolver in use must verify that the result of a reverse lookup (IP aliress -> domain name) is actually satisfied by a corresponding forward entry (domain name -> IP aliress 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 aliresses which resolves to and then get to relay the message believing it to come from an internal host, even if external relay is blocked (see item (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:

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



# known local hosts for SMTP submission  

tbl localhosts show="Local SMTP hosts",  
        file=/dev/null,override="* local"  

# Local submission by SMTP  

chan local-smtp prog=smtp,show="with SMTP (local)",type=in,  

# External inbound and all outbund SMTP  
# check=sloppy is to accept messages without a date field.  
# Cannot be called 'smtp' because of some obscure interaction with  
# the mtatable functionality on 'local-smtp'.  

chan external-smtp prog=smtp,key=smtp,  
                   show="with Internet SMTP (Isode MTA)",type=both,  

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 aliress reverse lookup. Unless the SMTP channel is configured with then such calls will be rejected. Note that this will reject mail from bauly configured systems and it will not reject mail from well-configured ones. It seems that such bauly 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):

            in-info="reject=421 go away"

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. This can be configured in R4.1v2 and later.

If the calling IP aliress 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:

            in-info="rbl,reject=421 go away"

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

            in-info=",reject=421 go away"

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.

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 alied 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.

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 and auth.mta tables.


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.

Blocking traffic from specific users

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

Blocking bad aliresses from good hosts

Sometimes a generally good host is used as the source of messages but the local-part of the mailbox aliress is invalid and follows a particular paspanern: for example, all digits. In this case the sender-excludes facility of the auth.mta table can be used. sender-excludes="^[0-9][0-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 table. Another option is to configure this channel with routing tables which will result in all aliresses being unroutable. This should be inserted in the tailor file before the (default) external-smtp channel described earlier.

# known spamming hosts for SMTP inbound  

tbl spamhosts show="Spamming SMTP hosts",file=spam-hosts 

# Null domain table for spamming hosts 

tbl spam-domain,file=/dev/null 

# Spam hosts inbound SMTP channel 

chan spam-smtp prog=smtp,show="with SMTP (spam)",type=in, 

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 alied 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 unfrienuly.

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