Straightforward direct-delivery incoming mail

Wait, are you saying you have a catch all MX record set up to have all mail for your domain sent to the mail-receiver container? Or why don’t you have to setup an alias for a new category custom email?

Sort of, but no. Unless I set up a valid recipient in discourse, it doesn’t work. If you send to – and nobody set it up – it gets rejected and the sender notified.

I may be completely misunderstanding something, but isn’t that always the case, regardless of whether you use direct delivery or POP3 polling?

Here is what (I believe) you have to do when setting up a new category custom email in both scenarios:

POP3 polling using Gmail as your inbox:

  1. Create a new email-address and forward it to said Gmail account.
  2. Paste that new email address into Custom incoming email address in the category’s settings

Direct-delivery as described in the OP

  1. Create a new email-address and forward it to the mail-receiver container.
  2. Paste that new email address into Custom incoming email address in the category’s settings

Hm, as I write this, I realize where I might be thinking wrongly: the point is that this MX record will route all emails sent to that subdomain to the mail-receiver container:

Right? So that’s where it saves you some work, right? But then again, you could do that with Gmail too by setting up a catch-all * email forwarder to the Gmail account…

No. The cool thing with the mail-receiver is that if you want to add an address to a group or category, you just make up an address and stick it in the settings. You don’t need the first step.

I must be missing something. What would you expect to happen with mail sent to a non-existent address?


Yes, that’s what dawned on me too, but then:


Yes, but I don’t need pop3 polling – which means I don’t need to have a pop3 mailbox – I COULD set up a catch-all – but why? This works – in a straight-forward way too.

Okay, fine. Now we closed the circle, which I believe started off by comparing whether or in what ways direct delivery was less work and you arguing that it was because

Anyway, I now understand that the difference is not all that big when it comes to the day-to-day work, but setup actually does seem more straightforward.

Now, regarding the catch-all email functionality (which comes by default with direct-delivery and which is optional, as it were, with POP3): may this not potentially cause problems when a lot of emails arrive that are not actually used in discourse at all (SPAM, in other words)? Is it not an advantage to have those not even reach your server in the first place?

Yes, if you use the reduced backscatter patch (coming someday to mainline, I swear!), attempts to deliver to non-existent addresses will be rejected before they’re accepted by your server, which is a Very Good Thing.


Make that someday – be in the near future pleaseeeeeeeeeeee – not that my forum has an issue with spam right now…

Yeah, unfortunately it’s not on the money-making side of things, and I’ve got to rework the patch to make it backwards compatible, so it’s not a trivial merge. It’ll get there, just not today.

1 Like

Is it usable in its current state? Is there anything I can do to expedite things, as in I’m willing to help.

Yes, as long as you don’t need to support an older config file with a newer container image (ie you’re a new user, or edit your mail-receiver.yml to use the new variables), the patch as currently available reportedly works great.

Well, if you’re up for a bit of programming…

The problem that keeps this from being merged and released is that existing mail-receiver.yml files will define the DISCOURSE_MAIL_ENDPOINT environment variable (because that’s what the existing template says to do), but the newer mail-receivercontainer has switched to using DISCOURSE_BASE_URL.

What’s needed is either:

  1. additional logic to recognise that DISCOURSE_BASE_URL isn’t set, but DISCOURSE_MAIL_ENDPOINT is, and deal with it appropriately (probably don’t enable backscatter protection, etc etc); or
  2. at the very least, detect that the config is out of date and provide suitably simple instructions to upgrade the configuration.

Then, the testing… that’s the time-consuming part, really, making sure everything still works.

If you put together a tested PR for one of those, it would be gratefully accepted.


Perfect – built the image local and it’s running.

We can derive the DISCOURSE_BASE_URL from the DISCOURSE_MAIL_ENDPOINT since it is very likely that the base URL is the on the current domain…if it’s in a subdirectory (e.g, – then we’re in trouble…that’s the one issue – otherwise this is pretty simple to do…

Shoot, I forgot this issue was still pending.

Would it be easier to just back out the one patch where we changed the environment variable? Having a base URL is a better idea in a general sense, but not if it risks breaking people’s installs.

Oh dear god – no – I’m using this :slight_smile: Don’t break my install :stuck_out_tongue:

Is what I proposed sane…we’d have to do some gymnastics to deal with – i’m not even sure that’s possible – or at least not easy

The curse of software development!

There’s probably some startup script that sets these variables, surely we can just have it build the base URL variable from the old one, and vice versa, so everything Just Works for everyone involved.

1 Like

Yes, figuring out what the site’s base URL is from the mail endpoint (strip off /admin/email/handle_mail) is another possible approach.


This is the sane approach, but only if it’s not defined.

Hi there!

I’m wondering if you’ve made any progress on the backwards compatibility here? We are looking to add some customizations to mail-receiver and I didn’t want to duplicate your work.


I’ve created a PR To ensure backwards compatibility:

I was quite careful when writing it, but I’m not clear how to test it short of creating an entire production environment to do so, so I figured it’s worth having it reviewed first by more eyeballs.