SMTP-AUTH（SMTP認証）とメールの暗号化の概要を理解する

私は qmail で POP before SMTP という古い仕組みを使い続けていたため、SMTP認証とメールの暗号化について理解が曖昧なところがありました。また、Submission(TCP 587)ポートがありますが、なぜSMTP(TCP 25)ポートだけではいけないのかなど疑問がありました。メールサーバを構築する際に不思議に思う方もおられると思います。

今回は、設定のお話ではなく、SMTPサーバーを構築するにあたり私の理解した概略(覚書)をブログにして紹介していきたいと思います。

CentOS7上のPostfixとDovecotでメールサーバーを構築する方法は以下の初回記事から参考にしてみてください。

CentOS 7 で Postfix と Dovecot を利用してメールサーバーを構築する方法

本記事では CentOS 7 をインストールすると最初から入っている Postfix を利用してメールサーバー(SMTP サーバー)を構築する方法を紹介します。MUA (POP...

hrkworks.com

2018-11-03 17:26

参考：
http://www.postfix.org/TLS_README.html
https://ja.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

SMTPについて

ご存じの通り、SMTPとは Simple Mail Transfer Protocol のそれぞれの頭文字の略です。SMTPの歴史は古く、1982年に RFC 821で標準となりました。

当時はその名前の通り、シンプルな仕組みでメールを中継・転送することだけが目的でした。当時はインターネットを使っている人も少なく、「盗聴の危険性」や、「スパムの被害」なども気にしなくとも問題はなかったのでしょう。

このSMTPの通信を大きく分けると、メールクライアント(SMTPクライアント)とメールサーバー（SMTPサーバー）が行う MUA間通信 と、メールサーバー同士が行う MTA間通信 の2種類に分かれます。（※それぞれの通信をこのように呼ぶのは微妙だと感じる方もおられると思いますが、本サイトでは説明の簡略化のためこのように表記して区別し進めます。）

具体的な動きで例を示すと、MUA間通信でメールクライアントがメールサーバーにメールを送信し、MTA間通信でメールサーバーが、別のメールサーバーにメールを転送します。図では、メールを転送するMTA間通信について、主語を「宛先となるメールサーバー」として「メール受信」と記載しています。

現在では、スパム対策や盗聴の対策のため、このSMTPの仕組みの強化(追加仕様)がなされています。

認証や暗号化のタイミング

認証は、MUA間通信で利用されます。認証に成功したクライアントのメールだけを中継するようにメールサーバーを設定することで、スパムメールの踏み台(不正中継)にならないようにします。これがSMTP-AUTH(SMTP認証)です。認証をせずにメール中継できる SMTPサーバーがスパムの踏み台になり、スパムメールを不正に中継してしまいます。

なお、MTA間通信には認証はありません。MTA間通信は、自ドメイン宛でかつメールボックスが存在していれば、全てのメールを受け取ります（ただし、SPAMメールの受信対策を実施することで、SPAMと判定されたメールを破棄することができます）。

暗号化は、MUA間通信、MTA間通信ともに利用可能です。ただし、公開サーバー間のMTA間通信に関して、暗号化の強制を行うと RFC 2487 に違反します。これは、世界中全てのメールサーバーで暗号化するよう対応されなければ、暗号化に対応していないサーバーとのメールの送受信ができなくなってしまうためです。

下記図のMUA間通信（赤い矢印）は暗号化の強制が可能であり、MTA間通信（青い矢印）は暗号化の強制が不可能（非推奨）です。注意したいのは、認証情報(ユーザ名やパスワード)は、暗号化で守ることはできます。しかし、メールの本文は暗号化ができないMTA間通信があれば、漏洩する可能性があるということです。

以下では、さらにSMTPを「認証」と「暗号化」の観点でさらに詳しく見ていきます。

認証

スパムメールの踏み台にならないためには、MUA間通信 においてメールサーバー（SMTPサーバー）に、何らかの形で認証機能が必要になります。今どきはほとんどないと思いますが、もし、クライアントが SMTP-AUTH機能に対応していない場合でも、POPの認証を利用することもできます。また、メール送信（中継）を許可するネットワークを、自ネットワーク（ローカルネットワーク）のみとすることでもスパムの対策になります(この場合、モバイルで外部から送信するには、VPNなどで内部ネットワークに接続する必要があります。)

SMTP認証（SMTP-AUTH）

今まで認証機能がなかった SMTP に、MUA間通信を開始する際に SASL メカニズムを利用した認証を行うように拡張された仕組みが RFC 2554(最新 RFC 4954) として標準化されました。

SASLとは、Simple Authentication and Security Layer の略でコネクション型のプロトコルに対して認証機能を提供します。この仕組みを利用することで、認証されたユーザしかSMTPサーバーへメール送信を依頼することができなくなります。

ただし、サーバー側の対応だけではなく、クライアント側も SMTP-AUTH に対応している必要があります。

認証には、CRAM-MD5,LOGIN,PLAIN などの方式があります。LOGIN や PLAIN認証のようにパスワードを平文で流す場合は、後で説明する暗号化が推奨されます。

POP before SMTP

10年以上前によく使われていました、私は最近まで使っていました。昔から認証機能のあるPOP3（メール受信）の認証を利用する方法です。POP3の認証が成功したユーザを正規ユーザとみなし、SMTPサーバーへメール送信を許可する仕組みです。

この仕組みは、最低サーバー側だけ対応すればよく、クライアント側は POP Before SMTP に対応していない場合でも、「SMTP送信の前にPOP3 の受信を成功させておく」という簡単な手順で認証を実施することができます。

実装としては、POP3で認証が通ったIPアドレスからの SMTP 送信を、一定期間の間許可するようなものとなります。

OP25B

Outbound Port 25 Blocking の略です。認証や自宅サーバーで行うスパム対策ではありません。プロバイダーが実施するスパム対策（メール送信の規制）になります。プロバイダー契約を行っているユーザが悪意を持ってまたは、ウィルス感染によりスパムメールを送信することをブロックするために、インターネットに抜ける SMTP(TCP 25) の通信をふさぐ仕組みです。

AWS上にメールサーバーを構築すする際も、Amazonに OP25B を解除する申請をする必要があります。(https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-port-25-throttle/)

この仕組みが施されているプロバイダでは、自宅サーバーにメールサーバーを構築してもメール送信ができません。一度プロバイダの SMTPサーバーを踏んだり、gmailを踏んだりして回避する必要があります。

固定IPを契約した場合、OP25Bの規制対象外のプロバイダもあるようです。詳しくは契約中のプロバイダに確認してください。

暗号化

ユーザ名やパスワード、メールの内容を盗聴されないように、MUA間通信 と MTA間通信 でそれぞれ設定する必要があります。ただし、すでに述べたように、MTA間通信は、昔ながらのSMTPサーバーが残っているため、一方的に暗号化を強制することはできません。

そのため、Postfixで設定する場合には、暗号化通信の設定( smtpd_tls_security_level )に関しては、「暗号化を使えたら使ってね！」(任意：may)という設定をするのがベストアンサーになります。

これにより、Postfixでは SMTP(TCP 25)ポートは任意で暗号化するようになるため、クライアントが SMTP(TCP 25)ポートを利用する場合、暗号化を設定していないと平文での通信が可能になってしまいます。

SMTP over SSL

SSLで暗号化されたSMTPの暗号化通信をおこなう専用のポート(TCP 465)です。SSL対応したメールクライアントが必要です。通信は最初から暗号化されており、SMTP-AUTH にてPLAIN認証を使っても、ユーザ名とパスワードはもちろん、メール本文も SSLで暗号化されています。

STARTTLS

一般的に、Submissionポート(TCP 587) で暗号化する際に利用されます。シーケンスは途中まで平文で実施され、そこで暗号化を促します。Postfix では、Submission の smtpd_tls_security_level を encrypt に設定することで、暗号化できないクライアントとの接続を拒否することができます。なお、この設定も SMTP(TCP 25)ポート同じように、may を設定することで、暗号化できないクライアントとも通信が出来るようになります(その場合は平文で流れます)。

前述の通りクライアントのとの通信(MUA間通信)は暗号化が強制可能です。encrypt を設定して暗号化を強制した運用をするのがおすすめです。

最後に

こう見ていくと SMTP-AUTH 対応(もしくは、POP before SMTP対応)した SMTP(TCP 25) を STARTTLS を may で運用するだけでも十分な気がしませんか？というか私はそう思い続けていました。なぜ、Submission(TCP 587) もしくは、SMTPs(TCP 465)をわざわざ用意する必要があるのでしょうか。ここで、認証のところで少し触れたOP25Bが関係してきます。

たとえば、出張先のホテルなどが契約しているプロバイダが、スパム対策としてOP25Bを採用している場合があります。この場合、MUA間通信で、自宅サーバーのSMTP(TCP 25)ポートにメールを送ろうとすると、ホテルのプロバイダからOP25Bによりブロックされ、独自ドメインでのメール送信ができません。そんなときは、Submission(TCP 587) もしくは、SMTPs(TCP 465)が役に立ちます。昨今のメール事情では、MUA間通信には Submission(TCP 587) もしくは、SMTPs(TCP 465) を用意しておくべきでしょう。

雑な説明になりますが、MTA間通信では昔ながらの SMTP(TCP 25)を STARTTLS を may で利用し、MUA間通信では Submission(TCP 587) もしくは SMTPs(TCP 465) を利用すると理解しておけばよいでしょう。