「カスタム受信メールアドレス」に関する制約 (ホスト型サイトのみ、かもしれません？)

[BradCray (Brad Chamberlain)]

Discourseコミュニティの皆様へ —

以下の内容は、試行錯誤を通じて私が観察したことですが、ドキュメントを見たことも、警告やエラーに遭遇したこともありません。

私たちのサイトはDiscourseによってホストされており（大変感謝しております！）、カテゴリのカスタム受信メールアドレスを設定する際、そのメールアドレスが「foo+」で始まる場合（「foo」は私たちのサイトの一般的なスラッグです）にのみ機能するようです。

具体的には、私はよく新しいカテゴリを設定し、直感的だと思うメールアドレスを設定して、そのアドレスにテストメールを送りますが、バウンスメールを受け取ることも、サイトの受信または拒否されたメールログに表示されることもありません。その後、これまでの経験を思い出し、アドレスを foo+\u003csome name\u003e に設定して再度テストすると、すぐに機能します。

もし私の思い違いでなければ、これはDiscourseがホストされている複数のサイト間で、どのサイト宛のメールかを区別するための手段として理解できますが、私の認識が正しいか確認したかったのです。あるいは、もし間違っているなら、私が最初に選択したメールアドレスがなぜ/dev/nullに送られるように見えるのか、他の説明があるかどうかを知りたいです。

よろしくお願いいたします！
-ブラッド

[supermathie (Michael Brown)]

@BradCray

カスタムの受信メールアドレスをカテゴリに設定すると、「foo」（サイトの一般的なスラッグ）の前に「foo+」が付いている場合にのみ機能するように見えます。

声に出して言うのは簡単で単純かもしれませんが、カスタムメールアドレスは、それが実際にサイトに配信された場合にのみ機能します。

したがって、そこに何かを置くだけでは機能せず、アドレスがサイトに配信されないと機能する可能性はありません。

Discourseには、それが起こることを確認するためのそのアドレスの検証方法がないため、それを確認する責任は管理者にあります。

ホスティングでは、サイトに配信されるように事前に手配したいくつかのメールアドレスを活用することをお勧めします。

• {ANYTHING}@{YOUR PREFIX}.discoursemail.com
• {ANYTHING}@{your.site.hostname}

[BradCray (Brad Chamberlain)]

@supermathie さん、ありがとうございます —

私たちの（ホストされている）サイトでは、…@{OUR PREFIX}.discoursemail.com がオプションであることに気づきませんでした。デフォルトの「受信メールを受け入れる」アドレスがそれを使用しているため、ホスト名として…@discoursemail.com しか試したことがありませんでした（元の質問でホスト名を省略していたため、これを明確にするために上記の元の質問を更新しました）。試してみます、ヒントをありがとうございます！

Discourseのセルフホストインスタンスではメールアドレスを検証できないことは理解していますが、ホストされているインスタンスで、メールアドレスが予期される形式でない場合に警告またはエラーを生成することは可能でしょうか？（または…discoursemail.comアドレスを使用する場合に予期される形式でしょうか？

改めてありがとうございます、
-ブラッド

[supermathie (Michael Brown)]

@BradCray

ホストされたインスタンスで、メールアドレスが予期された形式でない場合に警告またはエラーを生成することは可能でしょうか？

「予期された形式」には、「有効なメールアドレス」以外の制限はないため、これは実現不可能です。

@BradCray

または、…discoursemail.com アドレスを使用する際の予期された形式は？

これは、私たちができることかもしれません。

[BradCray (Brad Chamberlain)]

ご返信ありがとうございます！

これで、これが私たちのようなホスト型Discourseサイト特有の問題であるという私の疑念が確信に変わったと思います。このフィールドに入力された…discoursemail.comアドレスが有効であることを、そのようなサイトが検証するためにどの程度の労力が必要かは分かりませんが、もしそのような機能があれば、過去数年間、新しいメーリングリストやエイリアスを設定する際に、なぜ機能しないのかと悩む時間とフラストレーションをかなり節約できたことでしょう。他の方々にとっても役立つと思います。

あるいは、ホスト型サイトのそのフィールドに、有効なアドレスはslug+...@discoursemail.comまたは...@slug.discoursemail.comでなければならないことを示すちょっとしたツールチップがあるだけでも、大いに助けになります。ただ、そのヒントをホスト型Discourseサイトに特化させることが、そのアプローチを非現実的なものにするかどうかは分かりませんが。

-ブラッド

[supermathie (Michael Brown)]

@BradCray

あるいは、ホストされているサイトのそのフィールドに、法的住所は slug+...@discoursemail.com または ...@slug.discoursemail.com でなければならないことを示す簡単なツールチップがあれば、大いに役立つでしょう。

これは正しくありません。制約は、電子メールがこれらのアドレスのいずれかに配信されること（宛先であること）であり、機能することです。以下は、私たちや多くのお客様が使用しているセットアップの例です。

• （Discourse内で）postings@contoso.com に送信された受信メールを受け入れるように投稿カテゴリを設定する
• （contoso.com メールサーバーで）postings@contoso.com を {ANYTHING}@contoso.discoursemail.com に転送するように設定する
• 最終結果：postings@contoso.com 宛てのメールが投稿カテゴリに送信されます。

これは、以下と同等に機能します。

• （Discourse内で）postings@contoso.discoursemail.com 宛ての受信メールを受け入れるように投稿カテゴリを設定する
• 最終結果：postings@contoso.discoursemail.com 宛てのメールが投稿カテゴリに送信されます。

[BradCray (Brad Chamberlain)]

@supermathie — 配信先住所が宛先住所よりも関連性が高いというご指摘、もっともです。

以前のリクエストを修正すると、@discoursemail.com または @*.discoursemail.com パターンに一致する受信メールアドレスを入力しようとしたときに警告を表示することが、依然として有用だと考えられます。ただし、slug+… で始まらない、または @slug.discoursemail.com で終わらない場合に限ります。これは、Discourse がホストするコミュニティに関する警告となります。

これにより、最初のケース（discoursemail.com が接尾辞として含まれていないため）は引き続き許可されます。一方で、私が常に使用し、メールがサイレントに破棄されたときに混乱したパターンの slug-users@discouresmail.com アドレスを設定しようとした場合に警告が表示されます。

（contoso がコミュニティのスラッグであると仮定すると、2番目のケースでも警告は生成されません）。

-Brad