Solved RoundCube/SMTP does not send emails to @icloud.com

[paulonichio]

On one of our servers, we've noticed that for several days, no emails are being delivered to @icloud.com addresses (there are no issues with other providers like @gmail.com, @hotmail.com, and @yahoo.com).

When attempting to send emails through RoundCube, simply clicking the Send button results in the following error message:

SMTP Error (550): Failed to add recipient "[email protected]" (No such recipient here).

When sending directly through SMTP, the message is not delivered, and in the server logs (mainlog), only this is recorded:

2023-09-22 09:30:50 H=(UserPC) [17x.xx.xx.xx0] F=[email protected] A=login:[email protected] rejected RCPT [email protected]:

No additional information is displayed, and there is no email bounce.

We've checked the server's IP against hundreds of blacklists, and our IP is not listed on any of them. We've also tried changing the outgoing email IP, but it still doesn't work.

The server is using RSPAMD + blockcracking + easy_spam_fighter.

We've disabled the CSF firewall, but the issue persists.

Does anyone have any ideas about what this could be?

 

[Zhenyapan]

SMTP Error (550): Failed to add recipient "[email protected]" (No such recipient here).
try send email via roundcube from this server to this email, check result.

 

[Richard G]

SMTP Error (550): Failed to add recipient "[email protected]" (No such recipient here).

Message is clear. No recipient here means the mail address does not exist.
Which might also be the reason you don't see no info and no bounce, often this is done to prevent spam messages bouncing to sender mail addresses.

 

[paulonichio]

SMTP Error (550): Failed to add recipient "[email protected]" (No such recipient here).
try send email via roundcube from this server to this email, check result.

When I try to send an email to any @icloud.com address through RoundCube, I receive the following error message:



When I attempt to receive an email from any @icloud.com address, it doesn't arrive in my inbox, and when checking the server logs (/var/log/exim/rejectlog), I see only the following:

2023-09-23 12:40:35 H=st43p00im-zteg10063501.me.com [17.58.63.176] sender verify fail for [email protected]: 2023-09-23 12:40:35 H=st43p00im-zteg10063501.me.com [17.58.63.176] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=no F=[email protected] rejected RCPT [email protected]: Sender verify failed

A telnet test to the IP 17.58.63.176 and port 25 works without any issues.

 

[paulonichio]

Message is clear. No recipient here means the mail address does not exist.
Which might also be the reason you don't see no info and no bounce, often this is done to prevent spam messages bouncing to sender mail addresses.

Hi Richard! The email address is being entered correctly, and it does exist (it's my personal email), but in the logs, there are several other clients who are also sending and experiencing the same error. It's something very strange.

 

[Zhenyapan]

Sender verify failed - try also check email rating at https://www.mail-tester.com/

 

[paulonichio]

I appreciate everyone's attention, and I have finally identified the issue. One of our customers (reseller) created an account with the icloud.com domain. That's why when the server attempted to send emails, it was checking if the same account existed on the server.

After deleting the account, the sending process has been restored to normal. If anyone in the future comes across this topic, please check if the domain doesn't exist on the server.

 

[sparek]

This list of forbidden domain names is controlled by the file:

/usr/local/directadmin/data/templates/forbidden_domains.list

I'm not sure if you can directly add additional domains to this file - and if you can, I don't know how that works when DirectAdmin updates this list in a DA Update (are custom changes lost?).

Probably needs to have another file, a custom supplied list - i.e. /usr/local/directadmin/data/templates/forbidden_domains_custom.list - that also gets checked during domain creation.

Although you can also accomplish this same task with a pre domain_create hook.

 

[Ohm J]

I never testing by myself on "forbidden_domains.list",

trying put it into "/data/templates/custom/forbidden_domains.list" and restart DA.

normally, DA can custom every template by just copy file from
"./data/template/" into "./data/template/custom"

But not work in every file. Besure you test it by yourself.

 

[Richard G]

It's something very strange.

Well at least we now know it did not exist locally, so the error was correct. Indeed something we can remember for the future.

 

[sparek]

Indeed.

Copying /usr/local/directadmin/data/templates/forbidden_domains.list to /usr/local/directadmin/data/templates/custom/forbidden_domains.list and adding your desired domains to /usr/local/directadmin/data/templates/custom/forbidden_domains.list does appear to work.

You do have to copy the file the file - or at least set all the domains you want to forbid into the /usr/local/directadmin/data/templates/custom/forbidden_domains.list file. If /usr/local/directadmin/data/templates/custom/forbidden_domains.list exists, then DirectAdmin uses it. If it doesn't exist, it falls back to /usr/local/directadmin/data/templates/forbidden_domains.list

I don't know how often DirectAdmin updates the /usr/local/directadmin/data/templates/forbidden_domains.list file. Probably not very often. But still you may want a a post update_da hook that reads /usr/local/directadmin/data/templates/forbidden_domains.list and combines it with a personal list into a /usr/local/directadmin/data/templates/custom/forbidden_domains.list file. To be sure you're using a full set of forbidden domain names.