My clients reports me a problem. There is a free email service in Hungary what is like gmail or yahoo or outlook.com. No emails are recived from this service in the past two weeks.
I checked my logs and the problem is the free email service server’s IP addresses are on RBL list, marked as spammers.
I know this is good, my server is protected against spams but I need temporary to allow the connections from this servers (this is a well known free email service in Hungary, I think now there is no spam problems with it).
Is is possible to whitelist an IP or domain in Realtime (SBL) Blacklists?
I think it’s always bad to release or whitelist a mail provider when it’s listed in rbls
If you do want too though, you can either remove the rbls list it is shown in (bad though as spam gets through) or if you know the ip you can add it to trusted network (bad) or I believe you can add it to goodemail in var/qmail/control
I could be wrong though, and ofcourse spam assassin may spam it, so you may have a lot of work to do to fully whitelist it
Thanks John for the quick reply, I know the ip’s, I think the solution will be the trusted network - if it is really necessary.
Can I add a network like this: xxx.xxx.xxx.xxx/24 under Firewall -> Global IP Access Control -> Trusted IPs?
I personally would add them individual and from nodeworx, server, firewall, but you may need to play around a little and test to make sure it works.
Although, a /24 is a lot, which I’m pretty sure they all will not be mail servers.
It’s late here sorry, and I’m about to finish, but I’ll check the best way later or tommorow and post, I’m sure there’s an easier way but just cannot remember it sorry.
The solution is working when added an IP to /etc/tcprules.d/tcp.smtp.
Is it possible to add somewhere a domain and not only one IP for exeption? For example, if the server recives a connection from an RBL listed IP, before drop the connection check which domain is the sender’s domain, and if it is on the whitelist somewhere -> the RBL check is skipped.
Hi Gabor
Good question. I would think there is no exception for a domain, just an IP address, and also I believe there is no whitelist to check if the IP address is listed in blacklist, but effectively the exception you list in tcp.smtp becomes the whitelist, alebit it removes the RBL check so no check is completed.
The reason for this is a time constraint, in that it is at entry level SMTP, and I believe it only needs to check blacklist to decide if to accept/continue with communication or drop. If you can appreciate, if it is a low volume mail server, perhaps no issue, if med or high volume, it would become an issue, as is my understanding.
I’ll have a think/look later though, in case I am wrong, which is most of the time sorry
Many thanks
John
Thanks John for the ansver, the problem is some of my clients reports me they can’t send emails. I checked and the problem is the clients ISP’s IP address is on RBL blacklist. The /etc/tcprules.d/tcp.smtp “whitelisting” is working, but it is a temporary solution.
My clients only using SMTP port 587 for sending and nobody use port 25 for send.
I think there will be 2 solutions for this problem:
close down port 25 for smtp sending (i only need port 25 for receive) and disable rbl check
disable rbl check only on port 587
Maybe the second one will be the best solution. I hope it is understandable, if not, please let me know, it is my bad english!
What do you think?
Sorry, I’m sure its me not understanding correctly or perhaps getting confused sorry.
To summerise your issue so I knwo if I understand as follows:
some siteworx users on your IW system, cannot send email through your SMTP mail server (IW Qmail)
All email processed by your SMTP outgoing server is delivered to external mail providers correctly
All email from external mail providers are correctly received and processed by your SMTP incoming mail server
The siteworx users who cannot send email through your SMTP server is due to their IP Adress been listed in RBL (ie it is their connection IP to your system which is triggering the block)
Am I correct in my understanding or have I missunderstood.
My thoughts on your 2 solutions personally are you should not implement them. If you were too, you would be opening yourself up to receiving a lot spam, placing additional load on your system (due to a lot more connections been received) and on port 25, you are removing the facilities of failover if TLS is not working as expected or stops, and also making it harder to problem solve. Other users may disagree, but those are my thoughts.
If I am correct in my thinking above re your issue, and you are dealing with Dynamic IP from an ISP provider, which your clients are using for their connection to broadband, then I would look to see which RBL is listing them, and change the RBL checks to exclude only those RBL checks, which should be easy done by setting specific RBL checks to use.
I hope it helps but please let me know if above is correct or not and I’ll have a think about it a little more and post back.
Thank you for saving time for my problem, in the future I’m planning to set up more IW servers (now I only have one), and now I have to find the best installation and settings for that.
My ansvers, in order:
yes if they ISP’s IP’s on RBL blacklist
yes
yes
yes, exactly!
You understand perfectly my problem! In this case my clients calling me to help on you, and now the only thing I can do is to add their ISP IP in /etc/tcprules.d/tcp.smtp, but this is a temporary solution, when the ISP is changing their IP the problem exist again.
Is it possible somehow to disable the rbl check only on port 587? If yes, my problem is solved!
I hope you don’t mind, and I have PM you a question, but you will not be able to stop port 25, and only use 587, as TLS are upgraded from 25 to 587 before any credentials are passed.
You can try the following, and I’m sorry, I think I was wrong, and you can add domain names or IP Address ranges as follows:
ipAddress:allow,RBLSMTPD=""
or for domain names,
=domainName:allow,RBLSMTPD=""
To give you and example, which probably makes it clearer as follows:
111.222.333.:allow,RBLSMTPD=""
(all range of 111.222.333. - note the . after 333)
