メールアドレス抽出の正規表現

■ Procmailで使えるメールアドレス正規表現

From、Return-Path などからメールアドレスを抽出する正規表現、意外と難しいです。
結論から言えば、正規表現一発ではできません。

例えば、こんな反則的なメールアドレスが実際にあったりして

Return-Path: <a-b-c._.d=efg@hogehoge.com>

例えば、メールアドレスらしきものが2つ含まれていたりして

From: "I-am@office.work" <a-b-c._.d=efg@hogehoge.com>

こんなやつも引っ掛けるには以下のようにします。

echo 変数 | grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

すると、こう展開されます。

echo '"I-am@office.work" <a-b-c._.d=efg@hogehoge.com>' \
| grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

結果
a-b-c._.d=efg@hogehoge.com

ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

スパムメールでは From はよく詐称されます。
From はあてにならないので From でブラックリスト判定するのは意味ないです。
やるなら Return-Path でブラックリスト判定のほうがマシ。
でも、ブラックリストを追加するのも疲れるしイタチごっこです。
もっとうまい方法がないか・・・

■ ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

From と Return-Path が違ったらもう削除してしまうなら以下


# ヘッダからメールアドレス抽出して変数へ

:0
* ^Return-Path:\/.*
RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^From:\/.*
ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^To:\/.*
ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

# スパム判定

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
/dev/null

でもこれだと、いろんなものが弾かれてしまいすぎ。
いやいや、それはちょっと厳しすぎると思う場合、
From と To が同じときスパム確定にするなら以下


ヘッダからメールアドレス抽出する部分は上記と同じ
・・・

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う - 目印を付けるだけ
:0fw
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
| formail -i "Procmail-Match-From-Return-Path: unmatch!" \
| formail -i "Procmail-Return-Path: $RETUERN_PATH" \
| formail -i "Procmail-From: $ORIGINAL_FROM" \
| formail -i "Procmail-To: $ORIGINAL_TO"

あとは、総務省の迷惑メール対策室へ自動で転送したり
From と Return-Path のドメインも判定したり・・・


######## ヘッダからメールアドレス抽出

:0
* ^Return-Path:\/.*
{
  RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  RETUERN_PATH_DOMAIN=`echo "$RETUERN_PATH"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^From:\/.*
{
  ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  ORIGINAL_FROM_DOMAIN=`echo "$ORIGINAL_FROM"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^To:\/.*
{
  ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
}

######## スパム判定

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
{
  # Return-Path ドメインが From ドメインを含まない
  :0fw
  *! $RETUERN_PATH_DOMAIN ?? $ $ORIGINAL_FROM_DOMAIN
  | formail -i "Procmail-Match-FromDomain-Return-Path: unmatch!"

  :0Efw
  | formail -i "Procmail-Match-From-Return-Path: unmatch!"

  :0fw
  | formail -i "Procmail-Return-Path: $RETUERN_PATH" \
  | formail -i "Procmail-From: $ORIGINAL_FROM" \
  | formail -i "Procmail-To: $ORIGINAL_TO"
}

# spamassassin
:0fw
*!^X-Spam.* 
| /usr/bin/spamc

:0c
* ^X-Spam-Flag: YES
{
  # 総務省の迷惑メール対策室へ転送
  # これで捨てずに自分も受信する

  SENDMAILFLAGS="-oi -f $RETUERN_PATH"
  ! meiwaku@dekyo.or.jp
}

こんな感じ。

総務省へ迷惑メール情報提供するプラグイン

総務省へ迷惑メール情報提供するプラグインのご紹介です。
ダウンロード http://plugin.antispam.soumu.go.jp/

迷惑メールとは
「特定電子メールの送信の適正化等に関する法律(平成14年法律第26号)」に違反していると思われる以下のようなメールです。

・送信に同意した覚えのない広告宣伝メール
・表示義務違反メール
・送信者情報(電子メールアドレス、IPアドレス、ドメイン名 等)偽装メール

総務省は迷惑メール対策に取り組んでいます。

総務省|電気通信消費者情報コーナー|迷惑メール対策
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html

特定電子メールの送信の適正化等に関する法律のポイント
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/pdf/m_mail_pamphlet.pdf

【主要な罰則】

送信者情報を偽った送信
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意のない者への送信
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意の記録義務違反
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して100万円以下の罰金)

続きを読む

SPF判定をパスするスパムメールの例(SPFは意味がない証拠)

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回は、実際に筆者に送られてきたスパムメールがSPF判定をパスしている例を示します。
SPF判定をパスするスパムメールは非常に多く、SPF判定は何の意味もないのが現実です。

■ 送られてきたスパムメールの例

From: 【ECショップ】ご注文の確認につきまして <zqtafc5pn5ww8umr0kew8d@virk.dj8eiidz78rxjk.site>
To: xxxxx@yahoo.co.jp
Subject: 【xxxxx@yahoo.co.jp】様 ご注文の確認につきまして

xxxxx@yahoo.co.jp 様


ご注文を頂きまして誠に有難う御座います。きゆおをにろつに

お取引終了まで短い間では御座いますが何卒宜しく御願い申し上げます。きゆおをにろつに

今回ご注文を致しました商品のご確認をお願い致します。きゆおをにろつに



http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDc2-ODAxMTEy/NTAyMwQ6a0dQ6a0d/



尚、御発送に際しましては改めてメールにてご案内申し上げます。きゆおをにろつに
何卒宜しく御願い申し上げます。きゆおをにろつに






■配信停止
http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDkz-ODAxMTEy/NTAyMwQ6a0dQ6a0d/

きゆおをにろつに
4374きゆおをにろつに

(ただし、xxxxx は伏せ字)

■ 送られてきたスパムメールのヘッダ解析

続きを読む

GoogleのGmailのIPv6逆引き判定が迷惑な問題

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回はさらに突っ込んでGoogleのGmailの厳しい判定が迷惑な問題について書きます。

参考)

一括送信ガイドライン – Gmail ヘルプ
https://support.google.com/mail/answer/81126

Googleだけに限ったことではないですが、Gmailはシェアが多いのでトラブルが目立ちます。

トラブルというのは【Gmailに送ると届かない】という問題です。
これはGmailが、迷惑メール対策として判定が厳しいためです。

Googleは最近、自分たちのガイドラインに【何が何でも従わせる】という強引なやり方をするようになりました。
事実、Googleのガイドラインに従わないメールはリジェクト(受信拒否)されるトラブルが多く、最近 Gmail / G Suite(旧 Google Apps)のメールに関して問い合わせが多いです。
仕事の取引先からの必要なメールでもGoogleのガイドラインに反していると届きません。
迷惑メールフォルダに振り分けられるならまだしも、勝手にリジェクトされて気付かないままになります。

続きを読む

SPFで迷惑メール判定が逆にスパムを増長させる問題

SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きます。

#SPFレコードとは送信ドメインを認証の一種で、詳しくはネットで調べてください。
#独自ドメインを持っている人はSPFを知らずに済ますことはできません。
(特にGoogleのせいで知らないでは済まなくなってしまいました)

参考)

SPF(Sender Policy Framework): 迷惑メール撲滅委員会
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/

SPF レコードについて – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/33786?hl=ja

一括送信によるメール返送 – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/168383

Googleだけに限ったことではないですが、メールをサービスするプロバイダの傾向として、SPFレコードの設定を(なにがなんでもやれと)強制するような動きがここ数年で強まっています。

続きを読む

特定電子メール法違反にあたる迷惑メール対策

特定電子メール法違反にあたる迷惑メール対策について書きます。

■ 特定電子メール法とは

平成14年に「特定電子メールの送信の適正化等に関する法律」が成立し、同年7月より施行されています。

特定電子メールとは「自己又は他人の営業につき広告又は宣伝を行うための手段として送信をする電子メール」と定められており、一般に広告宣伝メールのことです。

■ 特定電子メール法違反事項

広告宣伝を目的としたメールは、「原則としてあらかじめ同意を得た者以外の者への送信禁止」「一定の事項に関する表示義務」「送信者情報を偽った送信の禁止」「送信を拒否した者への送信の禁止」などが定められています。

特定電子メール法(平成十四年四月十七日法律第二十六号)
http://law.e-gov.go.jp/htmldata/H14/H14HO026.html

続きを読む