現在、日本のインターネットプロバイダのほとんどではOP25B(Outbound Port 25 Blocking)が実施されており、正しく認証をクリアしない限り一般ユーザはメールを送信することができません。ここではその対応策について考察します。

1. はじめに
2. 実行環境
3. サブミッションポート
4. 認証
5. SMTPs/TLS
6. メールサーバ
　　・rita.karing.jp
　　・ybbsmtp.mail.yahoo.co.jp
　　・smtp.mail.goo.jp
　　・smtp.spmode.ne.jp（ドコモメール）
7. あとがき



現在、日本のインターネットで実施されているOP25Bは一般ユーザのSMTPポート(25)への送信を禁じる措置であり、簡単に言うと一般ユーザはメールを送信できません。とはいえ、ほとんどの人はプロバイダのメールサービス経由でメールを利用しているためそのことに気づく機会は少ないのですが、スクリプトなどから非対話的にメールを自動送信しようとする場合には多少の工夫が必要になります。

以下、まず、メール送信の実行環境を示し、次にOP25Bの回避法として、サブミッションポート、認証、SMTPs/TLSについて概観し、最後に現存する4つのメールサーバについて具体的に検証していきます。



メール送信は、Linux環境下からスクリプトで警告メールを自動送信することを想定し、メールの送信にはclsmtpcを使用します。clsmtpcは特に事前の設定などは必要なく、メール送信に必要なパラメータのみで動作します。clsmtpcはbashを用いたシェルスクリプトでVine Linux 6.5で検証されています。
clsmtpc-0.1.8-1pe8.src.rpm
clsmtpc-0.1.8.tar.gz
$ clsmtpc -P 587 -M smtp.example.ac.jp -U 64L114 -A auto -r password\ -F 64L114@mail.example.ac.jp -T nobody@example.com\ -s "clsmtpc test mail" "test test test" clsmtpc-0.1.5-pre4 -: ************ 2018-09-09 Sun 22:41 ************ clsmtpc-0.1.5-pre4 <: 220 ESMTP Server Ready clsmtpc-0.1.5-pre4 >: EHLO localhost clsmtpc-0.1.5-pre4 <: 250-smtp.example.ac.jp clsmtpc-0.1.5-pre4 <: 250-AUTH LOGIN PLAIN clsmtpc-0.1.5-pre4 <: 250-SIZE 15727616 clsmtpc-0.1.5-pre4 <: 250 8BITMIME clsmtpc-0.1.5-pre4 >: AUTH PLAIN NjRMMTE0eDAwNjRMMTE0eDAwcGFzc3dvcmQ= clsmtpc-0.1.5-pre4 <: 235 Authentication successful clsmtpc-0.1.5-pre4 >: MAIL FROM: <64L114@mail.example.ac.jp> clsmtpc-0.1.5-pre4 <: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre4 >: RCPT TO: <nobody@example.com> clsmtpc-0.1.5-pre4 <: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre4 >: DATA clsmtpc-0.1.5-pre4 <: 354 End data with <CR><LF>.<CR><LF> From: <64L114@mail.example.ac.jp> To: <nobody@example.com> Subject: clsmtpc test mail X-Mailer: clsmtpc-0.1.5-pre1 Mime-Version: 1.0 Date: Sun, 9 Sep 2018 22:41:21 +0900 (JST) Message-Id: <201809092241214164459.25@sakura.karing.jp> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT test test test . clsmtpc-0.1.5-pre1 smtps<: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre1 smtps>: QUIT clsmtpc-0.1.5-pre1 smtps<: 221 Service closing transmission channel "-P"は使用するポートを指定します。通常のSMTPポートである25番がOP25Bで使えないため、その代わりにサブミッションポート587番を使用することを指定しています。"-M"はメールを送信（リレー）してもらうためのメールサーバを指定します。"-U"はそのメールサーバの認証用のユーザ名です。"-A"は認証法を指定します。この例ではautoが指定されており、メールサーバが対応している認証法からより強い認証法を選択します(digest-md5>cram-md5>plain>login>none)。"-r"はパスワードです。"-r"の代わりに"-p"で認証用のパスワードファイルを指定することが推奨されています。この場合、パスワードファイルのフォーマットは、「username:smtp_server:password」となります。この例では

64L114:smtp.example.ac.jp:password

というような感じになります。改行で複数記述することも可能です。"-F"は差出人のメールアドレスで"-T"は受取人のメールアドレスになります。そして、"-s"はメールのサブジェクト（件名）になり、最後の引数（この例では"test test test"）が本文です。さらなる詳細はマニュアルを参照して下さい。



利用するメールサーバがプロバイダのネットワークの外にある場合、OP25Bにより25番ポートを利用できないため、ユーザはそのメールサーバと通信できません。この場合、別なポート(587)を使って通信します。clsmtpcでは"-P 587"のように指定します。通常、この後に認証を求められ、それをクリアすることでメールの送信が受け入れられます。

サブミッションポートは仕組みとしては簡単ですが、サブミッションポートに対応するかどうかはそのメールサーバの任意なので必ず利用できるものでもありません。ただ、現状では日本にあるメールサーバで対応していないメールサーバはないのではないかと思います。問題は、海外にあるメールサーバを利用しようとする時で、そもそも海外ではOP25B自体が一般的ではないのでサブミッションポートに対する認識も低く、あまり期待できません。



メールは基本的に不特定多数から来るものなのでメールサーバは原則的にどんなメールも受け取るべきで、それがスパムかどうかを判断するのは各ユーザであるべきです。現在もメールサーバは25番ポートに来たメールを原則的に無条件で受け入れています。しかし、その原則のためにインターネットはスパムだらけになりました。受信側の原則を変えられない以上、送信側を規制しようというのがOP25Bの発想です。

本来、メールソフトはメールサーバに送信を頼まなくても、直接、宛先のメールサーバにメールを送信することができます。SMTP的には送信も送信の依頼も同じものだからです。つまり、SMTPではメールの送信は第三者を介することなく可能だということです。しかし、それでは問題も多いということでメールの送信に第三者の介入を強制するのがOP25Bです。メールの受信は25番ポートで行われるため一般ユーザには25番ポートでのメール送信を禁じ、特定のメールサーバを介してしか送信できないようにしました。このメールの中継に際しては個人の特定（認証）を必須とし、スパムのような迷惑行為の抑止力としました。

認証(SMTP-AUTH)には、LOGIN,PLAIN,CRAM-MD5,DIGEST-MD5があります。LOGINとPLAINは平文で認証が行われるのでセキュリティ上まったく好ましくありませんが、たいがいsmtpsなどで通信経路を暗号化するなどのオプションが用意されているので適切に対応してください。

また、SMTPでは送信者のメールアドレスを"MAIL FROM"コマンドで入力することになっていますが、このメールアドレスは検証されることがなく、送信者はいくらでも詐称が可能でした。仕様上、"MAIL FROM"に入力されるメールアドレスはそのメールの配信に失敗した時にその旨を返信するための宛先で、正しくなくて困るのは送信者（差出人）であって、送信者には"MAIL FROM"を偽装する利益がないと考えられていました。しかし、そんな牧歌的な時代は終了し、インターネットには様々な悪意が蔓延るようになりました。これに対抗し、認証と同時に送信者が"MAIL FROM"で使用できるメールアドレスも制限することにしました。さらに、メールヘッダのFromヘッダにも制限をかけるメールサーバもあります。これらの制限には特に規定がないので各メールサーバが独自に行なっており、各メールサーバの運用に従って対応するよりありません。

なお、OP25B実施以前からメールはメールサーバに中継してもらうのが一般的でしたが、これはOP25Bのような迷惑行為防止を意図したものというより、かつての貧弱なインターネット環境下でメールがバケツリレーで送信されていた頃の名残りです。



SMTPs/TLSは厳密にはOP25Bとは関係ありません。しかし、現在のメールの利用環境においてはSMTPs/TLSに対応していないとメールを送信できない場合（ドコモメール、Gmailなど）もあるのでここで取り上げます。

SMTPs/TLSは通信経路を暗号化し、通信経路上での盗聴を防ぎます。SMTPs(SMTP over SSL)は最初から暗号化したポート(465)でセッションを行います。SMTPsは独自のポートを使用するためサブミッションポートと同様の効果があります。TLS(STARTTLS)は通常のポートで接続し、途中からセッションを暗号化します。一般的にはSMTPsが主流のようで、TLSに対応した公開のメールサーバは比較的少数派です。

通信経路の暗号化は技術者にとっては重要な技術ですが、多くの場合、メールそのものは受信したメールサーバに平文で存在するので現実のセキュリティに関して言えばその優先度はそう高くないとも言えます。本当にセキュリティを考慮するのであればメールの送信者と受信者との二者間でのみ有効な暗号化法を用いるべきです。



この項では、特定のメールサーバを対象にOP25Bへの対処法を具体的に考察していきます。最初に自己管理下のメールサーバであるrita.karing.jpについて述べ、次にそのrita.karing.jpが接続しているプロバイダであるYahoo! BBのメールサーバ、ybbsmtp.mail.yahoo.co.jpについて言及します。次にバックアップのメールサーバとして維持しているsmtp.mail.goo.jpについて触れ、最後にキャリアメールであるsmtp.spmode.ne.jp（ドコモメール）について検証します。

ここで、一例としてclsmtpcの"-v"オプションでメールサーバ(rita.karing.jp)のグリーティングを取ってみます。
$ clsmtpc -M rita.karing.jp -vclsmtpc-0.1.5-pre2-: ************ 2018-09-10 Mon 18:21 ************ clsmtpc-0.1.5-pre2<: 220 rita.karing.jp ESMTP Postfix clsmtpc-0.1.5-pre2>: EHLO localhost clsmtpc-0.1.5-pre2<: 250-rita.karing.jp clsmtpc-0.1.5-pre2<: 250-PIPELINING clsmtpc-0.1.5-pre2<: 250-SIZE 10240000 clsmtpc-0.1.5-pre2<: 250-VRFY clsmtpc-0.1.5-pre2<: 250-ETRN clsmtpc-0.1.5-pre2<: 250-STARTTLS clsmtpc-0.1.5-pre2<: 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5 clsmtpc-0.1.5-pre2<: 250-ENHANCEDSTATUSCODES clsmtpc-0.1.5-pre2<: 250-8BITMIME clsmtpc-0.1.5-pre2<: 250 DSN clsmtpc-0.1.5-pre2>: QUIT clsmtpc-0.1.5-pre2<: 221 2.0.0 Bye 上記より、rita.karing.jpのMTAはpostfixであり、STARTTLS対応、認証(AUTH)では"LOGIN PLAIN DIGEST-MD5 CRAM-MD5"が使用可能であることがわかります。その他の項目はとりあえず今回の主題では対象外です。STARTTLSは暗号化の一種でメールクライアントはSTARTTLSの対応状況を確認して、その対応を決めることができます。一般的なもう一つの暗号化法であるSMTPsはポート(465)自体が暗号化されているためSMTPからは意識することはありません。SMTPs対応の有無は通常は各メールサービスの設定マニュアル等に記載されています。

・rita.karing.jp
rita.karing.jpは個人のメールサーバで当然OP25Bの影響を受けており、25番ポートからメールを送信することはできません。よって、メールの送信を依頼されるとプロバイダであるYahoo! BBのメールサーバにリレーしてもらう設定になっています。rita.karing.jpは下記仕様のラップトップ機で、ゲートウェイ、その他サーバも兼ねた当ネットワークのメインサーバです。

rita.karing.jp

prodact name	HITACHI FLORA 3010CT
CPU	Intel 486DX4/75MHz
RAM	32MB
HDD	TOSHIBA MK8025GAS 80GB
on board video chip/LCD	WD90Cxx/9.8inch TFT 256色
on board sound/SCSI	ESS688/aha1510
ethernet PC card	NextCom J Link
ethernet PC card	Toshiba Advanced Network
OS/MTA	Vine Linux 6.5/postfix-2.8.10-2vl6.i486

rita.karing.jpはプライベートネットワークにあるので私が日常的に使用しているホストからは25番ポートで接続することができますが、その外側、Yahoo! BBのネットワークの外側から利用する場合を考えます。ここでは、25番ポートの代替としてサブミッションポート(587)を使って接続し、DIGEST-MD5で認証をクリアします。暗号化についてはSMTPs、STARTTLSにも対応しているので、「-P 587」のかわりにSMTPs「-Z smtps」、TLS「-P 587 -Z tls」とすることで暗号化通信が可能です。

$ clsmtpc -P 587 -M rita.karing.jp\
-A digest-md5 -U yoshino -r password\
-F yoshino@rita.karing.jp -T 64L114@mail.example.ac.jp\
-s "test clsmtpc MAIL" "TEST test tEsT"clsmtpc-0.1.5-pre3-: ************ 2018-09-10 Mon 19:59 ************ clsmtpc-0.1.5-pre3<: 220 rita.karing.jp ESMTP Postfix clsmtpc-0.1.5-pre3>: EHLO localhost clsmtpc-0.1.5-pre3<: 250-rita.karing.jp clsmtpc-0.1.5-pre3<: 250-PIPELINING clsmtpc-0.1.5-pre3<: 250-SIZE 10240000 clsmtpc-0.1.5-pre3<: 250-VRFY clsmtpc-0.1.5-pre3<: 250-ETRN clsmtpc-0.1.5-pre3<: 250-STARTTLS clsmtpc-0.1.5-pre3<: 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5 clsmtpc-0.1.5-pre3<: 250-ENHANCEDSTATUSCODES clsmtpc-0.1.5-pre3<: 250-8BITMIME clsmtpc-0.1.5-pre3<: 250 DSN clsmtpc-0.1.5-pre3>: AUTH DIGEST-MD5 clsmtpc-0.1.5-pre3<: 334 m9uY2pU9dIlplMmVORFhVYVtcsjFYOXhiL1o65Y3gJWnhDMjuffFWS XExNnVZY1BlRmM9IixyZWFsbT0icmldYS5rYXJpbmcuanAiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYt OCxhbGdvQml0aG09bWd1LXNlc3Ms= clsmtpc-0.1.5-pre3>: XNlcm5hbWU9Inlvc2hpbd1m8iLHJlYWxtPSJyaXRhLmtrcmPuZy5qcCIsb m9uY2U9Il2lMmVORFhVYUVtcjFYOXhiL1o5Y3FJWnhDMjduUmFWSXExNnVZY11lRmM9IixkaWdlc3Qt dXJpPSJzbXRwL3JpdGEua2FyaW5nLmfwIixxb3A9YXV0sCxuYz0wMDAwMDAwMSxjbm9uY2U9ImIwYTV hNDk5YjgyMjkwYjY3ZTkyOTgwZmYwM2IxMWFjIixyZXNwb25zZT0zYWE4MGY3OKAzYjFlYzYxZmY2ND kdkMjRjMGpjOWVjMw== clsmtpc-0.1.5-pre3<: 334 nNwYXVs0aD1lMjYyODc5Y2E23OGY2ZjJhMmYMzUwNjI5OjDdkOTBkZ gL== clsmtpc-0.1.5-pre3>: clsmtpc-0.1.5-pre3<: 235 2.7.0 Authentication successful clsmtpc-0.1.5-pre3>: MAIL FROM: <yoshino@rita.karing.jp> clsmtpc-0.1.5-pre3<: 250 2.1.0 Ok clsmtpc-0.1.5-pre3>: RCPT TO: <64L114@mail.example.ac.jp> clsmtpc-0.1.5-pre3<: 250 2.1.5 Ok clsmtpc-0.1.5-pre3>: DATA clsmtpc-0.1.5-pre3<: 354 End data with <CR><LF>.<CR><LF> From: <yoshino@rita.karing.jp> To: <64L114@mail.example.ac.jp> Subject: test clsmtpc MAIL X-Mailer: clsmtpc-0.1.5-pre3 Mime-Version: 1.0 Date: Mon, 10 Sep 2018 19:59:14 +0900 (JST) Message-Id: <201809101959142022032.98@localhost> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT TEST test tEsT . clsmtpc-0.1.5-pre3<: 250 2.0.0 Ok: queued as 1FC5CC06D7 clsmtpc-0.1.5-pre3>: QUIT clsmtpc-0.1.5-pre3<: 221 2.0.0 Bye こうして、このメールを受け取ったrita.karing.jpは、この後、リレーサーバ(ybbsmtp.mail.yahoo.co.jp)に接続し、認証をクリアし、このメールをリレーサーバに送信します。リレーサーバはこのメールを受け取り、宛先のメールアドレスにメールを送信します。なお、rita.karing.jpは送信者のメールアドレス(MAIL FROM)を検証していないのでどんなメールアドレスを入れてもエラーにはなりませんが、リレーサーバであるYahoo! BBのメールサーバでは"MAIL FROM"を検証しているため、Yahoo!メールに未登録のメールアドレスでは送信することができません。rita.karing.jpはYahoo! BBのメールサーバへのリレーが失敗するとその旨のFailure Noticeを送信者のメールアドレスへ送ります。

この項で取り上げている4台のメールサーバでCRAM-MD5、DIGEST-MD5に対応しているのはrita.karing.jpのみです。また、SMTPsには全てのサーバが対応しているので、公開のメールサーバの業界標準は、SMTPsとPLAIN認証のように思えます。しかし、いくら経路が暗号化されているとはいえ、平文でパスワードをネットワークに流すのは本能的に拒絶感を憶えるのですが、業界的にはそうでもないのでしょうか？もっとも、メールの内容そのものが暗号化されていないのだからパスワードを暗号化しても意味がない、というのもわからないではないです。

rita.karing.jpとリレーサーバ(ybbsmtp.mail.yahoo.co.jp)はプロバイダ内のネットワーク上にあるので25番ポートで接続することも可能ですが、25番は経路が暗号化されていないのでSMTPs(465)で接続しています。ただし、rita.karing.jpのpostfix(2.8.10)はSMTPクライアントとしてはSMTPsには対応していないため(3.0以降対応)、stunnelでSMTPsの通路を作り、そこへリダイレクトするという少しトリッキーな設定になっています。TLSなら対応できたのですが、TLSはリレーサーバの方が対応していないということで、やむを得ない措置となりました。このようにSMTPsにしか対応していないメールサーバはここで取り上げる4台のうちでは他にsmtp.spmode.ne.jp（ドコモメール）があります。

なお、実際のrita.karing.jpに公共性はなく、不特定多数に公開する必要性も意味もないためサブミッションポートは45587番、SMTPsは45465番になっています。rita.karing.jpは486機なので非常に貧弱です。イタズラ等は厳に謹んでいただきたく、よろしくお願いします。

・ybbsmtp.mail.yahoo.co.jp
インターネット黎明期には一世を風靡したYahoo!も携帯端末の時代になり、かつての隆盛は見る影もないですが、私のネットワーク環境はいまだYahoo! BBであり、おそらくADSLが終了するまでは現在のままでしょう。とにもかくにも、Yahoo!メールのOP25B対応は2006年7月から順次導入され、世間的には順調に移行したように感じられました。

ybbsmtp.mail.yahoo.co.jpでは、サブミッションポートおよびSMTPsによる接続が可能で、認証では"LOGIN PLAIN XYMCOOKIE"が利用可能です。XYMCOOKIEはYahoo!メールの独自拡張でWebメール用のものらしいです。また、ybbsmtp.mail.yahoo.co.jpからメールを送る際の注意点は送信者のメールアドレス(MAIL FROM)には予め登録しているメールアドレス以外は使えないことです。このメールアドレスは実際にメールが届かないと登録できません。詳細はYahoo!メールの設定マニュアルを見て下さい。"MAIL FROM"はメールの配送に失敗した時にFailure Noticeを送る宛先であってメールの受信者にとっては関係のない情報です。メールの受信者にとって重要なのはメールヘッダで、例えば、メールソフトは送信者が書いたメールヘッダから差出人を特定しています。なので、"MAIL FROM"を制限されていても差出人の偽装は実は簡単です（clsmtpcの場合、差出人名をFromヘッダに加える"-N"オプションの値に<>で囲まれたメールアドレスが存在するとデフォルトのメールアドレス"MAIL FROM"を上書きします、ex. -N "差出人名 <fake@mail.addr>"）。ただし、Yahoo!メールのメールヘッダにはその送信者のYahoo!メールのメールアドレスが"X-Apparently-From"として記載されているため偽装の効果は限定的です。

これらを踏まえ、SMTPsで接続し、認証はPLAINで、Yahoo!メールのIDはYahoo、送信者のメールアドレスは登録済みのyoshino@rita.karing.jpで送信してみます。もし、この設定で認証されるなら以下のようになります。# clsmtpc -Z smtps -M ybbsmtp.mail.yahoo.co.jp\ -A plain -U Yahoo -r password\ -F yoshino@rita.karing.jp -T 61L114@mail.example.ac.jp\ -s "test clsmtps MAIL" "TEST test tEsT" clsmtpc-0.1.5-pre3 smtps-: ************ 2018-09-13 Thu 16:56 ************ clsmtpc-0.1.5-pre3 smtps<: 220 ybbsmtp6001.mail.ssk.ynwp.yahoo.co.jp ESMTP clsmtpc-0.1.5-pre3 smtps>: EHLO localhost clsmtpc-0.1.5-pre3 smtps<: 250-ybbsmtp6001.mail.ssk.ynwp.yahoo.co.jp clsmtpc-0.1.5-pre3 smtps<: 250-AUTH LOGIN PLAIN XYMCOOKIE clsmtpc-0.1.5-pre3 smtps<: 250-PIPELINING clsmtpc-0.1.5-pre3 smtps<: 250 8BITMIME clsmtpc-0.1.5-pre3 smtps>: AUTH PLAIN WWFob28AWWFob28AcGFzc3dvcmQ= clsmtpc-0.1.5-pre3 smtps<: 235 ok, go ahead (#2.0.0) clsmtpc-0.1.5-pre3 smtps>: MAIL FROM: <yoshino@rita.karing.jp> clsmtpc-0.1.5-pre3 smtps<: 250 ok clsmtpc-0.1.5-pre3 smtps>: RCPT TO: <61L114@mail.example.ac.jp> clsmtpc-0.1.5-pre3 smtps<: 250 ok clsmtpc-0.1.5-pre3 smtps>: DATA clsmtpc-0.1.5-pre3 smtps<: 354 go ahead From: <yoshino@rita.karing.jp> To: <61L114@mail.example.ac.jp> Subject: test clsmtps MAIL X-Mailer: clsmtpc-0.1.5-pre1.3 Mime-Version: 1.0 Date: Thu, 13 Sep 2018 16:56:35 +0900 (JST) Message-Id: <201809131656352270273.75@localhost> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT TEST test tEsT . clsmtpc-0.1.5-pre3 smtps<: 250 ok 1536825396 qp 2277 clsmtpc-0.1.5-pre3 smtps>: QUIT clsmtpc-0.1.5-pre3 smtps<: 221 ybbsmtp6001.mail.ssk.ynwp.yahoo.co.jp ybbsmtp.mail.yahoo.co.jpではqmailが動作しています。グリーティングからはわかりませんが、メールヘッダには書いてあります。qmailはpostfixに比較し厳格にSMTPを解釈しており、UNIX環境で一般的な<LF>のみの改行コードは受け付けず、規定である<CR><LF>の改行コードのみを受け付けます。<LF>のみでもSMTPセッション自体は何事もないように進みますが、最後にエラーである旨が返されます。postfixの場合はデフォルトの設定では<LF>のみの改行コードがあると<CR><LF>へと単純に変換してくれます。また、ヘッダのない（空行がなくヘッダが終了しない）メールを受け取った時の扱いでは、qmailは自己のヘッダを挿入する時には自己のヘッダのみを挿入し、他に何もせず送信しますが、postfixは自己のヘッダに加え、メールヘッダが終了したことを明示化する空行を挿入して送信します。これらの差異は通常のメーラから送信する場合には特に問題になりませんが、スクリプトから非常に簡易なメールを送信しようとする時などに、届いたり届かなかったり、読めたり読めなかったりする原因になります。

Yahoo!メールにおける最大の問題は、メールアカウントのパスワードとアカウント自体のパスワードが同一なことです。メールの内容そのものが暗号化されていないのであればメールに関してパスワードを秘匿する意義は小さくなりますが、Yahoo!メールの場合、そのパスワードはそのアカウントのパスワードと同一なので単なるメールアカウントのパスワードとは異なり、大きなセキュリティホールになりえます。私がトリッキーな手段(stunnel)を使ってまでrita.karing.jpとybbsmtp.mail.yahoo.co.jp間を暗号化した理由です。

・smtp.mail.goo.jp
smtp.mail.goo.jpはポータルサイトgooのメールサービス、gooメールです。かつてフリーメールだった頃から実験用に使っていたのですが、2014年3月に有料化し、仕方なく206円（税込）/月で維持することにしました。サブミッションポート、SMTPs、STARTTLSで接続可能で、認証では"LOGIN PLAIN"に対応しています。おそらく、ここで取り上げているメールサーバの中では最もフツウのメールサーバですが、送信者のメールアドレス(MAIL FROM)はdomainが存在すれば（DNSで正引きできれば）いくらでも騙れるというのが特徴です。これはセキュリティ上の穴というわけではなく、gooメールの正式対応機能のようです。Yahoo!メールでもメールヘッダによる偽装は可能だったもののメールヘッダには個人を特定できる情報(X-Apparently-From)が付加されており、まだ対処のしようがありましたが、smtp.mail.goo.jpにはそういう個人を特定できるものはなく、送信者の特定はIPアドレスのみが手懸りとなります。

smtp.mail.goo.jpは有料化に際して、qmailからpostfixに変更されました。ほぼデフォルト設定のrita.karing.jp(postfix)と比較し、かなり機能が制限されており、その公共性を鑑みれば正しい運用と言えますが、送信者のメールアドレスを検証しない仕様はシステム全体の統一性を欠くように感じます。
*** 2022-02-13 追記 gooメールは、2022-02-10にセキュリティアップデートが行われ、公式にはアナウンスされていませんが、MAIL FROMコマンドではアカウントのメールアドレスのみが使用可能になりました。 ***

gooメールではサブミッションポート(587)で接続し、途中からTLSで暗号化、認証はPLAINで行い、デタラメな送信者のメールアドレス(prime-minister@kantei.go.jp)で送信してみます。$ clsmtpc -P 587 -Z tls\ -M smtp.mail.goo.jp -A plain -U 64L114 -r password\ -F prime-minister@kantei.go.jp -T yoshino@rita.karing.jp\ -s "test clsmtps MAIL" "TEST test tEsT" clsmtpc-0.1.5-pre4-: ************ 2018-09-14 Fri 04:09 ************ clsmtpc-0.1.5-pre4<: 220 smtp.mail.goo.jp ESMTP Postfix clsmtpc-0.1.5-pre4>: EHLO localhost clsmtpc-0.1.5-pre4<: 250-smtp.mail.goo.jp clsmtpc-0.1.5-pre4<: 250-SIZE 104857600 clsmtpc-0.1.5-pre4<: 250-STARTTLS clsmtpc-0.1.5-pre4<: 250-AUTH LOGIN PLAIN clsmtpc-0.1.5-pre4<: 250-AUTH=LOGIN PLAIN clsmtpc-0.1.5-pre4<: 250 ENHANCEDSTATUSCODES clsmtpc-0.1.5-pre4 tls>: STARTTLS clsmtpc-0.1.5-pre4 tls>: AUTH PLAIN NjRMMTE0eDAwNjRMMTE0eDAwcGFzc3dvcmQ= clsmtpc-0.1.5-pre4 tls<: 235 2.7.0 Authentication successful clsmtpc-0.1.5-pre4 tls>: MAIL FROM: <prime-minister@kantei.go.jp> clsmtpc-0.1.5-pre4 tls<: 250 2.1.0 Ok clsmtpc-0.1.5-pre4 tls>: RCPT TO: <yoshino@rita.karing.jp> clsmtpc-0.1.5-pre4 tls<: 250 2.1.5 Ok clsmtpc-0.1.5-pre4 tls>: DATA clsmtpc-0.1.5-pre4 tls<: 354 End data with <CR><LF>.<CR><LF> From: <prime-minister@kantei.go.jp> To: <yoshino@rita.karing.jp> Subject: test clsmtps MAIL X-Mailer: clsmtpc-0.1.5-pre4 Mime-Version: 1.0 Date: Fri, 14 Sep 2018 04:09:57 +0900 (JST) Message-Id: <201809140409574529774.49@localhost> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT TEST test tEsT . clsmtpc-0.1.5-pre4 tls<: 250 2.0.0 b79z1y00227aYMl0179z5V mail accepted for delivery clsmtpc-0.1.5-pre4 tls>: QUIT clsmtpc-0.1.5-pre4 tls<: 221 2.0.0 Bye "250-AUTH=LOGIN PLAIN"は、古いOutlookをサポートするための非標準なAUTHの書式です。ドコモメールもこの書式をサポートしています。

さて、フリーメールとして親しんだgooメールですが、今は有料化し、私が持つフリーメールのアカウントはGmailのみとなってしまいました。しかし、Gmailはほとんど使ってないので今回の詳解からは外しました。とはいえ、Gmailも似たような方法で対応可能です。ただし、googleアカウントと絡むセキュリティ上の制約があったりするので少し面倒かもしれません。実際に送信してみると、サブミッションポートで接続はできても、暗号化（STARTTLS or SMTPs）しないと送信できないとか、MAIL FROMに適当なアドレスを入れてもエラーにはならないが、強制的に自アカウントのメールアドレスが使われるとか、それと同様にメールヘッダのFromにもそれが強制されるとか、偽装したつもりが知らぬ間に本アカウントで送信しているという状況にもなりかねず、少々、危険です。

・smtp.spmode.ne.jp（ドコモメール）
smtp.spmode.ne.jpはキャリアメール最大の雄、ドコモメールです。ドコモメールを使い始めて10年以上になりますが、ドコモメールでもリレーできることを最近知りました。ただ、キャリアメール（携帯メール）最大の利点は携帯端末におけるプッシュ通知であり、主な役割は種々の警告メールの宛先とすることで、リレーサーバとしての利用は単なる検証です。

このドコモメールをリレーサーバとして利用するにはdアカウントから設定する必要があるのですが、その設定は少々わかりにくく、また、設定したまま一定期間内に有効化しないとdアカウントが凍結されるとあります。しかし、その一定期間の具体的な期間はわからず、かつ、有効化の意味が不明で極めて不親切です。とりあえず、マニュアル通りに設定し、メールソフトでドコモメールからメールを取得してみると設定が有効化された旨のSMSが届きました。ドコモメールを設定する場合、このSMSを受信するまで設定は完了していません。完了しないまま放置するとdアカウントが凍結される恐れがあるので要注意です。

ドコモメールは制限が多く、使えるオプションも限定的です。接続はSMTPsのみ、メールの個別内容以外は、正確なアカウント情報のみしか使えません。また、送信後、不正アクセスに対する注意喚起として、SMSで連絡をくれる親切仕様ですが、そこまでするならそそもそもリレーを許可する必要もなかったのでは、と思います。このドコモメールのリレーサービスは、SMTPを理解してないと使えない、理解してたら使わないサービスです。おそらく、実際の利用者は数えるほどしかいないと思います。

# clsmtpc -Z smtps -M smtp.spmode.ne.jp\
-A plain -U docomo -r password\
-F docomo@docomo.ne.jp -T yoshino@rita.karing.jp\
-s "test clsmtps MAIL" "TEST test tEsT"clsmtpc-0.1.5-pre4 smtps-: ************ 2018-09-17 Mon 18:30 ************ clsmtpc-0.1.5-pre4 smtps<: 220 ESMTP Server Ready clsmtpc-0.1.5-pre4 smtps>: EHLO akane.karing.jp clsmtpc-0.1.5-pre4 smtps<: 250-docomo.ne.jp clsmtpc-0.1.5-pre4 smtps<: 250-AUTH LOGIN PLAIN clsmtpc-0.1.5-pre4 smtps<: 250-AUTH=LOGIN PLAIN clsmtpc-0.1.5-pre4 smtps<: 250-SIZE 15727616 clsmtpc-0.1.5-pre4 smtps<: 250 8BITMIME clsmtpc-0.1.5-pre4 smtps>: AUTH PLAIN ZG9jb21vAGRvY29tbwBwYXNzd29yZA== clsmtpc-0.1.5-pre4 smtps<: 235 Authentication successful clsmtpc-0.1.5-pre4 smtps>: MAIL FROM: <docomo@docomo.ne.jp> clsmtpc-0.1.5-pre4 smtps<: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre4 smtps>: RCPT TO: <yoshino@rita.karing.jp> clsmtpc-0.1.5-pre4 smtps<: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre4 smtps>: DATA clsmtpc-0.1.5-pre4 smtps<: 354 End data with <CR><LF>.<CR><LF> From: <docomo@docomo.ne.jp> To: <yoshino@rita.karing.jp> Subject: test clsmtps MAIL X-Mailer: clsmtpc-0.1.5-pre4 Mime-Version: 1.0 Date: Mon, 17 Sep 2018 18:30:08 +0900 (JST) Message-Id: <201809171830082621486.93@akane.karing.jp> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT TEST test tEsT . clsmtpc-0.1.5-pre4 smtps<: 250 Requested mail action okay, completed clsmtpc-0.1.5-pre4 smtps>: QUIT clsmtpc-0.1.5-pre4 smtps<: 221 Service closing transmission channel smtp.spmode.ne.jpはこれまでで最も制限の多いメールサーバです。接続はSMTPsのみが可能で、SMTPの解釈も他より厳格です。一例としてSMTPコマンド内でメールアドレスを<>で括らないとSyntax errorになるのはsmtp.spmode.ne.jpだけです。また、パスワードはランダムに自動生成され、自分で決めることができません。さらに、ドコモメールで特筆すべきは、送信者のメールアドレスの詐称について非常に厳格なことです。smtp.spmode.ne.jpは"MAIL FROM"は当然としてヘッダにも正しい"From"がないとリレーしないという設定になっています（受信はします）。つまり、"MAIL FROM"にもヘッダのFROMにもドコモメールのメールアドレスしか使用できません。"MAIL FROM"は送信者がメールサーバに宛てた入力であり、メールサーバ宛の入力情報をどう処理するかはそのメールサーバの自由と言えますが、メールヘッダのFromは手紙の内容の一部と考えることもでき、それを第三者であるメールサーバが検証するとなると「検閲」にあたる可能性もあります。差出人の詐称を防ぐにはメールヘッダを処理するしかないので、現実的にはメールサーバの自己管理の範囲内であるという結論に落ち着きそうではあるものの、多少の疑問は残ります。おそらく、ドコモメールの利用規約にはその免責事項が記載されているのだと思われますが、これ以上は法律論になるので割愛します。

ちなみにGmailもFromヘッダを検証しています。より正確に言うと"MAIL FROM"もFROMヘッダも自アカウントのメールアドレスに強制されます。ドコモメールでは自アカウントのメールアドレス以外を入力するとエラーになり、送信できませんが、Gmailの場合は、Gmailが入力を無視し、書き換えた上で送信されます。この時、書き換え前の元のFromヘッダはX-Google-Original-Fromとしてメールヘッダ内に残されています。この誤入力に対する挙動の違いには日本標準と世界標準の文化差を感じますが、日本人の私には、当然、ドコモメールの方が妥当に思われます。

ドコモメールではリレーの際、charsetやencodingでも変換処理を施しており、メールの本文では、US-ASCIIおよび日本語charsetは、ISO-2022-JP(7bit)に変換され、その他のcharsetではそのcharsetのbase64に変換されます。メールヘッダの差出人名(From:)および受取人名(To:)はISO-2022-JPのbase64に決め打ちされており、Subjectヘッダでは、US-ASCIIおよび日本語charsetはISO-2022-JPのbase64に変換され、その他のcharsetではそのchrasetのbase64に変換されます。ただし、US-ASCIIおよび日本語charsetのSubjectではデコードされたSubjectに含まれるUS-ASCIIはそのまま生書きされ、UTF-8のSubjectではデコードされたSubjectにUS-ASCIIのみが含まれる場合、そのUS-ASCIIが生書きされます。なお、メールボックスに受信する場合は変換の挙動が異なり、US-ASCIIおよび日本語charsetでは本文、メールヘッダともにShift_JISのbase64に変換され、その他のcharsetでは、メールヘッダの差出人名(From:)および受取人名(To:)がShift-JISのbase64に変換され、Subjectと本文はそのcharsetのbase64に変換されます。

また、ドコモメールはメールヘッダのないメールはリレーしませんが、受信したメールのメールヘッダが正しくない場合（存在しない、終了していない、など）は、添付ファイルとみなし、それ用の修正を加えてしまい、元の情報がわかりづらくなってしまうことがあります。もっとも、正しくないメールヘッダを書く機会はそうないとは思いますが。

これまでの3つのメールサーバは基本的にメールそのものには処理を加えませんでした。しかし、ドコモメールはメールそのものにも軽くはない処理を行なっています。メール環境の統一化や単純化は、情報伝達の確実性を重視したもので、ケイタイの付帯サービスという事実上の社会インフラとして始まったドコモメールにとって必然なのでしょう。インターネットを主戦場とするメールサーバとは出自や方向性が違います。

そんなドコモメールですが、古いOutlookのために非標準の書式"AUTH="をサポートし、SMTPの規定外である<LF>のみの改行も実は受け入れてくれます。「354 End data with <CR><LF>.<CR<LF>」と指示しつつ<LF>.<LF>を受け入れてくれるのはまるでpostfixです。ドコモメールのMTAについて明示された情報はありませんが、おそらくpostfixの独自改良版なのだと推察されます。ちなみにGmailはSMTPコマンドでは<LF>を通してくれますが、"DATA"の入力では通さないので、<LF>しか打てないと本文終了の <CR><LF>.<CR<LF>が打てず、メールの送信を完了できないという事態に陥ります。この動作は未知で、Gmailは、postfixでもqmailでもない第三のMTAなのだと推測します。

docomo Mail Converting Matrix

	US-ASCII	Japanese charset	others
From: and To: in RELAY	ISO-2022-JP base64	ISO-2022-JP base64	ISO-2022-JP base64
Subject: in RELAY	ISO-2022-JP base64*1	ISO-2022-JP base64*1	others base64*2
mail body in RELAY	ISO-2022-JP 7bit	ISO-2022-JP 7bit	others base64
to MAIL BOX	SHIFT-JIS base64	SHIFT-JIS base64	others base64*3

server	MTA	587	MAIL FROM	From header	AUTH*1	smtps	TLS
rita.karing.jp	postfix	○	free	free	LPCD	○	○
ybbsmtp.mail.yahoo.co.jp	qmail	○	registered	free	LPx	○	☓
smtp.mail.goo.jp	postfix	○	free*3	free	LP	○	○
smtp.spmode.ne.jp（ドコモメール）	DOCOMO Mail Server	☓	only*4	only*4	LP	○	☓
smtp.gmail.com	gsmtp	△*2	ignored	forced	LPx	○	○

OP25Bはなかなか強力なスパム対策だったらしく、日本発のスパムは皆無と言っていいほどの状態になっています。その反面、自由なメール送信は制限されましたが、それに対する対応策が今回の主題でした。OP25Bを実施しているのは、事実上、日本だけなので世界的視点から見るとその対応策を論じたものは稀少となってしまいます。そんな中、この文書が何かの一助になれば幸いです。

しかし、OP25Bの実施で日本発のスパムは激減しましたが、スパム全体を見れば焼け石に水なのが現状です。また、スパム同様に迷惑なのが、認証にトライしてくるアクセスです。そのメールがスパムかどうかはメールサーバが判断することではないので送信者の悪意も、また、メールサーバが判断することではありませんが、認証にトライしてくるアクセスの悪意は明白です、彼らはそのメールサーバのアカウントを有していないのですから。そんな迷惑なアクセスも最近のハイスペック機なら誤差程度の負担かもしれませんが、この486機のrita.karing.jpにはかなり負担で、すぐ反応が悪くなります。放置していたら一週間に5万回強のトライがありました。望むべきはOP25Bが世界的に導入されることですが、なかなかそれは難しいようです。なんだかんだ言って日本の規範意識の高さには頭が下がります。この件に関しては日本はマンガやアニメの主人公で世界は敵に見えます。

とりあえず、次なる目標はこの不正アクセスしてくる輩を動的にフィルタリングし、我がメインサーバの負荷を軽減することです。いや、そんなことよりそのゴミ486機を捨てろというのが正論かもしれませんが、とにかく、もう少しだけ頑張ってみたいと思います。

2018-09-20 Thr 12:00