-----BEGIN PGP SIGNED MESSAGE-----

===========================================================================
              AUSCERT External Security Bulletin Redistribution

                   ESB-97.118 -- CERT-NL Security Advisory
		      Avoiding the relay of e-mail spam
                              15 September 1997

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

The CERT-NL team has released the following advisory concerning sites
being used as a relay of unsolicited e-mail (spam).  The costs of being used
as a spam mail relay can be considerable in terms of money, time, and wasted
system and network resources.  AUSCERT has received reports of Australian
sites being abused in this manner.

The following security bulletin is provided as a service to AUSCERT's
members.  As AUSCERT did not write this document, AUSCERT has had no
control over its content.  As such, the decision to use any or all of this
information is the responsibility of each user or organisation, and should
be done so in accordance with site policies and procedures.

Contact information for CERT-NL is included in the Security Bulletin below.
If you have any questions or need further information, please contact them
directly.

Previous advisories and external security bulletins can be retrieved from:

	http://www.auscert.org.au/information/advisories.html

If you believe that your system has been compromised, contact AUSCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 4477
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
	AUSCERT personnel answer during Queensland business hours
	which are GMT+10:00 (AEST).
	On call after hours for emergencies.


- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----

===============================================================================
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

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

B. Preventing Third Party Relaying with PP/MMTA
===============================================

PP and MMTA can be configured to prevent unwanted relaying. This is done by
splitting the smtp channel and the use of the authorization facilities of
PP/MMTA. The main change is done in the pptailor file (or the smtp part of
pptailor for MMTA version 2.1 and higher). It also requires one extra table
and extra authorization rules in the auth.channel table and changes in the
routing tables (channel and domain). In some circumstances it also requires
extra authorization rules in the auth.user table (see NOTE 4 below).

NOTE 1: The presented examples are used on a MMTA 2.0 installation. Please
        don't copy these examples as is, but use them to adapt your own
        configuration. Many variations are possible, these examples are
        meant as a starting point only. Note also that the new MMTA 2.2
        uses a different authorization mechanism. These examples are NOT
        tested with the new 2.2 mechanism.

NOTE 2: This setup will prevent unwanted relaying. It will however generate
        many bounces to the local postmaster address. Be prepared for this,
        possibly by constructing a mailfilter to filter out these bounces.

NOTE 3: Domains for which your mailserver acts as MX-host should be routed
        to the local-smtp channel.

NOTE 4: Be aware that local aliases/synonyms pointing to external addresses
        will, in general, be routed to the other-smtp channel. To prevent
        blocking of these messages one should add these external addresses
        to the auth.user table with the key other-smtp=both. The same goes
        for messages originating from local users delivering mail to your
        server from external locations (e.g. when they attend a conference).

It is recommended to test the configuration for a while with the 'test'
clause in the auth.channel table (i.e. other-smtp->other-smtp:block,test).
This test-clause prevents blocking but logs possible violations of the
authorization rules.

 -- Changes in the pptailor file

 ####
 # this table is needed to perform the split between local traffic and
 # external traffic
 tbl     local-domains  file="local-domains",
                        show="Local SMTP Domains",
                        flags=linear
 #
 # The smtp channel is split
 # local-smtp will handle incoming calls from hosts/domains in the
 # local-domains table.
 # NOTE: Order is important, the catch-all channel (other-smtp) must
 #       be the last channel with key=smtp and CANNOT have the name smtp !
 #
 chan    local-smtp      key="smtp",mtatable=local-domains,
                prog="smtp -h",show="with Local-SMTP (PP)",type=both,
                adr=822,hdrout=822-us,check=sloppy,
                ininfo="care8bit=false,strip8bit=true",
                bptout="ia5,mime.*",
                content-out=822,drchan=dr2rfc,
                lookup="dnstbl queue table"
                appcont="1.3.6.1.4.1.453.5.2"
 chan    other-smtp      key="smtp",
                prog="smtp -h",show="with SMTP (PP)",type=both,
                adr=822,hdrout=822-us,check=sloppy,
                ininfo="care8bit=false,strip8bit=true",
                bptout="ia5,mime.*",
                content-out=822,drchan=dr2rfc,
                lookup="dnstbl queue table"
                appcont="1.3.6.1.4.1.453.5.2"

 -- Format of the local-domains table (to be put in the tables directory)

 #######
 #
 # Table to list 'local' MTA's, ie MTA's that are mapped to the local-smtp
 # channel on *incoming* connections. Format is conform the domain table.
 # This table is checked using the Fully Qualified Domain Name (FQDN)
 # of the connecting MTA (as resolved by DNS). If you have a host with
 # mydomain.nl as FQDN (i.e. the hostname equals the domainname) you
 # should add an entry without the wildcard, i.e. 'mydomain.nl:mta'
 #
 *.mydomain.nl:mta
 *.my-second-domain.nl:mta

 -- Changes in the auth.channel table

 # Relay blocking
 # Use block,test to check the rules first
 # Can be overruled by entries in auth.user
 #
 other-smtp->other-smtp: block

 -- Changes in the auth.user table (optional, see NOTE 4)

 ## Accept all messages from the following local user(s) when they
 #  deliver mail from external locations
 our.traveling.user@mydomain.nl:other-smtp=both
 ## Accept messages destined for aliases pointing to external addresses
 external-alias@otherdomain.nl:other-smtp=both

 -- Changes in the channel table

 # Deliver mail to other local mailhosts via local-smtp
 local-mailhost.mydomain.nl:local-mailhost.mydomain.nl(local-smtp)
 # DNS delivery for local and MX-ed domains
 loc-nameserver:(local-smtp)
 # DNS delivery for other domains
 nameserver:(other-smtp)

 -- Changes in the domain table

 ## Static route for local SMTP traffic (mapped to local-smtp in
 #  the channel table)
 local-domain.mydomain.nl:mta=local-mailhost.mydomain.nl
 ## DNS routing for local domains
 *.mydomain.nl:mta=loc-nameserver min=0
 *.my-second-domain.nl:mta=loc-nameserver min=0
 ## DNS routing for domains for which you provide MX-service
 *.mxdomain.nl:mta=loc-nameserver min=0
 ## DNS routing for all other domains (mapped to other-smtp in the
 #  channel table)
 *:mta=nameserver

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

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850

iQCVAgUBNBk4oEU5nQkWIq1FAQEjOgP/RceF5F2Z+JxJNBXWIK+9x4jmRbl2LbYM
hk1w6/YALjicbSG3V2spqITQDabAVLhCQcWE5lQL4DEajo+hpgvgLgp1vDOLfUPl
GXEnIcw1KoDS6AE7n1g1aMWeYlFi4Jv3uQy3rBFZ1xfmXbofoSYVnObVIgfLa9zP
E40ZNnZURWs=
=ryMF
- -----END PGP SIGNATURE-----

- --------------------------END INCLUDED TEXT--------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBNB5y4Ch9+71yA2DNAQEcKQP/U5+s3CYBkOuQQQb9AKOkhgPmkf1FV0Ek
lwXVpgPYcE2MdysbkYsQxd7lvZqRUmMbsh9+MfbC4ZxN0zrnqEzjjkzF03M29bdr
/0zY+JLSr7jq8wBa5Khl+zAwo8yo1zJ7tGWKVsKOcDQtYd3Qg4skHMDt+m/uIA9P
qZITylEfOhs=
=kTHE
-----END PGP SIGNATURE-----