-----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 iQCVAwUBNCE250U5nQkWIq1FAQHqbAP7BO8wbvTPpaGdDknxQBOEG09FxCyJAO1r BoCdsKUc/nyX3Y4XGKQtdEKlh69N45XvQer8N2nFD+QryuYOWzjDhs95TSB9dPbR 8fLloi7u+sUJWRzc+fejkx/D5NXOu4Bed8h6BYG4767VLLUQk/sdyT+uYKiu0iJw HVWmFvc3z3Q= =r+lk -----END PGP SIGNATURE-----