The basic function of an SMTP server is to HANDLE mail, not necessarily to relay it. Most SMTP severs on the net RECEIVE mail for local delivery, but _may_ relay it also for local clients. The problem, as he's pointed out, is when they relay for _anyone_.

In the UUCP days, indeed relaying _was_ a necessity. In parts of the former soviet union, UUCP is still a major form of E-Mail transport, and relaying is STILL needed... but it _can_ be controlled.

The MAPS RBL info is quite accurate. The "RBL" stands for "Router Block List" and may cut off the abused domain from ALL traffic to nearly 40% of the Internet, even HTTP. The reasoning is that if an ISP is unable to provide services because they're careless about allowing Spammers to abuse their E-Mail services, they'll either go out of business or correct the problem. In the meanwhile, they are ignored as if they did not exist. (Packets from their domain are discarded) Either way, the spam gets blocked. It's a harsh, but efficient theory that actually works.

Yes, some services (who have large pipes) will BOUNCE rejected mail instead of merely blocking packets. This means that the spam hits the abused system multiple times. Once when it is passed for relaying and again when it bounces. It is this abused system that really takes the "brunt" of the problem. It's not only valid, but proper for the systems refusing the mail to send that bounce message. Some don't because of the load on _their_ servers. But this makes the abuse by a spammer, even more of a "Denial of Service" attack on the abused system.

Even version 5.6.12 of Sendmail (perhaps the best of the 5.6.x versions) is wide open for relaying UNLESS strong measures have been done to lock it down. VSNL is indeed in danger, if added to the RBL. Packets routed through VSNL will be blocked from much of the net, and especially E-Mail packets (those destined for port 25 on a host).

New Guide is using: Sendmail 8.9.3 at the moment. But if VSNL's entire suite of netblocks are blocked, that is of no benefit. ALL of VSNL will be refused access to as much as nearly half of the Internet, and vice-versa - nearly as much as half of the internet will ALSO be denied access to _anything_ at VSNL.

I cannot confirm ALL details in the article, but it seems substantially correct, except for the very first sentence. :) I have no reason to doubt the validity of the information I cannot directly confirm.

I'm delighted that there is now an "india.cauce.org".

mailbg.vsnl.net.in is now refusing connections from my host, here, and even from newguide. It may be that a major backbone is refusing packets to/from that host, but unlikely, because newguide is also unable to connect to a mailserver on that host.

giascla.vsnl.net.in has upgraded to Sendmail 8.9.3
bom4.vsnl.net.in has upgraded to Sendmail 8.9.3

TO HELP YOUR UNDERSTANDING OF THIS ISSUE ....

Here's an example. >>> lines are TO the server, <<< lines are FROM it. Other lines are informational, except for the greeting line which is continued on a 2nd line.

% telnet mail.guide.vsnl.net.in 25
Trying 202.54.51.50...
Connected to mail.guide.vsnl.net.in.
Escape character is '^]'.
<<< 220 mail.guide.vsnl.net.in ESMTP Sendmail 8.9.3/8.9.3; \
Mon, 27 Mar 2000 13:34:51 +0530 (IST)
>>> HELO localhost <<< 250 mail.guide.vsnl.net.in Hello home [209.181.16.2], pleased to meet you
>>> MAIL FROM: bruce
<<< 553 bruce... Domain name required
>>> MAIL FROM: bruce@mail.guide.vsnl.net.in
<<< 250 bruce@mail.guide.vsnl.net.in... Sender ok
>>> RCPT TO: bgingery@gtcs.com
<<< 550 bgingery@gtcs.com... Relaying denied
>>> QUIT
<<< 221 mail.guide.vsnl.net.in closing connection
Connection closed by foreign host.

As you can see, pass-thru relaying, as he describes is denied. Now compare the SAME connection, but originating on the machine itself, via my remote login...

%telnet mail.guide.vsnl.net.in 25
Trying 202.54.51.50...
Connected to mail.guide.vsnl.net.in.
Escape character is '^]'.
<<< 220 mail.guide.vsnl.net.in ESMTP Sendmail 8.9.3/8.9.3; \
Mon, 27 Mar 2000 13:39:23 +0530 (IST)
>>> HELO localhost
<<< 250 mail.guide.vsnl.net.in Hello newguide [202.54.51.50], pleased to meet you
>>> MAIL FROM: bruce@mail.guide.vsnl.net.in
<<< 250 bruce@mail.guide.vsnl.net.in... Sender ok
>>> RCPT TO: bgingery@gtcs.com
<<< 250 bgingery@gtcs.com... Recipient ok
>>> DATA
<<< 354 Enter mail, end with "." on a line by itself
>>> From: bruce@newguide
>>> To: bgingery@gtcs.com
>>> Subject: example/test
>>>
>>> Test
>>> .
<<< 250 NAA23470 Message accepted for delivery
>>> QUIT
<<< 221 mail.guide.vsnl.net.in closing connection
Connection closed by foreign host.

As it should, it allows on-host processes to connect SMTP, and will send mail _anyplace_ for local users. The message that was hand-entered above was in my mailbox here almost before I could type QUIT. Here it is:

-> Received: from mail.guide.vsnl.net.in (newguide [202.54.51.50])
by serv.gtcs.com (8.8.8/8.8.8/serv.gtcs.com-2.01) with ESMTP id IAA04575
for bruce@mail.guide.vsnl.net.in; Mon, 27 Mar 2000 08:10:50 GMT
(envelope-from bruce@mail.guide.vsnl.net.in)
-> Received: from localhost (newguide [202.54.51.50])
by mail.guide.vsnl.net.in (8.9.3/8.9.3) with SMTP id NAA23470
for bgingery@gtcs.com; Mon, 27 Mar 2000 13:39:51 +0530 (IST)
-> Date: Mon, 27 Mar 2000 13:39:51 +0530 (IST)
-> Message-Id: <200003270809.NAA23470@mail.guide.vsnl.net.in>
-> From: bruce@newguide.vsnl.net.in
-> To: bgingery@gtcs.com
-> Subject: example/test
->
-> Test

Note that first, a Date: and Message-ID line were added by sendmail. They are required by RFC to be added by the first SMTP host that handles the message, if they are not already present. At times these are forged, however, especially in SPAM. Because it's set to do so, it also added ".vsnl.net.in" domain to the bare hostname that was used when I typed the message. I typed "bruce@newguide" but it converted that (incorrectly) to bruce@newguide.vsnl.net.in

It then added a Received: header That says where the connection was from, who was listed in the "RCPT TO:" protocol, and a timestamp. Note that it did NOT tell who the "MAIL FROM:" was claimed, however. This is because (I think, I'd have to doublecheck) that it was "From: " a valid local user. I _think_ it would add a Sender or Presumably From or some such header if that had not been valid.

Then my mailserver here added a comparable Received: header.

Here are the /var/log/maillog entries that match the above activities:

Mar 27 13:35:02 mail sendmail[23431]: NAA23431:
ruleset=check_mail, arg1=bruce, relay=home [209.181.16.2],
reject=553 bruce... Domain name required
Mar 27 13:35:02 mail sendmail[23431]: NAA23431:
from=bruce, size=0, class=0, pri=0, nrcpts=0,
proto=SMTP, relay=home [209.181.16.2]
Mar 27 13:35:23 mail sendmail[23438]: NAA23438:
ruleset=check_rcpt, arg1=bgingery@gtcs.com,
relay=home [209.181.16.2], reject=550 bgingery@gtcs.com... Relaying denied
Mar 27 13:35:30 mail sendmail[23438]: NAA23438:
from=bruce@mail.guide.vsnl.net.in, size=0, class=0, pri=0,
nrcpts=0, proto=SMTP, relay=home [209.181.16.2]
Mar 27 13:40:46 mail sendmail[23470]: NAA23470:
from=bruce@mail.guide.vsnl.net.in, size=71, class=0, pri=30071,
nrcpts=1, msgid=<200003270809.NAA23470@mail.guide.vsnl.net.in>,
proto=SMTP, relay=newguide [202.54.51.50]
Mar 27 13:40:52 mail sendmail[23482]: NAA23470:
to=bgingery@gtcs.com, ctladdr=bruce@mail.guide.vsnl.net.in
(1004/1004), delay=00:01:01, xdelay=00:00:06, mailer=esmtp,
relay=serv.gtcs.com. [209.181.16.1], stat=Sent (IAA04575
Message accepted for delivery)

Note that it looked up my userid (1004) and group (1004) in /etc/passwd before validating the message and passing it along. This makes it more difficult to send "forged" E-Mail, even from on-host.

Similarly, I have a log on 209.181.16.1 of the message that was actually sent (not refused for relaying)...

Mar 27 08:10:52 serv sendmail[4575]: IAA04575:
from=bruce@mail.guide.vsnl.net.in, size=368, class=0, pri=30368,

nrcpts=1, msgid=<200003270809.NAA23470@mail.guide.vsnl.net.in>, proto=ESMTP, relay=newguide [202.54.51.50]
Mar 27 08:10:53 serv sendmail[4577]: IAA04575: to=bruce, delay=00:00:03,
xdelay=00:00:01, mailer=local, stat=Sent

The reason that "newguide" is used as a name on my end is an /etc/hosts entry. It would normally give the full DNS name of the sending relay host (if there _is_ reverse DNS for it) and refuse mail for which it could get no name. You may recall that I was ADAMANT that there be reverse DNS for the new guide server. That's the biggest reason.

Bruce