Issue Can send mails but can't receive (554 5.7.1 Relay access denied)

[TurabG]

Server operating system version

CentOS 7.9

Plesk version and microupdate number

Plesk Obsidian 18.0.44

Hi all.

I have been searching for this issue all the day. I tried solutions like;

1- plesk repair mail
2- Add 127.0.0.1/32 and ::1/128 to whitelist.
3- Change relay option from "closed" to "SMTP"
4- Change reject_unauth_destination value of smtpd_recipient_restrictions to defer_unauth_destination
5- Sender was listed in sorbs; I disabled its lookup. (It is when the maillog changed from "spam" to "relay access denied".
6- Enable/disable forwarding for this mail address.

MX is Plesk; no external mail service is used for this domain. In fact I want to set up forwarding for this account to an external mail. But looks like I can't get to receive mails even to its own inbox, let alone forwarding.

So what can I do now?

 

[IgorG]

Try to repair mail settings first with:

# plesk repair mail

Then verify that the mailbox appears in the postfix virtual_alias_maps:

# postmap -s /var/spool/postfix/plesk/virtual | grep [email protected]

 

[TurabG]

Thank you for your time. As I already said, "plesk repair mail" is the first thing I had already tried. It doesn't help.

I verified that this mail address is present in the virtual file. (Output of the postmap command.)

By the way, I disabled local delivery on this instance; but having it enabled doesn't change the issue here. (As "plesk repair mail" already re-enables it and revokes the changes I made in main.cf)

 

[Bitpalast]

By the way, I disabled local delivery on this instance; but having it enabled doesn't change the issue here. (As "plesk repair mail" already re-enables it and revokes the changes I made in main.cf)

Disabling local deliver of course prevents receiving mail locally.

Your further input indicates that you are not using a default setup, but have made a wealth of edits to the mail server configuration file. It is very unlikely that in a default setup the same issues appear. A "pleskl repair mail" does not revert all entries of main.cnf to a default setting, but only entries that Plesk knows about. It is very well possible that there are more entries in that file that have messed things up. I suggest to either replace it with a default version that matches a correct setup for IP, domain name etc. of your server or to reinstall the whole server.

 

[TurabG]

Then there is certainly a misconception here. What is implied with "local delivery" is "delivery" all? Or is it meant only for bypassing the local delivery as the name actually suggests? Why I disabled "local delivery" is not for I didn't want "any" mail to be not delivered. But instead, I wanted to make sure that Postfix wouldn't try to deliver "all" mails of all domains locally if they are hosted in Plesk.

Like for example: there is a domain in this instance of which I host the mail outside. But I also have a local account for use with some SMTP clients. That means, I can send mails from this domain from Plesk instance. But I receive my mails from another service provider, like Google Apps. The catch in this scenario, if you send an email to your domain from Plesk, since it is already hosted in Plesk, Postfix thinks it should deliver the mail right into the local inbox instead of querying the MX server of this domain. Disabling local delivery achieves this, telling Postfix to not deliver locally but instead, query the MX server and deliver it there.

Now what you are saying is; Postfix doesn't do that, doesn't bypass the local inbox and doesn't query the MX server; but instead it disables "delivery" all together. Is this correct? If yes, then as I said, there is a huge misconception here. We should call it "disabling delivery all together" rather than calling it "disabling local delivery".

Plus, what I did to disable local delivery is actually reverted back by "plesk repair mail". I didn't make a wealth of edits to the configuration unlike you thought. What I did was merely to comment out the lines below: (as proposed in this KB article.)

#virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains
#virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
#virtual_mailbox_maps = , hash:/var/spool/postfix/plesk/vmailbox

And to update mydestination directive like:

mydestination = localhost

And I confirm that "plesk repair mail" reverts these changes. I can confirm that because right after running the command;

1- The lines I comment out are re-added and mydestination directive is set back to default.
2- Local delivery immediately re-activates. (I know it activates because the error log for that domain shows "unknown user" errors, for which it tries to find a local user for that mailbox which is actually not local.)

But it still gives the same error when I try to send a mail to this domain.

 

[Bitpalast]

From where do you send and is your MX record pointing to the server?

 

[TurabG]

I have several domains in this instance and to eliminate confusion, I will tell them apart;

1- I have domain.tld which is hosted in Plesk. Mail service is enabled. There is a local mail account which I am using for some automated notifications sending. MX is pointing to Google Apps. So normal users send and receive mails from Google Apps. (This is why I disable local delivery. Because if an automated notification is sent from [email protected] to [email protected], Postfix tries to look for "user" locally which is not there.) This scenario works well when I disable local delivery.
2- I have anotherdomain.tld which is also hosted in Plesk. MX server is also Plesk. I want its users to send and receive mails from Plesk. This is what I can't achieve now. I can send mails from Plesk Webmail of this domain to outside. I can also send mails using a mail client. But I can't receive mail.

 

[Bitpalast]

So the only relevant case here is (2). Have you verified using a tool like mxtoolbox.com that the MX record of anotherdomain.tld is pointing to your Plesk server?

 

[TurabG]

Yes. It shows the default settings of Plesk DNS like mail.anotherdomain.tld and it points to this server's IP and mail health shows no errors.

 

[Bitpalast]

Next step is to check the exact error messages and message flow in maillog for an incoming mail to anotherdomain.tld. When you send a mail to anotherdomain.tld from an external source, what are all entries in maillog in regard to processing that mail on your server? There will not only be one saying "relay access denied", but there should be several lines.

 

[TurabG]

And that's exactly what I wrote in the subject of this topic. Here is the detail:

Jun 17 12:04:20 lin1 postfix/anvil[27938]: statistics: max connection rate 1/60s for (smtp:52.55.244.91) at Jun 17 12:00:59
Jun 17 12:04:20 lin1 postfix/anvil[27938]: statistics: max connection count 1 for (smtp:52.55.244.91) at Jun 17 12:00:59
Jun 17 12:04:20 lin1 postfix/anvil[27938]: statistics: max cache size 1 at Jun 17 12:00:59
Jun 17 12:04:22 lin1 dovecot: imap-login: Disconnected: Connection closed (no auth attempts in 1 secs): user=<>, rip=xxxx, lip=xxxxx, session=<xxxxx>
Jun 17 12:14:52 lin1 postfix/smtpd[29000]: connect from mail-ed1-f53.google.com[209.85.208.53]
Jun 17 12:14:53 lin1 postfix/smtpd[29000]: NOQUEUE: reject: RCPT from mail-ed1-f53.google.com[209.85.208.53]: 554 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-ed1-f53.google.com>

 

[Bitpalast]

My first though is that MultiRBL.valli.org - Results of the query 209.85.208.53 is actually blacklisted on all major blacklists. So if your server uses any of such blacklists, it will not deliver the incoming mail form hat IP. You said that you are not using blacklists though. But the symptoms strongly point to that issue nevertheless. Make sure that in the blacklist section of your Postfix configuration file there are no additional blacklists mentioned that you might not see in your Plesk GUI, because for this variable, Plesk only handles the entries that Plesk knows about, not the ones that you might have entered in addition to what has been entered through the GUI.

Then you probably already worked through

[Troubleshooting] Mail users on Plesk server are unable to receive or send messages: 454 4.7.1 Relay access denied

Applicable to: Plesk for Linux Symptoms Unable to send or receive email messages on Plesk server. The following error appears in log file /usr/local/psa/var/log/maillog: CONFIG_TEXT: NOQUEUE: ...

support.plesk.com

You said that you have set all these options.

If the above does not help, in this case I see two options:
a) Try to switch toggle Postfix to Qmail and back to make sure that you get a default Postfix configuration.
b) Contact official Plesk support for an individual analysis on your server https://support.plesk.com/hc/en-us/articles/213953025-How-to-get-support-directly-from-Plesk-

 

[Bitpalast]

Could you also provide your exact line of "smtpd_relay_restrictions" in your Postfix configuration file?
I've found NOQUEUE: reject: RCPT from on freebsd and postfix
and UFHH01's entry Resolved - PostFix Receiving Email - NOQUEUE: reject Relay access denied; who pointed out that in another similar case there was a syntax error in that line.

 

[TurabG]

Could you also provide your exact line of "smtpd_relay_restrictions" in your Postfix configuration file?

I will try the other suggestion you made. In the mean time, I looked for that directive in my main.cf but it is absent all together. There are other restriction directives liek:

smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists,permit_sasl_authenticated
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

 

[Bitpalast]

The first two are good, the last one should be:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

 

[TurabG]

Well, in fact it actually was like that when you asked. Then I tried to change it to "defer" instead of "reject" as I saw this suggestion in Plesk forums. This directive must have reverted back to "reject" when I ran "plesk mail repair". Either way, it has no effect on the behaviour and no change in the logs whether it is "reject" or "defer".

 

[TurabG]

Now checking the other suggestion you made; I had already tried it before. (My first post, article 3). And I have tested disabling blacklist check altogether; it's not an issue about it. We can easily confirm it because when sorbs list was active, maillog was showing "spam" error; but when I disable blacklist check, spam error gets away and there comes "relay access denied".

There is only one thing I could try, changing to Qmail and then to Postfix back; but I am not actually very hopeful. I am already considering to use Yandex 360 free plan.

 

[esmitex]

I have recently moved my website to a new host that uses Plesk Obsidian and to be honest the email settings have been driving me crazy. First, I couldn't send e-mails, after fixing this issue, I tried to send e-mails from a Gmail account and I got the error "554 5.7.1 <[email protected]> Relay access denied".

I don't see any option to execute commands on the website so I haven't been able to try to the "plesk repair mail" solution. Since I added various records to make e-mail delivery possible, I suspect there's some issue in my DMARC or SPF records. I haven't been able to figure out how to set up a DKIM record.

 

[TurabG]

I don't think absence of DKIM would cause "relay access denied" error as default mail setup in Plesk doesn't include DKIM and it works well normally. So I am pretty sure the problem lies elsewhere. I couldn't fix this issue and I moved to Yandex 360 rather than using Plesk for hosting the mail.

 

[Bitpalast]

error "554 5.7.1 <[email protected]> Relay access denied".

You have to login to the outgoing mail server to be able to send mail through it. If you see "Relay access denied" you have not logged in properly.