Issues in receiving email: 554 5.7.1 - Recipient address rejected: Access denied

Hi all, I'm having mail issues on a Debian server managed via ISPConfig. The server handles several email domains, each with several users.
Most users receive email without issues, but some users can't: when someone tries to send email to such users, (s)he gets this error message via Thunderbird:

Code:

<[email protected]>: Recipient address rejected: unverified address: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied (in reply to RCPT TO command).

([email protected] is the recipient email address.)
This happens to some users belonging to different domains. But other users of the same domains receive email regularly.

This is driving me crazy. Howtoforge forums and Google searches didn't point me anywhere.
Might be something related to postfix user table that got corrupt?

Any suggestion is welcome
Kind regards
Aldo

 

Start with this to get some context:
https://forum.howtoforge.com/threads/please-read-before-posting.58408/
Can those users receive e-mail if sent from Roundcube webmail on the same server?

 

Does "[email protected]" exits in the mail_user table on that server? (assuming "[email protected]" is a mailbox a not a alias or forward)

 

Hi Taleman, thanks for your answer.
Sorry for not having done this test before: tried it, and actually the affected users CAN receive email when sent via Roundcube on the local server itself.
So, to summarize:
- most users can receive mail with no issues, from outside and from local server via roundcube
- few users can NOT receive mail from outside with error 554 5.7.1 described above, but can receive email from local server via roundcube.
To me, this might make to exclude issues in mail_user table, do you agree?
I can't figure out where is the issue, now. :-(
Thanks
Aldo

 

Thanks pyte,
I've just checked, the mail_user table contains all users, including those affected by the issue.
Kind regards
Aldo

 

Can you please run the following command on the mailserver and show us the output?

Code:

doveadm user [email protected]

 

Here it is:

Code:

doveadm user [email protected]
field    value
uid    5000
gid    5000
home    /var/vmail/DOMAIN.EXT/RECIPIENT
mail    maildir:/var/vmail/DOMAIN.EXT/RECIPIENT/Maildir
quota_rule    *:storage=0B
sieve    /var/vmail/DOMAIN.EXT/RECIPIENT/.sieve

Obviously, i changed real user and domain into RECIPIENT and DOMAIN.EXT.
The same output is obtained for both users affected by the issue and not affected.

One more info: the issue appears discontinuous, i.e., some users that yesterday were affected, now receive email without issues. Some other users that yesterday received email, today are affected by the same problem.
This makes me even more confused...

Thanks
Aldo

 

Thats quiet strange. Can you describe your setup and envoirenment a bit more?

 

Strange, indeed.
Setup: Debian 10 server, upgraded from 8 and 9 during years.
ISPconfig in place since first install, about 2015.
Server handles some domains for web and email.
Total no. of emails about 75 in total.
Spamassassin in place (but shouldn't have any relationship with these issues, I already tried to disable it for affected mailbox, with no benefit).
Up to now, worked with practically no problems.
Plenty of disk space (2 TB of mirrored disks, about 75% free). SMART enabled with disks health OK.
16 GB of RAM, mostly unused.
Last ISPconfig update during early January 2023 to 3.2.9, with reconfiguration of services.
No recent changes to mail services configuration.
A few customizations were made to etc/postfix/main.cf; it was necessary to re-apply one of these customizations after last ISPConfig update with reconfiguration of services in January.

I was thinking to move the customizations of etc/postfix/main.cf to /usr/local/ispconfig/server/conf-custom/install/postfix_custom.conf.master to be safer in future upgrades of ISPConfig, followed by an update with the "--force" option.
Maybe this can help?

Kind regards
Aldo

 

Update:
I've just run a ispconfig_update.sh --force with "reconfigure services = yes", but this didn't change anything.
I'm clueless now. :-(
Aldo

 

LOOKS LIKE that the issue was solved.
Activating and analyzing postfix verbose logging, I eventually found the check that triggered the REJECT:

Code:

>>> START Recipient address RESTRICTIONS <<<
generic_checks: name=reject_unverified_recipient
reject_unverified_address: [email protected]
connect to subsystem private/verify
-------- (cut) ---------
private/verify socket: wanted attribute: recipient_status
input attribute name: recipient_status
input attribute value: 2
private/verify socket: wanted attribute: reason
input attribute name: reason
input attribute value: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied (in reply to RCPT TO command)
private/verify socket: wanted attribute: (list terminator)
input attribute name: (end)
generic_checks: name=reject_unverified_recipient status=0
>>> END Recipient address RESTRICTIONS <<<

So, I found in main.cf that the check reject_unverified_recipient was requested by smtpd_recipient_restrictions.
I further searched into the forums and found => here <= that, according to Jesse Norell (ISPConfig developer),

Since I can't understand how to fix such verification mechanism, I decided to remove the reject_unverified_recipient part in smtpd_recipient_restrictions.
The updated configuration line in main.cf is now:

Code:

smtpd_recipient_restrictions = permit_mynetworks, reject_unknown_recipient_domain, reject_unlisted_recipient, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unauth_destination, check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_recipient.cf, check_policy_service unix:private/quota-status

Restarted postfix and - voilà - it started again to accept emails.

A couple of doubts remain:

• Will this change in configuration jeopardize my server or open doors to spammers? I don't think so, by looking at the Jesse Norell's forum post.
• WHY this strange behaviour started apparently without correlation to ISPConfig upgrades or configuration changes? I guess that might be due to postfix caching mechanism of verified recipients, managed by its "verify server", that caches verified recipient for several days; so once the recipients started gradually to expire from the cache, several days after the upgrade of ISPConfig, the issue revealed.

I hope that this post can help, in case someone else falls in similar issues.

Kind regards, and thanks to those who tried to help me.
Aldo