"sender verify fail for <apache@server.domain.com>: Unrouteable address" (recent change?)
Did something change with exim settings in v98.0.6? I have a client who has two servers, server B with cpanel. Server A, up until very recently, has been able to send emails via PHP from the apache@server.domain.com to server B without issues. Now they appear to be getting blocked:
2021-08-30 20:41:14 H=server.domain.com [xxx.xxx.xxx.xxx]:32972 sender verify fail for : Unrouteable address
2021-08-30 20:41:14 H=server.domain.com [xxx.xxx.xxx.xxx]:32972 F= rejected RCPT : Sender verify failed
2021-08-30 20:41:14 SMTP connection from server.domain.com [xxx.xxx.xxx.xxx]:32972 closed by QUIT
Any idea what setting changed, if any? This was working as recently as 1 week ago, and has been working for years now. Also, any idea why they wouldn't bounce? They just appear to be hitting a black hole. Thanks.
-Michael
-
Hey there! The "unroutable address" error would seem to indicate there is a DNS issue of some type with the "server.domain.com" hostname. Has there been any changes to the DNS for the hostname that it is trying to send to? It's possible the resolvers on the sending server are experiencing an issue as well, causing DNS lookups to not always complete properly. In order to test that, you could update the /etc/resolv.conf file to have the following entries: nameserver 8.8.8.8 nameserver 8.8.4.4
to see if that changes the behavior. Another test would be to see if a direct message works from webmail, outside of the PHP script/form being used, as that could give you some clues.0 -
The "unroutable address" error would seem to indicate there is a DNS issue of some type with the "server.domain.com" hostname.
It's not a DNS issue, the email is an unrouteable address (the server exists, the email does not), but again this was working just last week. Server B is the DNS server for server A, and there have been no changes. I created a workaround by changing the Return-path email on server A to one that exists, so the emails are going through now, but I am still curious as to what would have changed on cpanel's end for this to just start verifying whether or not the email was routeable. I maintain 6 cpanel servers so worried this might crop up again where I won't have access to the sending server. While looking up the error it seems like there are 2 checks exim could be doing to trigger this (there might be more, these are the 2 I saw): a) it's checking to see if server.domain.com has an MX record (in this case domain.com does, server.domain.com does not), or b) it's connecting to server.domain.com to see if apache@server.domain.com is an actual existing email. Do you know where these settings are in cpanel, and whether or not the defaults on them would have changed in the 98.0.6 update? Thanks. -Michael0 -
If that is the issue, that would be the Sender Verification option in WHM >> Exim Configuration Manager, although that isn't something I would expect to get enabled automatically. 0 -
If that is the issue, that would be the Sender Verification option in WHM >> Exim Configuration Manager, although that isn't something I would expect to get enabled automatically.
I just checked on multiple servers, and apparently Sender Verify is enabled by default and Sender Verify Callout (where it actually checks the email itself) is disabled by default, and I checked a client who is still on cpanel v78.0.49 and it's been that way since at least back then, so honestly I have no idea what would have changed with that or why it used to work at all. Weird. -Michael0 -
Right, we haven't made any tweaks to that in a while, so I'm not sure why that would have changed. 0
Please sign in to leave a comment.
Comments
5 comments