Does the mail-receiver work with arm?

Installation
,
1

I’m in ARM architecture and it throws errors at the above command. I guess this plugin is not suitable for arm?

Is there any other plugin to receive mails for arms?

2

I’m afraid I’m not familiar with arm, so can’t advise on if it’s unsuitable, but just wanted to note that this isn’t a plugin. Though hopefully it’s just a terminology confusion and you’re not trying to install it as a plugin as that won’t work. :slight_smile:

1 Like
3

Thank you for the reply. Ah my bad, I thought it acts like a plugin. If it has a different term, please let me know. My server is running on arm64 the new chips I guess in amazon ec2.

I just installed it as explained in the post. But it throws errors. Seems like it doesn’t work on arm64.

1 Like
4

Just for clarification, are you saying that you have successfully gone through the standard install and have a working Discourse instance on arm, however setting up mail-receiver specifically is failing?

What are the errors that you are seeing? If you can provide the error messages, that may help identify a cause. Be careful to check for anything sensitive that needs redacting.

It’s a bit hard (for me) to give it a particular term in relation to Discourse. Under the hood it’s just a totally separate container application for a receive-only email server which happens to be (is deliberately) set up to deliver those emails to Discourse via its API.

2 Likes
5

Yes that’s the standard install procedure to install the discourse. And discourse is working fine I guess on arm64.

The errors are as follows,

Status: Downloaded newer image for discourse/mail-receiver:release
docker.io/discourse/mail-receiver:release

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

exec /usr/bin/gem: exec format error

cd /pups && /pups/bin/pups --stdin

bootstrap failed with exit code 1

** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.

I started using the aws WorkMail for the time being, but if the discourse can have a simple mail receiving and composing feature, then that’s worth for sure to use it as an official mail inbox.

6

There is no such thing as simple mail server. There is a mail server or there is not. And mail servers are extremely difficult, very vulnerable to turn to spamcenters and in most of cloud/VPS- services forbidden.

That’s why Discourse will poll a real mail server, picking up mail and moving sended to that. If an admin has set up that.

1 Like
7

I think you got me wrong.

I’m not referring to the “Creating of a mail server”. Rather having a simple but nice interface (UX) to compose (to send emails) and to read (incoming emails), so we can use it to reply to official emails we receive.

Isn’t AWS’s “simple Email service (SES)” already controlling spam etc? We just have to provide the UX in the discourse so we have a nice yet simple UX mail inbox and a composer.

I’m not quite sure if providing a single page UX in discourse is that complex (as we already have the server built into it and we can use AWS SES via discourse as well.)

8

For the Discourse base image, the launcher tool detects when running on arm64 and switches to an arm64 image with a warning about it being experimental. The same doesn’t happen for mail-receiver and looking at the images on Docker Hub, it seems an arm64 version does not exist.

There are two obvious options that come to mind:

  1. Switch to an amd64 EC2 instance, giving you a not-experimental Discourse install and allowing you to install mail-receiver alongside it.
  2. Add a second EC2 instance, the tiniest option with amd64 (t3a.nano, I think), and install mail-receiver to that.

It doesn’t matter where mail-receiver lives, the DNS MX record for your reply by email address just needs to reliably point to it and it needs to be able to connect to your Discourse instance.

If this is referring to handling of emails to addresses like info@yourcompany.com, sales@yourcompany.com, support@yourcompany.com, etc., then I think group messaging will give you what you’re looking for.

That is, after you’ve got mail-receiver working, you can create appropriate groups in Discourse and give the groups one or more custom incoming email address. When looking at your own user’s messages, you will see inboxes/etc. for any groups you belong to.

If you use this domain for staff email, e.g. prettygirl@yourcompany.com, then you will need to set something up with your email provider to get particular (e.g. info@) addresses in to Discourse. Depending on what your email provider offers, this may be challenging to get the emails in to Discourse with correct from addresses - you can’t just forward them as Discourse will see everything as coming from your own address instead of the original sender.

In Microsoft 365 / Exchange, a combination of a connector to route to mail-receiver and transport rules to cause particular emails to use that connector would work.

Email is hard, mail-receiver is designed to simplify replying to email notifications and creating topics (new messages to groups included in that) where the domain used does not overlap with existing email services. Beyond that, you’re getting into unsupported advanced, potentially “it was not designed to be used in that way” territory.

2 Likes
9

The answer to the question posed in the title is “no.”

1 is what I’ve thought from the beginning. That’s the recommended and supported solution at this point.

I’ve seen action on discourse_docker recently about increasing support for ARM, I think, but it seems improbable that supporting the mail receiver in ARM is something that’s going to get added any time soon. But that’s just a guess. I have no control over the matter, and there’s a lot I don’t know.

The other would be to figure out how to get ARM to support the mail-receiver and submit a PR.

If you love, love, love ARM, then you could find some full-blown mail receiver with mailboxes and all of that and manage a bunch of mailboxes.

2 Likes
10

It would certainly be possible to support mail-receiver on ARM systems. There’s nothing amd64-specific in there (or, at least, there wasn’t when I made it, and I can’t imagine any major changes would have been made to invalidate that assumption). It would just be a matter of the docker image maintainers making a build of the image for arm64, as they already do for amd64.

Someone could also do an unofficial build and put it somewhere, along with instructions on the one-line change needed to the pups template, or you could do your own local build from the repo on the arm64 system you’re running on.

5 Likes
11

There is socketee which is downloaded to /usr/local/bin from GitHub as part of the Dockerfile. That’s an x86_64 binary so that won’t work, however it looks like that only gets used if explicitly configured.

Specifically that feature above would fail on arm64 as socketee would fail to execute. I can’t see anything else that wouldn’t just work by building for arm64.

I’m not 100% sure but from casual observation, it seems like just adding these lines to the build file might do that:

docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
12

Yeah, I excluded that from my analysis because it’s extremely unlikely that anyone outside of CDCK is using that, since it was included for the very niche purpose of centralising Postfix logs – something that your average mail-receiver consumer is almost certainly not going to do.

2 Likes
13

if mail-receiver does not work on ARM and IMAP only works with GMail, this is very limiting.
This is the first time I see :discourse: running in my shadow, and this saddens me a lot.

14

If anyone’s interested, I’ve done an arm64 image build and pushed it to womble/discourse-mail-receiver:arm64, to tide people over until such time as the core team can get an official image build spun up. See my branch’s README for more details on limitations (no socketee for now; I’ll add it if anyone says they need it), how to use it, and how to report problems (ie “tell me, not the core team”).

4 Likes