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.
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)|
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 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)).
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",
# Local submission by SMTP
chan local-smtp prog=smtp,show="with
# External inbound and all outbund SMTP
chan external-smtp prog=smtp,key=smtp,
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"|
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="rbl=rbl.widgets.com,reject=421 go away"|
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.
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.
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.
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.
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.
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.
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 aliresses being unroutable. This should be inserted
in the tailor file before the (default) external-smtp channel
|# known spamming hosts for SMTP inbound
tbl spamhosts show="Spamming SMTP hosts",file=spam-hosts
# Null domain table for spamming hosts
# Spam hosts inbound SMTP channel
chan spam-smtp prog=smtp,show="with SMTP
This will cause messages to be rejected at the SMTP level.
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.
6a) MUST NOT refuse "MAIL From: <>".
6b) MUST NOT refuse "MAIL From: <email@example.com>".
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, <firstname.lastname@example.org>.
Possible using item (7)
7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
8) SHOULD be able to limit ("Rate Control") mail flow.
9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).
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