大量に届くスパムメールの中で、From: ヘッダに ? が混じっているものが来ています。
こういう時は、od コマンドですね。
$ od -x
Pay?pay?株?式?会?社?
0000000 6150 3f79 6170 3f79 a0e6 3faa bce5 3f8f
0000020 bce4 3f9a a4e7 0abe
0000030
$
od コマンドなので出力は2バイトづつ反転して表示されています。
? 文字は 0x3f 普通のクエスチョンマークでした。
なぜこのようになるのかそのヒントを探りたいと思い、Gemini に聞いてみました。
ここから＝＝＝＝＝＝
Q:
メールのヘッダーが文字化けしている。途中に１６進数で 0x3F の文字が挿入されている。これは何故ですか？
A:
メールヘッダーに「0x3F（半角の疑問符 ?）」が挿入されて文字化けする場合、文字コードの変換失敗（フォールバック表示）が原因です。
主な理由は以下の3点に集約されます。
## 原因1：対応していない文字の置換
システムやメールソフトが、ある文字コードから別の文字コード（例：UTF-8からISO-2022-JP）へ変換する際、変換先に存在しない文字（環境依存文字や絵文字など）があると、安全な代替文字として「?（0x3F）」に強制変換されます。
## 原因2：MIMEエンコードの失敗
メールのヘッダー（件名や送信者名）に日本語を使う場合、=?ISO-2022-JP?B?...?= といったルール（MIMEエンコード）で英数字に変換する必要があります。このエンコード処理のプログラムにバグがあったり、途中でデータが欠落したりすると、デコード側が解析できずに ? を出力します。
## 原因3：不適切なデータによるエラー処理
プログラムが不正なバイト列（文字の区切りが壊れたデータ）を検出した際、システムがクラッシュするのを防ぐためのエラーハンドリングとして、異常な箇所をすべて ?（0x3F）に置き換える処理が行われるためです。
------------------------------
トラブルを特定するために、文字化けが起きている場所（件名、送信者名など）や、可能であれば化ける前の本来の文字列（推測される文字）を教えていただけますか？状況に合わせた対策をご提案します。
＝＝＝＝＝＝ここまで
例によって、Markdown形式で回答しています。ちょっと気になったので、ヘッダの文字について確認してみます。
ここから＝＝＝＝＝＝
Q:
メールのヘッダには 0x80 以降の文字は含めてはいけないのになぜそのような文字を挿入してしまうメーラーがあるのでしょうか。
A:
メールヘッダーに 0x80 以上の文字（8ビット目が高ビットの文字）が直接挿入されてしまう理由は、主に歴史的な規格のズレと開発者の実装ミスにあります。
原因は以下の3点に要約されます。
## 原因1：UTF-8（8bit）のそのままの送信
現代のインターネットでは、本文やヘッダーを「UTF-8」で処理するのが主流です。UTF-8の日本語は 0x80 以上のバイト列で表現されます。
本来ヘッダーに使う際はMIMEエンコード（=?Base64?...= など）が必要ですが、一部のモダンなメーラーや自作の送信プログラムが「現代のサーバーならエンコードしなくてもUTF-8をそのまま通せる（8BITMIME拡張に対応している）」と過信し、生データをそのまま書き込んでしまうためです。
## 原因2：文字コード変換（Shift_JISなど）の失敗
古い日本のメーラーやWebシステムでは、内部で日本語を「Shift_JIS」や「EUC-JP」で処理しています。これらの文字コードも 0x80 以上の値を使用します。
送信時に「ISO-2022-JP（7bit文字コード）」への変換やMIMEエンコードの処理がプログラムのバグでスキップされると、0x80 以上の生データがヘッダーに残ってしまいます。
## 原因3：古い規格（RFC 822）と現行運用の乖離
電子メールの根本的な古い規格（RFC 822）では7ビット（0x7Fまで）しか許されていませんでした。しかし、その後に登場した「SMTPUTF8」という拡張規格により、特定の条件下ではヘッダーに 0x80 以上のUTF-8文字を直接含めることが公式に認められるようになりました。
この「古いルールを厳格に守るシステム」と「新しい拡張ルールで送るメーラー」の間のミスマッチが原因です。
------------------------------
この 0x80 以上の文字が含まれるメールは、特定の特定の海外製メーラーや、Webサイトのお問い合わせフォームなどの自動送信システムから届いたものでしょうか？もし送信元の環境（プログラム言語やツールなど）が分かれば、具体的な修正・対策方法をお伝えできます。
＝＝＝＝＝＝ここまで
新しい規格 SMTPUTF8 について説明してくれています。古い規格？ RFC822 は提示してくれているのに新しい規格のRFCがないのが気になりますが、ここで本題に入ります。
送信元の環境を調べてくれるそうなのでさらに聞いてみます。
ここから＝＝＝＝＝＝
Q:
送信者のメーラーはヘッダが X-mailer: TEmHlZ 7 でかつ、cn ドメインからの送信のようです。0x3F文字が From: ヘッダに挿入されていて、3バイト毎にその文字を含んでいます。最後の改行は 0x0A なので普通のものでした。具体的な修正・対策方法はありますか。
A:
X-mailer: TEmHlZ 7 という見慣れないシグネチャ、cnドメイン（中国）、および「3バイト毎に 0x3F（?）が挿入されている」という特徴から、このメールは一般的な市販メーラーからではなく、独自のバルクメール送信ツール（スパム配信ツールを含む）や自動生成スクリプトによって送信された可能性が極めて高いです。
3バイト毎に 0x3F が現れる現象は、中国語の標準文字コードである GBK または UTF-8（3バイト文字） のデータを、送信側プログラムが強引に別の文字コードへ誤変換、または不正なMIMEエンコードを施したためにデータが破損した状態を示しています。
受信側（あなた）の環境でこの文字化けをクリーンに修復することは困難ですが、システム運用者としての対策や、プログラムを用いたデータ救済の具体的なアプローチは以下の通りです。
------------------------------
## 受信者・システム管理者が取るべき対策## 対策1：メールフィルタによる一括拒否（推奨）
不審な X-mailer ヘッダーやドメイン、破損したヘッダーを持つメールはセキュリティリスク（フィッシングやマルウェア）を含んでいることが多いため、ゲートウェイやメーラーのルールでブロックするのが最も安全です。
* [IIJmioのメールフィルタ解説](https://www.iijmio.jp/mm/m-filter/filter-setup2/)などを参考に、メールサーバー側のフィルタリング機能（IIJmioなど）を利用して、X-Mailer: TEmHlZ 7 または .cn ドメイン からのメールを隔離・破棄するルールを設定します。
## 対策2：セキュリティ認証（SPF/DKIM/DMARC）の検証
[メールヘッダの解析方法](https://baremail.jp/blog/2020/06/03/728/)（baremailなど）を参考に、Authentication-Results ヘッダーを確認してください。ヘッダー構造がここまで壊れている送信元は、SPFやDKIMの認証に失敗（Fail）している可能性が非常に高く、その場合は即座に迷惑メールフォルダへ振り分ける対策が有効です。
------------------------------
## プログラムで強引にデコード・救済を試みる方法
もし業務上、どうしても From の内容をプログラム等で復元・判別しなければならない場合の修正アプローチです。
## 1. 0x3F を除外して文字コードを再当てはめする（Python例）
「3バイト毎に 0x3F が挿入されている」ということは、本来のマルチバイト文字（中国語のGBKやUTF-8）のデータ列の間に、バグで 0x3F がインターリーブ（挟み込み）されているか、特定のバイトが 0x3F に置換されている可能性があります。
以下の手順で、挟み込まれた 0x3F を取り除いてからデコードを試みます。
python
# 破損しているFromヘッダーの生バイト列（例）
broken_bytes = b'...\x3F...\x3F...'
# 対策：3バイト毎、あるいは特定位置の 0x3F (63) をフィルタリングして除去する
# もし「文字の間に0x3Fが挟まっているだけ」なら、0x3Fを除去すれば元のバイト列に戻る
cleaned_bytes = bytes([b for b in broken_bytes if b != 0x3F])
# 中国語の文字コード（GBK または GB18030）でデコードを試みる
try:
print(cleaned_bytes.decode('gbk'))
except:
# 失敗した場合は UTF-8 でデコードを試みる
print(cleaned_bytes.decode('utf-8', errors='ignore'))
## 2. 原因：なぜ3バイト毎に発生するのか？
* UTF-8のバグ解釈: 漢字1文字が3バイトで表されるUTF-8において、送信側プログラムのループ処理が「1文字（3バイト）処理するごとに、区切り文字やエラー値として 0x3F（?）を1バイト挿入してしまった」という、完全に送信側実装のバグ（オフバイワンエラー等）が考えられます。
* 改行コード（0x0A）について: 末尾が 0x0A（LFのみ）なのは、送信元がLinux/Unix系の格安VPSやサーバー上で動くスクリプト（PHPやPython、Goなど）から直接ソケット送信されたことを裏付けています（Windows系であれば 0x0D 0x0A になるため）。
------------------------------
このメールは定期的に届く業務上の重要な通知でしょうか、それとも突発的に届いた心当たりのないメールでしょうか？もし前者であれば、送信元へ「MIMEエンコードに失敗している」旨をフィードバックする際の文面をご提案します。
＝＝＝＝＝＝ここまで
X-mailer: TEmHIZ 7
をあやしいと疑っていますね。質問ではスパムメールであるとは陽に言っていないので、中々興味深い返答です。
中国語とはcnドメインからのメールということでの推定でしょう。
対応の具体的な方法がスパムメールであることを前提に話を進めている（対策１と対策2）のは良い回答というべきでしょう。
対策2は、以下のヘッダを見よと言っている普通の対策ですのでもっともな提案です。実際、
Received-SPF: FAIL identity=mailfrom; 以降省略
Authentication-Results: xxxxx;
dkim=pass header.d=xxxxxxxx.xxxxxxxx.cn xxxxxxxx@xxxxx.xxxxxx.cn
header.b=nbmpmxy3;
dmarc=fail 以下省略
でしたから、明確にスパムメールであると見なせます。
とはいうものの、余分な文字を除去する Python プログラムまで提示してくれていますね。
0x0A は、質問時のこちらのうっかりミス（無視してよい）でしたが、それなりに解説してくれています。
今回は、回答の最後に言及している「突発的に届いた心当たりのないメール」でしたのでここまでの回答で良しとしました。
Gemini の応答によって、メールのヘッダについても気軽に聞ける環境ができたということで、ある程度該当する知識を身につけていれば詳しく聞いてそれなりの回答が得られると言えそうです。ちなみにあやしいと言っている似たような名前のメーラーを収集すると、
EEOmbG 5
RFypP 8
VIgQi 6
PFrnu 5
8pEdYc 7
3snw9 6
と、似たような感じのメーラーが次々と見つかりました。6文字くらいで、最後に空白文字に続いて数字があるのが特徴です。オリジナルから派生したスパムメール生成ツールかもしれませんね。
昔なら、メールのヘッダについて話が盛り上がるには sendmail を扱っている等の制約があったので大変でしたが、生成AIのおかげでつくづく便利になったと実感しました。
- 前ページ
- 次ページ