メールサーバに関する技術等のまとめページです。（個人的なメモも含みます）
記載されている情報について誤った情報が記載されている場合はご連絡頂けると助かります。
記載されている情報の正確さは保証しておりません。また個人的な感想や意見も多大に含まれております。
各技術は RFC などの原文も合わせてご参照ください。

SPF/Sender ID
2006/11/17 Written by A.K.I Software(H.Matsuda)

SPF (Sender Policy Framework) は、PoBox.com の Meng Weng Wong 氏が提唱した送信者認証技術で Sender Policy Framework の略。DNS サーバの TXT タイプにドメイン単位で配信を行うサーバなどの情報(SPF情報)を登録し、受信側のサーバで SMTP プトロコルで使われる MAIL FROM コマンドで指定されるメールアドレスのドメインと SPF情報を参照して、送られてきたメールが本来のドメインが管理しているサーバから送られてきた物かを確認します。
Meng Weng Wong 氏が提唱した SPF を Sender ID と区別し、SPF Classic と呼ぶ場合があります。

のちに Meng Weng Wong 氏の SPF と Microsoft社 が提唱する Caller ID for Email をあわせて、Sender IDと言う規格が定められました。
現在 SPF/Sender ID と呼ばれるものはこれを指します。
当初は、Microsoft社が持つ特許技術 PRA(Purported Responsible Address)が含まれた為にライセンスの問題が発生して規格制定は一時中断される自体となりました。
その後、Microsoft社がライセンスの条件を変更したりしています。一応ライセンス契約は必要ですがロイヤリティフリーと明言されています。が、はっきりとしていない部分もあるので微妙です。

SPF(Classic) と Sender ID の違いは殆どありませんが、受信側サーバでチェックする箇所が違います。
Sender ID の場合 メールヘッダ中の情報も参照する場合 PRA方式となり、Microsoft社が持つ特許技術に抵触するようです。
これまた、Microsoft社が明言していないので、判断が難しいところですが、PRA方式の場合は Microsoft社とライセンス契約を結ぶ必要があり、MAIL FROM のみで判断する場合は、Microsoft社の特許技術(PRA)に抵触しない為、ライセンス契約を結ぶ必要がないようです。

SPF情報を DNS で公開する行為はなんら制限はかけられておりません。

SPF/Sender ID 共にフィッシングメールなど、差出人を詐称してメールを送り受信したユーザーを騙すメールに対して効果があります。
spam 対策として扱われますが、spam を送信しているメールサーバが SPF情報を登録している場合には効果はありません

導入は比較的用意で、認証情報を公開する側は DNS に TXT タイプを登録するのみで可能で、受信側は受信時に DNS へ問い合わせを行い確認をするだけです。（技術的にも対応は楽です）
SPF情報はそうそう更新されるものではありませんのでサーバ側でキャッシュしておくことにより DNS への負荷を低減することができます。また確認作業は単純比較となりますのでCPUパワーもそれほど使いません。
本来の SPF/Sender ID では条件によって受信を拒否したりするのですが、PMail Server の場合、サーバ側で SPF Classic で確認を行い、その情報をヘッダに書き込みを行い、専用Webmail 側でその情報を参照して表示するような仕組みを入れています。（サーバとクライアントを一緒に開発している強みですね*smile*）「受信は寛大に、送信は厳しく」がもっとーですのでこういうメカニズムなので受信拒否します。ってのはどーかと。海外じゃ知りませんが日本国内のISPなどがこれをやったら電気通信事業法に引っかかるのではないかと思うのですが。（SPF Classic はコマンド中のメールアドレスから認識する訳ですが、そこで拒否したとしてもそれは相手側サーバから明確に条件が示されていますので良い気もします。ただ PRA の場合メールヘッダの中身を見る訳なので検閲に当たらないかなぁ、と。）

DKIM
2006/11/17 Written by A.K.I Software(H.Matsuda)

DKIM(DomainKeys Identified Mail) は、Yahoo社が提唱した、DomainKeys と Cisco Systems社が提唱した Identified Internet Mailという技術をあわせた物。
メールに電子署名を行い DNS に登録されている公開鍵と比較し正当性の確認を行うもの。
メールを直送する場合は、きちんと正当性の確認が取れるので非常に安全。
(個人的に DKIM には疑問点が山盛りなので批判的な文章になっているのはご了承を)
その半面、最近のメールサーバ事情（Dynamic DNS でのメールサーバ構築）などの場合、Outbound Port 25 Blocking が実施されている場合、直送できませんので中継するサーバで再認証をしてくれないとヘッダ情報が書き換わり署名が破壊されます。ちまたでも言われていますがメーリングリストなどメールの件名などを変更する場合なども同様に署名が破壊されるので署名の正当性が正しく行えない場合が多いんじゃないでしょうか？と思っています。
署名範囲の制限とかもできるようですが、範囲を制限したらそれこそ正当性の質が落ちると思うのですが。
SMTP Gateway タイプの spam フィルタ製品とか通しても軽く壊れそうですし。
ISPなどの中継サーバが再認証してくれる場合の中継サーバのCPU負荷も馬鹿にならないと思います。（メールの内容をパターンマッチングして行うフィルタよりは全然マシですが）
ただ、PGP/MIME や S/MIME のように内容が書き換えられていないや、暗号化され中身を第三者に見られる心配が無いような仕組みであればいいのですが、ここまでやって「差出人は正しいとわかるかもしれない」レベルなのでメールサーバを作る側からしてみると「面倒過ぎです」の一言です。ある程度はコード組みましたが完成には程遠いです・・・
DKIM が必須なんてことになったら、なにかの陰謀です。

SMTP over TLS/POP3 over TLS
2006/11/17 Written by A.K.I Software(H.Matsuda)

メールサーバとメールクライアントの間を TLS 通信によって安全に通信を行う物。
http と https のようなものです。
PMail Server2 は MTA for SSL/TLS が利用できますので、配信先のサーバーが SSL/TLS に対応している場合は、安全に送信が可能ですが、全てのサーバーが SSL/TLS に対応している訳ではなく、その場合は平文で送受信される為、完全に安全って訳ではありません。
素直に、PGP/MIME や S/MIME 使う方が安全な気がします。