Spam!スプァム!すぱーむ。

自宅のマシンに届くSpamは一日100通を越えます。
大抵は、フィルターに引っかかってゴミ箱行きなのですが…。
中にはそうでないのもマレに居ます。

携帯電話に届くSpamも、酷い時は一日20通を越える時もあります。
自分の知っている数名の人間以外に携帯電話のメールアドレスを教えて居ないのにも関わらず…です。
まぁちょっと文字数の少ないメールアドレスなのが問題なのかと思いますが…。
僕の携帯電話の契約は、メールの受信は無料なので、
実質的な被害は電池の消耗が激しくなる位ですが、そうでない方もいらっしゃると思います。
と言うか、Spam如きに電池を消耗させられる事にも理不尽を感じます。
Spamを受信する為に充電してんじゃナイノニ。

話がそれました。元に戻します。

敵を知って己を知ればナントヤラ。

果たしてSpam業者は、どうやってメールアドレスを手に入れるのでしょうか?

  • 「個人情報とセットで名簿業者から買う」
  • 「アヤシイECサイトを立ち上げて集める」
  • 「HTMLのmailto:等、メールアドレスと思しき文字列をネットからbotで集める」

まぁ、色々あると思います。
でも、一番簡単なのは、「ランダムな文字列+@+ドメイン」です。
使用するSMTPサーバと送信対象になるドメインを設定したら、
後はSpamを送りまくるプログラムを作ろうと思えば、1日もあれば十分です。
それに加えて、送りまくった後に、
作ったメールアドレスが生きてるメールアドレスなのか
ログを取っていくのも別段難しくないですし。言及しませんが…。
SMTPサーバを大量に確保するのも難しい話ではありません。
フリーのメールサービスなんて幾らでもあります。
それらのアカウントを自動的に引っかき集めるプログラムも簡単に作れます。
最初のプログラムと連動するような仕組みにしたって、
合計で1週間もあればほぼバグの無いアプリケーションが作れると思います。
と、大多数のSpam業者が金の掛からないこう言う簡単な方法でSpamを送信している…とします。

対抗策とは、コレ如何に。

コヤツ等に対抗する為の手段として考えられる方法は、消極的ですが1つだけです。
・メールアドレスを64byteにする。
RFCで、長さの最大長は大体これ位がエエんでないのと、言ってるサイズです。
でも、これ位なら数週間もあれば辿り着けるんじゃないですかねぇ…。

じゃ、どうするのか?……で、最初に戻って来るワケデス。
メールアドレスの@より以前の部分を.(ドット)で終わらせりゃエエのです。
これなら、少しくらい短くても全然オッケー。
携帯電話以外からのメールを受けられなくナルケドネ。
RFCにしっかりと準拠したメールサーバからの送信は全部エラーで止まるですよ。
つまり前述したようなフリーのメールサーバを使ったSpamも全部止まるって訳デス。

ヲヲ!?意外とイケてない?…………ンな訳無いか…

仕事で使ってて、普通のメールサーバからもメール受け取らないといけないって人は、
メールアドレスを64byteにする感じで。

これで、全てのSpamが止まるって訳じゃないけど、それなりに効果はあるんじゃないかな〜とか。


RFC2821とRFC2822のメールアドレスについて言及しているBNFを抜粋してみたり。

はっきり言って、落ち着いてBNF見れば、
@の前に.(ドット)が使えない事位判るですよ。
BNFの読み方が分らないなら話は別だけども……ねぇ……。
まぁ、RFC2621だけ幾ら眺めても、
メールアドレスにどんな文字列が使えるのか分らないってのは、事実デスガ。


RFC2821 4.1.2 Command Argument Syntax より抜粋
Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
; Note that this form, the so-called "source route",
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
; any CHAR excluding "=", SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
; See section 4.1.3
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
String = Atom / Quoted-string


RFC2822には、明確に書いてあるますな。

ヘッダに入るのは、大体が普通のキャラクタで、そいつらを「atom」と呼び、

.(ドット)が入るのは、「dot-atom」だんせ。と。

つまりは、.(ドット)がatextにゃー入らにゃー、っつう訳どす。


RFC2822 3.2.4. Atom より抜粋
Several productions in structured header field bodies are simply
strings of certain basic characters. Such productions are called atoms.

Some of the structured header field bodies also allow the period
character (".", ASCII value 46) within runs of atext. An additional
"dot-atom" token is defined for those purposes.

atext = ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)

でも、メールアドレスに関する記述は1つ見れば分る
RFC821の方が分り易ったなぁ…と思ったり…。


RFC821 4.1.2. COMMAND SYNTAX より抜粋
<reverse-path> ::= <path>
<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
<at-domain> ::= "@" <domain>
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<mailbox> ::= <local-part> "@" <domain>
<local-part> ::= <dot-string> | <quoted-string>
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig> ::= <a> | <d>
<let-dig-hyp> ::= <a> | <d> | "-"
<dot-string> ::= <string> | <string> "." <dot-string>
<string> ::= <char> | <char> <string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
<char> ::= <c> | "\" <x>
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<number> ::= <d> | <d> <number>
<CRLF> ::= <CR> <LF>
<CR> ::= the carriage return character (ASCII code 13)
<LF> ::= the line feed character (ASCII code 10)
<SP> ::= the space character (ASCII code 32)
<snum> ::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<c> ::= any one of the 128 ASCII characters, but not any
<special> or <SP>
<d> ::= any one of the ten digits 0 through 9
<q> ::= any one of the 128 ASCII characters except <CR>,
<LF>, quote ("), or backslash (\)
<x> ::= any one of the 128 ASCII characters (no exceptions)
<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | the control characters (ASCII codes 0 through 31 inclusive and 127)



ネタ元

RFC821,RFC2821,RFC2822



RFCやら、W3Cの勧告やら、公的な仕様の類を読んで無いのは、

チョトマズイでんなぁ…と言う話でした。

ああ、でもJSFの仕様もEJB3.0の仕様も真面目に全部読んでナイや…。

あぅあ……orz



今日は、LiveDoorはてなに全く同じ内容を書いてみたり。

はてなの方が読みやすいなぁ…とか。よって明日からのエントリは、はてなになるます。