Spam Block problem

floyd

floyd

Verified User
Joined
Mar 29, 2005
Messages
6,271
I don't know if this can fixed or not but just wanted to make everybody aware of something I just discovered.

A client informed me that they could send out mail through one of my servers. I checked the log and found that their ip was blocklisted by SORBS. I checked the ip at mxtoolbox.com and found that it was listed in more than one blocklist including Spamhaus. I check the report at Spamhaus and ended up here http://www.spamhaus.org/pbl/query/PBL267068

If I am reading this correctly RoadRunner is in effect having their own dynamic ip's blocklisted.

I am not sure what should be done at this point if I want my clients on RoadRunner to be able to use my servers to send mail. I was able to whitelist the one client but what about the rest of my clients who may have the same situation?
 
Last edited:
Perhaps you could point them to something like Google Postini. They can use it for inbound and outbound, and they get their email spam/virus protected at the cloud level - and they've got a reseller system.

Google Postini hasn't been listed since we've used them in any RBL-like system - and I think I read somewhere that they've never been listed. I also think they've probably stopped spam from "getting out" - which is usually the reason why IP's get listed in the first place.
 
ranz said:
Perhaps you could point them to something like Google Postini.
Click to expand...

I don't want to have to point them anywhere else. I want them to be able to use my servers to send email. That is one of the reasons they are paying me instead of using somebody else.

which is usually the reason why IP's get listed in the first place.
Click to expand...

In this case RoadRunner listed their own ip's.

I believe its an attempt to get around people using alternate ports to send email. As we know many isp's block port 25 and people have just started using alternate ports to get around that block. So now what RR has done is just blocklist their own ip's so now it doesn't matter what port is being used.

I could be wrong about the intent but the effect is the same. If we are going to use blocklists we are blocking some of our own clients from using our servers to send mail from their own computers.
 
Fair enough - I guess now they've got more of a reason to use your servers.

RBL listing doesn't prevent 100% of emails being sent/received - just those who use the service (and I'm not saying you said that it did either). If RR wanted them to stop using SMTP outbound, there are other ways to monitor the network (instead of simple port blocking). Having said that, it would be interesting if they went to such tactics ...

A similar example I saw is where a large company wanted to prevent SSH tunnelling ... people were setting up $5/mth VPS Linux boxes and using them to ssh tunnel services back to their workplace. The network engineers found a way to prevent it.
 
I am not sure what the intent of RR is but when we use blocklists such as SPAMHAUS then now our clients on RR cannot use us to send mail.

So it appears our choices are to disable SPAMHAUS or whitelist all of our clients. Whitelisting clients is a lot of trouble to maintain.

If done by email address or domain then spam will get through even though the sending ip is blocklisted.

If done by ip what if the client's ip changes and a spammer now has the whitelisted ip?
 
A dilemma it is ...

Whitelisting is not the way to go unless all other options are exhausted.

Can you not have RBL checks disabled (for only their Subnet), but still score on Spam? That way you can do it via IP subnet for the RBL lists - but then still have it check the message for a Spam Score (in an effort to pick up real spam).

I don't know if this is possible - but certainly worth a shot?
 
but then still have it check the message for a Spam Score
Click to expand...

I think you are referring to spamassassin here. If so I do not use spamassassin for 2 reasons, load and its too late to reject email. It is my opinion that mail should be accepted or rejected at smtp time and not filtered. I see way too many cases of legit email being filtered into a spam folder and the recipients not getting it because they auto delete the spam folder contents, they don't even look through it. But perhaps that is a discussion for another thread.
 
@ranz Your image: Are you a Pepsi drinker? That is what I think every time I see it.
 
@floyd:

The ISP is merely doing what all good ISPs should do; dynamic IP#s should never be allowed to deliver email; they should only be allowed to submit it to an MTA via an authenticated login.

And authenticated logins through port 587, with our standard exim.conf files, should be authenticated, authorized, and accepted for delivery, before blocklists are checked. If they're not, espeically with my latest release candidate, then I've made a horrible mistake somewhere; please check for me.

@ranz:

Memories from my earliest childhood:

Pepsi-Cola hits the spot;
Twelve full ounces; that's a lot.
Twice as much for a nickel, too;
Pepsi-Cola is the drink for you.

Based on the then current practice of selling Pepsi in 12 ounce bottles, and Coke in 6-1/2 ounce bottles. For five cents.

http://www.youtube.com/watch?v=ym4Ue2xE-Hg

Yes, I'm old :)

Jeff
 
@jlasman:

A nice tune from the past ...

pitty now it has no relevance in my profile :(
 
Edited because everything I said previously on this particular post was wrong.

Long story short: I use pop before smtp for authenticating even on port 587. The client had stopped checking mail long enough for the time limit to expire. For some reason exim replied with the RBL error which was correct to a degree. But when the client authenticates with pop the RBL gets bypassed.

When the pop before smtp time expires and:
When the ip is not blacklisted it errors with authentication required.
When the ip is blacklisted it errors with the RBL error.

I have been able to replicate this with exim -bh

I think it is working as it should for the most part.
 
Last edited:
You must log in or register to reply here.
Back
Top