日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

未来 >>

メールサーバー間でSMTPS使うの?

メールサーバーに手を入れているときに、GmailではSMTPSで受信したか否かで表示が変わるらしい。

送受信時のメールの暗号化 (Gmail)

暗号化のアイコンの意味ということで書かれているが、

まず、緑色の鍵マークはS/MIMEで暗号化されているということで、これは明確な暗号化である。

ただ、S/MIMEによる暗号化をするには、送受信双方に電子証明書が必要なので、ほぼ使われていないかと。

赤色で鍵が破れた表示になっているのは、平文のSMTPで受信したメール。伝統的なE-mailですね。

その間に灰色の鍵マークがあるが、これはTLSで受信したということを指している。

鍵がかかった絵で描かれているので、Googleの認識はTLSで受信したメールは暗号化されているということらしい。


最初に「SMTPSで受信したか否かで」と書いたのは、あまり適切な書き方ではなかったね。

SMTPSはSSLによって暗号化されたSMTPプロトコルを表す言い方だった。

SMTP+SSL=SMTPSということで、SSLで暗号化されたHTTPSをHTTPSと書くのと同じ。

現在はSSLはTLSと言い方が変わっているので、TLSによって保護された――というのが正しい。

SMTPSと書いた場合、ポート465を使って、いきなりTLSで通信を開始するものを指すのが通常である。

一方で、SMTPは、途中からTLS通信への切り替えを行う STARTTLS というモードを備えている。

この場合、ポート587(サブミッションポート)あるいは、ポート25 でもTLSを使って通信内容を暗号化できる。


そもそも、SMTPはE-mailを他のサーバーに転送するプロトコルである。

ユーザーがプロバイダーのメールサーバーに転送するのも、そこからあて先のメールサーバーに転送するのも同じ。

これが迷惑メールの温床となっていたので、従来のポート25でのSMTPはメールサーバー間の転送のみに使い、

プロバイダーは一般ユーザーのポート25の使用を禁止して(OP25B)、

ユーザーがプロバイダーに接続するにはサブミッションポートという別ポートを使い、何らかの認証をするようにした。

SMTPでパスワード認証を行う SMTP-AUTH の場合、特に認証情報の暗号化の必要性も高いので、

SSL版サブミッションポートとしてポート465が使われることになったそうである。

もっとも、ポート587で必要によってSTARTTLSでTLSに切り替える方が標準的な方法らしいけどね。

必要によって切り替えるといっても、TLSに切り替えないと認証が通らず結局使えないことが多いと思うが。


というわけで、TLSによる暗号化をSMTPに適用するのは、ユーザーがメールを送信するためのものだと思っていた。

ただ、メールサーバー間の転送に使うポート25にSTARTTLSを適用することもできる。

Gmailのメールサーバーではポート25でもSTARTTLSを受け入れ、送信先のメールサーバーがTLS対応ならSTARTTLSを適用しているようである。

理屈上できるなぁとは気づいてたんだけど、実際にやってるところがあるとは、今まで知らなかった。

ましてやそれを一般ユーザーに向けて表示して、TLSが適用されなかった場合は警告的に表示しているとは。


僕がポート25へのSTARTTLSに懐疑的だったのは、メールサーバー間の暗号化は保証できるかもしれないが、

全てのメールサーバーがSTARTTLSに対応しているならともかく、対応していない方が多く、

TLS非対応のサーバーとはメールがやりとりできないとすると、とても使えたもんではない。

さらに、メールサーバーの前後の暗号化も明らかではなく、ここだけ暗号化しても意味はないんじゃないかと。

とはいえ、大昔のメールサーバーはメールサーバーをバケツリレーのように転送していたというけど、

現在はほとんどのE-mailのSMTPのフローは 送信者 → メールサーバー → メールサーバー の2段階で終わり。

送信者のクライアントがメールサーバーに接続するには、今はほとんどTLSが使われているだろう。

そう考えると、実用上は送信者から受信者のメールボックスまでずっと暗号化されてると見てよいと。

Gmailの表示の意図はそういうことなんじゃないか。


すでに、Let's Encryptでまともなサーバー証明書を持っていて、TLS自体はすでにポート465で使っている。

なので、Postfixに少し設定を加えるだけで対応できる。

まず、master.cf。

smtp      inet  n       -       n       -       -       smtpd
   -o smtpd_tls_security_level=may
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_ask_ccert=yes
  -o smtpd_sasl_auth_enable=yes

SMTP(ポート25)はTLSの使用を"may"ということで、使いたければ使えるが必須ではないとする。

一方のSMTPS(ポート465)はさっき書いたようにクライアントの認証用なので、

最初からTLSで、クライアント証明書を要求、パスワード認証を有効という設定をしている。

クライアント証明書またはパスワード認証が成立しなければ、他メールサーバーへの転送を許可しない設定は別途している。

(基本はクライアント証明書での認証だが、互換性の問題でパスワード認証も併用、ただしパスワードはPostfix専用のものにした)

裏返せば、ポート25では認証が成立しないということなので、自分のサーバー宛のメールの受信のみできる。


逆に送信側の設定、こちらはmain.cf。

smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_security_level = may

smtp_から始まる設定は、SMTPクライアントとしてのPostfixの設定を表している。

そちらでTLSの使用について"may"としているということは、こちらも使える場合だけ使うと言うこと。

これを"encrypt", "verify"にすると、STARTTLS非対応のメールサーバーには送信できなくなる。

あと、CA証明書も必要なので、CentOSにバンドルされてるものを指定したけど、

実はTLSの使用について"may"の設定の場合、証明書の検証結果によらずTLSで接続して送っちゃうんだそうだ。

STARTTLS非対応のサーバーにも平文で送るぐらいだし、接続先は疑わしくともTLSで暗号化できるだけマシということか。


この設定をすると、Gmailに送ったとき、灰色の鍵マークで表示され、逆に受け取ったメールには、

Received: from mail-xxxxxxx.google.com (mail-xxxxxxx.google.com [xx.xx.xx.xx])
	by hdmr.org (Postfix) with ESMTPS id xxxxxxxxxx

というヘッダがつき、ESMTPS ということで暗号化して受信されたことが確認出来る。

Thunderbirdで"hdmr.org (Postfix) with ESMTPS"をReceiveに含んでるとマーキングするという設定をして、

参考に見ているけど、届くメールの半分ぐらいがTLSを使ってるみたい。

(Receiveヘッダの偽造まで考えられた厳密な条件ではないので、参考程度の情報だが)

案外、普及してるもんだなと思ったけど、GmailがTLS対応の動機になってたのかもしれない。


あまり意味は無いかも知れないが、平文よりTLSの方がよいのはそうだろう。

現状、平文よりマシという程度の運用なので、STARTTLS対応にしたがために拒否されたということもあまりないだろう。

HTTPSだと証明書の証明期限切れとか起きてると、禍々しい警告が出てくるけど、

それはHTTPSへの期待度が高まった時代だからこそで、以前はここまでではなかったわけだし。

将来的にはどうかわからないけど、SMTPの古さを考えると、なかなか厳しいことも言えないような気はしますね。


Author : Hidemaro
Date : 2019/11/26(Tue) 23:52
コンピュータ・インターネット | Comment | trackback (0)
blog comments powered by Disqus

トラックバック

トラックバックURL取得

Tools