RBoy
(RBoy)
1
Discourse でメールリスト、特にバウンスメールをクリーンアップする方法を調べています。サイトではプライベート SMTP サーバーを使用してメールを送信していますが、応答は Discourse が POP アクセスするための Gmail アドレスに返信されるように設定されています。
そのため、_受信メール_ダッシュボードにバウンスメールが表示されています。
しかし、_バウンスメール_ダッシュボードには何もありません。
Discourse のエラーログを見ると、バウンスメールを検出していることがわかります。
Email can not be processed: Email::Receiver::BouncedEmailError
Delivered-To: xxx.yyy@gmail.com
Received: by 2002:xxx:7022:911:xx:73:xxx:f96 with SMTP id xxx7csp1115046dlb;
Thu, 25 Jan 2024 12:03:33 -0800 (PST)
X-Google-Smtp-Source: AGHT+IEagzW8QOUgAyfOxU9wYaox/wuiL/wNqWhvftUB4uO/85r9H/55+FnfT6NrSTkLI5kfj+Vy
X-Received: by 2002:xxx:620a:4xxx:b0:xxxx:9265 with SMTP id br34-xxx8ba09265mr280168qkb.77.17062130xxx;
Thu, 25 Jan 2024 12:03:33 -0800 (PST)
Return-Path: <>
Received: from xxx.com (xxx.com. [207.xxx.xxx.xxx])
by mx.google.com with ESMTPS id bi4-xxx0b00783c84e9ef8si590747qkb.206.xxx.01.xx.12.03xxx
for xxx.yyy@gmail.com
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 25 Jan 2024 12:03:33 -0800 (PST)
Received-SPF: none (google.com: xxx.com does not designate permitted sender hosts) client-ip=207.xxx.xxx.xxx;
Authentication-Results: mx.google.com;
dkim=pass header.i=@xxx.co.nz header.s=alpha header.b=biFVvXep;
arc=fail (signature failed);
spf=none (google.com: xxx.com does not designate permitted sender hosts) smtp.helo=xxx.com;
dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=xxx.co.nz
Received: from xxx.co.nz (xxx.co.nz [210.xxx.xxx.5x])
by xxx.com (Postfix) with ESMTP id 4DD66xxx8E3
for xxx@zzz.com; Thu, 25 Jan 2024 20:03:28 +0000 (UTC)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zzz.com;
s=dkim; t=1706213008;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
dkim-signature;
したがって、質問は次のとおりです。
- Discourse はバウンスメールをバウンスとしてマークしないのはなぜですか。また、これを修正するにはどうすればよいですか。
Discourse は、バウンスを送信済みメールに関連付けるために reply_key を使用します。Discourse がメールを送信する際、SMTP エンベロープ送信者として reply_by_email_address の値を使用します。
バウンスを正しい送信済みメールに関連付けることができるように、reply_by_email_address に {reply_key} が含まれていることを確認する必要があります。
たとえば、ここ meta では incoming+%{reply_key}@meta.discoursemail.com に設定されており、そのアドレスに送信されたものはすべてこのインスタンスに配信されます。
「いいね！」 1
RBoy
(RBoy)
3
ご返信ありがとうございます。残念ながら、メールリレーサーバーが + アドレス指定を認識しないため、メールへの応答の reply_key をオフにする必要がありました。他に選択肢はありますか？
「いいね！」 1
メールリレーサーバーは関係ありません。メールボックスが存在するエンドサーバーのみが関係します。メールのローカルパートは、中間サーバーからは不透明です。
次のようにGmailではありませんか？
バウンスを確実に検出する別のメカニズムがあるかどうかはわかりません。
「いいね！」 1
RBoy
(RBoy)
5
念のため明確にしておきますと、バウンスメールを受信する宛先のSMTPドメインサーバーは + アドレス指定を認識しないため、To フィールドに基づいてのみディスコースがPOP経由で取得するGmailに転送します。つまり、To フィールドに reply_key が含まれている場合、そのメールはディスコースが使用するGmailアカウントに転送されません。
そのため、メールアドレスに reply_key を含めることはできませんが、他の場所に含めることはできますか？件名や本文、またはディスコースが解析できるような場所に含めることはできますか？
設定で実際に使用しているものを（わずかに匿名化しても）記述していただけると、非常に助かります。
また、alternative_reply_by_email_addresses の設定も検討するとよいでしょう。
できないと思います。
可能であれば、あなたのセットアップには以下のようなものを推奨します。
reply_by_email_address を inbound+%{reply_key}@forum.hostname に設定するforum.hostname のメールを受信し、すべてを the.gmail.account@gmail.com に配信するようにメールサーバーを設定する
ここでは、中間メールサーバーはプラスアドレス指定を理解する必要はなく、ドメインのすべてのものを転送するだけでよいのです。
RBoy
(RBoy)
10
おっしゃることは理解しております。残念ながら、SMTPサーバーのルールには制限があり、サブドメインの転送は設定できません。ユニークなToメールIDのみ転送するように設定できます。
しかし、ここで明確にしたい点があります。Discourseの動作方法に矛盾があるようです。
- ユーザーがメール投稿に返信すると、正しく受信されます。
{reply_key}が明示的にどこにも設定されていなくても、返信は完全に機能するように見えます（上記のスクリーンショットを参照）。
- しかし、メールがバウンスすると、DiscourseはそれをReceivedとして分類し、Bouncedとしては分類しません。
- エラーログには、Discourse内の何かがバウンスメールであることを認識していることが示されています（最初の投稿のエラーログを参照）。Discourse内の何かがバウンスメールであることを認識しているのに、なぜReceivedではなくBouncedとして表示されないのでしょうか？
したがって、ユーザーが投稿に返信するとDiscourseによって正しく処理されるのに、バウンスメールはそうならないのはなぜでしょうか（また、エラーログとバウンスメールのダッシュボードの間にも断絶があるようです）。設定で何か見落としていることはありますか？
RBoy
(RBoy)
11
Discourse の reply by email address 設定を discourse.xxx+%{reply_to}@gmail.com に設定しましたが、メールが配信されると、Gmail は discourse の SMTP ドメインである yyy.com が gmail ドメインをなりすまそうとしていると判断し、スパムとしてマークするようです。返信先ドメインを送信者のドメインと異なる設定にすると、DMARC と SPF の失敗がトリガーされるようです。
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
find related posts with key をオフにしたため（警告を読んだことを願っています）、Discourse は in-reply-to メールヘッダーを使用して、返信がどのトピック/投稿を参照すべきかを判断しています。
バウンスメールではそれができません。Discourse は、どのメッセージがバウンスしたかを 知る必要 があり、その情報は1つの場所にしか保証されていません。それは To: アドレス（元のメッセージのエンベロープからのアドレスに由来します）です。
これが機能するためには、Discourse がメッセージを送信するとき、それが送信されたアドレスから返信を受け取る必要があります。Discourse はこの情報を To: ヘッダーで探します（エンベロープの To: ではありません）。
gmail ドメインをなりすましています。
gmail アドレスからメールを送信したい場合は、それらのサーバー経由で送信する必要があります。しかし、彼らはそれを好みません。
yyy.com の DKIM を設定していないようです。設定すべきです。それが正しく設定されれば、DMARC はパスするはずです。
「いいね！」 2
RBoy
(RBoy)
13
はい、設定されており、yyy.com SMTP サーバー経由で Discourse によって「送信」されたメールは、SPF、DKIM、および DMARC を問題なく通過します（少なくとも管理コンソールの「テストメールを送信」ページからは）。
この問題は、yyy.com アドレスではなく、gmail.com アドレスへの reply_by_email_address として Gmail アドレスを設定した場合に発生します。送信サーバーを yyy.com に維持したまま、Gmail アドレスへの reply_by_email_address を設定したときに DMARC が失敗しないように、このセットアップで何かできることはありますか？
「明白な」場所で必要な情報が見つからない場合（またはなりすましに関する警告とともに、それを行うための設定オプションを提供する場合）、バウンスメールの残りのコンテンツ/添付ファイルを解析してその情報を抽出することはできませんか？
この状況では、reply_by_email_address がエンベロープ From アドレスとして使用されるため、DMARC アライメントが失敗します。
バウンスで確実に残っているのは、アドレスだけです。
件名も残っているかもしれませんが、この情報を件名に含めるのは現実的ではありません。
一部のシステムでは元のメッセージを添付ファイルとして含めていることがわかります…もし存在する場合、より多くの情報を取得するために添付ファイルがないかバウンスをチェックすることは理論的には可能です。
RBoy
(RBoy)
15
私の理解が正しければ、reply_by_email_addressはDiscourse（yyy.comから）によって送信されるエンベロープのreply-toフィールドに設定されるべきです。そうすれば、ユーザーが返信するとき、元の（yyy.com）アドレスではなく、reply-toメール（gmail.com）に返信することになります。したがって、メール応答エンベロープでは、fromアドレスはユーザーのメールアドレスであり、toはgmail.comアドレスであるべきです。
なぜreply_by_email_addressがfromアドレスとして使用されるのでしょうか？
reply_by_email_address は差出人アドレスとしては使用されず、エンベロープ・フロムとして使用されます。これはバウンスを機能させるためです。
各アドレスがどのように使用されるかを示す画像は次のとおりです。アドレス自体はホスティング固有のものですが、例としては十分です。
notification_email: notifications@hs1.discoursemail.com
reply_by_email_address: incoming+%{reply_key}@hs1.discoursemail.com
通知：
返信可能なメッセージ：
「いいね！」 2
RBoy
(RBoy)
17
ありがとうございます。大変参考になります。
つまり、reply_by_email_address は、バウンスした場合にそのメールアドレスに戻ってくるように、Fromヘッダーで使用されます。そして、メールでの返信が有効になっている場合、同じメールアドレスがReply-Toヘッダーにも設定されます。
したがって、上記の私の理解が正しければ、DiscourseでReply-Toヘッダー用の別の設定（reply_to_email）があれば、DMARCの失敗の問題が解決するはずです。送信時にはreply_by_email_addressから取得したyyy.comドメインをFromに使用し、新しいreply_to_email設定から取得したgmail.comをReply-Toに使用します。メールがバウンスした場合、それは依然としてreply_by_email_addressに戻されますが、ユーザーが返信した場合はreply_to_emailに送信されます。
それはSMTPの「エンベロープFrom」であり、「From」ヘッダーではありません。「From」ヘッダーはバウンスには使用されません。
つまり、②ではなく①です。
DMARCを通過させるには、SPF（送信IPと組み合わせてエンベロープFromを検証する）またはDKIM（メッセージのFromフィールドとチェックサムフィールドを検証する）のいずれかがアラインする必要があります。
この作業の全体的な目的は、「見栄えの良い」返信先アドレスを設定し、ユーザーがそこに返信できるようにすることのようですね。
このようなことですか？
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
バウンスが機能しないようにするには、エンベロープFromをこのように設定する必要があります。
「いいね！」 1
RBoy
(RBoy)
19
はい、その通りです。envelope-from を reply-to と異なるものにするという考え方です。
envelope-from のドメインと送信IPが一致するため、SPFはパスするはずですが、同時に返信はGmailに送られて応答を処理し、メールがバウンスした場合は元のドメインサーバーに戻り、そこからバウンスをGmailの受信トレイに転送することができます。
実際には次のようになります。
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
私の設定では、受信SMTPがVERPをサポートしていないため（つまり、バウンスバックにVERPアドレスが含まれないため）、送信側にはVERPは設定されません。そのため、VERPをサポートしているGmailに reply-to が送信されます。これは現在発生しているようなDMARCの失敗を引き起こすはずではありません。
