Straightforward direct-delivery incoming mail

I initially had the same problem. The example domain name, I think, began with http and I didn’t think to change it.

Also, I have been blindly following instructions word for word, so needed to guess that to rebuild the mail receiver the command is ./launcher rebuild mail-receiver.

Even then I wondered if it was working, until I noticed the email time window mins setting default is 10 minutes, and soon the email notifications started flooding in…

Reply by email works fine now :slight_smile:


This caught me out late one night too. As Discourse now installs HTTPS as default it probably makes sense for mail-receiver.yml to default to HTTPS too, doesn’t it?

Threw the world’s smallest PR together:


I’m just trying to set this up on a new Ubuntu 20.04 (LTS)x64 droplet. Discourse is up and running on the droplet and seems to be working fine.

However, when I reach the ./launcher start mail-receiver step I am getting the error below.

Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused “process_linux.go:449: container init caused “sethostname: invalid argument””: unknown

Error: failed to start containers: mail-receiver

1 Like

What does the hostname in your yml look like? Was this bootstrapped successfully?

1 Like

There is no hostname in the sample mail-receiver.yml file? But I have this:


Yes, the ./launcher bootstrap mail-receiver step worked without error.

1 Like

Huh - I think I figured this out. The hostname digitalocean gave me was super long with a bunch of dashes. Renaming the hostname using these instructions and choosing a shorter name with no dashes, then rebuilding, appears to have worked. Go figure.


That’s quite strange. But that’s why it’s a good idea to use your, you know, hostname for the hostname when you create the droplet. :slight_smile:


It’s been a while since I’ve created a new droplet. I may have rushed through this but given the instructions, I thought it made sense to use a name that was very specific and descriptive. By default it suggested e.g. ubuntu-s-1vcpu-2gb-sfo1-01 to which I prefixed my name so my hostname was tobiaseigen-sitename-ubuntu-s-1vcpu-2gb-sfo1-011. This caused a weird problem only with mail-receiver. So far no issues elsewhere. :man_shrugging:

Changing it to sitename fixed it.

Screen Shot 2020-11-06 at 3.46.54 PM


Hi everyone, I’m trying to set this up for my server and I keep running into the following error when I look at the ./launcher logs mail-receiver:

Failed to POST the e-mail to execution expired (Net::OpenTimeout)

I went into the mail receive container and ran wget $DISCOURSE_MAIL_ENDPOINT and it tried to connect to the forum domain on port 443 and it fails. So, that tells me that it’s networking related between the Docker containers? But I’m not familiar with how to troubleshoot this more.

Can anyone point me in the direction of troubleshooting this? Thank you!

1 Like

Hey @tobiaseigen! I see you made some edits to the OP. Nice work! Thanks very much. The reject stuff is a nice touch.


Thanks for the thanks! :slight_smile: I happen to care quite a bit about this approach… it’s so much preferrable to the POP3 method.

I will also read through the topic and look for any more guidance we can add, then we can set it to remove replies older than 30 days.

Edit: I added a note about checking for https vs http on the endpoint, which seems to throw folks on older installs. Otherwise I think we’re ready to set this topic to delete replies after 30 days.


I edited the OP to suggest using the new receive_email API key scope.


Thanks for that! It doesn’t look like there’s a way to use the api rake task to generate a scoped key.

1 Like

I recommend using the UI for scoped API keys. While it’s possible to extend the rake task, it’ll definitely make it a lot harder to use.

1 Like

I’m afraid that’s true. My fully automated install installs and configures the mail receiver currently gets an API key with that rake task.

Hmm. It looks like the rake task would be just:

desc "generate a mail api key with given description"
task "api_key:create_mail", [:description] => :environment do |task, args|
  raise "Supply a description for the key" if !args[:description]
  api_key = ApiKey.create!(description: args[:description])
  api_key_scope = ApiKeyScope.create(api_key_id:, resource: "users", action: "check_emails")
  puts api_key.key

grep -r create_master spec comes up empty, so I think this is all it’d take. #pr-welcome?


Got this working (I think). Some notes for any non-techies like me:

The basis of MAIL_DOMAIN and DISCOURSE_MAIL_ENDPOINT are defined in that sample file, and it is just a case of overwriting them with or whatever your discourse domain is.

The DISCOURSE_API_KEY is created here:

Select single use and ‘system’ user as per:

Now to this:

Mine took some minutes to appear. Not sure if having port 25 unopened on my Lightsail instance was the problem, but I opened the port via the Lightsail panel and the email arrived a minute later.

Visited that POP3 thread only to be told at the end…

Which circles back to this thread.

Oh and there is this:

Which I have set.

I also set the reply by email enabled and set reply by email address to reply+%{reply_key} in the main dashboard Settings (just search for ‘reply’) … and a test reply has worked! INCREDIBLE!

So I think I am done!

1 Like

It was.

I’m not clear what your implication is. So maybe the OP shouldn’t mention that way? Maybe it should more loudly say something like “If you are familiar with POP3 polling…”?

Ah. So again, references to the other POP3 solution were confusing?

1 Like

I agree with the gist of this.

  • The “straightforward” instructions refer to the gmail way when ideally they would be self contained.
  • The gmail instructions don’t make it clear that the straightforward way is (usually) preferable, though I’ve read several comments to that effect.

I’m happy enough to do some work to find out the best way, and it’s good to have a choice of competing options, but at the same time it’s nice for a beginner to be spoon fed (eg “use a 2GB Digital Ocean droplet for the website and Mailgun for emails”).


The POP3 method is preferable for beginners, because it is much easier to set up and is less prone to needing troubleshooting. Email can get complicated, and getting up and running in the first place can be done quite easily with POP3. After a while you may want to transition from POP3 to direct delivery which is why this howto refers to POP3.

Maybe the problem here is with the word “Straightforward” in the topic title. That can be misleading if people interpret it to mean setup is straightforward - which it is not.


It looked more straightforward than the gmail alternative, but maybe that brings you back to your point about the topic title… The instructions were good and it was no harder than the initial Discourse installation.