All otherwise delivery of mail to local recipients died after last nights upgrade to mysql and ispconfig. Recipient address rejected: Access denied (in reply to RCPT TO command) ISPConfig upgraded to 3.2.8p2 mysql upgraded to Ver 15.1 Distrib 10.3.36-MariaDB Otherwise, no configuration changes were made. Thanks!
Which ISPConfig version did you use before? Did you choose to reconfigure services during the update? Which Linux distribution do you use and is this the MariaDB version that ships with that OS as default (so not using a MariaDB version from external sources like the MariaDB repository)?
Good question- I usually update when you guys release them, so whichever the release was immediately before this one. Yes- usually accept the defaults, and reconfigure services was set to yes. Debian buster and yes- default mariadb from the debian buster repos. Thanks Till!
That should be fine so far. Did you do any manual modifications in the mail setup? Did you get that error for all incoming emails? A rejection can be perfectly fine, e.g. the spam filter rejects spam emails.
Yeah- this box has been running for years fantastic, all the while with no issues. Right now, there are only 2 active mailboxes for one domain and they're both experiencing the same problem: 450 4.1.1 <[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); Interestingly, this query results in no data: SELECT 'reject_unverified_recipient' FROM mail_domain WHERE domain = 'target_domain' AND active = 'y' AND server_id = 1 Thanks for your continued help Till- I really appreciate it!
MariaDB [dbispconfig]> select 'reject_unverified_recipent' from mail_domain where domain = '[email protected]' and active = 'y'; +----------------------------+ | reject_unverified_recipent | +----------------------------+ | reject_unverified_recipent | +----------------------------+ 1 row in set (0.001 sec)
Ok, with the full error message, this is more clear to me. As a temporary workaround, please try to remove address_verify_virtual_transport and address_verify_transport_maps from /etc/postfix/main.cf, at least temporarily.