この記事は、少し古いです。代わりに以下の記事をご覧ください。この記事は、参考資料として「Appendix」を保存するために、このまま維持することにしました。 代わりの記事では、2020/09の時点において、Synology NASに立ち上げているWordPressから、外にメールを送れるように、「WP Mail SMTP by WPForms」プラグインとGMAIL APIを使って可能にする内容です(2020/09/13)。
概要
メール送信の手段は、以下のとおり2つある。
1. SMTPにるメール発信
このSMTPとは、WordPressが導入されてるいサーバーで可動しているSMTPである。SynologyもGoogleのgmailの仕様が変更されたことで、少し混乱しているかもしれない。サイトに行っても解決策が古かったりしているので、今、現在は、どうなのか不明だ。
現状では、SMTPを使用したサイト外への発信は断念した。そもそも、Synology NASのSMTPからWordPressのメールを飛ばせるのかどうかすら、よく理解できていない。
SMTPを使用する場合、DNSの設定とMailPlus Severの設定をそれぞれ整合させなければならないと思われるが、DNSの設定については、以下で述べているように、なかなかハードルが高く僕の技術と知識レベルでは、現状断念せざるを得なかった。
2. PHPによるメール発信
色々調べていく過程で、WordPressのプラグインを使用して、その基本プログラム言語であるPHPからメール配信をコントールできることが分かった。まず、最初に試した”WP mail SMTP by WPForms”は、配信の成否が分かるものの、配信できない場合の解決策を提案してくれなかった。
Synology: WordPress not Sending Emails (Solved)
そこで、次に試した”Post SMTP Mailer/Email Log”は、GmailアカウントとGoogle API consoleの設定により、メールをWordPress(厳密にはPHP)からサイト外に発信できるようにするプラグイン (作者: Yehuda Hassineさん)。これを使って、且つ、blogにある設定方法:“How to Set up and Configure Postman SMTP on WordPress”に従い設定を進めてた。
その結果、サイト外へのメール発信がこれまでできなかったが、無事に発信できるようになった。
3. 設定方法
基本的には、同設定方法に従えばよい。Google API Consoleの体裁が若干の変更があり混乱するが、図1のように、設定する項目は、左側のタグのように、後ほど確認できる。設定し忘れても、このページに戻ってから設定すれば問題ない。以下に、Google API Consoleでの作業における特記事項を示す
- ドメイン(harikiri.diskstation.me)の承認には、Google API Consoleでの作業でダウンロードしたhtmlファイルを、Google API Consoleが指定する、ドメインにコピペする
- クライアントIDとクライアント シークレットを、当該プラグインの入力領域にコピペすれば良い。
設定項目は、以下の図のようなタグ(左側)がある。
今回の作業で全体として分かったこと
- Synology NASのメールシステム(SMTP)を使用できるようにするには、DNSの設定が完全でないといけない。
- DNSの設定の検証には、MX TOOLBOXを使用できる。このツールは、Synologyサイトにも使用の記載があり、DNS, SMTP, MXなどをはじめ、サイトにおける多数のサーバーの設定の適切性を調べてくれる。
- DNSの設定には、A RECORD, NS RECORDに加えて、メール配信に関わるMX RECORDの正しい記載が必要である。
- 更に、近年のSPAMメール対策のために、多数の認証方法が取られており、SPF RECORDについても正しい記述が必要である。
- 以上のように、SMTPを使えるまでには、まだ、知識・技術が不足している。今後の自助努力によるSMTPの設定の完了に期待する。時期バージョンのDSMにも期待。
編集履歴 2019/12/14 はりきり(Mr) 2020/09/13 修正 (新しいくプラグインを変更したので、その記事への誘導、この記事は、Appendixほ保存するために、このまま維持する)
Appendix
- 以下は、SMTPを正常に稼働させるセッティングのために集めた情報
- Synologyサイトの解説では目的達成不可
- 以下のサイトでは、自分宛の通知メールの設定であるため、今回の目的は達成できない
1. 目的
DSM 6.2.2-24922 Update 2 以降のバージョンを使用しているユーザーで、次の目的でメールを送信する場合は、下の手順に従って SMTP サーバー設定を行う必要があります。
- 個人通知を送信します。
- ssmtp バイナリを使用して、タスク スケジューラでユーザー定義のスクリプトを実行するなどの電子メールを送信する。
- Web Station を使用して Web サイトを構築し、PHP を使用して電子メールを送信する。これには、他社製 Web サイトパッケージ (WordPress、MantisBTなど) からの電子メールの送信も含まれます → 手順に進む
- Photo Station の写真や記事に誰がコメントを残した場合にメール通知を送信する。
2. 手順
- Google アカウントへのアクセスを許可する
- Gmail SMTP サーバーを設定する
- 注) Googleのマイアカウントで、セキュリティの低いアプリのアクセスを許可する必要があります。
DNSの記述
Aレコード
- ドメイン -> IP Address
- メール配信に関わらない
NSレコード (ネームサーバー レコード)
MXレコード (メールエクスチェンジ レコード)
- ドメイン -> メール配信先
- user@harkiri.diskstation.meにメールが来たとすると、DNSの記述の一般設定は以下の通り
- harikiri.diskstation.me. IN MX 10 mail.harikiri.diskstation.me
- mail.harikiri.diskstation.meは、メールサーバー(mail server)
- メールサーバーは複数設定可能。その時の転送優先順位は、前述の記述では、10となっている。
MXレコード -> Aレコードで1組の設定
- MXレコードに対応するAレコードは以下の通り
- [mail.harikiri.diskstation.me -(A)-> 192.168.xx.xx]
NS RECORDからA RECORDで1組
- harikiri.diskstation.me -(NS)-> ns.harikiri.diskstation.me
- ns.harikiri.diskstation.me -(A)-> 192.168.xxx.xxx.
CNAME REDORDからA RECORD
- www.harikiri.diskstation.me -(CNAME)-> ns.harikiri.diskstation.me
TXT RECORD (テキストレコード)
- コメント欄のレコード
- A RECORDに関連しているドメインの情報を記載
- 迷惑メール対策(*1)に使用されている
- (*1) SPF, DKIMの記載に使用される
SPF (Sender Policy Framework), 送信元のアドレス詐称によるSPAMメール対策、DNSのSPF Typeの記述の仕方について詳細な説明
- SMTPでのメール送受信で使われる送信ドメイン認証方式
- A siteのDNSにはSPF RECORDが登録されている
- 登録内容は、メール配信するメールサーバーのIP Address一覧。これがSPF RECORDである
- A siteからB siteにSMTPでメールを送ると、
- A siteからB siteにメールを配信
- Bは、AのDNSにSPF RECORDを問い合わせる
- Bは、SMTP接続アドレスとSPF RECORDを照合する。
- 認証成功なら、Bは、ドメインで配信する
- なりすましを回避できる
SPFの書き方
- TXT RECORDに記述する
- v=spf1 +MTA(*)リスト[半角スペース[同リスト]]… MTAリスト以外から送出された場合の判定all
- 具体例 : v=spf1 +mx –all
- 送出MTAは以下のように記述する。(+は省略可能)
- (*) mail transfer agent
MXを指定 | +mx |
IPアドレス指定 | +ip4:61.123.198.244 |
ネットワークID指定 | +ip4:61.123.198.240/29 |
- allの自己判定は、”-“, “~”および”?”の3つのステータスがある。
Fail | –all |
SoftFail | ~all |
Neutral | ?all |
- 受け取り側で、これらステータスをどう処理するかは、受信側のポリシーに任される。
- 自分のなりすましを絶対に許さないと希望するなら、
「Fail (-all)」
- JEAGは、移行措置としてSoftFailを使うことを容認しているが、Failを推奨すはる
Synology NAS to set up mail sever part 2
きちんと下準備!メール配信に欠かせない「DNS」「MX RECORD」とは? Aレコード、MXレコードがDNSと関連させて分かりやすく解説されている
Synology site, How to set up MailPlus Server on your Synology NAS MailPlus ServerのSet Upについての説明
SPAMHAUS スパムメールとしてIP Address/Host Nameが登録されている
MX TOOLBOX mail serverが正しく設定されているかどうか調べるサイト
その他ツール
Windows power shell コマンド
- nslookup, DNSの名前解決の状況を知るためのツール
- tracert, hostまでの経路を知るためのツール
- www.kakaku.comまでの経路を知るなど.
Domain Healthの結果
DMARC (Domain-based Message Authentication, Reporting, and Conformance)とは、 電子メールにおける送信ドメイン認証技術の一つであり、 RFC 7489で標準化されている。
SPF レコードの例 IP Addressによる記述、FQDNによる記述、MXからしなメールが外に出ない場合はMXを利用する記述
- example.org. IN TXT “v=spf1 a:mx01.example.org a:mx02.exmaple.org a:ns.example.org -all”
Dynu.comから無償のドメイン名を取得する方法 ホームネットワーク研究所より
今すぐチェック!迷惑メールと見なされないための15の対策(2017年10月度版)
参考
Dmarc Recordに関する詳細情報の公開
このDMARCレコードが見つかりませんというエラーが発生している場合、これはドメインに公開されているDMARCレコードがないことを意味します。 DMARCレコードは、DNSを介してテキスト(TXT)レコードとして公開されます。 それらは、受信サーバーに、ドメインから受信した非整列電子メールで何をすべきかを知らせます。
ドメインベースのメッセージ認証、レポート、および適合(DMARC)は、メール受信組織によるメール処理を改善するためのメカニズムです。 RFC-7489によると、DMARCの究極の目的は、「メールオペレーターが既存の認証およびポリシーアドバタイズメントテクノロジーを活用して、メッセージストリームフィードバックと認証されていないメールに対するポリシーの施行を可能にするメカニズムを提供することです。 メール発信元組織は、メッセージの検証、処理、およびレポートのドメインレベルの配布ポリシー/設定を表現するためにDMARCを利用します。
DMARCの仕組み:
DMARCの採用は劇的に増加しており、メールの配信性にプラスまたはマイナスの影響を与えています。 主要なメールプロバイダーはすべて、DMARCをサポートしています。 いくつかの手段により、世界中のメールボックスの80%がDMARCによって保護されています。
DMARCは、SPFとDKIMを劇的に改善します。
SPFおよびDKIM構成で実際の問題を監視、検出、修正します
受信トレイに配信しているメールの量を見る
ドメインを装った脅威のメールを特定します。 (なりすまし)
メールの配信を制御し、なりすまし攻撃から身を守ります。
どのように設定しますか?
DMARCを開始するのに数分しかかからず、すぐにメリットが得られます。 最初に行う必要があるのは、単純なDNSレコードを追加して、DMARCレポートを有効にすることです。 MxToolBoxでDMARCレポートを処理する場合は、このシンプルテキスト(TXT)レコードをドメインのDNSに追加するだけです。
メール配信を管理していますか?
メール配信は、メールサーバーを実行したり、ブラックリストを定期的にチェックしたりするだけではありません。 顧客が確実にメールを受け取るようにするには、SPF、DKIM、およびDMARCをセットアップする必要があります。 DMARCの設定とメールプロバイダーからの応答を管理していない場合、顧客がメールを受け取っているかどうかはわかりません。
MxToolboxは、メール配信の専門家です。 MxDelivery Centerは、DMARC、DKIM、およびSPFのセットアップと分析を支援し、電子メールの構成を変更して顧客に電子メールを送信するために必要な洞察を提供します。
SMTPバナーチェックの詳細
メールサーバーによって発行されたSMTPバナーに、サーバーのIPアドレスに対して解決したホスト名が含まれていませんでした。
追加情報
電子メールサーバーは、ポート25の接続に、サーバーと管理者が世界に伝えたい情報を通知することを目的とするSMTPバナーと呼ばれるテキスト文字列で応答します。
サーバーの名前をSMTPバナーに配置して、IPアドレスを介して接続するユーザーが誰と通信しているかを知ることがベストプラクティスです。 IPアドレスでPTRルックアップを実行するときに取得するホスト名と同じドメインにない名前を提示すると、この警告が表示されます。
しばらくの間、多くのサーバーは、ネットワーク外の人への文字をアスタリスクに置き換えることにより、SMTPバナーを「マスク」していました。 この背後にあるロジックは、多くの場合、サーバーに対する攻撃に役立つ情報を提供することを恐れて、ネットワークに関する情報を外部の人々にブロードキャストしたくないというものでした。 これを行うことの利点は最小限であり、多くのサーバーはスパム軽減の一部としてバナーチェックを実行するため、このプラクティスに関連するマイナスのコストがかかります。 バナーがマスクされている場合、ツールは警告を発行します。
一部の受信メールサーバーは、スコアリングシステムでスパムソースの可能性を示すために、不一致またはマスクされたバナーを使用する場合がありますが、ほとんどの場合、これだけで受信メールを拒否しません。
PTRレコードがない場合、またはレコードがホスト名と一致しない場合は、ISPに連絡し、メールサーバーのホスト名と一致するリバース(PTR)レコードのセットアップを依頼することをお勧めします。