Hi
Tell your users to change their email's config checking (Outlook) "My server requires authentication". Try.
I dont' use, directly, this cpanel feature, I use this (wrote by hand):
deny hosts = !+relay_hosts
!authenticated = *
message = $sender_host_address esta listado en $dnslist_domain
log_message = Listado en $dnslist_domain
dnslists = sbl.spamhaus.org : \
xbl.spamhaus.org : \
list.dsbl.org : \
bl.spamcop.net : \
dnsbl.ahbl.org
Look at the first and second line: it tells exim to ignore this step for authenticated users.
Regards
Tell your users to change their email's config checking (Outlook) "My server requires authentication". Try.
I dont' use, directly, this cpanel feature, I use this (wrote by hand):
deny hosts = !+relay_hosts
!authenticated = *
message = $sender_host_address esta listado en $dnslist_domain
log_message = Listado en $dnslist_domain
dnslists = sbl.spamhaus.org : \
xbl.spamhaus.org : \
list.dsbl.org : \
bl.spamcop.net : \
dnsbl.ahbl.org
Look at the first and second line: it tells exim to ignore this step for authenticated users.
Regards
I noticed a problem with the zen rbl.
It includes the PBL list also, and that is not a list you want to block.
PBL is just a 'warning' saying the ISP's Policy bans users from using external mailservers.
So, if you have a user using your server for outgoing mail, instead of their ISP, their IP is listed in the PBL.
I don't think we should be using the 'zen' version of spamhaus RBL. the SBL+XBL version has always been good for me.
From Spamhaus website:
How to use the PBL
The PBL can be queried directly as pbl.spamhaus.org and is also integrated into zen.spamhaus.org (do not query both, use either one or the other). We recommend you use zen.spamhaus.org which combines all of the Spamhaus zones, see: ZEN.
Caution: Because the PBL lists normal customer IP space, do not use PBL on smarthosts or SMTP AUTH outbound servers for your own customers (or you risk blocking your own customers if their dynamic IPs are in the PBL). Do not use PBL in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers.
The PBL can be queried directly as pbl.spamhaus.org and is also integrated into zen.spamhaus.org (do not query both, use either one or the other). We recommend you use zen.spamhaus.org which combines all of the Spamhaus zones, see: ZEN.
Caution: Because the PBL lists normal customer IP space, do not use PBL on smarthosts or SMTP AUTH outbound servers for your own customers (or you risk blocking your own customers if their dynamic IPs are in the PBL). Do not use PBL in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers.
and
Should I use the PBL to block access to my webserver?
No! A listing in the PBL does not mean there is anything 'wrong' with the IP address or end user. A PBL listing does not mean an address is an open proxy or run by a spammer. All it means is that the IP address has been designated as 'not allowed to make direct-to-MX SMTP connections'. The majority of legitimate connections to webservers come from IPs listed in PBL. Please do not block innocent users.
No! A listing in the PBL does not mean there is anything 'wrong' with the IP address or end user. A PBL listing does not mean an address is an open proxy or run by a spammer. All it means is that the IP address has been designated as 'not allowed to make direct-to-MX SMTP connections'. The majority of legitimate connections to webservers come from IPs listed in PBL. Please do not block innocent users.
I upgraded cPanel yesterday and got tons of customers blocked because the PBL is included in the zen.spamhaus.org RBL. The cPanel doesn't appear to differentiate the returns from Zen properly to still allow the authenticated users (specifically on exim-587). In the end, I had to turn this feature off and go back to the SBL-XBL rbl list.
The acl block for rbls is after the accept line for authenticated smtp sessions so you shouldn't have an issue if you are using the default configs.
Does Exim-587 use the same configuration file?
I had users say they had the SMTP Auth setting correct on the email client, but still getting block by RBL. They were listed in the PBL. When I removed Zen RBL, they seemed to go through fine. I have them set to send email through port 587 because thier ISP blocks port 25 except through the ISP mail account.
I'm using ConfigServer MailScanner, which I forced reinstall after this latest cpanel upgrade. Could that have changed the operation of the default exim config file in terms of SMTP Auth order?
I had users say they had the SMTP Auth setting correct on the email client, but still getting block by RBL. They were listed in the PBL. When I removed Zen RBL, they seemed to go through fine. I have them set to send email through port 587 because thier ISP blocks port 25 except through the ISP mail account.
I'm using ConfigServer MailScanner, which I forced reinstall after this latest cpanel upgrade. Could that have changed the operation of the default exim config file in terms of SMTP Auth order?
There are way too many nonstandard things going on there for me to guess whats wrong. Its best to open a ticket so we can get a direct look.
Thanks
Thanks
While this is how the Exim ACL Flowchart claims it will work, this is not actually what is happening on any of our servers. We are inundated with people that can't send mail since the upgrade.
Could you please open a ticket with support at https://tickets.cpanel.net/submit/index.cgi?reqtype=tickets so we can investigate this issue further?
I'm having the same issue. Can you please post any result or changes that eliminate this issue.
This is very hard to debug because the client needs to be on a blacklisted IP to see the issue.
I have clients that reported the issue, but I've been unable to replicate the issue myself for debugging.
I agree that the ACL is correct, but it isn't doing what the ACL says.
This is very hard to debug because the client needs to be on a blacklisted IP to see the issue.
I have clients that reported the issue, but I've been unable to replicate the issue myself for debugging.
I agree that the ACL is correct, but it isn't doing what the ACL says.
I will - I'm having a heckuva time myself. Most of mine just want to send their mail, so they change their SMTP to their ISP instead of helping troubleshoot which is great for them, but making this really really difficult to pin down. I also have two servers that have what appear to be identical settings, one blocking and one not.
I is flummoxed.
I is flummoxed.
The problem I had was that the client went out of town and couldn't access their local ISP, as its an on network only type of thing. So, they had no choice but us my SMTP.
It's a huge pain.
If anyone is continuing to experience these issues and hasn't yet submitted a support ticket, please permit our technical analysts to assist you: http://tickets.cpanel.net/submit.
If you haven't already opened a ticket, please please please do so. I've seen this amount to at least three separate problems (update: actually all three issues were local problems).
The response I got from my NOC was:
The best solution at this time would be to have your customers having issues
sending mail to your server using SMTP authentication, is to instead use their
ISP's SMTP server to send mail.
So, don't look to me for a solution - apparently, I am not getting one. I'll let you know if I find one on my own.
The best solution at this time would be to have your customers having issues
sending mail to your server using SMTP authentication, is to instead use their
ISP's SMTP server to send mail.
So, don't look to me for a solution - apparently, I am not getting one. I'll let you know if I find one on my own.
Hello,
I am having this issue - I've added a dynamic IP address to the whitelist and it's still being blocked as appearing in the RBL and also being rate-limited.
I have found that switching on AUTH in .mailrc (I'm sending these particular mails from cron jobs on an Ubuntu server) makes no difference.
I've also found that routing the mail through my ISP's server (which requires authentication) still ends up being blocked my my cPanel exim server.
I'm running the Old Style Spam System for my Exim since some of my clients needs the subject re-writing / tagging capabilities for their extensive post-processing.
I'm using WHM 11.23.2 cPanel 11.23.4-S26138.
As others have stated, although the flow-chart for the exim config seems to state that authenticated sessions get let in, it doesn't seem to be the case (at least not for me). Also, whitelisting the IP address seems to be totally ineffective.
Any pointers would be useful, since the alternative is to switch off the RBL's and end up with my clients getting 400+ spam per day even after SpamAssassin has done it's work! The only other alternative that I can think of is to send these emails to my gmail account and then put an auto-forward on there to the account that I use to store the cron logs etc. Less than elegant...
Kind regards,
Dave.
I am having this issue - I've added a dynamic IP address to the whitelist and it's still being blocked as appearing in the RBL and also being rate-limited.
I have found that switching on AUTH in .mailrc (I'm sending these particular mails from cron jobs on an Ubuntu server) makes no difference.
I've also found that routing the mail through my ISP's server (which requires authentication) still ends up being blocked my my cPanel exim server.
I'm running the Old Style Spam System for my Exim since some of my clients needs the subject re-writing / tagging capabilities for their extensive post-processing.
I'm using WHM 11.23.2 cPanel 11.23.4-S26138.
As others have stated, although the flow-chart for the exim config seems to state that authenticated sessions get let in, it doesn't seem to be the case (at least not for me). Also, whitelisting the IP address seems to be totally ineffective.
Any pointers would be useful, since the alternative is to switch off the RBL's and end up with my clients getting 400+ spam per day even after SpamAssassin has done it's work! The only other alternative that I can think of is to send these emails to my gmail account and then put an auto-forward on there to the account that I use to store the cron logs etc. Less than elegant...
Kind regards,
Dave.
Hi,
Replying to my own thread, I've found a messy fix that works and that's to add the IP address into /etc/alwaysrelay - that seems to allow my cli based mail to get sent... weird but it works.
I'd still be very interested to know if there's a better way...
Dave.
Replying to my own thread, I've found a messy fix that works and that's to add the IP address into /etc/alwaysrelay - that seems to allow my cli based mail to get sent... weird but it works.
I'd still be very interested to know if there's a better way...
Dave.
