電子メイルを利用している人なら、スパムと呼ばれる見知らぬ企業や人からの広告のダイレクトメイルをもらったことがあるでしょう。このようなメイルを送る人達は自分のメイルサーバから送るとそのサーバがブラックリストに載り、受信を拒否されてしまうため、頻繁にアドレスを変えたり、第三者のサーバを不正に使用して送信したりします。第三者のサーバを利用すると、送信する人は一通のメイルを送るだけで、そのサーバが大量のメイルをばらまいてくれます。その踏み台になったサーバは大量の資源をそのために食い潰されます。一方、スパムに対する対策として、そのような不正なメイルの中継を許可するサーバそのものもブラックリストに載せ、そこからのメイルも拒否するという組織もあります。スパムを受け取る側としては第三者による不正中継を許可しているサーバも共犯というわけです。そのため、すべての組織のサーバが不正中継を認めないようにすることが望まれています。
第三者による不正中継を防ぐ手段としては、その組織の外部からの中継を一切認めないのが原則です。しかし、様々な理由により、その組織の正規ユーザが外部から送信したい場合があります。そのため、ここでは、正規ユーザのみが送信できる方法についてまとめてみたいと思います。
RFC 2554 "SMTP Service Extension for Authentication"が本命です。SMTP に対して認証を行う "AUTH" コマンドの拡張を定義したものです。認証には SASL (RFC 2222 "Simple Authentication and Security Layer") を用います。ElysiuM deeZine 氏による調査結果を見ると、サーバ側（オープンソースなもの）ではだいたい実装できるいるようです。クライアント側では滝澤による調査結果（Windows 用のメイラーのみ）に示す通り、いくつかのメイラーで実装が始まっています。平文でない安全な認証プロトコルとしては "CRAM-MD5" だけがほぼ共通で使えるようです。
SMTP-AUTH の実装が普及するまでのつなぎの方法だと思われるのがこの POP before SMTP です。POP3 の認証を利用して、正規ユーザの確認を行う方法です。そのため現状のサーバ/クライアントの仕様に少々手を加えるだけで簡単に実装できます。そのため具体的には規格化されているわけではありませんが、その方法が RFC 2476 "Message Submission" の "3.3. Authorized Submission" に記述されています。
POP before SMTP ではサーバ側ではおよそ次のようなことを行います。SMTP の中継を許可する IP アドレスを登録するデータベースを用意します。POP3 の認証後にこのデータベースにアクセス元の IP アドレスを追加します。SMTP の送信時にサーバはアクセス元の IP アドレスがデータベースに登録されているか確認し、登録されていれば中継を許可し、登録されていなければ中継を拒否します。この IP アドレスがデータベースに登録されたままだと他の人が中継できてしまうので、一定時間後にその情報を削除します。
一方、クライアント側では、送信前に受信を行えばよいだけです。この操作を手動でやってもよいですし、MUA によっては送信前に自動的に受信を行うものもあります。さらに、実際には受信は行わずに POP3 の認証のみを行ってくれるものもあります。滝澤による調査結果（Windows 用のメイラ─のみ）を見ると POP before SMTP を機能として実装しているものがたくさんあります。
現状ではこの POP before SMTP を採用する組織が増えつつあります。しかし、注意しなければならないのは、POP before SMTP はあくまでも POP3 の認証元のホストを保証するものであり、SMTP のセッションそのものが正規なものであるかは保証しないことです。
かつて Internet-Drafts として提案された "POP3 XTND Extensions" というものがあります。これは POP3 を "XTND" というコマンドで拡張する規格で、そのなかで、"XTND XMIT" という送信を行うコマンドが規定されています。一部のサーバやクライアントで実装されています。しかし、現在はこの方法をやめて、先に述べた SMTP-AUTH を使う方向で進めようという考えになっています。
RFC 2487 "SMTP Service Extension for Secure SMTP over TLS" に規定されている方法で、TLS を用いる方法です。TLS とはTransport Layer Security の略でウェブブラウザでよく使われている SSL 3.0 に基づいて規格化されており、RFC 2246 "The TLS Protocol Version 1.0" に規定されています。その機能としては証明書によるサーバやクライアントの確認が可能で、さらに通信路を暗号化してくれます。従って、この TLS を使うことで SMTP の送信者の確認を行うことが原理的に可能です。
実際の実装状況はどうかというと一部の MTA / MUA では実装されています。しかし、クライアントの証明書による送信者の確認を行っているのかは筆者の方では確認していません。ご存じの方は教えてください。ただし、WWW における SSL の使い方を見ていると、サーバの証明はよく行われていますが、クライアントの証明はほとんど見かけません。各クライアントが CA (認証機関)に対してデジタル ID を取得する必要があるので、クライアントのコスト面/作業面での負担が生じます。そのため、SMTP over TLS/SSL においてクライアントの証明が行われるかはその実効性として少々疑問に思います。