Is there a way to stop my mail server from always getting blocked by RBLs?

R

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
I run a few services and I'd say 80% of the time when people use the forget password feature they never get the email. I'm assuming it's getting blocked along the way by RBL servers.

Is there something I can do to permanently white list my server from being blocked? Not only does it not send spam, it barely even sends any kind of bulk mailings. Is there something I can do like register it somewhere as being a trusted server?
 
Dedicated server in Hamilton. (Carat Networks)

IP is 96.45.178.190 (considering it's a public server hosting my sites, it's not exactly private :p )

I was looking at a log and one of the blocked hosts is AOL, but this happens all the time, I get people telling me they did not get my email, it happens with lot of providers. In the case of AOL this is the message I get: "The IP address has been blocked due to a spike in unfavorable e-mail statistics."
 
Not currently listed anywhere.

There is no global "trusted server" thing.

You have reverse dns set to mail.iceteks.net. good start.
Carat's netblock may be getting thrown on the lists (if so there's very little you can do)

Things that help a lot:
SPF
DKIM

You should only ever send first party mail (stuff that your users signed up for directly)
 
I can just about guarantee that your mail is being blocked because the lack of an SPF entry in your DNS configuration..

You need to add a TXT entry with the following content:
Code: 
v=spf1 a mx -all

Receiving mail servers look up the mail servers, look for the SPF and verify that the mail server is listed then look up the rDNS to verify that it is exactly as the server responded. If it fails any of these steps your mail will be blocked.

If you PM me the domain and the FQDN of the mail server ill check it out for you.
 
Pretty sure I did, though TBH I did not really know what I was doing so maybe I did it wrong. This is what the DNS record looks like:

$TTL 600
;iceteks.net
@ IN SOA iceteks.net. webmaster.iceteks.com. (
1000000002 ; serial
12h ; refresh
1h ; retry
2w ; expire
1h ; minimum
)

IN NS ns1.iceteks.net.
IN NS ns2.iceteks.net.
IN MX 10 mail.iceteks.net.
@ IN A 74.86.204.212

;spf

iceteks.net. IN TXT "v=spf1 a mx -all"

; host records
ns1 IN A 96.45.178.186
ns2 IN A 96.45.178.187

mail IN A 96.45.178.190
Click to expand...

All those IPs actually go to the same physical server. If ever I get multiple servers then one of them will be a true secondary.



Is there anything special I need to be doing when sending mail? This is more or less how my programs do it:


helo localhost
mail from: <my server's email>
rcpt to: <reciepient's email>
subject: <subject>
data:
<data>
.
Click to expand...

Is there perhaps other headers I should be adding in there?
 
Well just found the domain name myself and you have a good SPF entry, let me check a few more things.
 
Your primary DNS server is not listed as a parent and your SOA serial number format is wrong.
 
Not sure what you mean by that, don't you just have to increment the serial number each time you make an update (though I always forget to do that tbh). I did not think it had any special format. And not sure what you mean about listing as parent, how and where do I do that?

Also do I need to put that SPF entry on all my records or just the one for the mail server? I have mail going out as other domains too. iceteks.com etc.
 
You cannot say helo localhost.

You must say helo from your actual hostname.
Preferrably, one that matches reverse DNS ( mail.iceteks.net )

Anyone running a server trying to reduce spam will block you if you try to send from a bogus helo, they don't even need RBLs.
 
mwarps said:
You cannot say helo localhost.

You must say helo from your actual hostname.
Preferrably, one that matches reverse DNS ( mail.iceteks.net )

Anyone running a server trying to reduce spam will block you if you try to send from a bogus helo, they don't even need RBLs.
Click to expand...

That is good to know. I'll have to change that. I think in most scripts I have it hard coded as localhost but I can easily make it pull from a config file or just hard code mail.iceteks.net.
 
Red Squirrel said:
Not sure what you mean by that, don't you just have to increment the serial number each time you make an update (though I always forget to do that tbh). I did not think it had any special format. And not sure what you mean about listing as parent, how and where do I do that?
Click to expand...
zone serials are irrelevant to this conversation..

Also do I need to put that SPF entry on all my records or just the one for the mail server? I have mail going out as other domains too. iceteks.com etc.
Click to expand...

Each domain must have the mx record "10 mail.iceteks.net." if you want to use that precise SPF for every domain. Every domain does need an SPF.
 
Red Squirrel said:
Not sure what you mean by that, don't you just have to increment the serial number each time you make an update (though I always forget to do that tbh). I did not think it had any special format. And not sure what you mean about listing as parent, how and where do I do that?

Also do I need to put that SPF entry on all my records or just the one for the mail server? I have mail going out as other domains too. iceteks.com etc.
Click to expand...

SOA SN is supposed to be YYYYMMDDnn

Your SOA isn't showing your DNS servers to have authority

You need an MX record on all domains pointing to your mail server's FQDN and the SPF has to be on ALL domains. If you currently have the SPF on ALL domains that send mail from the server, and the MX records for each domain don't show "mail.iceteks.net" then that is why your mail is being blocked. The IP gets blocked, not the domain.

Also, NS2.ICETEKS.NET doesn't respond to anything right now.
 
You should check to make sure reverse DNS is setup for your mail server. A lot of mail servers will reject mail if reverse DNS doesn't match.
 
bds1904 said:
SOA SN is supposed to be YYYYMMDDnn

Your SOA isn't showing your DNS servers to have authority

Also, NS2.ICETEKS.NET doesn't respond to anything right now.
Click to expand...

zone serial does not have a required format other than it being a 32-bit integer. Nothing's really looking at this, though..

His SOA should name the primary master in mname, but again, nothing other than DNS checkers look at this.. if the server answers, he's fine.

Delegating to a non-responsive NS is silly, though, indeed.
 
Red Squirrel said:
That is good to know. I'll have to change that. I think in most scripts I have it hard coded as localhost but I can easily make it pull from a config file or just hard code mail.iceteks.net.
Click to expand...

Please do. This is very likely the crux of your problem along with lacking SPF on each sending domain.
 
bds1904 said:
SOA SN is supposed to be YYYYMMDDnn

Your SOA isn't showing your DNS servers to have authority
Click to expand...

1. Wrong
2. Irrelevant

Serial numbers being YYYYMMDDnn is just a loose convention. You can as well start at 1 and increment by 1. All that matters is that a change is accompanied by a higher serial number than before.

The SOA doesn't grant authority, the NS records do. Third parties resolving names in the domain don't care about the SOA at all. The SOA is a hint for internal management, so that the primary nameserver knows not to send notifies to itself, for example. For outsiders, the NS records are important. A hidden primary setup, for example, doesn't list the ultimate master server anywhere in the zone, hence "hidden" primary.

ns2 being down at the moment is unfortunate, but that's why you specify two nameservers, anyway.

Squirrel:
A TTL of only 10 minutes for all records is kinda low. Unless you frequently change your NS records, you don't need 10 minutes for those.

About the mail problem, yeah, don't try to talk your own SMTP. Isn't there any library you can use? Hell, even calling your system's sendmail is better than trying to open your own TCP connection and talking wrong SMTP to the world.

Being a good admin is knowing when you don't know and knowing where to look. If you try to talk SMTP, you had better read the relevant RFCs. If you're unsure, use a ready-made library or the system's mail agents.
 
You must log in or register to reply here.
Back
Top