-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>>                                                      CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl.  Links  <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>>                                                                           <<
>> CERT-NL also has stopped the CERT-CC-Mirror service.  Due to this the     <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the  <<
>> complete CERT-CC advisory texts:                     http://www.cert.org  <<
===============================================================================
===============================================================================
Security Advisory                                                       CERT-NL
===============================================================================
Author/Source : Xander Jansen (SURFnet ExpertiseCentrum)    Index  :    S-97-68
Distribution  : World                                       Page   :          1
Classification: External                                    Version:          2
Subject       : Avoiding the relay of e-mail spam           Date   :  12-Sep-97
===============================================================================

SMTP servers are increasingly abused by so-called spammers to distribute
large quantities of unsolicited e-mail to many thousands of recipients.
Section I of this advisory contains a short description of the problem.
Section II describes the impact of this form of abuse. A general
description of possible counter-measures is presented in section III.
Examples for sendmail and PP/MMTA are given in the Appendix.

Because this form of abuse can result in the waste of resources, both
technical and human, CERT-NL strongly recommends to implement these
counter-measures where possible to prevent the abuse of your mailservers
as a spam relay.

I. Problem Description
======================

Spamming - the unsolicited sending of e-mail messages or news articles to
massive amounts of e-mail addresses or newsgroups, usually containing
advertisements or other unsolicited trivia - is an annoying problem of
today.

It is annoying not only for the individual who has to read or remove
the spams, but also for the system/network management departments of
institutions and companies. It can cost money and time and is a waste of
valuable system and network resources.

This is most notably so, when the spammers use Internet-accessible
SMTP servers to distribute their unsolicited messages. This so-called
'Third Party Relaying' (i.e. the SMTP server allows the relaying of
messages from and to third parties) is used by spammers to bypass
certain anti-spam filters and to cover their tracks. In general the
spammer connects to the SMTP port of the relay mailserver and then
sends batches of mail which the relay sends to the many recipients of
the spam message.

II. Impact
==========

This form of abuse can have the following results:

1) The spam appears to originate from the domain of the victim mailserver.
   This will result in complaints sent to the postmaster of the abused
   mailserver and possibly in the blocking of all mail coming from that
   mailserver by remote sites. Tracking down the real source of the spam
   and responding to complaints or resending them to the ISP from where
   the spam originated often takes a considerable amount of time,
   sometimes without any guarantee that the complaints will be acted
   upon effectively, if at all.
2) The load on the mailserver will be much larger since it has to deliver
   messages to a large list of recipients. This will have a negative impact
   on the normal performance and there are cases known where the abused
   server crashed due to the extra load.
3) A large amount of bounces will be generated since many recipient
   addresses will be undeliverable. In general these bounces will be sent
   to a non-existing address resulting in so-called double bounces.
   Many mail systems send these double bounces to the local postmaster
   or system administrator. This can result in filled up mailboxes.

Cases are known where the abuse of a mailserver as spam relay resulted in
over three days of work spent to get the systems back to normal.

III. Solution
=============

Generally speaking it is very difficult to take effective measures
against receiving spam. In many cases it is however possible to
prevent the abuse of your SMTP server as a spam relay.

Essentially, one should carefully define a set of hosts that can be
regarded as local (i.e. falling under the responsibility of your
institution or company) and a set of recipient addresses/domains for
which you will handle mail.

Any message submitted to your SMTP server FROM a host NOT in the set
of local hosts AND destined TO an address NOT in the set of local
recipient addresses/domains should be rejected. All other messages
can pass.

In the appendix examples are given on how to achieve this using
sendmail and PP/MMTA implementations. Both are popular mailservers
within the SURFnet community.

Anti-relaying may not be possible to realize in all mailservers.
In case of doubt please consult your vendor.

When implementing anti-relay measures you should take note of the
following points:

1) Check the correctness of your implementation as much as possible,
   preferably also (whenever possible) by using external accounts.
   Also carefully check your logfiles for possibly incorrect rejections.
2) If your mailserver acts as a fall-back MX-host for other domains
   the anti-relay rules should allow for messages destined for these
   domains.
3) Carefully check how anti-relay measures interact with local aliases
   and/or autoforwarders that expand to non-local addresses.
4) Anti-relay measures can have repercussions for users from your
   organization staying at remote locations (e.g. a conference) that
   want to use your SMTP server. If this functionality is needed you
   should take this into account when implementing anti-relay measures.

CERT-NL strongly urges you to implement the measures proposed, for the
following three reasons:

1) Makes life harder for spammers.
2) Can save you considerable time when YOUR mailserver is being used as
   a relaying site (see section II).
3) Is part of good Internet behaviour - reflecting both on your own
   organization and the SURFnet community as a whole.

More information on spamming in general and possible counter-measures
can be found on http://spam.abuse.net, mirrored at the Hogeschool van
Utrecht at http://spam-mirror.cetis.hvu.nl


CERT-NL thanks Xander Jansen for writing this advisory, Piet Beertema (CWI)
for a long list of contributions, Eric Wassenaar (NIKHEF) and
Maarten van Wijk (Tilburg University) for valuable input on the sendmail
examples and Wolfgang Ley (DFN CERT) for proofreading the final text.

===============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers.
SURFnet is the Dutch network for educational, research and related institutes.
CERT-NL is a member of FIRST (Forum of Incident Response and Security Teams).

All CERT-NL material is available under:
  http://www.surfnet.nl/surfnet/security/cert-nl.html
  ftp://ftp.surfnet.nl/surfnet/net-security

In case of computer or network security problems please contact your
local CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet
customer please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

   E-mail:    cert-nl@surfnet.nl     ATTENDED REGULARLY ALL DAYS
   Phone:     +31 302 305 305        BUSINESS HOURS ONLY
   Fax:       +31 302 305 329        BUSINESS HOURS ONLY
   Snailmail: SURFnet bv
              Attn. CERT-NL
              P.O. Box 19035
              NL - 3501 DA  UTRECHT
              The Netherlands

NOODGEVALLEN:    06 52 87 92 82      ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 52 87 92 82      ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.

===============================================================================

Appendix
========

DISCLAIMER: the configurations presented here are EXAMPLES ONLY. You
will have to adapt these to your own circumstances.


A. Preventing Third Party Relaying with sendmail
================================================

Recent versions of sendmail (8.8.x) can be configured to prevent
unwanted relaying. This appendix gives two examples. These
examples won't work with older sendmail versions. There is
no way to stop relaying via configuration in those older versions.
More information about the latest release of sendmail can be found
at http://www.sendmail.org/

Another working solution not given here is part of a larger set
of anti-spam measures maintained by Claus Assmann. These measures
can be found at

 http://www.informatik.uni-kiel.de/~ca/email/check.html

NOTE: As always the fields in sendmail rules are separated by
      TAB-characters. In these examples the TAB-characters have been
      replaced by spaces. Be sure to change them back to TABs when
      adapting these examples.

A.1 Basic solution
==================

A basic solution, based on an example at http://www.sendmail.org/antispam.html
requires a change in the sendmail configuration file and one extra file,
listing local domains and external domains for which your mailserver acts
as MX-host or from which you accept mail submissions in general. The
configuration change is presented as an M4 macro file. These M4 macros
should be added to your own M4 macro file after which you can generate the
sendmail configuration file (usually sendmail.cf).

 --- Basic anti-relay configuration (m4 format)

 LOCAL_CONFIG
 FR-o /etc/sendmail.relaylist

 LOCAL_RULESETS
 # TAB stop should be -><- here
 Scheck_rcpt
 # anything terminating locally is ok
 R< $+ @ $=w >          $@ OK
 R< $+ @ $* $=R >       $@ OK

 # anything originating locally is ok
 R$*                    $: $(dequote "" $&{client_name} $)
 R$=w                   $@ OK
 R$* $=R                $@ OK
 R$@                    $@ OK

 # anything else is bogus
 R$*                    $#error $: "550 Relaying Denied"

 --- Contents of the file /etc/sendmail.relaylist
 mydomain.nl
 mx-ed-domain.nl
 another-mx-ed-domain.nl
 trusted-site.nl

A.2 Extended solution
=====================

A more elaborate configuration doing some extra checks is presented
below (courtesy of Piet Beertema (CWI)). This version also handles
local submission by clients using the -bs flag (pine and MH for
example).

 --- extended anti-relay configuration (m4 format)

 LOCAL_CONFIG
 FR-o /etc/sendmail.mxdomains
 LOCAL_RULESETS
 # TAB stop should be -><- here and   -><- here
 Scheck_rcpt
 # anything terminating locally is ok
 R<$->                  $@OK            unqualified address == local
 R<$+@$=m>              $@OK
 R<$+@$+.$=m>           $@OK
 R<$+@$=R>              $@OK            accepted relay-to (MX) hosts
 # anything originating locally is ok
 R$*                    $:$(dequote "" $&{client_name} $)<$&{client_addr}>
 R<0>                   $@OK            local posting with -bs flag
 R$+<$->                $:$1<$[[$2]$]>  remote IP address -> hostname
 R$+.$=m<$+.$=m>        $@OK            must both be in our domain
 R$@                    $@OK
 # anything else is relayed and thus not permitted
 R$*                    $#error$:550 Relaying denied

 --- Contents of the file sendmail.mxdomains
 mx-domain.nl
 another-mx-ed-domain.nl

===============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
  http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

   Email:     cert-nl@surfnet.nl     ATTENDED REGULARLY ALL DAYS
   Phone:     +31 302 305 305        BUSINESS HOURS ONLY
   Fax:       +31 302 305 329        BUSINESS HOURS ONLY
   Snailmail: SURFnet bv
              Attn. CERT-NL
              P.O. Box 19035
              NL - 3501 DA  UTRECHT
              The Netherlands

NOODGEVALLEN:    06 22 92 35 64      ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64      ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IajSYjBqwfc9jEQJBHACgvFqgZXy8tD8B0gSksCsZkSDVat0An273
2vx1Vwlyg2u202f/gj1ZnBRn
=HmYv
-----END PGP SIGNATURE-----