Mailjetでの認証を試行中。txtファイルまたはDNSエントリが必要

はい、Mailjet を SMTP として使用しているのですが、バリデーションで問題にぶつかっています。まず、noreply@discourse.example.com という個別のメールアドレスを簡単にバリデーションできません。

できれば discourse.example.com というドメイン全体をバリデーションしたいのですが、ここで 2 つの問題に直面します。特別な名前のテキストファイルを使ってこの処理は可能ですが、Discourse はこれを許可していないようです(とはいえ、その URL に対して何かを返すように nginx 設定ファイルを変更しようかと考えています)。では、DNS の TXT レコードはどうでしょうか?ここでまた問題が発生します。example.com の DNS を管理しているのですが、Mailjet からは essentially mailjet.discourse.example.com というサブドメインに対するエントリを追加するよう求められています。このサブドメインへのエントリをどう追加すればよいのか明確ではありません。私は Ubuntu 16.04 上で BIND 9.3 前後を運用しており、いくつかのヒントがあると助かります。discourse.example.com に対する TXT レコードの追加方法については情報が見つかるのですが、Mailjet からは「そんなことは構わない、mailjet_xxxxx.discourse.example.com である必要がある」と言われています。つまり、これはサブネット(おそらくサブドメイン)を意味し、追加のゾーンが必要になるのでしょう。私は DNS の達人ではありませんが、複雑なシステムのインストールはそれなりに得意です。

しかし今、いろいろな方法を試して混乱しています。だから…助けてください?つまり、最善のニュースとしては、「もちろん、Discourse のルートディレクトリにこのようなテキストファイルを置けばいいのです」と言ってくれることでしょう。:frowning:

ドメインレジストラーまたはDNSマネージャーをご存知ですか?

レジストラーが提供するDNSマネージャーでDNSエントリを作成する必要があります。Cloudflareなどのサービスを使用している場合は、そちらでDNSレコードを作成する必要があります。

最近、この問題が発生しました。以下で解決しました:

OK、Discourse の「制限」があっても、TXT 検証方法が動作するようになりました。DNS 設定をいじるのが苦手な方(私にとって DNS 設定は、Web サーバーをいじるよりもずっと怖いですが、もちろん人それぞれです)にはおすすめです。

Discourse のインストール環境で nginx 設定ファイルを編集できる必要があります。そのファイルの場所は、Discourse をどこに、どのような方法でインストールしたかによって異なります。私の場合は Docker を使わずにベアメタルインストールしたので、/etc/nginx/conf.d/discourse.conf にあります。あなたの環境では異なるかもしれません。

そのファイルには以下のような location ブロックが含まれています。

 location / {
     ....
 }

さらに、その中に複数のネストされた location 指示も含まれています。

ここに新しい location ブロックを追加してください(他の location の中にネストさせないでください)。

location /stupidfilename.txt {
   alias /var/www/stupidfilename.txt;
}

ここで「stupidfilename.txt」は、検証のために追加を求められたファイル名です。また、パス(/var/www)は Discourse のデータとは別にあり、サーバー上で URL としてアクセス可能な場所にある必要があります。この設定が機能するのは、/ が Discourse のルートになるため、URL は http://discourse.example.com/stupidfilename.txt のように Discourse の下にあるように見えるからです(リンクが誤って生成されないよう、スペースを入れています)。

つまり、Discourse の外にファイルを置き、location でそれをエイリアスとして設定し、nginx を再起動するだけです。

できました!

(この回答を解決策としてマークした後、読みやすさなどを考慮して編集しました)

TXT レコードの作成は、Docker 内で公開可能なファイルを作成することに比べれば、朝飯前です。