Close your Open Relays Spam is cheap only to the spammer. He sends thousands of copies of his junk mail, exploiting a security hole in insecure mail servers, which allows anybody to send email through them, not just authorised users (from domains within their own IP space, or other trusted users, as specified). A server which has been used to relay spam can just crash under the heavy increase in mail load. The cleanup costs to recover from such an incident are huge, including * Cost of processing and deleting the spam * Bandwidth clogging, and resultant server downtime * Sysadmin manhours lost * Bandwidth charges * Damage to Professional Reputation and loss of Goodwill * The risk of landing in a global anti spam filter like * MAPS DUL/RBL - http://www.maps.vix.com * ORBS - http://www.orbs.org * RRSS - http://www.radparker.com This can lead to several servers on the Internet blocking all packets from your server. To get out of such a list, you have to take prompt action to close the open relay (or terminate the account of a spammer you are hosting / providing dialup access to). and last but not least * Apart from the fact that you're helping spammers... you may be legally liable for material sent through it. From http://www.idg.co.nz/wwwfeat/TechLaw/tl170599.htm "... A second legal issue is whether the owner of an open-relay server who allows relaying of spam or defamatory material is liable to others who are harmed or defamed. Criminal liability is unlikely, because most crimes require intention, not just negligence. A civil claim would require that any resulting damage was reasonably foreseeable by the owner of the open relay server. While each case will be fact specific, what can be said is that if warnings have been given then the courts may find that the damage was foreseeable. ..." Most servers in India are Corporate mailservers, and a large percentage of them are insecure open relays, ready and waiting to be exploited by spammers. To see if your server is an open relay, visit http://maps.vix.com/tsi (MAPS Transport Security Initiative) http://combat.uxn.com/ and run a series of tests on your server. This self test will point out several security holes in your server. For the benefit of the sysadmins reading this article, as you all know, the best solution is to keep your intranet behind a Linux (or other Unix) firewall. Here are ways to shut off relays on the most common MTAs around. Microsoft Exchange Server - This is the groupware of choice for corporates around the world. Unfortunately, older versions through 5.0 are vulnerable to unauthorized relay if they permit any local SMTP users. Servers that only act as a gateway between internal non-SMTP mail and the Internet don't have relay problems. Starting with version 5.5, provisions have been made to prevent unauthorized relay. Microsoft has released several patches for this. The solution is to upgrade your version of Exchange to version 5.5 sp 2. Version 5.5 can also be locked down without upgrading although 5.5 without service packs requires some registry hacks. For a GUI, download the latest service pack from ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/ For more details -- see Microsoft Product Reference - http://www.microsoft.com/products/prodref/599_ov.htm Chris Schroeder's Page - http://www.nvt.net/antispam.html Also check out the relevant KB articles - http://support.microsoft.com/support/kb/articles/q199/6/56.asp http://support.microsoft.com/support/kb/articles/q196/6/26.asp http://support.microsoft.com/support/kb/articles/q193/9/22.asp http://support.microsoft.com/support/kb/articles/q206/9/68.asp Lotus Notes - Notes, like older versions of Sendmail, is vulnerable to relay if a RCPT TO:<"user@host"> command is issued. The solution is to update your mailserver to version 4.6.2 or later In NOTES.INI, set: SMTPMTA_REJECT_RELAYS=1 SMTP_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 --- (not "SMTPMTA_OCH_..") SMTPMTA_RELAY_FORWARDS=1 [If SMTPMTA_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 is used, the host will still relay. This is the critical setting. Several other Lotus MTA controls are SMTPMTA_*, so be careful, this is quite easy to overlook.] For Lotus Notes 5.x: The configuration document in the Domino Directory has a section for SMTP Inbound Controls. Enter a * in both of the following fields: [1] "Deny messages from external internet domains to be sent to the following internet domains:" [2] "Deny messages from the following external internet hosts to be sent to external internet domains:" Netscape Messaging Server - Extensive anti-spam capability has been added with version 3.5. See the note published by Netscape at http://help.netscape.com/kb/server/980217-31.html on how to write a filter script to block unauthorized relay. More information can be found from http://home.netscape.com/comprod/server_central/product/mail/ The Netscape published note has holes you can fly a formation squadron of Boeing 747s through.(*) Use http://www.tsc.com/~bobp/nms-no-relay.html (*) 1 : Doesn't stop RCPT TO: 2 : If a spammer sets one local RCPT TO, all subsequent relay checking is disabled, no matter how many non-local RCPT TOs are set. Sendmail - The classic Unix MTA, Sendmail has been around for several years. Upgrade your MTA to version 8.9.3 immediately, especially if you are running version 8.6 or older. Sendmail builds can be downloaded from http://www.sendmail.org and set sendmail.cR as per instructions. This is quite clearly documented on the site, and indeed, making a newer version of sendmail an open relay is a very tough job. See http://www.sendmail.org/antispam.html and http://www.sendmail.org/~ca/email/relayingdenied.html for more details. For Sendmail 8 users, there are several pages showing how to use rulesets to block relay. There are a bunch more pages that show how to use the special sendmail rulesets to fight mail abuse. Maybe too many. :-) Here is a pile of them in no particular order. http://www.sendmail.org/antispam.html http://hexadecimal.uoregon.edu/antirelay/ http://www.oit.duke.edu/sa/antispam/acpub.html http://www.connect.hawaii.com/hc/webmasters/spam/norelay.html http://patriot.net/~scoile/isp-redhat/sendmail/antispam http://www.glenns.org/sendmail.antispam.html http://inorganic5.fdt.net/~jlewis/spam.html Qmail qmail prohibits relay by default, since version 0.91. The qmail-smtpd daemon will consult the rcpthosts control file to determine valid destination addresses, and reject anything else. The issue here is not how to disable third-party relay, but rather how to permit relay access by authorized hosts. This is answered in the qmail FAQ at [ http://www.qmail.org/qmail-manual-html/misc/FAQ.html#5.4. ] This is a method that allows you to grant relay access to certain hosts or networks. Also try Open SMTP by Russell Nelson [ http://www.qmail.org/open-smtp.tar.gz ], which grants relay access to users with valid POP3 accounts, regardless of the network address they come in on. ListServ LSMTP This is a popular List Server. To disable relaying in v1.1a (and later) go to Relay Control, Check the "enable" box and enter in the IP#/Netmask for the machines you wish to allow. Some versions may have problems with matching; LSOFT says: "the newer builds clear the bits of the IP address that are zeroed in the mask". Pegasus Mercury - This is a popular freeware MTA for Novell NetWare (and also Win NT) from the makers of Pegasus Mail (an extremely popular, freeware mail client). Users in India include IIM Ahmedabad, XIM Bhubaneshwar, MICA Ahmedabad, The Hindu Chennai, ... Provisions to prevent unauthorized relay have been added as of version 1.40 (for NetWare) and version 2.11 (Win32). Upgrade your version of Mercury to the latest version from http://www.pmail.com/dl For further details on Mercury's anti relay capablities, see http://www.pegasus.usa.com/announce/flash1.asp (Win32) and http://www.pegasus.usa.com/announce/flash2.asp (NetWare) To disable relaying, the following text should be added to the [MercuryS] section of "mercury.ini": [MercuryS] Relay : 0 Strict_Relay : 1 Allow : 2.3.4.5 # The offsite backup (MX server) Allow : 192.168.XXX.0 # Local network Allow : 192.168.YYY.5 # Another machine you allow to relay The "allow/refuse" entries under [MercuryS] must end with the line: Refuse: 0.0.0.0 --- Most other MTAs allow you to shut off relaying, and it is best to do so, and fast. See the operating manual / online resources or contact their tech support for help. Finally, if your MTA is too old (or if it is totally impossible to close unauthorized relays) there are some options [1] The obvious - Junk your old MTA and upgrade to the latest version (or another MTA which does not allow third party relay) [2] If there is a legacy issue and it is not feasible to upgrade / junk your MTA, hide it behind a firewall instead of leaving it directly connected to the Net - waiting to be abused. For further information, see http://spam.abuse.net/tools/mailblock.html and http://spam.abuse.net/tools/mailblock.html Suresh Ramasubramanian | suresh@kcircle.com CAUCE India | http://www.cauce.org CAUCE - The Coalition Against Unsolicited EMail - is an international anti spam organization. We have recently started a chapter in India. Visit http://www.cauce.org and sign up to join the fight against spam. From: Alan Brown Subject: cc:mail trivial DoS attack - self mailbombing. X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM This seems to work on most cc:mail installations Send mail to postmaster@[x.x.x.x] where x.x.x.x is the IP address of the server. In most cases, the machine will mailbomb itself into the ground with undeliverable mail messages. For bonus points, use a bogus, undeliverable sender envelope and watch it crash even faster. In some cases, postmaster@rDNS.name will have the same effect, depending how badly setup the server is. Script kiddies may like to have fun by using a sender envelope belonging to someone else. One case I've seen resulted in the machine sending over 5800 "postmaster: No such user" errors for one message sent to it. AB Last time I got an ORBS notification, one of the places it was mailed to was postmaster@[x.x.x.x]. So hypothetically a cc:Mail system is nominated to ORBS. The tester goes out, finds that it's open, notifies the various forms of postmaster that ORBS notifies and wham, the server crashes. Due to a bug, yes, but it's a Denial of Service caused by a relay test nonetheless.