私の管理しているWebサイトのいくつかはGMO VPSで運用しています。運用方法については「GMO VPSを契約してWordPressを安定動作させるまでのサーバ設定方法」という投稿で解説しました。

そのGMO VPSでタイトルにある通りGmailへメールの送信ができなくなりました。同じ問題で悩まれている方も多いと思われるので、原因と対処法を紹介します。

目次

• 障害の内容と原因について（GMOとのやり取りを随時更新）
• Postfixを利用したリレーサーバの設定方法について
• GMO VPSのずさんなサービス
• メールサーバの信頼性と、Googleによる市場の寡占に関する問題
• Googleが公式に案内するメールがブロックされた際の対処法

---

障害の内容と原因について（GMOとのやり取りを随時更新）

障害の具体的な内容ですが、Gmailへメールを送信すると以下のようなエラーメッセージが返されてます。
（ドメインやIPなどは仮のもの）

This is the mail system at host mail.example.com.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own text from the attached returned message.

                   The mail system

<○○○○@gmail.com>: host gmail-smtp-in.l.google.com[0.0.0.0] said:
    550-5.7.1 [0.0.0.0] Our system has detected that this
    message is 550-5.7.1 likely suspicious due to the very low reputation of
    the sending IP 550-5.7.1 address. To best protect our users from spam, the
    message has been 550-5.7.1 blocked. Please visit 550 5.7.1
    https://support.google.com/mail/answer/188131 for more information.
    cj5si35192836plb.76 - gsmtp (in reply to end of DATA command)

このエラーメッセージは「メールを送信したIPアドレスの評判が低いためスパム認定しブロックしました」というものです。
通常こうしたメッセージを受け取ったら、スパムと認定されるに至った原因を探ります。

まずはスパム認定されるような心当たりがないか。例えば不特定多数へメールを送信していないか。メールを受け取ったユーザーが一定数以上迷惑メールに登録すれば評価は下がります。
そうした心当たりが無ければログを見て、外部からの不正なアクセスがないかを調べたり、メールサーバの設定が誤っていないか調べます。それでも改善しない場合はSPFやDKIMなど、最新のなりすまし対策を行い、スパム認定のしきい値を超えない努力をします。

ただし、今回の例ではそうした対策は無意味です。
「GMOに割り振られているIPが範囲ごとスパム認定されたことが原因」だからです。

「【不具合発生/ALTUS byGMO】一部メール送信不具合につきまして」というページに障害情報が掲載されています。
このURLは「ALTUS byGMO」のものですが、GMO VPSでも同じように障害が発生しています。

ざっくりと原因をまとめると、GMOの利用者が大量のスパムメールを送信。あまりにもひどいのでGMOに割り振られたIPが全てスパム認定。SPAMHAUSというブラックリストを管理する団体からGMOへ警告が来た。GMOの推察によるとこれが原因ではないか、とのこと。

なぜ推察なのかというとGmailのスパム認定は明確な基準が示されていないからです。そのため原因を特定する術がありません。原因がわからないので、復旧の目処も立っていません。解除されるまで年単位で時間がかかったり、永遠に解除されない可能性もあるということです。

障害情報のページにもありますが、GMOでは暫定的な解決策としてリレーサーバを用意しているようです。「ドメイン名やIPアドレス、ご利用のMTA」を添えて「https://support.gmocloud.com/ask/」から連絡をすることでリレーサーバの利用方法を解説してくれるとのこと。

以下、作業状況を随時更新していきます。

5/29　GoogleのフォーラムでGMOが原因らしいという話題になっており、GMOの障害情報ページで障害を確認。GMOへリレーサーバを利用したい由を問い合わせる。

5/30　GMOから返信。リレーサーバを利用するかどうかの確認。（利用するにはどうするかを問合せたにもかかわらずオウム返しに聞くかな…）イラッとしながらも即、利用する由を返信。

5/31　警告の来たSPAMHAUSというサイト以外のブラックリスト（dnsbl.spfbl.net）へ掲載されているためリレーサーバの利用を拒否される。当方でブラックリストの解除申請をして、解除されてから再度申請する由、通達される。
GMOいわく、ブラックリストへの掲載有無を調べるのにはDNSBL Information – Spam Database Lookupを利用したのと事。

ブラックリストに掲載されるようなスパム行為に思い当たる節がないので、GMOに割り振られた他のIPをランダムに抽出した10件調べてみると結果は以下の通り。

IPアドレス	dnsbl.spfbl.net	それ以外のブラックリスト
153.122.40.5	○	☓
153.122.40.22	○	○
153.122.40.26	○	○
153.122.40.30	○	☓
153.122.40.65	○	☓
153.122.40.106	○	☓
153.122.40.107	○	☓
153.122.40.120	☓	○
153.122.40.155	○	☓
153.122.40.200	○	☓

なんと私が指摘されたdnsbl.spfbl.netへの掲載は9/10。しかも唯一掲載されていない1つは別のブラックリスト2箇所に掲載されているという状態です。つまり全滅です。
常識的に考えて、今回の件が影響しているとしか思えません。GMOはSpamhausから警告が来たことが原因としていますが、dnsbl.spfbl.netでも同様に登録されていたと考えるのが妥当です。
もしも今回の件が関係していないとしたら、dnsbl.spfbl.netのリストは信頼するに値しないとしか言えません。事実、ホスティングサービスの雄であるsakuraインターネットのIPを調べても、ブラックリストへの掲載が散見されました。

利用者には何の落ち度もないにもかかわらず、解除手続きを利用者に丸投げとは、なかなかのお役所仕事っぷりです。
しかも解除に必要な手続きの一切を解説していません。そもそもGmailのスパム判定は基準が不明であることを障害が復旧できないという根拠にしておきながら、利用者には信頼性も不明なブラックリストへの掲載を盾にリレーサーバの利用を拒否するとは、果たしてGMOはリレーサーバを利用させる気があるのでしょうか？

多くの点で釈然としないものの、とりあえずdnsbl.spfbl.netの登録を解除し、再度申請します。

6/3　GMOよりアカウント作成の案内。案内にあったURLを参考に設定する。
今までのGMOの対応とは打って変わって、設定方法は詳しく丁寧に解説されています。解説を見ればメールサーバを立ち上げられる方なら問題なく導入できると思います。一応、以下に設定方法をまとめました。

ちなみにdnsbl.spfbl.netの問題についての返答は以下のとおりです。

お客さまよりお知らせいただいたIPアドレスを都度確認しておりますが、
全てのIPアドレスが登録されているわけではなく、ほとんどのIPアドレスが
登録は無い状況でございます。

そのため、現時点では本不具合との直接的な関連性は無いものであると
認識いたしております。

どうやら私がランダムに抽出して調べたIPがたまたま10/10、全滅だっただけのようです。
ブラックリストの信頼性もGmailへの影響もわからぬまま、リレーサーバの安定稼働のために、全てのリストからの解除を条件としているとのこと。
どうやらこれがGMOの公式見解のようです。

11/15　GMO VPSのサポートページに障害は復旧したとの表記あり
どうやら復旧したようです。
【不具合発生/クラウドVPS byGMO】一部メール送信不具合につきまして
実際に気がついたのは10月の終わり頃です。「9/9 15:33更新」とあるので、把握するのに2ヶ月近く時間がかかってしまいました。だから重大な障害はメールで通知してくれと注文したのに、まったく治す気は無いようです。まさか利用者が毎日障害情報のページを見て確認する前提なのでしょうか？この姿勢一つ取ってもGMOのサーバは信頼に値しません。
リレーサーバの利用は継続するようですが、おそらく終了の通知もこのページでのみ行われ、メールでの通知などはなさそうです。ということで、いつ終了するかわかりようもないリレーサーバの利用はやめて、早めに設定を元に戻しておくことをおすすめします。

---

Postfixを利用したリレーサーバの設定方法について

postfixを利用している場合の設定方法

まずはリレー用の配送経路指定と、認証形式の追加

# vi /etc/postfix/main.cf

以下の要素を最後に追加。（既にリレーの設定等がある場合は上書き）

# GMO VPSのリレーサーバ用の設定
transport_maps = , hash:/etc/postfix/transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_security_options = noanonymous

gmail宛のメールをリレーするサーバの設定

# vi /etc/postfix/transport

以下の要素を最後に追加。

gmail.com smtp:relay.kumolabo.com:587

リレーサーバへログインする際のIDとPasswordを設定

# vi /etc/postfix/relay_password

「作成したメールアドレス」と「作成したメールアドレスのパスワード」はGMOによって発行されたものを指定する。

relay.kumolabo.com:587 [作成したメールアドレス]:[作成したメールアドレスのパスワード]

設定を反映させる。

# postmap /etc/postfix/relay_password
# postmap /etc/postfix/transport
# service postfix reload

以上でGmailへ送信するメールに関してはrelay.kumolabo.comもしくはrelay2.kumolabo.comを経由するようになります。ちなみにIPは180.222.183.249か180.222.183.250のようです。（ただし変更になる可能性もあるとのこと）

7月8日追記

上記の設定でリレーサーバから届くようになるのはGmailだけです。
独自ドメインでG suiteを利用したURLの場合は以下のようなエラーメールが帰ってきます。

<hoge@example.com>: host ASPMX.L.GOOGLE.com[108.177.97.26] said: 550-5.7.1
    [153.122.40.105      18] Our system has detected that this message is
    550-5.7.1 likely suspicious due to the very low reputation of the sending
    IP 550-5.7.1 address. To best protect our users from spam, the message has
    been 550-5.7.1 blocked. Please visit 550 5.7.1
    https://support.google.com/mail/answer/188131 for more information.
    v8si2440218plg.122 - gsmtp (in reply to end of DATA command)

独自ドメインでG suiteを利用したURLの場合は/etc/postfix/transportに追記する必要があります。URLが「example.com」の場合は以下のように追記します。

gmail.com smtp:relay.kumolabo.com:587
example.com smtp:relay.kumolabo.com:587

さらにGMOのお問い合わせで、リレーサーバへ新しいドメインの登録を依頼します。
なんと、追記するぶんだけ、毎回依頼する必要があるとのこと。

バウンスメールが着てから登録の依頼するという形だと、返信まで2～3日はかかることになります。対策を問い合わせると、DNSでメールサーバを問い合わせてMXレコードを調べてGoogle系かどうかを確認しろとのこと。
取引先すべてのMXレコードを調べろというのでしょうか…。

そもそも、DNSで問い合わせる方法だと、新規のメールアドレスついてはお手上げです。この体たらくじゃ、とてもじゃないけどGMOのサーバはビジネスじゃ使えませんね。

SPFレコード設定

上記の設定で問題なく送信できるようになるものの、リレーサーバのIPが指定されていないため、このままではSPFに通りません。
SPFの仕組みについては詳しく解説されたサイトを参照してもらうとして、複数のIPを登録する方法はあまり解説されていないのではないでしょうか。
結論から言うと、一行にスペース区切りで追加します。

今回の例で言えば以下のように書きます。（153.122.**.**の部分は自分のサーバのIPを指定）

v=spf1 +ip4:153.122.**.** +ip4:180.222.183.249 +ip4:180.222.183.250 -all

実際に追加する際にはtxtレコードに追加します。

# vi /var/named/example.com.hosts

example.com.	IN	TXT	"v=spf1 +ip4:153.122.**.** +ip4:180.222.183.249 +ip4:180.222.183.250 -all"	; SPFレコード

ドメインのあとのドットや、それぞれの要素をタブで区切る、といった細かな点も動作に影響します。サーバの書式に合わせて設定してください。

設定を変更したらシリアル番号を進めるのをお忘れなく。
設定を反映させるべく、念の為BINDを再起動。

# /etc/init.d/named restart

SPFレコードの確認は以下のツールが便利です。

https://mxtoolbox.com/SuperTool.aspx#

SPFの項目に3つのIPが登録されていて「PrefixDesc」の項目が「Pass」となっていれば正しく設定できています。
またはGmailへテストメールを送信して、届いたメールの「メッセージのソースを表示」で「SPF:」の項目に「PASS」と表示されていればOKです。

---

GMO VPSのずさんなサービス

今回の件について問合せた際に「重大な不具合にもかかわらず、なぜ通知がないのか」と確認しましたが、そもそもGMOには障害情報を通知する仕組みがないとのこと。
今どき弱小ISPでもメンテナンス情報と障害情報くらいはメールで通知するのが普通だと思いますが、なんとも前時代的というか呑気というか。

私としても今回の問題が発生した際、打てる対策はさまざま試みたものの状況が改善せず、GMOからなにかアナウンスがないかとユーザーページへログインしてみましたが、何も書いていません。
ダッシュボードに「GMOクラウドからのお知らせ」という項目があるのですが「そちらに記載がないということはやはり私のメールサーバだけの問題か…」とページを閉じました。

しかし、実は「メンテナンス情報・障害情報」という項目をクリックすると、今回の障害情報が掲載されていました。なぜこれだけ多くの利用者に影響のある重大な障害にもかかわらず、わかりやすく目立つように掲載しないのか。トップページに金赤で「不具合発生中」とアナウンスしても足りないくらいです。
はっきり言って、今現在Gmailへメールが送信できなければ、ビジネスとして成立しません。もしそのようなアナウンスが事前にあれば、間違いなく利用しません。この状況を知らずにGMOと新規契約してしまった人にはなんと言い訳するつもりなのでしょうか？

しかも不具合に関する項目名についても疑問があります。
「【不具合発生/クラウドVPS byGMO】一部メール送信不具合につきまして」
なぜ「一部メール」などとわかりにくい表現を使うのか…。「GMOに割り振られたIPからGmailへのメールが届かない現象について」と書けば内容が一瞬で理解できるのに、誰に、何の気を使っているのでしょうか？

また、案内も不親切です。
メールが不通の場合、上で紹介したとおりUndelivered Mail Returned to Senderというメールに「550-5.7.1」というエラーコードが記載されます。エンジニアが不具合の解決策を調べる場合、まず第一にこのエラーコードを検索します。

もし今回の問題が発覚した際にすぐにエラーコードと共に案内を出せば、Google検索ですぐに目に付くはずです。私のように不毛な努力をすることなく、すぐに対策を練れたわけです。

と、GMOの対応について愚痴を書き連ねましたが、今回の障害で、大切な取引先とのやり取りに支障が出て、お問い合わせの内容を通知したり、ユーザー登録のアクティベーション処理ができなかったりと実害を被っています。これくらいの愚痴は許されるでしょう。

ただまあ、GMOを擁護するわけではありませんが、VPSのサポートなぞ、どこも一緒です。機材の保守と電気代を考えれば、利益は雀の涙で、サービスの質など、どんぐりの背比べ状態です。自分でサーバを立てる煩わしさを考えれば、サービスを継続してくれているだけでもありがたいと思うべきかもしれません。（本当に何のフォローにもなってないな…ｗ）

---

メールサーバの信頼性と、Googleによる市場の寡占に関する問題

今回の問題がこれだけ大規模になった原因は、IPを範囲ごと拒否するという仕組みに起因します。
特定のIPだけがスパムメールを出しているなら、その特定のIPだけをブラックリストに入れれば良いわけです。

ただ、ブラックリストを作成する側の言い分もわかります。
IPの情報を参照してわかるのはネットワーク情報だけだからです。
IPの1つ1つについて情報を開示する義務がなく、多くの場合レジストラなど登録代理会社の情報しか入手できません。
実際にメールサーバを運用している責任者を特定するすべが無い以上、IPを範囲ごとブラックリストに登録する以外に対策がない。ということなのでしょう。

ただし、その理屈が通るのは小規模なWebサービスまでです。
Googleのような市場で支配的な影響力を持つ企業は、そうした機械的で画一的なサービスの停止には慎重であるべきです。

今回のようにGmailが利用できないとなると、もはやそのメールサーバは機能していないのと同じです。
検索エンジンで言えば、Googleのインデックスに登録されない、いわゆるGoogle八分の状態と同じです。グーグル検索で表示されないWebページは、この世に存在しないのと同じです。
米中による貿易戦争でHuaweiがAndroid OSの提供を拒否されただけでスマホの中古価格が100円になったように、市場を寡占した企業による締め出しは商品の価値に決定的な影響を与えます。

もはやWebサービスにとってGoogleは必要不可欠なインフラであり生命線です。Google都合のアルゴリズムに生殺与奪の権利を与えるのは、ネットの健全化にとって重大な足かせになります。
Googleのような寡占企業は、サービスの停止に関して慎重であるべきです。それが社会インフラを担う企業としての責任ではないでしょうか。
電力会社には安定した電力を供給する義務があるように、水道には水道法があるように、Googleにもサービスの停止を抑制的にする法整備が必要な段階に来ているのではないでしょうか。

少なくとも今回のように、明らかに誤解に基づくスパム認定だと判断できる場合は、スパム業者の利用停止など有効な措置を確認次第、速やかに規制を解除するべきです。
そうした対応が可能なだけの企業体力は十分あるはずです。

---

Googleが公式に案内するメールがブロックされた際の対処法

今回の騒動で唯一良い点があったとすれば、Gmailが公式にアナウンスしているブロックされた際の対処法を学べたことです。
GmailのエラーメッセージにはURLが記載されています。
「https://support.google.com/mail/answer/188131」

内容は「Gmail でメールがブロックされる理由」という直球のページです。
リンクをたどるとさまざまな対処法が記載されています。対策を箇条書きにすると以下のようになります。

• Postmaster Toolsを利用する
• SPF（Sender Policy Framework）を利用する
• DKIM（Domainkeys Identified Mail）を利用する
• DMARC（Domain-based Message Authentication, Reporting, and Conformance）を利用する
• Let’s Encryptを利用してオレオレ証明書からの脱却

今回の騒動で以上の対策を実施しました。
今回は徒労でしたが、Gmailで利用されているスパムの判定に対しては、かなりスコアが改善したはずです。

上記の改善方法を「Gmailに学ぶ『セキュリティに配慮したメールサーバを構築する方法』」にまとめました。よかったらご覧ください。