このディレクトリで新しいコンテナー定義を作成するには、どうすればよいですか！？
その直後に表示されるコマンドを実行することで。厳密には、そのディレクトリ内にファイルを作成しているのではなく、app.yml と同じように containers サブディレクトリ内に作成しています。
「いいね！」 3
ありがとうございます。最初はうまくいっていないようでしたが、テキストエディタで以下の状態になりました。
これには問題があるようです。./launcher logs mail-receiver を実行すると、テキストエディタで指定したドメインではなく、discourse_base_url=https://discourse.example.com と報告されます。
mail-receiver のブートストラップを再構築/再起動しましたが、正しいドメインに変更されていません。
「いいね！」 1
ちょっと困っています。アドバイスをいただけますか？
root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.
starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver
そして…
root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 4400 root 13u IPv4 24419 0t0 TCP *:smtp (LISTEN)
master 4400 root 14u IPv6 24420 0t0 TCP *:smtp (LISTEN)
試したこと…
root@JEN /var/discourse # netstat -nlp | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 4400/master
tcp6 0 0 :::25 :::* LISTEN 4400/master
そして…
root@JEN /var/discourse # ps j 4400
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 4400 4400 4400 ? -1 Ss 0 0:02 /usr/lib/postfix/sbin/master -w
オンラインでコンテナを停止し、プロセス（プロセス4400？）をキルするという指示を見つけました。
これは安全で、問題を解決しますか？
mail-receiver.yml ファイルのポート25を別のポートに変更する必要がありますか（または、すべきですか、すべきではありませんか）？
「いいね！」 1
postfixをインストールしていて、それを削除する必要があるのではないでしょうか？
ポートは変更できません。それを使用しているプロセスを停止する必要があります。再起動すると、どちらのプロセスが先に起動するかの競争になるため、単に終了させるだけではうまくいきません。
「いいね！」 3
私もそう思っていました。どうやってそこに入り込んだのか想像もつきませんが、取り除いてみます。そうでなければ、問題なく動作しているように見えるGmailを使用できます。
「いいね！」 2
フォーラムを新しい環境に移行したばかりで、その結果、メール受信者を再インストールしました。以前インストールしていたものよりも新しいバージョンのようです。YML設定が少し変更され、DISCOURSE_MAIL_ENDPOINTの代わりにDISCOURSE_BASE_URLが使用されています。YMLファイルの内容はその変更を反映していますが、このスレッドの冒頭の指示を更新する必要があります。
また、メールがバウンス/拒否されたときに、次のエラーが発生しています…
Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
有効なメッセージは正しく処理されているようです。以前のバージョンのメール受信者では、最近のログファイルから確認した限りでは、これらのエラーは発生しませんでした。少し調査したところ、https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/ にたどり着きました。
mail-receiver.yml ファイルに以下を追加すると、問題が解決するようです。
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
「いいね！」 4
DMARCサポートを追加したことをここに投稿します。これは discourse/mail-receiver:with-dmarc イメージを介して行われます。詳細については、OPの Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver を参照してください。
「いいね！」 3
既存トピックに2件の投稿がマージされました: Mail-receiver relay access denied
トラブルシューティングセクションに追記したいことがあります。
Mail-Receiver（ダイレクトデリバリー）は複数のドメインで機能していましたが、Gmailユーザーからのメッセージを受信できませんでした。原因がわかりませんでした。ログにはGoogleからの接続/切断以外何もありませんでした。すべて正常に見え、オンラインツールもDNSが正常であることを確認しました。
最終的に、DNSにSMTP TLSレポートレコードを作成しました。例：
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
数時間後、Google（Gmail）から、現在のMXレコードを反映していないmta-stsポリシーをキャッシュしていたことを示すレポートが送信されました。更新を引き起こすべき私の更新された_mta-sts DNSレコードを無視したように見えたため、Googleがそのキャッシュされたポリシーを1週間保持するのではないかと心配しました。
その後すぐに、何もせずに、バックアップされていたすべてのGmailがDiscourseに流れ込み始めました。このレポートは、Googleの視点から問題を理解するのに役立ち、メッセージが流れ始めたときに頭を悩ませるのを避けることができました。
SMTP TLSレポートはまれに発行されるため、辛抱強く待ってください。
「いいね！」 3
ガイドにはMTA STSの設定について何も記載されていないことを考えると、それを設定しない99.999%以上のユーザーを混乱させるだけではないでしょうか？
「いいね！」 2
私の場合は、単一のDNSレコードを追加するだけで問題が明らかになりました。ガイドにはすでにMail-Receiverのインストール用にDNSレコードを作成するように指示されているため、トラブルシューティングセクションに最後の手段としてレコードを追加するように提案しても、無理はないと思います。しかし、あなたの投稿には「いいね」が2つあり、私の投稿には1つもないので、それが限界かもしれません。
「いいね！」 1
それは良い知らせですね。Gmailは一般的な送信者なので、ガイドに追加するのに良い情報だと思います。
ガイドでは、MTA-STSを設定するためではなく、mail-receiverを機能させるためにDNSレコードを作成するように指示しています。したがって、ガイドに従っているユーザーは、あなたが経験したような問題に遭遇することはありません。そのため、ガイドを余計な手順で複雑にする必要はありません。
「いいね！」 1
一般的に、mail-receiverはGmailから送信されたメールを新しいトピックとして処理できますか？
これは重大な問題のようですが、原因が孤立したインシデントである場合はそうではありません。
結論として、マットが正しいということになりました。私の環境では、ドメインの通常のメールがMail In a Box (https://mailinabox.email/) によって処理されており、厳格なMTA-STSポリシーを要求し、Gmailがそのポリシーを強制するため、MTA-STSに対応する必要がありました。デフォルトでは、ポリシーはMail-Receiverの設定と競合する可能性があります。ほとんどのドメインにはポリシーがありません。ドメインにポリシーがある場合、それは以下で確認できます。
https://mydomain.com/.well-known/mta-sts.txt
私の動作中のポリシーは以下のようになっています…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
もう少し作業をしてから、“mode: none” を “mode: enforce” にアップグレードしたいと考えています。
「いいね！」 2
Discourse をコマンドラインで再構築する際、mail-receiver コンテナは自動的に再構築されますか、それとも別途行う必要がありますか？教えていただけますでしょうか。よろしくお願いします。
いいえ、指示された場合にのみ再構築されます。メール受信コンテナを頻繁に再構築する必要はありません。
「いいね！」 2
これは間違いなく私の役に立ちました:)
「いいね！」 1