てんこ

ブログ名は愛猫（てん）の愛称です。中身は個人のIT系学習記録です。

技書博読書感想文_01 迷惑メールにされないメール設定方法(GSuite編)

security 雑記

盆まで読まないと言っていながら、少し読んでしまったので感想です。

対象図書

「迷惑メールにされないメール設定方法 GSuite編」　さっぴー川原さん

https://kawahara-ci.hatenablog.com/

◆Boothでの紹介はこちら

booth.pm

所感

メールデータの基本的な構造の説明から始まり、 「メール」という仕組みにおける歴史や構成要素・注意点が良くまとまった書籍でした。 Emvelopeと本文のFrom/Toの違いについての説明なども、非常にわかりやすかったです。

また、設定を行うことで適用される具体的な効果や、見た目の違いなども分かりやすかったです。

このあたりの要素は、SNS全盛期とはいえ、レガシーな仕組みとして残る「メール」というものを確実に届けるには、考慮しておいて損はないものですし、GSuiteを例にその設定例を具体的に記載していただいているのは非常にわかりやすかったです。(私もGSuite使ったことないので、こんな画面なんだと思いながら読んでいました。)

SPFにおけるFailの条件や受信側での判定なども、非常にわかりやすくまとまっていました。 「メール出しているつもりなんだけど、迷惑メール判定されちゃうんだよな」という人にとって、チェックリストとして環境を見直してみるにはとても良い内容だと思います。

私もメールサーバの運用を経験している身なので、ここまで詳しく書いて頂いているならこれも…と欲（後述）が出てしまうくらい、良くまとまった本でした。 会社の中でも回覧させて頂こうと思います。

SoftFailの場合に受信拒否していいか、という点は悩ましいところです。

少しわかりにくいかな、と思った点

「迷惑メール」といわれるものは2種類あると思っています。

  • 受信者には届くが「迷惑メール」と扱われてしまう場合
  • 「迷惑メールサーバ」と判定され、そもそもメールを届けられない場合

書籍内の主眼は、前者の理由でメールが迷惑メールと判定される事についての対策を書いて頂いています。

【修正】前者と後者が逆になっていました。失礼しました。

なので、主眼からは外れる点となりますが、コラムなんかに1枚くらいのレベルで入っていると、事業者としての苦労も分かってもらえて嬉しいなあ、と欲が出た結果の話とご容赦いただければ幸いです。

前者の判定ロジックは、経由するMailGatewayや受信者が使うMUAによってまちまちですので、私も具体的にどうするといい、という内容についてはあまり知見はない(セキュリティ系ベンダーも開示してくれない内容)のですが、記載いただいたもののほかでは

  • 「URLリンクを張る時にIPアドレスで書かない」
  • 「メールマガジンなどでばらまかれるような書式でメールを出すと本文の評価で迷惑メール判定される場合がある」
  • 「実在しないURLなどを書いてしまうと迷惑メール判定される場合がある」

などの例はあっても良いかな、と思いました。

また、前者だったか後者だったか忘れてしまいましたが、私の経験上、ホスティングなどの共有環境でないのであれば、「送信メールサーバのIPの逆引きを、HELOで宣言するホスト名と一致させておく」などの対策はある程度効果があると思っています。 (移動体キャリアさん宛のメールで、この点を理由に蹴られた思い出があります…)

また、【2.5　メール通信内容における「きれい」】において、SMTPSやSTARTTLSなどの記載を頂いていますが、この点についてはMUA～MTA間とMTA～MTA間の模式図があったほうが良いように思いました。

加えてほしかった要素

少しだけブラックリストの内容に触れられていますが、IPアドレスでの着信制限は現役で動いていますし、非常に効果の高いものだと思っています。

受信側のMTAにとってはRBLは、大量に発生するスパムメールサーバからのSMTPコネクションからメールサーバを守るためによく使われます。

逆に、送信者側にとってみれば、受信者側がRBLを使っている前提に立ったうえで、「如何にRBLに掲載されないか」を常日頃から考慮する必要があります。

【追記】上述した「メールを届けられない」の大半がこれにあたる印象です。RBL掲載されているとTCPも張れなかったり、張れるもののHELOで蹴られたり…

最近ではGMOクラウドさんからGMailへのメールが届かない、という障害の話がありましたが、これもRBLが主な要因のようです。

これまで見てきた中では、一番ひどい条件だな、と思ったRBLの掲載理由が「接続元IPの逆引きにおけるDNSのTTL値が半日以下だったから」です。変動要素の多いIPアドレスだからスパムサーバの可能性が高い、という理由だと思いますが、これのおかげでいろいろとトラブルに巻き込まれた経験があります。

RBLの掲載はいつ発生してもおかしくなく、利用者からの「メール届かないんだけど！」から調査し始めると遅いケースもあるため、RBL掲載リストへの定期的なチェック(hostコマンドなどによる自動チェック)は有用だと思います。

ページのボリュームや主眼と異なるという点もあると思いますが、「迷惑メール」としてメールが届かない理由には2系統ある、というような記載があると、より分かりやすいのではないかと思いました。

確認ツールに追加するなら

appendにあるmxtoolboxは私も仕事でよく活用しました。

総合的に見れるもの…という点で最近はここを使ってます、というサイトをついでにご紹介です。

Cisco社の運営する「Sender Base」というサイトがありました。

これは、現在は「Talos」という名称に代わっています。

https://www.talosintelligence.com/

ここで自身のメールのドメインやIPアドレスなどを検索すると、Talosとしてどのように判定しているか、　Poor/Natural/Good　の3段階の評価で非常にわかりやすく表示してくれるのでお勧めです。

また、対象のドメインやメールサーバのIPアドレスを検索することで、メール流量の日時変化やIPアドレス逆引きの一致状況なども確認できるため、トラブルシュートをする際には便利に活用できるサイトです。

言い訳

書いてる内容については最新の対策やらDKIMを使った場合にスキップできるものがあるのか、などは知見がないので、多少古い情報の可能性がある点はご了承くださいorz.