GmailからエックスサーバへのSMTP接続がTLSエラーになる件

弊社のように、エックスサーバなど外部のメールアドレスをGmailで一括管理している方も多いはず。

ところが4月8日ころから、エックスサーバを介したメール送信が行えない事象が発生。その時点でエックスサーバで特に障害情報などは出ていませんでした。

送信後に以下のようなエラーが返ってきます。

証明書がマッチしないTLSネゴシエーションエラーのようです。Googleのコミュニティでも揉めてますね(笑)。

調べたら、早速詳しくまとめていただいている方がいました。

エックスサーバのSMTPサーバを調べると、証明書のドメイン名は「*.xserver.jp」(ワイルドカード)でしたので、各サーバに割り当てられているsvから始まるサーバ番号がわかればこのドメイン名が分かります。

例えば「sv1234」であれば、証明書のドメイン名「sv1234.xserver.jp」になります。

 

Gmailの設定で、SMTPサーバ名がこの「sv****.xserver.jp」でない場合は、この名前を指定してやれば解決です。

 

今見てみたら、エックスサーバのFAQにもそのように案内がありますね。(最近変わった?)

以上です。

【ECCUBE2】スパム対策としてお問合せフォームにreCaptchaを導入

定期的に中国から来る迷惑なお問合せフォームを利用したスパム。

スパムの一例↓

このように、メールアドレス欄に不特定多数のメールアドレスを指定し、自動返信機能を利用してメールを送り付けている。

今までは接続元IPを特定して、apacheの設定ファイルなり.htaccessで個別にアクセスを拒否するなど、対症療法をしていましたが、業務の負担になりつつあるので、導入することにしました。

結果として効果はかなりあったようで、対策後およそ1か月、未だスパムによる被害は1回もうけていません。

reCaptchaをECCUBE2のお問合せフォームに導入する手順は以下の通りです。

サイトキーとシークレットキーの取得

  1. reCaptchaにアクセスし「Admin console」を開きます。Googleアカウントが必要になります。
  2. 必要事項を入力し、サイトキーとシークレットキーを取得します。(今回は「」を採用します。)

テンプレートを修正

ECCUBE2のお問合せフォーム(確認画面)のテンプレートファイルを修正します。

スマホページも運用している場合はそちらのテンプレート(data/Smarty/templates/sphone/contact/confirm.tpl)も同様に修正します。

PHPファイルの修正

お問い合わせの受付・自動返信メール送信処理を行うPHPファイルを修正します。

確認

確認画面の右下に、以下のようなreCAPTCHAアイコンが表示されていれば、適用完了です。

 

参考サイト)

 

【ECCUBE2】外部からのPOSTでセッションが切れる件の対応

2020年4月に入ったあたりから、ECCUBE2を使用している内部サービスで、決済代行会社の決済画面から戻った際になぜかセッションが無効となり、ページ遷移エラーもしくは自動ログアウトしてしまう現象が発生。

原因は結果的に、chrome80からのCSRF(クロスサイトリクエストフォージェリ)対策として、Cookieセット時にSameSite属性が適切に指定されていない場合、外部からそのサイトにPOSTなどでアクセスされた際に発行されたサイトのCookieが強制的に無効になるという仕様によるものでした。(エンジニアが気づいた)

※なお、多くの混乱を招いたようで、直後のChromeアップデートで当仕様は取り急ぎロールバックされた模様

Googleからのアナウンスは、2019年11月には出ていた模様で、4月に入ったあたりから徐々にクライアントのChromeが80に強制アップデートされたようです。

現実に多くのショッピングサイトでは、決済時に決済代行会社の決済画面(特にリンクタイプ)で決済を行った後、処理結果受け取りのために決済完了画面からPOSTで戻って、パラメタを処理しています。

ECCUBE2のなどのカートシステムなどを利用している場合、大抵はページ遷移チェックがかかるため、この時決済画面に行く前のCookie情報が削除されていることから、セッション情報が判定できず、ログイン状態が無効となりセッションエラーもしくはログアウトという結果になります。

こういったサイトでは、対策として、

  • Cookie発行時に「SameSite=None; Secure」をセットする
  • httpsを利用する

ことで対応できます。

こちらに詳しくまとめていただいている方がいるので、適宜参照していただければと思います。

ECCUBE2のついては、すでにパッチが配布されていますで、ECCUBE2のサイト管理者は至急対応されることをおススメします。

なおこの配布パッチを充てると、具体的には、

  1. Cookieセット時に「SameSite=None;」を併せてセットする。この時、httpsなら「 Secure」を追加する
  2. SameSite=Noneが未対応のブラウザ用に、あらかじめ互換用のCookieを発行しておく。
  3. ECSESSIDが 現Cookieと対応しない場合は ECSESSID の Cookie が拒否されたと見なす
  4. 3の場合はあらかじめ発行しておいた互換用 cookie からセッションデータを読み込む

といった動作を行うようになります。

 

今回のアップデートについて、告知はされていたものの、もう少し具体的に影響を受ける対象事業者に対して大々的に告知してほしかったというのが正直なところ。

さらに言えば、決済代行会社も情報を早めに得て、影響を受ける顧客に周知するべきだったと思います。(リンクタイプを使っているクライアントはかなりいると思うし、、、)

うちが使っている決済代行会社は、通常結構この辺はきっちりしていて、こういう件が発生するときはかなり早めに連絡がくるのですが、今回に限ってはまったくもってノーマークだったように思います。念のため問い合わせたときに「特に障害情報は出ていません。どのような不具合でしょうか?」のような対応でしたからねー。