Mail-receiver relay access denied

Trying hard to enable replies by email using the mail-receiver container. I consistently get errors:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied

Why is this? How can I get into the mail-receiver container and examine the postfix config and debug it? I have disabled the postfix server on the system on which this is running, because of clash with port 25. Is that wrong?

I am reasonably sure DNS MX records are right, and this happens from any server sending mail inbound, I am using Amazon SES for outbound in the app container and that works fine.

I am a Discourse newbie and I dont know how to debug the ecosystem. I am an expert in postfix, but I don’t know how to configure it in this containerized universe.

First thing first, if You already have a postfix instance running, You don’t really need the mail receiver container.

You can configure postfix as an email receiver for the replies email and configure discourse to poll that email.

This howto from 2014 shall give you enough idea to get started and I assume you can figure postfix on your own.

I don’t agree with this at all, the benefit of the mail-receiver is that emails are pushed via the API, rather than polled. There’s a significant difference in the time taken for email to arrive in Discourse using the mail-receiver (minutes versus seconds).

There’s also a huge difference in simplicity in configuration, mail-receiver requires three lines of a yml file be updated, the postfix OOBE requires… more.

That error implies the mail domains don’t match.

As you’re obfuscating parts of the message we can’t easily troubleshoot this for you.

3 Likes

If you’re getting any mail delivered as you expect, then this implies that someone is trying to use your mail server to deliver mail to some other domain. If, for example, someone pointed their MX record to your IP address. Or, and I’ve never heard of this :wink: , someone was trying to nefariously have your mail server deliver unwanted mail.

Are all of these errors from the same IP? Can you see in the logs what domain they the errant messages are intended for?

The easiest thing to do is to ignore it.

3 Likes

I had this issue on a previously working mail-receiver which I’d made some changes to. I had thought I’d rebuild the container but clearly something hadn’t gone right as I got multiple ’ Relay access denied’ errors for all recipients. DNS was correctly configured.

In the end a good old git pull and launcher rebuild mail-receiver fixed it. Just posting this in case it works for anyone else.

2 Likes

Have this same error with mail-receiver reports: Relay access denied (in reply to RCPT TO command).

Mail receiving isn’t working for new install but have got this to work before. Believe all settings are correct but might have missed something.

This usually means that the mail is being delivered to a domain that’s not the one the receiver is configured to accept.

I have it set for the same sub-domain as the discourse site.

For the MX record value is “subdomain.domain,” and host is supposed to just be “subdomain” or @?

Does anyone know what causes the “Relay access denied” error?

It happens when the recipient domain doesn’t match with the domain configured in the mail-receiver.yml.

1 Like

Is that the address you’re sending the mail to?

Same address, is working now after rebuild of mail-receiver.

Believe had rebuilt that before but wasn’t working, good that works now.

should i need to additionally allow port 25 for mail-receiver to work properly.

In this case, working properly would be inbound emails showing in .\launcher logs mail-receiver reaching the discourse admin UI

Yes, you must open the port 25. That could be added to this guide as an optional rule.

1 Like

Well, I don’t have 25 open. So, no.

But ufw status isn’t that interesting. Instead nft list ruleset is.

1 Like

Update: ufw deny 25 has been applied and mail-reciver works fine (07/02/2025)

Can confirm this is correct, though i had made one other error. This is about my second forum to implement mail-receiver, and on the first i had the MX record of the domain receiving the mails Value as the DISCOURSE_BASE_URL

I now have the mails coming through to my (second) forum UI, rather than only my first :tada:

Note: this belief of correctness may have been due to not running ./launcher rebuild mail-receiver after changing the yml (06/02/2015)

I imagine you don’t need to allow port 25 on, say, an Azure or VPS panel firewall - so pre-Ubuntu

because the MX record Value should point towards the website, not the mail domain, interesting

The official guide mentions that port 25 must be open:

I myself ran into a mail-receiver issue because I forgot to open port 25 in my firewall. Adding the rule resolved the issue.

better solution might be to only allow the relevant IP address though?

Let’s not tell that to my mail-receiver :wink:

Outbound is happening using Amazon SES. Incoming comes per mx to domain of the forum and now docker kicks in.

The reason for that is docker and its internal way to work. It just doesn’t care ufw. If you want exact detailed explanation wait a second — I’ve asked once why Discourse doens’t care my firewall, and the reason was packet traffic. But understanding deeply what is going on is not my cup of tea. For me is enough that things work. And trust me: ufw is opened only ports 22, 80 and 443.

I reckon you quoted a situation where mail-receiver takes care of sending emails too using postfix.

1 Like