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

Discussion in 'Server Operation' started by Aldo Giove, Feb 2, 2023.

  1. Aldo Giove

    Aldo Giove New Member

    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:
    <[email protected]>: Recipient address rejected: unverified address: host[] 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
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Aldo Giove likes this.
  3. pyte

    pyte Well-Known Member HowtoForge Supporter

  4. Aldo Giove

    Aldo Giove New Member

    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. :-(
  5. Aldo Giove

    Aldo Giove New Member

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

    pyte Well-Known Member HowtoForge Supporter

    Can you please run the following command on the mailserver and show us the output?
    doveadm user [email protected]
  7. Aldo Giove

    Aldo Giove New Member

    Here it is:

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

  8. pyte

    pyte Well-Known Member HowtoForge Supporter

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

    Aldo Giove New Member

    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/; 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/ 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
  10. Aldo Giove

    Aldo Giove New Member

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

    Aldo Giove New Member

    LOOKS LIKE that the issue was solved. :)
    Activating and analyzing postfix verbose logging, I eventually found the check that triggered the REJECT:
    >>> 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[] 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 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 is now:
    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/, 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.
    fuxifux, pyte and ahrasis like this.

Share This Page