Scribble at 2022-11-09 15:16:40 Last modified: 2022-11-09 16:49:24
既に当社を退職した人物から、或る公共放送の方から「御社からスパムが送られている」という相談を受けたらしい。まず前提の話として、その退職した人物のメール・アカウントは何か月も前に失効している。仮に SOMEONE 氏としておくと、"someone@comp.co.jp" というメール・アカウントは、既に Google Workspace にてユーザを削除しており、このアカウントから正常にメールが送信されるはずはない。もちろん、このメール・アドレスを使ってメールを送受信していた（そして、ご相談をいただいた方のメール・アドレスともメールのやりとりをしていた）全員が、そういうスパムを送ってしまっている可能性がある該当者である。こんなことはメール送信の基本的な知識さえあれば造作もない話ではあるが、素人を相手に当社から送られたスパムではないと説明するには、もう少し手の込んだ解説を加えないといけないだろう。
メールというのはインターネット通信でデータを送受信するための通信規格に沿ったデータの形式であり、DNS など他の規格にも依存していることは多いが、直にメールの書式として依存しているのは、RFC という IETF（Internet Engineering Task Force）の技術仕様である。もちろん RFC は一つの仕様であって強制的ではないものの、RFC に従っていないメール・サーバとかメール・ソフトというものは、実質的に誰にも正しくメールを送れないし、誰からも正しくメールを受信できないので、RFC は事実上のスタンダードと言える。この RFC は日進月歩で増えたり更新されていて、本日2022年11月9日現在では9327のエントリーがある。
そして、メールの書式については RFC 5322 というものが規定されている。
https://www.rfc-editor.org/rfc/rfc5322
この "3.6.2. Originator Fields" には From フィールドなど送信元を表す書式が規定されていて、
"From:" mailbox-list CRLF
となっている。よって、"From: someone@comp.co.jp" で、最後に改行コード（CR/LF）を追加する（つまり１行で記述する）の原則だ。"mailbox-list" なので、カンマで区切った複数のメール・アドレスが送信元になっていてもよい。しかし、これには "3.4. Address Specification" という追加のルールがあって、アングル・ブラケット（山形括弧）でメール・ボックスつまりは送信元のメール・アドレスを囲むという記述が認められている。そして、この記述がある場合は、From 行の残りの文字列はメール・アカウントの名前として認識される。よって、"SOMEONE <someone@comp.co.jp>" となっていたら、"SOMEONE" は後続する括弧で囲まれたメール・アドレスの名前として処理されるわけである。メールというのは規格に沿っていれば送受信できるため、逆に言えば規格に沿った不正なメールをいくらでも送信できるという弱点がある。フィッシング・メールやスパムとして、正規の送信元のメール・アドレスを詐称したメールが横行しているのは、それが理由である。ウェブ・アプリケーションが書けるなら、"noreply@amazon.co.jp" とか "info@yahoo.co.jp" とか "contact@nhk.or.jp" といった送信元を詐称して、いくらでもメールを送信できてしまうわけである。
送信元が正しいかどうかを判定する方法はいくつもあるにはあるが、送信サーバをたどっていく方法は技術的にも金銭的にもそれなりの費用がかかり、時間もかかるわりには、結論が出ないこともある。スパム業者の中には、パブリック・クラウドの IaaS サービスを使って、テンプレート化されたメール・サーバのイメージを最初から大量に作成して、スパムが何通か送ったらインスタンスを廃棄して別の IP アドレスやドメイン名に挿げ替えたりするからだ。なので、現実的には送られてきたメールのヘッダー情報だけで判断することになり、そして意外とヘッダー情報だけで偽物だとわかることもある。
冒頭で紹介したスパムの受信者に送られてきたメールは、送信元の情報をスクリーンショットで（Outlook や Thunderbird で正確なヘッダー情報を全て表示する手順とかを説明するだけでも面倒なので、そこまでは要求していないらしい）見せてもらった限りでは、次のようになっていた。
"From: <SOMEONE> someone@comp.co.jp <foobar@spammer.com>"
実際には、右側は写真が切れていて何とも言えないのだが、明らかに弊社のドメインとは違うドメインのアドレスが記載されていた。これだけで、僕らは弊社から送信されたメールではないと断定できるのだが、実際にフィールドに「SOMEONE」という具体的な人名とか、「someone@comp.co.jp」という弊社で使っていたメール・アドレスが記載されていると不安を感じるのも仕方がない話であろう。
どうしてフィールドだけで "someone@comp.co.jp" から送られたメールではないと言えるのか。それは、山形括弧で囲まれたメール・アドレスがある時点で、括弧で囲まれていない "someone@comp.co.jp" は送信元のアドレスとは扱われてない（つまり名前として扱われる）からだ。メール・ソフトでは一緒に表示されるので、名前なのか送信元のメール・アドレスなのか、区別しないで見ている人が大半だろうとは思うが、上記の場合は括弧で囲まれた方が送信元のアドレスとして扱われる。そして、最初の括弧にはメールアドレスではない「SOMEONE」という文字が記載されている。mailbox つまりメール・アカウントの形式を満たしていない文字列はメールの送受信で正しいメール・アドレスとしては扱われない。よって、最後の "foobar@spammer.com" が送信元のメール・アドレスとして扱われるわけである。むろん、実際にメールを送信したメール・サーバが spammer.com というドメインを運用している保証もないわけだが、少なくとも "someone@comp.co.jp" という正規のアカウントからメールを送信したシステムが、わざわざ詐称を疑われるような別のメール・アカウントを From フィールドに記載するなんてことはないだろう。
そして、念のために上の画像で示したように、三種類の From フィールドを定義してメールを送信してみたわけである。これまでの説明からお分かりのように、"test 1," "test 2," "test 3" という件名で送信されたメールのうち、"test 2" は届かない。これは From フィールドの解釈からすれば "SOMEONE" という、メール・アカウントの形式を満たしていない送信元と判断されて、メール・ソフトが送信をやめてしまうからだ。(1) は、SOMEONE という名前の人物が "someone@comp.co.jp" というアカウントから正しく送信していた場合のフィールドである。もちろん、このアカウントは実際にはないので、そんなことが起きるわけがない。残る (3) は、"someone@comp.co.jp" は名前であると説明したし、最初の括弧で囲まれた「SOMEONE」が正常なメール・アカウントでないことも説明したので、後に括弧で囲まれたメール・アドレス、つまり僕の markupdancing.net のアカウントから送信したメールであるという扱いになる。よって、(1) 以外は someone@comp.co.jp とは関係がないのだ。