WordPress 4.6でmailが届かないときは投稿更新と送信経路を分けて確認する

WordPressを更新したあとにmailが届かない場合、更新したことだけを原因と決めません。投稿の保存、問い合わせformの送信、WordPressからmailを渡す処理、server側の送信、受信boxでの受け取りは別の段階です。どこまで動いているかを分けると、元へ戻す判断と問い合わせへの対応を急げます。

WordPress 4.6には、一部のserver configurationでmailが送信されない既知の問題が案内されています。これは、すべての4.6 siteでmailが止まるという意味ではありません。更新後に問い合わせmailが届かないと分かったら、投稿編集の画面だけを見ず、実際のformからtest送信して経路を確認します。

mailが届かないという連絡には、二つの意味があります。送信した人が完了画面を見られなかった場合と、送信した人は完了画面を見たが受ける側へ通知が届かなかった場合です。前者はformの入力や送信処理を確かめます。後者は送信の記録、server、受信boxを確かめます。同じ「届かない」でも、最初に見る場所が違います。

保存、送信、受信を別の段階として確認する

mail不達の確認は、次のように分けます。

説明用の仮例として、更新した翌日に問い合わせformからのmailが届かない場合を考えます。記事の投稿や管理画面の更新ができていても、formの送信、serverのmail処理、受信boxのどこで止まったかは分かりません。test用のaddressからformを送信し、完了画面、送信log、受信boxを同じ時刻で照合します。

testは、普段の問い合わせと区別できる内容で行います。件名や本文にtestであることと送信時刻を書き、実在の顧客情報やpasswordを入れません。送信した人、使ったbrowser、送信page、入力したaddressを残すと、受信側で探すときに役立ちます。完了画面の表示だけを記録して、受信boxを確認しない状態にしません。

問い合わせformが送信後に画面を切り替える場合は、移動先も確認します。送信buttonを押した直後にtop pageへ戻るなら、送信が成功したのか失敗したのか利用者は分かりません。errorが出るなら、どの項目を直すか読めるかを見ます。formが表示されること、入力を受け付けること、送信結果が分かること、通知が届くことを一段階ずつ分けます。

受信boxでは、受信トレイだけでなく迷惑mailの扱いも確認します。test mailがserverから出ていても、指定addressの受信箱で別の場所へ振り分けられることがあります。受信側の設定を変える前に、送信日時、宛先、件名で探します。受信boxへ届かないからといって、WordPressやform pluginの設定だけを先に直しません。

複数の宛先へ通知するformでは、どの宛先に届かないかも分けます。代表addressには届くが担当者のaddressには届かないなら、formの送信と担当者側の受信を同じ障害として扱えません。問い合わせの控えを送信者へ返す設定があるなら、事業側への通知と送信者への控えも別に確認します。誰に何が届く設計かを紙に書いてからtestします。

問い合わせを止めない順で切り分ける

原因を調べる間も、利用者からの連絡を受けられる状態を考えます。原因の調査に時間がかかるときは、formを開いた人が連絡できないまま待たされないようにします。電話、別のmail address、営業時間の案内など、用意している連絡手段のうち実際に受けられるものを選びます。動いているか確認していない代替手段を、画面へ追加して終わりにしません。

1. formの送信を一度testし、完了画面を確認する。
2. 送信日時、宛先、入力内容を記録する。
3. WordPress、form plugin、serverのerror表示やlogを確認する。
4. 受信boxと迷惑mailを確認する。
5. 復旧までの連絡手段をsiteへ示す必要があるか判断する。

説明用の仮例として、formの完了画面は出るが受信boxに通知が届かない場合を考えます。まず、testの送信時刻と宛先を確認します。次に、form pluginやWordPressがerrorを出しているか、serverの記録を確認できるかを見ます。serverでの送信が確認できるなら受信側の扱いを確認し、送信が確認できないならWordPressとserverの経路を調べます。更新を戻す判断は、この順に確認してから行います。

復旧までの案内を出す場合は、formが使えないことだけを書いて終わりにしません。電話で受けられるなら受付時間を示し、別のaddressへ送ってほしいならそのaddressをtestしてから示します。問い合わせの内容をSNSへ送るよう求める場合も、誰が確認するか、個人情報を受ける場所として適切かを別に考えます。代替手段は、読者にとって実際に連絡できる入口でなければなりません。

passwordや顧客の個人情報を含むtestは行いません。test用の内容を使い、logを外部へ渡すときも必要な範囲だけにします。logには送信者や受信者のaddress、IP address、本文が含まれる場合があります。制作会社やserver会社へ渡す前に、原因の確認に必要な時刻、error、対象formを選びます。更新前へ戻すか、server側の設定を調べるかは、確認した段階を基に決めます。

更新前へ戻してmailが届くようになった場合も、それだけで原因がWordPress本体にあると断定しません。戻したことでpluginやthemeとの組み合わせ、serverとのやり取り、cacheの状態が変わることがあります。戻した日時、戻した対象、test結果を残し、次に更新するときに同じ経路を確認します。復旧できたことと、原因を説明できることは別です。

更新作業とmailの運用責任を分ける

更新やserver調査を外部へ頼めます。しかし、問い合わせを受けるaddress、受信確認をする人、障害時の代替連絡手段、logを共有する範囲は事業側で決めます。更新を実行することと、問い合わせを受けられることを保証することは別です。保守担当者がserverを調べる間に、誰が問い合わせの有無を確認するかも決めます。

外部へ頼むときは、更新日時、WordPressのversion、formのURL、testの時刻、完了画面の結果、宛先、受信boxの結果、見えたerrorを渡します。保守担当者は、WordPress、form plugin、serverのどこまで確認したかを返します。事業側は、問い合わせの対応と代替連絡先を管理します。情報を一度に全部渡すより、経路ごとの結果を分けた方が、余計な個人情報を共有せず原因を追えます。

最初の一手は、問い合わせformについて、送信page、完了画面、宛先、test日時、受信確認者、代替連絡先を一枚にまとめることです。testでは、送信、完了画面、送信記録、受信boxを順に確認します。不達が起きたときに、更新とmailを混ぜずに確認できます。WordPress 4.6の既知の問題を見たときも、siteの問い合わせ経路を実際にたどってから判断します。