メールの通知の新戦略

今まで重要なメールはYMobileのメールアドレスに転送する、という戦略をとっていたのだけれど、 今まで知らなかったのだが、Virtualで(Virtualのみか?)拡張アドレスを含むアドレスのメールを受け取り、外部ホスト(@を含むメールアドレス)に対して転送すると拡張アドレスを含んだまま転送してしまうため、転送先でエラーになる。

そこで、後々の脱YMobileも視野に、Discordで通知するようにした。 もっとも、Discrodはあまり通知で起きてくれないのだけど。

以前、[Discordへの通知方法は記事にしたし]、既にメールから起動するwebhookでの通知というのは結構使っている。 Extract Mailtextは新開発のメールフィルタのコンポーネントで、メールを可読形式にするのはちょっと難しいのだが、ここで作っていた簡単なフィルタが有効に働いてくれた。 テキストフィルタで処理できるように作ったものだけに応用が効いた。

基本的にはこれでいいのだが、注意点が

  • Virtualからはコマンドが起動できない
  • Aliases(local)から起動されたコマンドには$PATHが入っていない
  • Aliasesから起動されるコマンドはnobodyで実行される

Virtualでコマンドが実行できない問題は、Aliasesのほうに専用の(外部には絶対わからないような)名前を作って、Virtualでローカルユーザー(Aliases上のエントリ)にまわして、さらにコマンドに回すのが良い。 拡張アドレスをつけてローカルユーザーに回すようにすれば、Aliasesで直接記述された拡張アドレスを含む場合の専用引数と、含まない場合、もしくは対応していない場合のデフォルトの引数を使うことができて便利。

新しいメールフィルタを開発 (Dovecot LDA, Postfix alias/PIPE)

新手のスパムが増えてきたので、追加のスパムフィルタを適用しようとしたのだが、従来のスパムフィルタがちょっと力技過ぎて(まぁ、2時間で作ったものだから)拡張が難しかったので、新しいフレームワークを作った。

GitHubで公開しているけれど まだREADMEを書いていないので利用は難しいだろう。

これ自体は大した話ではないのだが、部分的にとても苦戦したところがあったので、その話をしよう。

旧フィルタはPostfix aliasのPIPEで起動し、通過したものはsendmailでキューに戻すという仕様だった。 これは問題なかったのだが、フォルダへの振り分けも行いたい(特にJunkフォルダに対して振り分けたい)という理由でDovecot LDAを使うことにした。 これはArch Linuxだと/usr/lib/dovecot/dovecot-ldaである。

だが、ここで問題があった。Dovecot LDAはメールボックスに配送する。 一方Postfix sendmailはキューに入れるだけで、メールボックスへの配送はPostdropが行う。

だが、PostfixはPIPEをnobody:nobodyで起動する。 だから、メールボックスに対するアクセス権がなく、Dovecot LDAでメールボックスに配送することができない。

PIPEのユーザーを指定して起動する方法を検討したのだが、公式Wikiに「suidしろ」とか書いてあって絶望した。

ここまで特定するのに随分苦労したが、結局Postfix Sendmail同様、サーバーに対して送信する、という仕組みにすることにした。 rootで起動されているサーバーがDovecot LDAを呼ぶのでroot権限で動かすことができる。

これを実現するためにRubyのUNIXServerインスタンス(socketファイル)を777にしてあげる必要があるのだが、 UNIXServer.openにその機能がないため、

という感じ。

また、ログファイルもnobodyで書き込める必要がある。

2018年版コミュニケーションメディア 所感

eメール

最近はeメールを使う人は本当に減ってしまったようで、個人的なやりとりに使われることは現状ほぼない。

特段見くびるほどの欠点があるわけではないと思うのだが、実際のところレガシーな使いづらさというのは存在する これはどちらかというとソフトウェア実装上の問題である。

ただし、柔軟性に関しては最も優れている。 オープンで共通の仕様という意味では被験するのはXMPPくらいのもので、 この点を理由にeメールを扱いたい理由はある。

若い人の場合、大学生、あるいは大学卒であればeメールは扱えるが、 そうでない場合は扱えない傾向があるようだ。 また、eメールを扱う場合でも、特定のアプリとアカウントが紐付けられた状態(LINEのような状態)で認識しており、使い方は理解できていないというケースが目立ち始めている。

LINE

依然として日本においてデファクトスタンダードの座を譲らないLINEである。

アプリの使いづらさはある程度改善されつつあるのだが、Windowsアプリ版の使いにくさには批判が多いようだ。 また、アプリの種類によって機能が異なる点は単なる使いづらさになっている。

モバイルアプリ版に関してはヴォイスメッセージ機能が秀逸である。 トーク画面でヴォイスボタンを押している間に発した言葉が送信される。 あまり活用されていないようだが、非常に優れた機能といっていいだろう。(LINEが初なのかはわからないが)

メッセージ消去機能がついたが、Skypeと比べれば証拠消しなどには使いづらく良心的だと言えるだろう。 直前消去だけで良いのではないかという気がするのだが…

通話品質はあまり改善がみられず、非常に切れやすい。

LINEが優れている点はわずかだが、普及とスタンプという蓄積要素があるため、乗り換えも容易ではないところまできたように感じる。

Kakao Talk

混沌の時代に現れ、様々な雑な対応でユーザーを失ったカカオトークだが、 その混沌と荒野、そして雑さをついて出会い系利用に拍車がかかった。

直接的にIDを交換するケースもあるが、他の出会い系メディアからの連絡手段交換として利用されているようだ。 出会い系、というとソフトにきこえるが、ほぼ売春・援助交際目的である。

そして、それ以外の用途というのはあまり利用されていないことから、 「インストールすることでその人の素行品性が問われる」という状況にあるといっていい。

Skype

Microsoftに買収されてから改悪を続けるSkype。 5.4になってからレビューを著しく落としたのは有名な話だが、それ以降さらなる改悪を続けている。

まず、コンタクト機能がなくなった。 電話帳利用を強制しており、利用しない場合はコンタクト機能が存在せず管理不能の状態になる。 チャットした相手は全て自動的にコンタクトがある状態になる、という仕組みだ。 電話知用機能のないLinuxの場合、「チャットをしたことのある相手一覧」という形式になる。

また、ステータス表示機能もなくなった。 これは一旦削除し、激しい批判を浴びて復活させたのだが、完全になくなってしまった。 これは今までは「モバイルアプリ版にはない」だったのだが、ステータス通知APIもろともの削除で、外部アプリを使った場合でもステータスは取得できない。

SkypeのSNS化進行も激しく、だいたいsnapchat化している。 Skypeのコンタクトにはあまり親しくない人も多いことから非常に困ってしまう。

通話品質も低下しつつあり、より通話品質に優れるアプリが登場していることから避けたいメディアになりつつあるようだ。

Telegram

LINEと類似の一通りの機能、無料のステッカー、ステッカー同様にGIFを利用する機能などなかなか魅力的だ。 また、LINEに追加されたヴォイスメッセージに近い機能(もうちょっと慎重)と、同様に利用できるビデオメッセージも利用可能だ。

だが、致命的なのはWhats Appを意識しているのか、「電話番号と本名を前提としている」ということだ。

基本的にユーザー検索時はファーストネームと電話番号が必須である。 裏技として、ユーザーIDだけわかっていればシークレットチャット開始→ID検索ということも可能だが、 検索結果に本名と電話番号が表示される。

検索を防ぐ設定はないので女の人などは非常に不安だろうし、 「電話の代わり」という仕様はWhats App同様いかがなものか。 「日本人は秘密主義すぎる」みたいに言われることがあるのだが、世界的に見てそんなに受け入れられている気はしない。 むしろアメリカ人が個人情報やプライバシーに無頓着すぎると思う。

通話機能はかなり切れやすく、快適ではない。

XMPP

依然としてXEP-180(ビデオ通話)に対応したクライアントがなく、どのアプリも快適にはほど遠い。

期待されていたJitsiに関してはそもそもXMPPをやめてしまったという状況だ。

モバイルアプリは最も有力なのはXabberだが、Xabberにしてもあまりデキはよくない。 重要な相手とのやりとりには使用できないが、あまり密ではない(取りこぼしがあったとしても構わない)ような相手とのやりとりには利用できるだろう。

「XMPPを利用している人は少ない」という前提のもと、「XMPPを利用できないレベルの人にXMPPでやりとりをできるようにする」という作業を行う状況というのが限定的すぎて現実的ではない。

ただし、メリットは全くないわけではない。 XMPPアカウントの取得は比較的容易で、XMPPのウェブクライアントも存在するためだ。

PCの場合はインストールも不要で簡単にXMPPで会話することが可能になる。

現実的にはスマートフォンでインストールもせずにチャットするのはかなり難しい。 だが、そのような人はおそらく会話する意思に著しく乏しいものと思われるので配慮するだけ無駄ではないか。

Jitsi Meet

Jitsi MeetはWebRTCクライアント+WebRTCサービスである。

一応、他のWebRTCサービスも利用できるようだ。

つながっている手段が通話機能を提供していない場合(たとえばTwitterなど)、あるいはその方法が適切ない場合に有効である。 特に個人情報を教えたり登録したりする必要もないのもメリットと言えるだろう。

Discord

Discrodが良いものであることは既に明らかだが、明確な欠点がある。 それは、アカウントの使い分けが困難だということだ。

PCならいくつか方法はあるのだが、Discordは活用ジャンルが非常に広く、通知を分けることもできず、特定のチャンネルに集中することも難しい。 別にDiscordに固有の問題ではないとはいえ、便利だからといってあれもこれも教えていると困ることになってしまう。

方法は色々ある(たとえばInvisibleにするとか)のだが、使い方に配慮が必要なのは確かだ。

通話品質は非常によく、現状ベストな選択肢である。

なお、招待すると「ゲーマー」のところにみんなひっかかるので、そろそろ他のことも書いてくれないか。

Slack

日本語版がリリースされ、CMも打たれたため、名前だけは知っているような状態になっている。

実際一般にそこまでSlackが広まった印象はないが、少なくとも提案したときに受ける抵抗は減ったように思う。

Slackはログを商売にしているが、あまり良い手ではないというのが一般の意見だ。 XMPPサポートをそれを理由に切ったことも批判的に見られている。

Slackは全体的にDiscordに見劣りするが、明確にDiscordより優位な点がある。 それは切り分けが容易なことである。ユーザー単位では認識されないし、チームは分離される。 常に適切なリージョンで分割できるというのはメリットといっていいだろう。

なお、Slack Webはスマートフォンでは利用できない。

Google Hangouts

品質はあまり変わっておらず、少なくともSkypeやLINEよりは良い選択肢といっていいと思う。

しかし、Googleアカウントが特定されてしまうこと、結果としてGMailもわかってしまうこと、Google+をやっている場合は自動的にGoogle+でもつながってしまうことなどFacebook Messanger同様の使いづらさが存在している。

Viber

楽天が取り込んでいるけれども、プライバシー面で改善されたという話は聞かず、 かなり不安な状況のままだ。

まとめ

  • Discordは良いもの
  • 仕事など限定された環境のつながりはDiscordでなくSlackで
  • DiscordとSlackの使い分けは大事
  • LINEやTelegramのようなプライバシーに関わるものをプライベートなつながりでないのに要求する人からは逃げよう
  • 親しい人とLINEを交換するのは妥当。ただし「その人が親しい人でなくなるリスク」とセットで考えないと、ブロック/削除しても可視性が残る
  • Googleアカウントでつながってしまっている人に関してはHangoutsというのも結構妥当
  • 「とりあえずXMPPアカウント交換しておこうかな」というのもまぁ妥当な判断
  • カカオトークはやめましょう。人間性の問題になる。
  • Telegramは現状、電話番号以上のプライバシーの塊なので、本当に親しい人とでないと困難
  • チャット機能に関してはTelegramかなり使い心地いい
  • 妥当というか無難なのはLINE。メッセージ到達性は一番優秀
  • メール侮るべからず
  • 匿名性を保ってつながりたいという人は、XMPPとJitsi Meetを提案するのが多分無難
  • そのうちチャットつくるよ
  • Mimir YokohamaはTelegramが対応済み。XMPPもそのうち対応します

自前PostfixサーバーとGMail

自前のメールサーバーからGMailにメールを送ると

<*.com>: host
gmail-smtp-in.l.google.com[2404:6800:4008:c02::1b] said: 550-5.7.1
[2001:2e8:649:0:2:1:0:11 12] Our system has detected that this
550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam
sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550
5.7.1 https://support.google.com/mail/answer/188131 for more information.
kt7si2092671igb.13 – gsmtp (in reply to end of DATA command)

のように言われてしまう。

迷惑メールとしてブロックされてしまうのだ。されない場合もあるが、その原因がよくわからなかった。

色々と調べた結果、どうもDNSレコード内にSPFの記述が欠如していると配送されない、ということのようだ。

SPFは、メール配送においてそのドメインから贈られたメールとして受け取るべきサーバーのアドレスを示すものだ。そのアドレス以外からは当該ドメインのメールを受け取らない、というポリシーにすることによって、なりすましを防ぐ、らしい。

SMTPがちゃんとリレーしてくれない昨今、ローカルSMTPが使えなくなる原因ともなり、ひたすらやりにくい気がするが、まぁなりすましメールを防ごうというわけだ。

SPFはTXTレコードとして存在し、うちの場合

v=spf1 +ip4:27.120.84.145 +ip6:2001:2e8:649:0:2:1:0:11 ~all

となっている。これによって、@reasonset.netからのメールは、このアドレス以外のサーバーから配送された場合はなりすましメールとみなし、排除してよい、という情報を与えることとなる。
GmailはSPFを必須とするようだ。

SPFレコードを追加したが、それでもGMailに拒否される。
どうやら、AAAAレコードも必要なようだ。AAAAレコードを追加したところ、拒否されなくなった。
ただし、失敗を繰り返したアドレスに対してはいばらく送ることができなかった。

ケータイのメール、eメール、VPS

ケータイのメールに関する設計がおおよそ固まった。結構複雑な構成なので試行錯誤となったが、いい感じになった。なお、今回は一般ユーザーが真似するのは難しい話になるが、一般ユーザーでも応用可能な方法を最後に紹介する。

やり方

まず、ケータイはWILLCOMのフィーチャーフォン(A)とスマートフォン(B)の2台だ。主にAを使用しており、現在のところBの用途は定まっていない。これは、Bのほうが多様に使うため、バッテリー的な理由だ。

「ケータイアドレス」はA、B共にある。Aはもちろん、Bも届くと直ちに自動で受信される。着メロや振り分けにも対応する。

基本的にケータイのメールをPCで扱いたい。打つのもバックアップもそのほうがずっと楽だ。そのような理由でまずメールの転送を考えるのだが、Aは転送ができるが、WILLCOMのスマートフォンであるBは転送できない。Yahoo Mobile Mailに属するサービスなので、恐らくソフトバンクでもできない。これは困った。

まずVPSのaliasを使ってケータイのバックアップ用のアドレスを作る。単純に共有するには、Aから転送されるそのaliasでPCとBに送るようにすればいい。だがこの場合、Bに送られたメールは孤立する。Bは転送できないため、この問題をこのアプローチで解消できない。

そこで、メール機能の設定でReply-Toヘッダを入れるようにし、返信時に他のアドレスに届くようにする。その受信アドレスはAliasとし、PCとスマホに転送する。

ここまでを実現するには次のことをしなくてはいけない

  • スマホのアドレスを教える時は転送用のアドレスも一緒に教え、送る時はそちらのアドレスに送るように頼む
  • PCからのメールを受信できるようにしてもらう
  • なりすまし防止機能をoffにする。でないとPCからケータイのアドレスで送った時にはじかれる(ソフトバンク、WILLCOMでは必須の設定)

オープンに使うには相手に頼まなくてはいけないことが多く、ややハードルが高い。クローズドなアドレス向きだ。

だが、これではAに送られたメールはAliasによってBとPCに行く。だが、Bで返信してしまうとAにはいかない。もしこれでAに行くようにしてしまうとループする。AのメールをBで扱うことができない。BのメールをAで扱いたいことはさすがにないと思うが、Aの絶望的な入力効率を考えると、バッテリーを気にしなくていい状況ではBで打ちたいところだ。

そこで、Android端末であるBにK-9 Mailを入れた。これはIMAPマルチアカウント対応のMUAである。これがなかなかすぐれもので、アカウント設定に加えて送信メールアカウントを設定できる。Aliasを使っている場合、ひとつのIMAPメールボックスに配送されるが、アドレスはひとつでないという状況になるわけだが、IMAPメールボックスのみを設定し、その上でそのメールボックスに追加のメールアドレスを設定するだけで対応できるのだ。

送信アドレスごとの署名、SSL/STARTTLSの設定、ポート設定など結構細やかにできる。複数のIMAPアカウントにも対応し、扱いやすい。K-9 Mailのアドレス帳はスマホのものをそのまま使用する。

だが当然ながらこのメールボックスPCで扱っている時もあるし、同期してほしくない時がある。なぜか「同期しない」設定にしているとリアルタイムに同期されてしまう。これは結構困る。同期設定はアカウントごとに可能だ。

方法としては、同期して欲しい時はグローバル設定で同期設定を「常に」、してほしくない時は「しない」に切り替えることでそれをコントロールできる。これでかなりいい感じになる。

そしてIMAPアカウントとしてAから転送されるアカウントを設定し、送信アカウントとしてAのメールアドレスを設定すれば完了だ。標準でストアする送信済みメールは自動で消されてしまうので、フォルダの設定でIMAPフォルダを指定しておく(普通はsentだろう)。

BからAのメールを扱う時はK-9 Mailを起動する。この方法の欠点は、K-9 Mailができる通知は通知だけなので、誰からメールがきたかによって通知方法を変えることができない。ランプ色や着信音などだ。もちろん、Bに直接送られたメールについては問題ない。

VPSを用いない応用

柔軟かつ簡単に設定でき、管理もできるということでVPSのアドレスを使っているが、それが嫌なら方法はある。

転送ができるアドレスと、IMAPアクセスができるアドレスを用意する。転送ができるアドレスは複数アドレスへの転送ができなくてはいけない。転送用アドレスは1つでいい。BとPCに転送されるようにすれば、Aのほうは転送設定ができるので、転送設定でその転送アドレスを指定すれば両方に、PCだけを設定すればAとPCに届くようになる。Bは転送アドレスをそのまま使う。

あとはIMAPアクセスすれば良い。Yahooは猛烈にレスポンスが悪いのでオススメしない。IMAPメールボックスはかなり遅いところが多い。VPSのものとは雲泥の差だ。

早いのはGMailだが、GMailはあまり好きでない。GMailを使えばK-9 MailでなくGMailの純正クライアントを使うこともできる。

Mail Virtual Alias @ CentOS 6

メールサーバーの本運用は通常virtualであるはずだ。メールアカウントの数だけユーザーアカウントがあるというのは考えられない。

ただし、私の場合はサブドメインをバーチャルエイリアスにするため、バーチャルドメインが必要になる。

新しいDovecotに関する情報がなく苦労したが、http://vogel.at.webry.info/201312/article_10.htmlの通りにやってみた。大体これでうまくいったのだが、私の場合はいくつかひっかかった点があった。

まず、hown -R mailuser ~mailuserをちゃんと実行しておかなくてはいけないこと。vmailboxファイルは最後に/をつけ忘れるとmbox形式になってしまうこと。

しかしこれではPOPの認証がfailedとなる。調べてみると、このサイトにはデフォルトでコメントアウトしているauth-passwdfile.conf.extのロードをしていない。

[root@server ~]# grep -R auth-passwd /etc/dovecot
/etc/dovecot/conf.d/10-auth.conf:#!include auth-passwdfile.conf.ext

さらに、パスワードファイル認証も無効化されている。

[root@server ~]# grep disable /etc/dovecot/conf.d/10-auth.conf
#disable_plaintext_auth = no
# Authentication cache size (e.g. 10M). 0 means it’s disabled. Note that
# 0 disables caching them completely.
# NOTE: See also disable_plaintext_auth setting.

この2点を修正したが、それでもエラーになる。原因はパスワードファイルのファイル名(設定ではなくファイル自体)が間違っていたためのNo such file or directoryだった。

さらにPostfixからのDovecot認証の利用は情報が錯綜してよくわからない状態だったが、結局のところ/etc/dovecot/conf.d/10-master.confのPostfixから利用するコメントアウトをはずすだけでエラーは出なくなった。しかしながら、認証自体がうまくいかない。userとgroupの設定を追加したが、元々666なのだから、効果はなかった。明らかに問題はPostfixにあり、Dovecotはこれでいいだろう。

telnetを打ってみると25番ポートが反応しない。ここでOP25Bによるものだと気付いた。

submissionの設定を探してみると、master.cfにsubmissionの項目があり、このコメントアウトをはずせばsubmissionは機能する。しかしながら

submission inet n – n – – smtpd
# -o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

TLSを強制するとTLSが機能しない。とりあえず、TLSは要求しないことにした(encryptでなくmayにしておく)。

しかし、それでも544 host access deniedという応答で送ることができない。調べてみると、さらに別のパラメータを設定する必要があるようだ。main.cfに記述する。

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restricions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
broken_sasl_auth_clients = yes

さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。

TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。

[root@sesrver]# openssl genrsa -aes128 1024 server.key
Generating RSA private key, 1024 bit long modulus
.++++++
…………………….++++++
e is 65537 (0x10001)
Enter pass phrase: #ここでは普通にパスフレーズを入力する
Verifying – Enter pass phrase:
[root@dti-vps-srv71 certs]# openssl rsa -in server.key -out server.key #これによってパスフレーズを消滅させる
Enter pass phrase for server.key:
writing RSA key
[root@dti-vps-srv71 certs]# openssl req -new -x509 -key server.key -days 3650 -out server.crt # certファイルを作る
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [XX]:JP #カントリーコード
State or Province Name (full name) []:Kanagawa #神奈川
Locality Name (eg, city) [Default City]:Yokohama #横浜
p {[
“さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。”,
“TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。”
]}

sb { -END
[root@sesrver]# openssl genrsa -aes128 1024 server.key
Organization Name (eg, company) [Default Company Ltd]:HarukaSound #組織名
Organizational Unit Name (eg, section) []: #部署はない
Common Name (eg, your name or your server’s hostname) []:reasonset.net #FQDN
Email Address []:master@reasonset.net #メールアドレス
[root@dti-vps-srv71 certs]# openssl x509 -in server.crt -outform der -out server.der # derファイルの生成

これで鍵の生成は完了。ファイル名が若干変わったので、main.cfを修正。さらに、DovecotのSSLが設定されていなかったので、/etc/dovecot/conf.d/10-ssl.confを修正(ssl = yesのコメントアウトをはずし、ファイル名を修正)。

そしてmaster.cfencryptに戻して完了。STARTTLSが正しく働くようになった。

PostfixでTLSをサポートさせる

relay testでTLSがサポートされていないことには気付いていたのだが、なかなか検証できずにいた。ようやく今日やった。

証明書を作った記憶はあったのだが、なぜサポートされていないのだろうか、と調べてみた。すると、TLSまわりがごっそりコメントアウトされている。なぜコメントアウトしたのだろう?

まず、main.cfに追加されていたのがこの部分。

#SSL setting
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/server.pem
smtpd_tls_key_file = /etc/pki/tls/certs/server.key
smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_schache

これがコメントアウトされていた。わざわざ書いたのに。さらに、master.cfのこのセクションもコメントアウトされていた。

smtps inet n – n – – smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes

これはもともと存在した部分で、単純にコメントアウトされていたのだろう。恐らくはSASL authを無効にしたままでTLSを有効にすると起動せず、それで無効にした、というところではないかとは思うのだが。

これでrelay testするとTLSサポートが確認された。