Creating Rule for Postini Spam Filter

Hey all! I’m at my wit’s end with this issue and I’m certain it’s just something simple that I’m missing. I host my own e-mail server on my DSL connection and I also subscribe to the Google Postini spam filtering service. In order for the service to be most effective, I need to restrict incoming access to port 25 to only Postini’s IP addresses. this prevents spammers from bypassing my domain’s MX records and directly telnetting into my mail server to relay spam. My old router (D-Link DGL-4300) had an inbound filter option that I could use to accomplish this. That router died and the new one I use (WRT54GL with Tomato 1.19) doesn’t have that option. I installed Comodo Firewall and configured a rule for my server that I thought would accomplish the same thing. The rule is this:

Application Path: C:\Program Files\hMailServer\Bin\hMailServer.exe
Action/Protocol/Direction: Alllow/TCP/In
Source Address: IP Range (Set to the range Postini gave me)
Destination Address: Any
Source Port: Any
Destination Port: 25

I have another rule that allows outbound traffic on port 25 so that the server can send outgoing mail. If I try to telnet into my mail server on port 25 from the outside world, I get in and so do the spammers. I’ve tried playing around with some of the settings in the rule so no avail. How would I need to configure this rule in order to prevent all access on port 25 that doesn’t originate from the Postini IP range I need? Thanks all!

I have another rule ...

Can you please post details of the other rule, just so we’ve got the total picture?

Also, are there any relevant log entries?

Ewen :slight_smile:

I’m pretty sure that’s the fastest forum reply I’ve ever had. :slight_smile:

The other rule is just an Out rule for port 25 that has every tab set to Any. I don’t really care about restricting the server’s outgoing access to port 25 as it does send e-mail out that way. I only care about restricting what IP addresses that are allowed to talk in to port 25.

Were there any relevant entries in your logs?

Please ensure that your rule is set to log when fired (even though logging has been reported to be a bit flaky :-).

Ewen :slight_smile:

Speaking as a site admin with a mail server that gets hammered by spam, let me say “Thank you! (:CLP)” for putting in rules to keep the spammers at bay.

Your rule looks correct. If it isn’t working, then the question is where in the list of rules is it? The order of rules does make a difference. If some preceding rule is letting traffic in, then this port 25 rule just won’t get exercised.

Global Rules read from the top down, first match wins. I’d put this port 25 rule right at the very top, so nothing can get in the way of it.

If that doesn’t do it, then I’d suggest running the CFP Config Reporting Script and posting the result here, so we can make sense of what your rule sequence and setup is. The script is available in one of the sticky topics at the top of this forum page.

If these are global rules, you need to block all other inbound to port 25 as your second rule. Otherwise everything is passed on to your application-and what are the rules there? Also, have you reconfigured tomato to use port 25 for telnet vs port 23, or is that a typo.

Good catch: allow this, block all else. You definitely need the all else. Not having that could be the problem.

Telnet can be used to query any TCP port. Full syntax is “telnet host port”. If no port parameter, it defaults to 23.

The telnet daemon in the tomato firmware on the linksys router only runs on port 23 unless you reconfigure it. And he should post the application rules for the mail server package also. :slight_smile:

No, my SMTP server is running on port 25. I don’t use telnet on my router so that port is closed. If the rule I have created is set to accept only from the Postini IP range on port 25, do I still need a rule excluding everything else? I figured the rule as it is configured would already disallow everything else. That rule is also the first one under the hMailServer process. I will try creating a rule closing up the rest of port 25 and see what happens. Thanks!

You should have the block all rule, although you should get a popup asking for permission if you don’t have it in your application rules. Safer to put it both places, though.

Still no luck. I created a rule blocking all access to port 25 and then put the rule allowing port 25 from the Postini IPs below it. The outside world can still telnet in to port 25 and get a response from my server. I really don’t get it. :slight_smile:

Rather thanm setting it up as an application specific rule, would this be best done as a Global BLOCK rule, using “exclude” and nominating the valid inbound address as the exception?

Ewen :slight_smile:

The rules are evaluated from top to bottom, so the allow whould be above the block. Try block rule
block&log/tcp/in/any/any/any/any just after the allow in your global rules and in your hMailserver process.

I am really confused. I tried creating a block rule and placing it as you describe and that closes off port 25 so any e-mail that comes in times out alone with attempts to telnet to it. It seems that no matter how I set it up, it either lets everything into port 25 or blocks everything. I can’t get it to just let in port 25 from the specific IP range I want. Very confused. 88)

I think I am confused too about your configuration. Does the inbound email get sent by clients to the Postini filters IPs and then come to you on port 25. And the Postini filters set up smtp connections to you? Can you post actual copies of your rules? You can do a screen capture by downloading free Irfanview if you don’t have something else.
I also don’t understand your outbound rule using port 25 as a source at the same time it is being used as a destination. ???

OK, you’re right in that I haven’t been clear on exactly how this works. Postini is an incoming filter service only. It doesn’t affect mail that my server sends out. What happens is that the MX records for my domain point mail delivery to Postini’s servers. Postini analyzes incoming messages and if they pass the filter, it delivers them to my server on port 25 as per normal mail delivery. It’s basically an intermediary. Because some spammers bypass MX records and try to deliver directly to port 25 on my server, Postini recommends that I setup things so that only mail from their server IP addresses gets accepted and everything else gets blocked. If I don’t do this, I still get a fair amount of spam. This is only on the incoming side. My server sends out mail on port 25 as any other server does.

Here’s three screenshots of my main rule screen and the key parts of the first rule:

The inbound rule destination address and source port are set to Any. The outbound rule is set to Out and just allows everything out on every port from every address.

You’re sooooo close.

Try this as a Newtork Control rule

Action : BLOCK
Protocol : TCP or UDP
Direction : IN
Description : Postini incoming filter


Source Address : IP RANGE - Addresses as per your diagram above
Destination Address : ANY
Source Port : ANY
Destination Port : 25

The key difference here is that it is a BLOCK rule with an EXCLUDE. This means it should BLOCK all attempts EXCEPT those that satisfy the excluded address range.

Let us know if this helps,
Ewen :slight_smile:

Your third server rule needs to be a block all, not an allow all. :slight_smile: At this point you might add “log” to all your server rules to help see if we are missing something.

Hey guys. Sorry for taking a bit to respond. I’m starting a business and yeah, time demands and all that. :slight_smile: I tried the idea of creating a block rule with an exception for the IP range and I’m happy to say it seems to be working. Strangely I seem to recall trying this a while ago and it didn’t work so I must’ve done something wrong then. E-mail still goes in and out from my server and I had a friend try to telnet into it and it timed out for him which is exactly what should be happening. I’ll keep trying it tonight but I think you guys got it. Thank you so much for your help everyone! It’s been excellent and I’ll definitely be recommending Comodo Firewall to others.


I figured it would need to be something like that. If it’s an incoming request, then the very first Comodo thingy that’s going to stick it’s finger in the pie are the Network Rules. They have to be satisfied before anything else can happen.

Ewen :slight_smile: