電子メールが重要な情報交換ツールとなって久しい。 そうした中、2022年春にGmailがなりすましメール対策として セキュリティレベルを変更したことに伴い、Gmailに届くメールの一部が 受け取りの拒否に遭い、送信元に不達メールとして戻される事態が起きている。 残念なことに拒否されたメールの中にはなりすましメールではないものも 多数含まれており、Gmail利用者として不便を感じている。 本文書はこれへの対応を、検討した方策と共に記録したものである。
- 電子メールというもの
今や電子メールは研究者同士の意見交換には必須のアイテムとなっている。 国内に限らず世界中何処にでも瞬時に届き、返信を期待できる。 かつてのような郵便でのやり取りとは比較にならない即時性があるだけでなく、 電子情報に限られるという制約はあるものの流通する情報量も格段に増えた。当初の電子メールはメールサーバーの管理とセットで運用されていることが多く、 複数のメールアドレスを保持できるのは、管理者の特権と言える部分もあったが、 有用性が認識されるに従って、電子メールアドレスを無料で確保できる サービスも出現し、20世紀末期に出現した AOLやHotmail、Yahoo! がその嚆矢であったように思う。 後発組と言えるGoogle社のGmailは2004年にサービスを開始し、 今や世界中を席巻している。 当初いぶかしがっていた私もこのGmailの自由さ、柔軟性に魅力を感じ 現在では大いに利用させていただいている。 その利用方法は人によって様々であろうが、複数のGmailアドレスを 工夫して使っている人も少なくないであろう。 Gmailの魅力は何と言ってもその抜きん出た検索力にあるように思う。 受信した電子メールの中から指定した文字列を含むものを 即座に提示してくれ大いに重宝している。 SPAMの判定も適切で、溜め込める容量も大きく、これらサービスが全て無料で 利用できることも驚異的である。
私個人の経験を振り返れば、 1993年には電子メールを使っていた記憶がある。当時は Sun というワークステーション上に自分で電子メールアドレスを作成し、 システム内蔵のメールプログラムを使って読み書きをしていた。 それ以前はパソコン通信(PC-VAN, Nifty Serve等)と称されるネットワークで連絡を 取ったり、掲示板を運用していたりしていた。 離れた場所の知人に一瞬で連絡が取れることが不思議であり有用でもあった。 メールサーバーが有機的にリンクしていて、個々人が発した電子メールが バケツリレー式にメールサーバー間を移動し、最終的に目的の相手に届けられるという 仕組みは面白いとも感じた。
時は流れ、現在では電子メールでのやり取りが普通になり、連絡を取り合う道具として 必須の道具立てに成長しインフラの一翼を担っていることは疑いのない事実であろう。 実際、サーバートラブル等で電子メールが届かない事態に陥ると、 変に不安を感じるようにもなってしまった。
- 私の運用方法
メール文の作成には一定程度広い画面とキーボードを用いたいという嗜好から、 送信にはパソコン(PC)を利用しているが、一方、受信に関しては閲覧だけなので、 時刻・場所を問わず適宜確認したいとの希望から、携帯端末を利用してきた。 特にPHS(Personal Handy-Phone System)は優秀で、端末が小さいにも関わらず、 本来の目的である通話に加えて電子メールもやり取りでき、 バッテリーの持ちも良かったので、電子メールの閲覧には大いに活躍してくれた。しかし、3G 回線の終了と共に、PHS のサービスも終焉を迎え、 否応なく4G回線への移行を求められた。多くの人はスマートフォン(スマホ)に 移行したようだが、スマホは画面が大きく読み易くなることは利点と思うが、 ポケットに入るサイズではなく、常時携えておくには不向きである。 加えてバッテリーの持ちもさほど良くない。
仕方がないので、通話と電子メールの閲覧の機能は分離することにし、 前者の目的には PHS 時と同様のストレート形状のケータイ(セイコー製 Simply) を持つことにした。 とは言え、筐体は胸ポケットには収まるものの、PHS より一回り以上大きく・重くなり、 しかもバッテリー消費もPHS と比較すると激しい。OS が Android なので、技術的には 電子メールのやり取りも可能ではあるのだが、そのためには追加料金も発生する。 通話が第一目的ということと、閲覧のためだけに追加料金を払うことには 納得が行かなかった。ということで、電子メールの閲覧にはケータイの利用を諦め、 スマホ上のGmail アプリを利用することにした。ということで、私の生活において、電子メールはPC から送信し、 スマホで閲覧するというスタイルとなっている。
SPAM判定にも定評のあったGmailであるが、2022年春になって「なりすましメール」の 排除に乗り出したようである。その根幹部分の技術的手法を正確には 理解できていないのだが、 メールヘッダー内のSPF(Sender Policy Framework)フィールドの指定が 適切でないと判断した場合は「なりすましメール」と認定され、 Gmailは受信を拒否して、その旨を付した「不達メール」を発信者に返しており、 そのメール本文には「550-5.7.26エラー」と表示される。
この状況は少なくとも2つの点で困った事態を引き起こしていると感じている。 1つ目は受信拒否となった電子メールが存在したことを、Gmail利用者には 通知されないため、このような事象が発生していることを認識できないことである。 多くの電子メールは問題なく受信できていることから、 トラブルなく運用できているものと思い込んでしまい、対策を立てようという 動機付けが起きない。2つ目は不達メールに表示される送信元メールアドレスが Gmailのものとなっていることである。元々の電子メールの発信者は 受信者の(職場等の)電子メールアドレス宛に送信するのだが、 受信者個人が私的に指定したGmailのアドレスから「不達メール」が返却されてくる ことになる。受信者は発信者に予告することなくプライベートのGmailアドレスに 転送しているため、発信者の知らないGmailアドレスから通知が送られてくることになり 状況を理解し辛い。送信した電子メールが相手に届いていないのかと不安にもなる。 加えて、受信者が私的に設定しているGmailアドレスを 発信者に知られてしまうことにもなっている。
なお、このSPFフィールドの適正な指定には、電子メール送信者の メールサーバー側で設定する必要があるため、 受信者側で何らかの手を打てるわけではなさそうである。 加えてメールサーバーの設定は管理者が行うことになるため、 送信者個人で何らかの対策を講じることができない場合も多いと思われる。
受信者の取れる一つの方策としては、受信拒否に遭った発信者の電子メールアドレスを その都度「迷惑メールにしない」という指定をしてGmailのフィルターに 登録し続けることであるが、前述のようにGmail利用者には どの電子メールアドレスが受信拒否に遭ったかを知る手立てがないので、 送信者からの申し出が有った場合に限られ、即時性は期待できない。 もしくは、職場に届いた電子メールとGmailで受信できたもとのと差分を取ることで 把握することも可能ではあるが、両者を日々比較するのは労力が大きく 率先して行いたい作業とも思えない。
加えて厄介に感じていることとして、同じ電子メールサーバーからの電子メールでも、 時刻に依っては受信拒否されているものがあるように思われ、 再現性に欠けるように感じている。 Googleが設定に少しずつ手を加えているのかもしれない。
ここからは雑感であり、私の誤解も入っていると思われるが、 SPFフィールドが不完全であり、ルールに則らない電子メールが 多数流通している段階で、厳格なルールを適用しようとすると、 受け取れなくなる電子メールが一定程度発生することは自明であろう。 Google社がなりすましメールの根絶に乗り出したことは評価するが、 このような困った状況を各地で引き起こしていることを考えると、 現状に即した導入も有り得たのではないか。 このようなルールに則らないサーバーの根絶を狙って導入したものなのか Google の真意は判らない。ただ、困惑しているユーザーが相当数出現しているのは 事実であろう。
スマホのアプリをGmailからOutlook に替えて閲覧するという手もあるが、 後々検索することを考えると、これまで通り職場に届く電子メールは 今後も継続的にGmailにプールし続け閲覧したいと考える。 送信者のメールサーバー管理者にいちいち連絡を取るのは 現実的ではないし、受信側のメールサーバーに手を加えることも 末端の電子メールユーザーからは困難である。
そのために幾つか思案・試行して、 現実的で実効性のある方策を見い出した(ような)ので、ここに記録しておく。
- Outlook の転送機能を利用して実現する方法
(お急ぎの場合、本節は読み飛ばしてください)
Gmail に転送すると受信拒否が起こるようなので、その手前に別のメールサーバーを 設置して、そこを経由して転送することを考えた。- ルーティングの変更
説明を解り易くするために、電子メールの配信経路を以下のように模式化して示し、 これに基づいて説明する。【これまで】 発信元 ==> 職場 ==> Gmail_1
【これから】 発信元 ==> 職場 ==> Outlook(旧Hotmail) ==[転送(3手法)]==> Gmail_1
==> Gmail_2 (現状の確認用)これまでは、職場に届いた電子メールを直接Gmailに転送していたが、 これでは受信拒否に遭遇することが判ったので、 間に一つ別の電子メールサーバーを仲介させることを考えた。 この介在させるメールサーバーはGmail以外であれば何でも良いのだが、 たまたま過去にHotmai(現Outlook)のフリーメールアドレスを確保していたので、 これを活用することにした。 また、現状を再現し続けるために、確認用に新たにGmail_2を準備し、 そこにも転送しておく。
このようなルーティングを構成することにより、Outlookに届いているものと、 Gmail_2に届いたものとの差分を取ることによって、 受信拒否に遭った電子メールを把握することが可能となる (正確には職場のサーバーで受信したものとの差分でも可能である)。
- Outlookの設定
Outlookからの配信には、「(単純な)一括転送」以外に、 「ルールに基づいた転送」が用意されており、これにも「リダイレクト」と 「転送」の2通りが用意されている。 これら3手法が内部的にどういう手続きで実装されているかは類推するしかないのだが、 手始めに「(単純な)一括転送」を指定して配信させたところ、 この設定が不規則に解除される現象に見舞われた。 正確なところは解らないのだが、Gmail_1からエラーメールが返ってくると、 転送設定が自動的に解除される仕組みになっているようにも思われた (同様のことに言及したWebページあり)。 その度に毎回手動で転送設定を復旧させることを試みてみたものの (何時解除されたかは判らない)、確実性・継続性に欠けると判断し、 もう一方の転送方法である「ルールに基づいた転送」に切り替えた。 準備するルールは「全てのメール」を対象とし、 「指定のアドレスにリダイレクト」する方法と、 「指定のアドレスに転送」する方法の二通りで転送する手続きを準備した。 よって、現状では2通ずつGmail_1には配信されるようになっている。このように設定した場合、前者の「リダイレクト」では、Gmail_1側に届いた 発信者のメールアドレスの横に「経由」と表示され、 また、後者の「転送」ではSubjectの先頭に「FW:」との文字列が追加され、 加えてGmail_1で受け取った電子メールの発信者がHotmailになっている。 見た目では前者の方が好ましいと思えるのだが、 「不達メール」になった場合のことを考えると、 後者であれば不達メールがHotmailに通知され、 元の発信者には返っていかないのではないかと期待している。
と、ここまでの設定で運用していたところ、「ルールに基づいた転送」においても 勝手に解除される事態に見舞われた。具体的にはルールを有効/無効にする スライドスイッチが勝手に無効側に戻されていた。 「(単純な)一括転送」を用いた時にも感じたが、利用者が陽に指定しているものを システム側で何のワーニングも表示せずに勝手に解除することは理解に苦しむのだが、 現状でそのような動作をすることも事実なので、 これに対しても何らかの対策を立てる必要がある。 調べてみると、ログインを2段階認証にするとこのような現象は起きなくなると 説明したWeb ページがあったので、モノは試しと2段階認証を導入し、 現在様子を見ているところである。
ちなみに、2段階認証にすると「(単純な)一括転送」も安定するかと期待したが、 残念ながらこれは早々に & 勝手に解除されてしまった。何れにしても、3つのうちの1つでも期待通りの動作を実現してくれれば ありがたいと考えている。しかし、Outlook(旧Hotmail)が依然として 不安定な動作をするのであれば、Outlook を諦めて、 他のフリーメールを介在させることに変更することを検討する方が 近道なのかもしれない。 ちなみに、AOL は現在もサービスを続けているものの、 AOL 自身には転送機能が実装されていないようであるが、 Gmail 側から POP で読み出すことで転送を実現できるようである。
【参考】2通りの「ルールに基づいた転送」の設定画面(緑の枠囲み内)
- 簡単なメモ
「指定のアドレスに転送」のルールに基づいて転送された電子メールの Subject には、元の電子メールのSubjectの前に「FW:」が加えられ、 元の電子メールに加工が施されるため、気にならないわけではないが、 こちらの方が確実に届けられるように思われる。
前日には問題なく転送出来ていた某メールサーバーからの電子メールが、 翌日には「指定のアドレスにリダイレクト」では配信されない事例に遭遇した。 今回、Google は転送処理されたメールの扱いについて問題にしているようにも 思われるので、リダイレクトの場合は、正に転送メールとして取り扱われ、 場合によっては受信拒否の判定を下される可能性があるが、 「指定のアドレスに転送」の場合は、発信元がHotmail のアドレスに替わっている ことからも、Hotmailから改めて発信された電子メールと見なされ、 Gmail の今回の対象からは外れるのではないかと想像している。あくまでも私見。 - 【参考にしたWebサイト】
- Outlookメールの転送設定が勝手に解除される問題
- メールのルールの設定が勝手に解除されている
- 【Outlook】受信メールを他のメールアドレスに自動転送する設定方法
- Gmailへ転送時に「550-5.7.26」エラーが返るならSPFの設定を！
- メールの転送設定が勝手に解除されます
- Gmailへ配信されない現象はSPFレコードを追加して回避する
- Gmail宛に550-5.7.26エラーで送信できない。
- Gmailでメールドメインの受信設定をする方法
- gmail宛に送れない！送信できないエラー！550-5.7.26 authentication fails
- gmailにメールを送れなくなった件（解決）
- メーラーからGmailへの接続時に認証（パスワード）のエラーが生じる場合の対処方法
- 試行した結果
原因は判らないが、2段階認証を導入しても、依然として「(単純な)一括転送」も、 2通りの「ルールに基づいた転送」も勝手に解除されてしまう現象を 止めることができない。到着する電子メールの頻度にも拠るのだろうが 12時間も持たない感じ。これでは実用に耐えられない。 想像だが、この「勝手に解除」を阻止することができれば、 目的の環境を手に入れることができると思われるが、 設定が意図せず解除されるようではどうしようもない。
ということで、今回はこの方法での実現を諦めることにする。非常に残念だ。
- ルーティングの変更
- Gmailify を利用して実現する方法
前項のOutlookの転送機能が不安定なので、別の手法も模索した。 いろいろと調べた結果、2016年にGmailに導入された「Gmailify」機能を使って 電子メールを共有するのが良さそうだと気付いたので試してみた。- ルーティングの変更
説明を解り易くするために、電子メールの配信経路を以下のように模式化して示し、 これに基づいて説明する。【これまで】 発信元 ==> 職場 ==> Gmail_1
【これから】 発信元 ==> 職場 ==> AOL <--<Gmailify>-- Gmail_1
==> Gmail_2 (現状の確認用)これまでは、職場に届いた電子メールを直接Gmailに転送していたが、 これでは受信拒否に遭遇することが判ったので、 間に一つ別の電子メールサーバーを仲介させることを考えた。 この介在させるメールサーバーはGmail以外であれば何でも良いのだが、 今回この目的のためにAOL のメールアドレスを取得し、ここに据えた。 また、現状を再現し続けるために、確認用に新たにGmail_2を準備し、 そこにも転送しておく。
このようなルーティングを構成することにより、AOLに届いているものと、 Gmail_2に届いたものとの差分を取ることによって、 受信拒否に遭った電子メールを把握することが可能となる (正確には職場のサーバーで受信したものとの差分でも可能である)。
なお、この前提として、AOL は送信されてきた電子メールを 全て受信出来ると仮定している。AOL の受信フォルダーに注視することで この判断ができるであろう。 - Gmailifyの設定
Gmail の機能であるGmailifyは、各社のフリーメールアドレスに届いた電子メールを Gmailで一括してハンドリングするためのもので、 例えば、AOLに届いたメールをGmailで読めるだけでなく、 AOLから発信したように装うこともできる。 いわば各社の電子メールを一括して管理するアプリのように動作する。当初、AOL からPOP3 を用いて電子メールを取り込む方法を試みたが、 AOL側からエラーが返され何故かうまく設定できなかったために、 次の一手として Gmailify を利用することにした。設定自身は簡単であり、 主には AOL のメールアドレス(ユーザーID)とパスワードを指定するだけであるが、 具体的には以下のサイトを参照されたい。
このGmailify でハンドリングできるフリーメールアドレスとしてはAOL以外に、 Outlookも含まれているので、AOLでの利用が安定していることが確認できた暁には、 Hotmail(現Outlook)に切り替えて試すことも考えている (前項のこともあり、現時点で Outlook に対する信頼性に疑問を感じているが)。 不思議なことにGmailify のことを記述したWeb サイトは余り多くないように感じるのは 何か原因があるのであろうか。
- 【参考にしたWebサイト】
- 「Gmailify」を使ってGmail以外のメールアドレスも管理しよう
- 他のメール アカウントで Gmail の機能を利用する
- Gmailアカウントで複数のメールをまとめて受信する その設定の仕方について
- 試行した結果(現在進行形)
一日弱経過した段階で、うまく機能しているように思われる。 正確なタイミングは判らないが、定期的に AOL 側を読みに行っているようで、 ほとんど遅延なくGmail 側に反映される。 一応これで目的の環境が手に入れられていると言えるであろう。
今後、もう少し様子を見る必要はあるが、しばらく運用してみて、 安定しているようなら、AOL に代えて Outlook(旧Hotmail)のアドレスを指定して 同様のことが実現できるか試してみる予定である。 - 現時点での帰着点 (現在運用中)
このGmailify を用いて構築してみたところ、 「これまで通りGmailに集約できていること」、および 「不達エラーは起こっていないこと」が確認できた。 そこで、今度はAOLに代えて Outlook(旧Hotmail)のアドレスを指定して 同様のことが実現できるか試したところ、これもうまく機能した。 つまり、AOLでもOutlookでも私の目的には差異はなかった。 最終的にどちらを利用するかは好みの問題であるが、今回はOutlookを使うことにして、 現時点のルーティングは以下の通りとなっている。【これまで】 発信元 ==> 職場 ==> Gmail_1
【これから】 発信元 ==> 職場 ==> Hotmail <--<Gmailify>-- Gmail_1
【参考】変更前後の電子メール配信ルーティング
2週間程度運用した感触として、これまで職場に届いた電子メールは Gmail_1にもほぼ同時に届けられていたが、 今回の変更で、やや到着までに時間を要する(最長で5分程度か?)ようになった。 しかし、確実に届けられており、不達トラブルも発生しておらず、 主目的であるGmail_1に到着電子メールを集約することが実現できている。 そもそもGmailに集約するのは将来の検索のためであるので、 多少の到着遅れは問題にならない。
今回の試行から解ったことは、終端のアドレスをGmailにすることを止めて、 代わりにOutlook(やAOL)に変更し、そこからの読み出しをGmailifyに任せれば 回避できるようだということである。
なお、ここまで言及してこなかったが、実は、学会等のメーリングリスト(ML)に 登録している電子メールアドレスは、職場のものではなく、これを目的として確保した Gmailアドレスである(上図ではGmail_MLと表記)。 このように分離して運用している理由は、職場のメールアドレスが変更になった際に、 個々のMLの登録をそれぞれ変更する手間を省くためである。この方法を用いれば、 Gmail_MLに設定している転送電子メールアドレスを修正するだけで 全てのMLが新しいアドレスに配信されるように修正できて好都合だからである。
また、今回の一連の作業の過程で判明したことだが、従来のGmail_1を終端とする ルーティングを行っていた場合、MLに不達メールが返される際に Gmail_MLにもその痕跡が残っていた(当初見落としていた)。 そこで過去に遡って調べてみたところ、 私の場合、最初に不達メールが発生したのは4月14日9:00であり、 その後、15件/月程度の頻度で発生していた。 終端をOutlook(やAOL)に変更してからは、不達トラブルは発生していない。
この方策が今後もうまく機能するかは誰にも判らないであろう。 Gmailify というGoogleの機能を利用させてもらっていることから、 再度Googleが何らかの改定を実施した場合に影響を受ける可能性は 依然として孕んだままである。その意味で不確定性は残ってはいるが、 便利に利用させてもらえる間は、ご厚意に甘えて活用していこうと考えている。
- ルーティングの変更
今回、Gmail の仕様変更に起因する不具合を解消するために、 幾つか方策を検討・試行した。 根本的な解決には、以前の仕様に戻してもらうことを希望したいが、 無料で利用させてもらっているサービスにこのような要求を行うことは不可能であり、 末端の利用者としては現状を受け入れて、対応策に勤しむしかないのであろう。
今回は職場の電子メールの転送に関する不具合であり、実害が大きかったため、 積極的に策を講じようと腐心したが、 これ以外にも幾つか転送機能を用いて実現している電子メール環境があり、 それらでも同様の不具合が生じている可能性がある。 それぞれを一つずつ確認する必要があるものの、 この種の電子メール環境の構築の際に直面する課題として、 多くは発信者からの電子メールを受けての対応を検討するものであり、 自らがサンプルメールを発して試すことが難しいため、 その探求には相当に時間と労力を要する。 勢い実害が発覚するまでは放置するしかないように思われる。
今回の方策が以前の環境を取り戻す一助となることを願っている。