However, as the Internet became more and more popular, it attracted the attention of spammers - the same people who used to deluge your postal mailbox with junk mail advertising everything from Get Rich Quick schemes to secret virility pills guaranteed to work twice as well as Viagra, at half the cost.

These people gleefully switched over to sending their trash by email - citing vague reasons like -

• "We are saving a tree by sending email instead of using paper"
• "It costs nothing to download an email - just hit delete if you don't want it"
• "It is much cheaper for me to send email than pay for stamps and envelopes"

When the victims of their spam started tracing them, some spammers had their accounts disconnected and were successfully sued by their ISPs. Spammers, therefore, started to hide their tracks, using forged email headers and abusing third party smtp servers instead of using their ISP's SMTP servers.

Such "open" relays, which allow anyone (not just authorised users) to send mails through them - are now routinely abused by spammers, who pump several megabytes of spam through it (millions of mails, sometimes) - leading to server crashes or, at the least, slowing your mailserver to a crawl, with legitimate email bouncing because all available resources on the system have been hijacked by the spammer.

Earlier, spammers were systematically scanning for and abusing Malaysian, Indonesian, Japanese and Korean open relays - most of which have ended up in the MAPS RBL [*], cut off from over 40% of the Internet.

Additionally, all networks in the .my (Malaysia) domain were barred for several months from accessing all the IRC networks (Undernet, EFNet etc). Some of the larger Malaysian ISPs had to give written undertakings that they would close open relays and crack down on spammers among their users.

[*] If your server has the misfortune of landing in the RBL, several hosts will bounce packets from these boxes at the router level - and your box will crash with all the bounces if the spammer has not crashed it already. To see how you can get into (or leave) the RBL - visit http://maps.vix.com/rbl/candidacy.html

Spammers have now discovered India it appears. The anti spam community around the world has noticed a steady increase in the amount of spam originating from Indian open relay SMTP servers.

The problem is compounded by the fact that several of these servers are running old Mail Transport Agents (mostly outdated versions of Sendmail) which are anonymous open relays. That is, they allow spammers to relay mails without their IP address being logged in an rDNS lookup, as is the case with most modern MTAs.

Worse, such old MTAs have gaping security holes. Because sendmail runs as UID 0 (the same as root) a spammer can easily gain root access on a unix system running such an outdated MTA. This (or something quite similar) happened just after the Pokhran blasts, when BARC's servers were hacked by MilW0rm.

Here is a partial list of the Indian servers which have been abused in the past few days. All these are running outdated sendmail versions.

1. National Informatics Centre, Karnataka (kar.kar.nic.in) -
   
   They were running an insecure, outdated version of sendmail on a Sun Unix platform (SMI/SVR4), and were listed in the MAPS RBL list. After I mailed them with the facts, the systems adminstrator Mr.D.Krishna Rao took prompt action to upgrade to sendmail 8.9.1 and secure their server (which was, therefore, removed from the RBL list).

2. VSNL - mailbg.vsnl.net.in ; giascla.vsnl.net.in ; bom4.vsnl.net.in
   
   No response yet - even after several months. The giascla server is currently in the RBL, cut off from 40% of the Internet. The other two are also slated for inclusion soon. Two are running SMI/SVR4 and the other is running Sendmail 5.6 - which is even older.

3. Tata Institute of Fundamental Research - tifr.res.in
   
   Again an SMI/SVR4 box. Based on a phone number mentioned in the spam, the spammer has been traced down and the details mailed to the TIFR sysadmin.

The following may be of some use with regards to securing your server against spammers / hackers.

Sendmail:

The classic Unix MTA - it has been around for several years and is still extremely popular (and is free). Sendmail admins can see http://www.sendmail.org/tips/relaying.html which has quite a few useful bits of information.

Sendmail builds lower than 8.8 are fundamentally insecure, and full of security holes. Additionally all versions of sendmail prior to 8.8.9 are susceptable to a HELO buffer overflow attack - and most recently, several thousand sendmail 8.8 installations have been exploited by a spammer using RCPT TO:<"victim@target"> - with the "" in the envelope.

If you have one of these sendmail versions, disable or update it immediately and audit your machine's security. Sendmail Inc describe version 8.6 and earlier as "Not supported, not secure and should NOT be run on a network-connected computer."

If you are running Sendmail 8.8, see Claus Assmann's check_rcpt Sendmail 8.8 antirelay patches, which fix relay vulnerablities using "", %, ! and : vulnerabilties in 8.8.x sendmail.
Visit his page at http://www.sendmail.org/~ca/email/check.html for more details. More useful information is available at http://hexadecimal.uoregon.edu/antirelay/

Sendmail 8.8 is effectively unsupported and susceptible to a buffer overflow attack (caused when a HELO of over 1024 characters is sent). There are probably more relaying holes lurking in it. Sendmail 8.9.0 and 8.9.1 are susceptable to relaying attacks using the : pathing control character in the RCPT TO:<> header.

Update to 8.9.x or later, or consider the latest beta for sendmail (sendmail 8.10.0.Beta6) which supports Authenticated SMTP. It also (amongst other things) has built in support for multiple dns based blacklists (like the RBL).

When upgrading sendmail to secure versions:
Always generate a new sendmail.cf - continuing to use the sendmail.cf from a previous version which had a relaying vulnerability will usually result in that relaying vulnerability not being fixed. If you are uncomfortable with M4 scripting, WIDE in Japan have a .cf generator which may be useful. It can be downloaded from ftp://ftp.jpcert.or.jp/pub/security/tools/CF/

If you need sendmail on a machine so that processes can send out mail, but no inbound mail facilities are needed, all you need to do is change sendmail's startup settings by removing the "-bd" flag. It's the -bd flag (-bD if run in the foreground) which tells sendmail to listen on port 25 and if that is deleted, it will only deliver locally generated mail rather than acting as a full-blown mailserver. Please note: this will only secure a server for as long as the -bd flag is disabled, so should be regarded as a temporary measure. Eventually, someone is bound to accidentally re-enable the -bd flag. Wherever possible, please update to sendmail 8.9.3 or later.

Redhat linux users check out ftp://admin.netus.com/sendmail/ and download preconfigured, secure sendmail 8.9.3 rpms. Linuxconf users beware! - Linuxconf was found to be generating faulty (old) check_rcpt tables as recently as 20 July 1999. Make sure your version is newer than this before using it to generate sendmail.cf files.

Sun Admins may see
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
for updates to sendmail 8.9.x.

QMail:

From the QMail FAQ

http://www.qmail.org/qmail-manual-html/misc/FAQ.html#5.4.

5.4. How do I allow selected clients to use this host as a relay? I see that qmail-smtpd rejects messages to any host not listed in control/rcpthosts. I know I could entirely disable this feature by removing control/rcpthosts, but I want to be more selective.

Answer: Three steps. First, install tcp-wrappers, available separately, including hosts_options. Second, change your qmail-smtpd line in inetd.conf to -

smtp stream tcp nowait qmaild /usr/local/bin/tcpd
/var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd

(all on one line) and give inetd a HUP. Third, in tcpd's hosts.allow, make a line setting the environment variable RELAYCLIENT to the empty string for the selected clients:

tcp-env: 1.2.3.4, 1.2.3.5: setenv = RELAYCLIENT

Here 1.2.3.4 and 1.2.3.5 are the clients' IP addresses. qmail-smtpd ignores control/rcpthosts when RELAYCLIENT is set. (It also appends RELAYCLIENT to each envelope recipient address. See question 5.5 for an application.)

Alternative procedure, if you are using tcpserver: Install tcpcontrol (http://pobox.com/~djb/tcpcontrol.html). Create /etc/tcp.smtp containing -

1.2.3.6:allow,RELAYCLIENT=""
127.:allow,RELAYCLIENT=""

to allow clients with IP addresses 1.2.3.6 and 127.*. Run -

tcpmakectl /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp

Finally, insert -

tcpcontrol /etc/tcp.smtp.cdb

before /var/qmail/bin/qmail-smtpd in your tcpserver line

MS Exchange:

Update to MS Exchange 5.5 service pack 2 or later. Service pack 3 is available at http://www.microsoft.com/exchange/DeployAdmin/sp3.htm

Also check out the MS Knowledge base articles -
http://support.microsoft.com/support/kb/articles/q193/9/22.asp?FR=0
http://support.microsoft.com/support/kb/articles/q195/9/69.asp?FR=0
http://support.microsoft.com/support/kb/articles/q196/6/26.asp?FR=0

Microsoft have discovered a new vulnerability not yet being exploited by spammers. Details in q237927. There is a fully supported patch available - update now! -
ftp://ftp.microsoft.com/bussys/exchange/exchange-public/
fixes/Eng/Exchg5.5/PostSP2/imc-fix

MS Exchange 5.0 can only be secured against unauthorised relaying by disabling all internal POP3/SMTP access. That is, all internal clients must be running Microsoft exchange software and third party clients like Eudora cannot be used after this. This is an ad hoc fix, because eventually someone will probably re-enable POP3/SMTP. Please update to MS Exchange 5.5sp2 or later as soon as possible.

To quickly verify a machine: Any MS Exchange mailserver which shows a version number below 5.5.2448 on its SMTP port is unlikely to be fully secure. 5.5.2448 is only secure by explicit configuration as MS Exchange defaults to no relaying control

MS IIS SMTP Service:
See Knowledge Base article
http://www.microsoft.com/exchange/
DeployAdmin/sp3.htm

Lotus cc:Mail:

This is totally outdated, unsupported and full of security holes. If not properly setup, any mail sent to postmaster@[literal.IP.address] will cause the server to mailbomb itself into the ground with an infinite loop of bounce messages. Upgrade to Notes or use a firewall.

Lotus Notes

This can easily be secured and Lotus has recently released information on doing so: Update to Lotus Notes 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

WARNING:

If SMTPMTA_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 is used, the host will still relay. Check your spelling!

For 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:

"Deny messages from external internet domains to be sent to the following internet domains:"

"Deny messages from the following external internet hosts to be sent to external internet domains:"

Netscape Messaging Server:

Netscape Messaging Server: Netscape's documentation is poor and the antirelay examples they provide are easily defeated. Among other holes, a spammer may set as many non-local RCPT TO:<> lines as he likes, as long as he sets at least one local RCPT TO:<> as the first recipient. Bob Poortinga has put together several pages detailing how to properly configure NMS to prevent relaying at http://www.tsc.com/~bobp/nms-no-relay.html.

IMail:

This is a popular NT based MTA - used by several NT mailservers. Imail 5.x can be secured with little effort. The only portion of it that is rough is advising remote users that they will have to use SMTP authentication to send mail. This just means checking a single control in most POP3 clients (Outlook / Eudora / Pegasus etc).

They can set Relay For Addresses in SMTP Security and then only allow their local blocks or known, trusted blocks. If you have Admin access to port 8181 on the box you can set this there also, instead of hammering your sysadmean (if the mailserver is remotely hosted).

MDaemon:

Go to Setup | Relay Control and tick the "This Server Does Not Relay" Box. If the server doesn't host any "gateway" domains, this covers the majority of relay techniques.

At this point, however, anybody claiming to be a local user in the MAIL FROM can still relay. Go to the IP Shielding window and enter the IP blocks from which legitimate users can originate mail. If desired, tick the "Insure Sender's Address..." box.

Note that if the server hosts "gateway" domains, than ANY address at the gateway domain will be considered a valid local user regardless of the "Insure" box. You will also need to insert the valid IP blocks for the "gateway" domains or relaying will be enabled for anybody forging an address from a "gateway" domain.

The big drawback to the way MDAEMON operates is that although it will now pass all of the relay tests I have been able to run on it, it also won't allow somebody with a local address to send email into it, whether directly or through another server. You will get a 500-series "domain.com is not allowed access from this location" message.

For more information on securing other MTAs - visit the below pages (from where most of this information above has been taken).

The MAPS TSI page - http://maps.vix.com/tsi/ar-fix.html
ORBS http://www.orbs.org/otherresources.cgi

Suresh Ramasubramanian | suresh@india.cauce.org
Founder Member, CAUCE India
Phone: +(91-40)3736553/3745398 | eFax: +(1-603)590-5437
Stop Spam | Join CAUCE | http://www.cauce.org/