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
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
