SMTPRC

re: SMTPRC

Kendra Taylor — Sun, 11 Jan 2009 14:57:59 GMT

1sroitxx1olpqtub

good luck

re: SMTPRC

Orlando Sandoval — Sat, 10 Jan 2009 02:22:21 GMT

1sroitxx1olpqtub

good luck

re: SMTPRC

fluke — Fri, 30 Jun 2006 18:58:23 GMT

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.

re: SMTPRC

hypovex — Fri, 30 Jun 2006 18:18:02 GMT

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

re: SMTPRC

dogbigair — Fri, 30 Jun 2006 16:35:59 GMT

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

re: SMTPRC

anandeep — Fri, 30 Jun 2006 02:35:22 GMT

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?

re: SMTPRC

fluke — Thu, 29 Jun 2006 18:44:44 GMT

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.