noriyuruの日記: Kipple mail
日記 by
noriyuru
ゴミメールへの対策を検討していて理解したことがある。
それは、電子メールの設計思想は用途に合わせ沢山のメールアドレスを用意せよ、ということだ。
Webサイトを利用するユーザにすればサイトへのアドレスは一つが望ましい。複数あるとどれへ送信すればよいか悩んでしまう。サイトへのメールとサイト運営の企業へのメール送信ですらサービスの規模しだいでは悩むこともある。
これについては、窓口は用途ではない、と解釈するべきだろう。窓口は運営側の“都合”である、と。
用途とはシステムの要求によって定められる。まあ、システムの“都合”だ。
例えばReturn-Pathはシステムの都合で作成する。サイトのサービスが自動生成するメールはサービスの単位で分けたReturn-Pathを付ける。Return-Pathは常に一意でなくとも時間などの識別IDを付加したアドレスでもよい。
こういった方法により各メールアドレスにくる“明確な理由のあるメール”を受け取る。理由が明確なのだから理由なきゴミメールがどれかは確実に分かるし、機械識別が可能となる。
識別ID付きアドレスを受け取り可能なメールサーバーならデーターべースとの連動なども可能となる。
メールの本文やヘッダーへ仕込みを行っても同じ結果が得られかも知れないが、それらは確実ではない。また、メールのフォーマットはプログラムで扱うには面倒で不安定なものである。
サーバー管理者はメールアドレスの自由な発行“も”武器とできる。
それは、電子メールの設計思想は用途に合わせ沢山のメールアドレスを用意せよ、ということだ。
Webサイトを利用するユーザにすればサイトへのアドレスは一つが望ましい。複数あるとどれへ送信すればよいか悩んでしまう。サイトへのメールとサイト運営の企業へのメール送信ですらサービスの規模しだいでは悩むこともある。
これについては、窓口は用途ではない、と解釈するべきだろう。窓口は運営側の“都合”である、と。
用途とはシステムの要求によって定められる。まあ、システムの“都合”だ。
例えばReturn-Pathはシステムの都合で作成する。サイトのサービスが自動生成するメールはサービスの単位で分けたReturn-Pathを付ける。Return-Pathは常に一意でなくとも時間などの識別IDを付加したアドレスでもよい。
こういった方法により各メールアドレスにくる“明確な理由のあるメール”を受け取る。理由が明確なのだから理由なきゴミメールがどれかは確実に分かるし、機械識別が可能となる。
識別ID付きアドレスを受け取り可能なメールサーバーならデーターべースとの連動なども可能となる。
メールの本文やヘッダーへ仕込みを行っても同じ結果が得られかも知れないが、それらは確実ではない。また、メールのフォーマットはプログラムで扱うには面倒で不安定なものである。
サーバー管理者はメールアドレスの自由な発行“も”武器とできる。