SMTPRC - Port 25: The Open Source Community at Microsoft

SMTPRC by admin on June 28, 2006 01:30PM

Spam is a well-known problem for many on the Internet. If you have an email account anywhere, chances are you’ve gotten something you didn’t ask for; a “stock tip”, an adult entertainment solicitation, or possibly a plea from an altruistic member of the “[Random Nation] Royal Family” to assist in some friendly money-laundering.

As the anti-spam movement gets craftier, so do the spammers. Fortunately for the spammers and unfortunately for the internet, there are a wealth of open-relay mail servers should have never been put online. While most common and current-version SMTP software is secure by default, there are plenty of people who still run outdated software, never bothered to upgrade, or configure properly in its present state.

If you are tasked with administering and monitoring a large portion of IP space assigned to people with autonomous control of machines on an externally visible network, this problem can get to be a thorn in your side very quickly - just ask any ISP that allows their customers to run servers.

If you’re not allotted much (or anything) of a software budget to purchase fancy enterprise tools to hunt down open relays on your network, there are some free and lightweight tools for Linux. One such utility is a small application written in C, called “smtprc” (smtp relay check): http://freshmeat.net/projects/smtprc . This simple application takes about 10 minutes to set up. First unzip it into your directory of choice. Next read the README file, and specifically check the Compilation/Installation section to make sure it ends up where you want it to. If not, edit the Makefile and put it where you want it to go. Do a “make” and “make install”, edit your scan configurations and go. It will output results to an html file (location specified in configuration). They will be color-coded by result. The collected data may then be used to notify administrators of vulnerable machines.

Note: Some older versions of NT Mail and Lotus Notes will turn out false positives. The messages smtprc attempts to relay are what I would call “passively rejected”. The SMTP server being tested will accept the inbound messages, but they are never actually delivered. When in doubt, it is best to test manually.

$ telnet mailserver.com 25 ß telnet to the host in question on port 25

Trying 10.197.173.28...

Connected to mailserver.com.

Escape character is '^]'.

220 mailserver.com ESMTP Sendmail 8.13.1/8.13.1; Wed, 14 Jun 2006 15:17:39 -0700

helo bleh ß most mta’s now require a “helo/ehlo”

250 mailserver.com Hello [157.55.209.144], pleased to meet you

mail from:<me@here.com> ß sender address

250 2.1.0 <me@here.com>... Sender ok

rcpt to:someone@wherever.com ß intended recipient address.

250 2.1.5 <someone@wherever.com>... Recipient ok

data ß indicates message is now being written

354 Enter mail, end with "." on a line by itself

Subject: open relay? ß can be anything

Hrrrm…… ß message.

. ß dot on a line by itself indicates end of message, server will queue for delivery

250 2.0.0 k5EMHdHl028091 Message accepted for delivery

quit

221 2.0.0 mailserver.com closing connection

Connection closed by foreign host.

Check your mailbox in about 15-30 minutes. If it doesn’t arrive, chances are this is not an open relay.

Email Digg It! Del.icio.us SlashDot It!

Comments RSS

fluke said:

Please tell me this was intended to be a joke instead of a serious attempt on discussing reducing spam in 2006.

SMTPrc was an interesting project back in 2002. If you need to monitor multiple IP addresses on the cheap then probably you first step should be contacting SORBS (see http://www.us.sorbs.net/). Unlike SMTPrc, SORBS also takes into account other additional methods of sending spam such as open proxies.

But even after checking with SORBS, the biggest source of spam in 2006 seems to be BotNets. The spammer takes advantage of systems that allow for remote execution of arbitary code. For example, MS06-15 at http://www.microsoft.com/technet/security/Bulletin/MS06-015.mspx

What makes MS06-15 interesting for someone that wants to issue spam, is that for Windows 98 and Windows ME the OS vendor has already stated they have no intention of addressing the known security issue. (Oddly enough, one of the arguments given against using FOSS is that the roadmap is unclear. But is it truely a clear roadmap that calls for security patches until June 30th while there is also a security bulletin on June 8th that a security patch will *NOT* be provided.)

Once a system is exploited to be a member of a BotNet, it will not be detected by SMTPrc since it is a technically not a SMTP relay.

Also, several of the subject examples given above ("stock tip", adult entertainment, etc) tend to also be "Joe Jobs" where the From field is fake. Sender-ID was created as a method to help reduce this type of problem.

The Apache Software Foundation (that handles updating the SpamAssassin project) has details as the licensing problems with Sender-ID available:
http://apache.org/foundation/docs/sender-id-position.html

The Debian group has also written a detailed statement as to problems with the Sender-ID license:
http://www.debian.org/News/2004/20040904

And CircleID which is seprate from both the FOSS groups and Anti-Microsoft groups has an article called "Sender ID: A Tale of Open Standards and Corporate Greed?" which goes into problems adopting Sender ID as an open standard:
http://www.circleid.com/posts/sender_id_a_tale_of_open_standards_and_corporate_greed_part_i/

But thank goodness we have Port 25 to suggest SMTPrc. The FOSS community has given specifics why they can interoperate with Sender-ID and those issues haven't been resolved but at least Port 25 can suggest a GPL solution to finding port 25 open relays. Three cheers for Port 25!

And a couple months ago the strangest thing went through my head... "Port 25... cool... the FOSS community has the ear of the largest player in the computer industry... we might be able to make a difference." But I guess to really make a difference, I should have just stuck to searching SourceForge all along. *sigh* Oh well.

Thanks for pointing the FOSS community to the FOSS community. I now know who to go to when I want to interoperate instead of continuing to get crippled rights to "open" standards.

posted at 01:44PM 06/29/2006
anandeep said:

Fluke – thank you very much for your response.

As you indicated you wanted in your comment, we at Port 25 ARE listening.

This article was obviously not addressed to people like yourself who are deeply knowledgeable about the issues. We have a number of people who are equally knowledgeable in the Windows side, but are dealing with interoperability issues without possessing the familiarity with FOSS that you do. This was intended as a quick and simple tip for them to secure their mail relays with an open source tool.

We could have pointed them to a comprehensive set of Windows tools, but I doubt the Port 25 audience would fully appreciate that. Now we find that pointing to open source isn’t satisfactory as well!

Your comment will be very valuable to people who click on this blog post, they can use the information you provided to do the investigation to the depth they need.

Is there anything specific that you would want Port 25 to address - a discussion of blacklists or of the sender-id?

posted at 09:35PM 06/29/2006
dogbigair said:

I cannot understand why you suggest such an outdated tool. All Linux distributions include SpamAssassin. There is no need to install an inferior product.

posted at 11:35AM 06/30/2006
hypovex said:

dog: their article was concerning an smtp relay checking utility, you're talking about a mail filtering program. Apples and oranges...

posted at 01:18PM 06/30/2006
fluke said:

anandeep:
Promoting SMTPrc to a novice administrator may end up with a luck rabbits foot effect if it finds nothing it might lead an administrator to believe they are in the clear.

Before choosing a tool, an administrator should decide what the network policies are. Do your customers/users need to be able to establish SMTP connections directly from their workstation to external SMTP servers. If not, configure the border firewall to block all outbound SMTP connections that don't originate from the established SMTP servers.

Tools that can be helpful for dealing with administating a large IP space are nessus and snort. One provides active security scanning for machines that might contain exploits. The other is an IDS to do passive scanning for signs of compromised machines.

I would be happy if you pointed us to a comprehensive set of Windows tools and descriptions on the functionality provided. It would be interesting to see where there are gaps in the FOSS offering that MS solutions could help fill. I would also be interested to know what tools MS would be willing to support running on Wine, Mono, mod_asp, etc. I don't expect all solutions to be FOSS. Nessus v3 isn't even FOSS and there are members of the community that accept that.

But pointing out tools like SMTPrc and g4u, while both interesting FOSS projects, are not very helpful in the grand scheme of things. Fighting spam with SMTPrc seems like fighting crime with a squirt gun. And g4u as a recovery tools seems to be throwing the baby out with the bath-water.

There is also already articles available online explaining why RBLs are of limited value in modern day spam fighting.

I want to discuss how MS current method of handling Sender-ID is in MS best interest in the long run. Should AT&T charged royalities for the transister? Did IBM come out ahead by controlling Microchannel? Could Sony have done something different to make Betamax a widely used standard? Could MS actually come out ahead by providing Sender-ID under less restrictive terms? Is DomainKeys the next EISA or VHS?

Also, where are we on the road to Cairo? Why can malware (including BotNet) authors hide their start-up from the UI by using Run/RunOnce registry keys? Is the desktop explorer monolithic or can I replace the start button handler object with one that displays the icons referred to in Run/RunOnce in the Startup folder (without also having to also re-write the tray handler, desktop icons, background displayer, etc. objects).

When someone comes to me with a machine infected with Blackworm and I have a solution but requires BartPE style live CD to work, how can I purchase just the parts of the OS I need for my live CD so I can legally distribute it? (Cairo papers once referred to being able to purchase just the spell checker object from office, is that possible yet?)

What is stopping the ClamWin anti-virus group from providing a real-time on-access scanner for Windows? Does the Windows DDK/IFS license need to have terms/clauses that most FOSS developers would never agree too? And why is there no FOSS equivalent to *nix's lsof command or SysInternals FileMon/TCPView. Is it because the FOSS community is not interested in writting such tools for Windows or are they locked out from using the example code needed?

----------

dogbigair: I just want to point out that smtprc and spamassassin are geared toward two very different functions. One is geared towards fighting outbound spam and the other is geared towards rating inbound spam. However, in addition to including spamassassin, newer distributions also tend to bind the SMTP listener to localhost which also addresses what smtprc is looking for. But since not everyone keeps up with the latest version or configures their software correctly, smtprc does have some limited usefulness.

posted at 01:58PM 06/30/2006