It looks to me that the Spammer’s may be using Trojan mail servers in order to propagate a large amount of the SPAM they are sending.



The following is a sample “Received: from” in the header of a SPAM msg that I will use to explain why I believe this:



Received: from dhcp065-031-063-150.woh.rr.com ([65.31.63.150] helo=nwn.de)

by mx10.mydomain with smtp (Exim 3.35 #7)



I have changed my ISP’s mail server domain name to mydomain in the above example.



My mail server performed a Reverse DNS lookup on the IP address of the incoming mail and inserted the result in the beginning of the line “from dhcp065-031-063-150.woh.rr.com”.



If the RDNS had failed, the mail would have still been accepted (my ISP does not refuse RDNS failures), but the line would have looked like this:



Received: from [65.31.63.150] (helo=nwn.de)

by mx10.mydomain with smtp (Exim 3.35 #7)



The first thing I want to say about this is that the only control that the Spammer has on this “Received: from line” is whether the server he is using to send the SPAM can be resolved using RDNS. This line is generated by your ISP’s Mail server, not by the Spammer.



The second thing that I will say is that if the Spammer did have full control of whether or not his server would be resolved, he would ensure that it would not be and all the headers from that spammer would look like the second example.



Finally, in the first example (RDNS resolved) it is pretty obvious that the computer that was resolved is a High-speed customer of RoadRunner. (in this example).



More than likely, the owner of that computer does not even know that it is being used for propagating SPAM. I have a very strong feeling that somebody’s home computer has been infected with one of the Spammer’s Trojan Mail servers, and that the Spammer is using that Trojan in order to send large amounts of SPAM while hiding his true identity.



Any legitimate mail from that user would have more than likely gone through their ISP’s SMTP server and would come to your ISP’s MX server via the foreign ISP’s MX server.



The Spammer probably has tens of thousands of these Trojan servers (if not more) running around the world and are using them to send their SPAM through them on a random basis. If this is the case, we can probably thank Microsoft for having done such a sloppy job with security in their operating systems, but that is a different topic


With that said, is there a way to combat this method?



YES!!!!!



That is…provided your ISP does a Reverse DNS lookup on the IP’s of any mail coming in from the outside.



The filter that follows can be used to trap any msg that was received by your ISP in which the resolved RDNS name has a combination of at least six numbers (\d) or dashes (-) prior to the first dot (.) in the resolved name. Generally, a legitimate mail server will never have that many numbers and dashes prior to the first dot (.) in the resolved name.

On the other hand, most dialup or high speed accounts (will have some numeric code that represents the assigned IP or the assigned user number as the first block of the resolved name within the ISP’s domain. They will usually carry many numbers and dashes prior to the first dot.





^Received: from ([\w-]*?([-\d][^.]*?){6}).*?by mx\d\d\.mydomain





You can adjust the sensitivity of the filter by changing the value of the iterator (in bold). I would recommend not setting it any lower than 5.



You will want to alter the last part (in italics) to substitute your own ISP’s mailserver name.



You may want to look into the headers of several e-mails you have received to find name of your ISP’s mailserver. Generally, reading from the top “Received line” in the headers, it is the lowest line that contains your domain name after the “by” and is NOT an “smtp”

Server. (The smpt server can be seen if you send an email from yourself to yourself).



I figure that the Spammer’s must have quite a large investment into these Trojan servers and it is not going to be easy for them to change what they are doing. At least, if nothing else, it will be very expensive for them to counter this filter strategy. I don’t mind giving away a strategy if it means that it will cost the Spammer a very large amount of money to counter

This is pretty cool. I do have some messages on the server that trigger this filter. In trying to expand upon it, though, I came across a MWP bug. I added \s and \( in the brackets next to the \w so I could hit on this:

Received: from compuserve.com (hsdbsk142-165-157-46.sasknet.sk.ca [142.165.157.46])

MWP hangs and maxes out the CPU. I can "End Now" and restart it (without the \s) without a problem.

Replacing [\w-] with (\s|\w|-) also causes the problem. Curiously, (\s\w|-) doesn't cause this.

Thanks. That looks like it would work, if it didn't cause MWP to max out the CPU.

Timeghost,


I have run into that problem before.

Try renaming your "filters.txt" file to "filter1.txt".

restart MWP to create the new "filters.txt" file and then close MWP.

Then copy your filters, one at a time from the old file to the new one. As you copy each file individually, save the file then restart MWP.

There may be a flaw in your filters.txt file (anywhere in the file) that is causing what you are seeing.

It may or may not work for you, but doing this has got me back up and running several times when I have seen what you are describing.

Are you suggesting that the problem might not be with the changes I'm making? Because to me it seems obvious if my filters work well, and then I add a \s to a rule and click OK, and then MWP maxes out the CPU, that the problem is with the addition of that \s.

And since I'm making the change in the GUI, not the text file itself, I can close and then re-open MWP and have it work fine without the \s.

And now, MWP maxes the CPU when I stick a \( somewhere infront of the rule as I try your suggestion and other variations of it.

So I can try renaming the filters file, but I suspect that if MWP had only this one rule in it, and I add \s or \( to it as before, it would hang.

Can you try putting a \s right before the \w on your copy and see what happens? I recommend using the GUI to do this, so you won't save changes to MWP if it should crash.

Timeghost,

I am only suggesting that because I have run across substantially the same problem before. During editing of filters, and before saving anything MWP has at times taken next to forever to process.

It would seem to freeze while downloading messages, but eventually would work its way through.

I used the method posted above to find the filter that was causing the problem, and it was not necessarily the filter that I was editing.


I have altered my filter and place the \s in front as you have suggested. I will have to wait till I have some incoming messages to process, but that should not take too long.

Timeghost,

I checked out the \s and it did not have any effect.


I did notice that the filter could be sped up by doing something else though.

In the last example that I gave you:

^Received: from ([^(]*?([\w-]*?([-\d][^.]*?){6}).*?by mx\d\d\.mydomain

make the following change (in bold)

^Received: from ([^(]*?([\w-]*?([-\d][^.]*?){6})[^:;]*?by mx\d\d\.mydomain

I have a pretty fast machine so the slowdown that was caused by using the " .*?by" was not as noticible till I had a large number of msgs in my inbox.

This change seems to speed things up by about a factor of 4 or 5, so it might help.

Just out of curiousity...how fast is your machine? I am running a 1.8Ghz P4 with 1GB of RAM running on Xp.

Knowing the speed would be helpful, as it is something that needs to be factored in while analysing the problem.

Thanks for experimenting. The modification seems okay.

Yesterday when I was adding the \s, I had the filter configured to take precedence over the friends list. I think that had a lot to do with my problem.

Here's the rule I finally ended up:

^Received: from .*?\((\w|-)*?([-\d][^.]*?){6}[^:;]*?by mx\d+\.mydomain\.tld

And here's a sample line that it matches:

Received: from 68.193.163.137 (ool-44c1a389.dyn.optonline.net [68.193.163.137]) by mx3.mydomain.com

Timeghost,

I have an earlier form of the Regexp that might run a little faster. It works a little dirfferently from the one I posted to begin with.

^Received: from [^[]*?((cpe|dhcp|dsl|host|ool|pcp|ppp|dialup|user)[.\d-]+|[\d-]{5,}?).*[[].*by mx\d\d\.mydomain


You will have to modify it to fit your IP's "Received:" line structure, but it is faster.

The two try to trap it in different ways, but the results are similar (though not exact).


Thanks for your comments on this....they resulted in improvements in the expression. If anyone else out there knows anything that would help speed these up, or improve the trap rate, please feel free to chime-in.

I made another change to the first filter and have improved its speed:

^Received: from [\w-]*?(\w*?[-\d]){6}[^:;]*?by mx\d+\.mydomain

I have 26 e-mails in my inbox and this is taking less than a second to run through them, so it should be OK as far as speed.

Thanks again for your suggestions Timeghost.

Speaking of 'Trojan' Main Servers.....

Here is a link to a site in India that has developed and sells a bulk e-mailer that they tout on their website as follows:

Their website is:

http://www.essencomp.com/frmproducts.asp?bulkmailer&feature


After reading about their wonderful software, you may decide that you would like to forward to them examples of what their software is used for.

Here are some of their e-mail contact addresses, if you would like to advise them of what you think of their product:

helpdesk@essencomp.com

sales@essencomp.com

billing@essencomp.com

support@essencomp.com

webmaster@essencomp.com


Perhaps MWP may want to add a feature in their next release that allows the user to autoforward any SPAM they receive that was sent in such a manner (bypassing the sender's SMTP server) to one of the addresses above. This might be much better and more effective than a mere bounce to a fake e-mail address.

I think I'll pass on that the user agreements of my ISPs could get my accounts closed for harrassment.

With that quote in hand I'd bet you would be safe until they actually asked you to stop.