У меня архитектура ARM, и при выполнении указанной команды возникают ошибки. Я полагаю, что этот плагин не подходит для ARM?
Есть ли какой-либо другой плагин для получения писем на архитектуру ARM?
Боюсь, я не знаком с arm, поэтому не могу посоветовать, подходит ли он или нет, но хотел лишь отметить, что это не плагин. Надеюсь, это просто путаница в терминологии, и вы не пытаетесь установить его как плагин, так как это не сработает. 
Спасибо за ответ. Ах, моя ошибка, я думал, что это работает как плагин. Если у этого есть другое название, пожалуйста, сообщите. Мой сервер работает на архитектуре arm64, это новые чипы, которые, я полагаю, используются в Amazon EC2.
Я только что установил его, как объясняется в посте. Но он выдаёт ошибки. Похоже, что он не работает на arm64.
Только для уточнения: вы имеете в виду, что вы успешно выполнили стандартную установку и у вас работает экземпляр Discourse на arm, однако настройка именно mail-receiver завершается ошибкой?
Какие ошибки вы видите? Если вы сможете предоставить сообщения об ошибках, это может помочь выявить причину. Будьте внимательны и проверьте, нет ли там чувствительной информации, которую нужно скрыть.
Мне немного сложно (для меня) дать этому конкретный термин в контексте Discourse. «Под капотом» это просто полностью отдельное контейнерное приложение для почтового сервера, принимающего только входящую почту, которое намеренно настроено на доставку этих писем в Discourse через его API.
Да, это стандартная процедура установки Discourse. И, кажется, сам Discourse на архитектуре arm64 работает нормально.
Ошибки следующие:
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.
Пока я использую AWS WorkMail, но если бы в Discourse была простая функция получения и отправки писем, то определённо стоило бы использовать его как официальную почтовую почту.
Не существует понятия «простой почтовый сервер». Либо почтовый сервер есть, либо его нет. А почтовые серверы крайне сложны в настройке, очень уязвимы для превращения в спам-центры и в большинстве облачных/VPS-сервисов запрещены.
Именно поэтому Discourse будет опрашивать реальный почтовый сервер, забирать почту и пересылать отправленную на него. Если администратор настроил это.
Кажется, вы меня неправильно поняли.
Я имею в виду не «создание почтового сервера», а простой, но удобный интерфейс (UX) для написания (отправки) и чтения (получения) писем, чтобы мы могли отвечать на официальные письма, которые получаем.
Разве AWS Simple Email Service (SES) уже не занимается контролем спама и т. п.? Нам нужно лишь обеспечить UX в Discourse, чтобы у нас был приятный, но простой почтовый ящик и редактор писем.
Не совсем уверен, что создание одностраничного UX в Discourse — это так уж сложно (ведь у нас уже есть встроенный сервер, и мы также можем использовать AWS SES через Discourse).
Для базового образа Discourse утилита launcher определяет запуск на архитектуре arm64 и переключается на образ для arm64, выдавая предупреждение о том, что это экспериментальная функция. То же самое не происходит для mail-receiver, и, судя по изображениям на Docker Hub, версии для arm64, похоже, не существует.
В голову приходят два очевидных варианта:
- Переключиться на экземпляр EC2 архитектуры amd64. Это даст вам установку Discourse без статуса «экспериментальная» и позволит установить
mail-receiverвместе с ней. - Добавить второй экземпляр EC2 — самый минимальный вариант с архитектурой amd64 (t3a.nano, если не ошибаюсь), и установить
mail-receiverна него.
Не имеет значения, где именно будет работать mail-receiver. Главное, чтобы DNS MX-запись для вашего адреса «ответа по электронной почте» надежно указывала на него, и чтобы он мог подключаться к вашему экземпляру Discourse.
Если речь идет об обработке писем на адреса вроде info@вашакомпания.com, sales@вашакомпания.com, support@вашакомпания.com и т. д., то, по-моему, групповая переписка даст вам то, что вы ищете.
То есть, после того как mail-receiver заработает, вы сможете создать соответствующие группы в Discourse и назначить этим группам один или несколько пользовательских адресов входящей почты. При просмотре своих личных сообщений вы увидите почтовые ящики и прочее для любых групп, в которые вы входите.
Если вы используете этот домен для корпоративной почты, например prettygirl@вашакомпания.com, то вам нужно будет настроить что-то у вашего провайдера электронной почты, чтобы направлять определенные адреса (например, info@) в Discourse. В зависимости от того, что предлагает ваш провайдер, это может быть сложно реализовать так, чтобы письма поступали в Discourse с правильными адресами отправителя. Вы не можете просто пересылать их, так как Discourse будет видеть все письма как исходящие от вашего собственного адреса, а не от оригинального отправителя.
В Microsoft 365 / Exchange сработает комбинация коннектора для маршрутизации в mail-receiver и правил транспортировки, заставляющих определенные письма использовать этот коннектор.
Работа с электронной почтой — дело сложное. mail-receiver разработан для упрощения ответов на уведомления по электронной почте и создания тем (включая новые сообщения в группы), где используемый домен не пересекается с существующими почтовыми сервисами. За пределами этой сферы вы попадаете в неподдерживаемую продвинутую область, где, возможно, «инструмент не был спроектирован для такого использования».
Ответ на вопрос, заданный в заголовке, — «нет».
Вариант 1 — это то, что я считал правильным с самого начала. На данный момент это рекомендуемое и поддерживаемое решение.
Я видел недавнюю активность в discourse_docker по расширению поддержки ARM, но, похоже, маловероятно, что поддержка mail receiver для ARM будет добавлена в ближайшее время. Но это лишь предположение. Я не контролирую этот вопрос и знаю далеко не всё.
Другой вариант — разобраться, как обеспечить поддержку mail-receiver для ARM, и отправить pull request.
Если вы очень, очень, очень любите ARM, то можете найти полноценный mail receiver с почтовыми ящиками и всем остальным и управлять множеством почтовых ящиков.
Поддержка mail-receiver на ARM-системах, безусловно, возможна. В коде нет ничего специфичного для amd64 (по крайней мере, так было на момент создания, и я не могу представить, чтобы были внесены какие-либо существенные изменения, опровергающие это предположение). Всё сводится к тому, что разработчики Docker-образа должны собрать версию для arm64, как они уже делают для amd64.
Кто-то также может создать неофициальную сборку и разместить её где-либо, вместе с инструкциями по внесению однострочного изменения в шаблон pups, либо вы можете выполнить локальную сборку самостоятельно из репозитория на вашей системе arm64.
Есть socketee, который загружается из GitHub в /usr/local/bin как часть Dockerfile. Это бинарный файл для x86_64, поэтому он не сработает, однако, похоже, он используется только при явной настройке.
В частности, описанная выше функция не сработает на arm64, так как socketee не сможет выполниться. Я не вижу ничего другого, что не работало бы при сборке для arm64.
Я не на 100% уверен, но по поверхностному наблюдению кажется, что добавление этих строк в файл build может решить задачу:
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
Да, я исключил это из своего анализа, потому что крайне маловероятно, что кто-либо, кроме CDCK, будет использовать его, так как он был включен для очень узкой цели — централизации логов Postfix. Это то, что обычный пользователь mail-receiver, скорее всего, делать не будет.
Если mail-receiver не работает на ARM, и IMAP работает только с GMail, это очень ограничивает. Это первый раз, когда я вижу 
, работающий в моей тени, и это меня очень огорчает.
Если кому-то это интересно, я собрал образ для архитектуры arm64 и загрузил его в репозиторий womble/discourse-mail-receiver:arm64, чтобы помочь вам до тех пор, пока основная команда не подготовит официальный образ. Подробнее об ограничениях (на данный момент нет поддержки socketee; я добавлю её, если кто-то скажет, что это необходимо), способах использования и порядке сообщения о проблемах (то есть «сообщайте мне, а не основной команде») читайте в README моей ветки.
Я отправил PR с удалением socketee Remove socketee support by Firefishy · Pull Request #28 · discourse/mail-receiver · GitHub
Также я с радостью отправлю PR с изменениями для приведения mail-receiver в соответствие с процессом сборки для ARM64, используемым в discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub