(Note: Are you inclined to send mass email messages wishing to reach large audience? Don't. It is called spamming. VSNL takes a very dim view of such mass mailings and you are likely to get your account frozen. Still worse... if this continues you won't be able to send mail to more than half the Internet hosts in the world. As they will block messages orginating from VSNL. If you know someone who is wanting to do this discourage them. If you receive such unsolicited messages frequently, report to VSNL.-- Dr. Raj Mehta)
The basic function of an SMTP server
is to relay mail - as the RFCs specified in the good old days when
the Internet was a small, cozy community restricted to a few
universities and research laboratories. In fact, relaying was a
necessity, given the uncertain nature of email services in those
days - just to provide an alternative route for mail.
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
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
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
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.
National Informatics Centre, Karnataka
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).
VSNL - mailbg.vsnl.net.in ; giascla.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.
Tata Institute of Fundamental Research -
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.
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
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
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
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
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
Sun Admins may see
updates to sendmail 8.9.x.
From the QMail FAQ
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
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
(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: 220.127.116.11, 18.104.22.168: setenv =
Here 22.214.171.124 and 126.96.36.199 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 -
to allow clients with IP addresses 188.8.131.52 and
127.*. Run -
tcpmakectl /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp <
Finally, insert -
before /var/qmail/bin/qmail-smtpd in your tcpserver
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
Microsoft have discovered a new vulnerability not
yet being exploited by spammers. Details in q237927. There is a
fully supported patch available - update now! -
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
MS IIS SMTP Service:
See Knowledge Base
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.
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:
- (NOT "SMTPMTA_OCH_..")
If SMTPMTA_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 is
used, the host will still relay. Check your
For Notes 5.x:
The configuration document in the Domino Directory
has a section for SMTP Inbound Controls. Enter a * in both of the
"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.
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 /
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
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..."
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"
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
The MAPS TSI page - http://maps.vix.com/tsi/ar-fix.html
Suresh Ramasubramanian | firstname.lastname@example.org
Member, CAUCE India
Phone: +(91-40)3736553/3745398 | eFax:
Stop Spam | Join CAUCE | http://www.cauce.org/
Read some clarifications by Bruce Gingery
Coded by vikrant