Roundcube の雑多な設定

メールクライアントの環境を、 Rainloop から Roundcube に移行したので、細かい使い勝手などを整えていきたいと思います。

Roundcube 1.5.3

表示名と署名の設定

主に使っているメールアドレスだけですが、表示名と署名を追加しておきます。

なお、署名も追加したアカウント毎に設定できます。

メール新規作成時の署名について

新規作成時の送信元は、選択中のメールアドレスになります。

が、署名は、『設定』タブの『識別情報』にある各識別情報のうち『初期値を設定』が有効にされたメールアドレス（識別情報）に紐づく署名が入るようです（『初期値を設定』は複数の識別情報のうち、１つだけに設定できるようです）。

ident_switch で複数のメールアカウントを切り替えて使う場合、送信元アドレスだけでなく、署名も切り替えたいかと思います。この場合は、メールの作成画面で、送信元の識別情報を再度選択してやると、その識別情報に対応した署名に切り替わります。

この点、自動で切り替わってくれないので注意が必要です。

なお、すべてのアカウントから、『初期値を設定』をはずすと、挙動がよくわからなくなってしまいました・・・。 基本的には、識別情報の先頭のメアドになるようなのですが、例外になるのもあって、よくわかりませんでした。

フォルダ階層の区切り文字を設定

あるメールアカウントについては、フォルダ階層の区切り文字が『 . 』（ピリオド）ではなく『/』（スラッシュ）になっているものがあります。これをただしくフォルダで表示するために、区切り文字を設定しておきます。

新着メールをチェック

『受信箱』の設定内容として『すべてのフォルダーで新着メールを表示』というのがあります。

デフォルトは、有効になっていないのですが、しばらく使ってみていると、なにもチェックをつけてなくても、それぞれのフォルダで新着メールが表示されてるっぽい印象があります。

とはいえ、少し前のバージョンになりますが、英語版のヘルプを見ると、『Mailbox View』の『Check all folders for new messages』のところを見ると、

By default, only the Inbox is checked for new messages periodically. If you have server-side filters installed that will move incoming messages to other folders, you should check this option.

とあります。デフォルトでは、受信箱（inbox）のみ新着チェックを行っているので、それ以外のフォルダで新着メールをチェックしたければ、このオプションを有効にしろ、という説明ですかね。

なので、一応これにチェックをつけておきます。

メッセージ関連の設定

下記記事を参考に設定を変更しました。

Roundcubeのおすすめプラグインと設定方法 | iEhohs.com

メッセージの表示

『メッセージの表示』 ＞ 『電子メールアドレスを表示名と共に表示』を変更して、有効にしておきます。

引用の設定

『メッセージの作成』 ＞ 『返信時の本文』で設定を『元のメッセージを引用した前に本文を作成』に変更します。

ただ、これだけだと、署名が引用メッセージの前に入るスタイルになってしまいます。なので、『引用したメッセージの後に署名をのせる』を

有効にすることで、メッセージは引用メッセージの前にして、署名は引用メッセージの後に入れることができるようにしておきます。

システムフォルダ設定および不要フォルダを削除

『設定』タブの『設定』の『特殊なフォルダー』から、システムフォルダとして、

• 下書き
• 送信済み
• 迷惑メール
• ゴミ箱

にそれぞれのフォルダを割り当てておきます。

なお、『特殊なフォルダー』の設定内容はメールアカウント毎に保持することができました。

やり方は、『電子メール』タブを選択して、メールアドレスを切り替え後、この画面に移動してくれば、フォルダの割り当てを識別情報（メールアカウント）毎に行うことができるようです。

あと、Rainloop を使った際に、

• Archive
• Junk E-mail

といったフォルダが作られていたので、それらのフォルダを未使用のアカウントについては、フォルダごと削除しておきます。

また、下書きフォルダに該当するものとして Draft と Drafts があったりするので、元のメールアカウントが提供しているものを残して設定し、他方を削除しておきます。

その他

当面、あとはデフォルトのままで使っていこうと思います。何かあったら、適宜設定を見直していきたいと思います。

Roundcube で 1MB 超の添付ファイルが送れない

こちらの記事で書いたように、メールクライアントとして Roundcube を使っています（Roundcube は QNAP NAS 上で docker で動かしています）。

いままで、順調に使えていたのですが、先日添付ファイルを送ろうとしたら、エラーが表示されて、添付ファイルをアップロードすることができないという事態が発生しました。

取り急ぎは、元のメールアカウントの Web メールを使って送信したので、事なきを得たのですが、このままだとせっかく Roundcube を使っている意味がありません。

ということで、原因の調査をしてみたので、ことの顛末をメモっておきます。現在の環境は以下の通りです。

• Roundcube: 1.5.3
• QNAP TS-251+
• QTS: 5.0.1.2425
• Container Station: 2.6.7.44

制限が発生する添付ファイルのファイルサイズ

この現象に遭遇する以前から、添付ファイルは問題なく送れています。今回送ろうとしたのが、 Roundcube に切り替えてからは初の accessのファイル ( .accdb ) だったので、考えられる原因は２つあります。

• ファイル種類の制限
• ファイルサイズの制限

最初は前者かと思い、いろいろと調べていたのですが、どうもそれらしい制限が見当たりません。

ここまではブラウザとして Chrome を使っていたのですが、試に Firefox でやってみたところ、下記の画像のように『 Request Entitiy too large 』と表示されました。

あぁ、ファイルサイズが原因っぽいですね。

ということで、新規メールの作成を使ってテストしてみます。PDFファイルは何度も過去に送ったことのあるので、 PDF ファイルでいろいろなサイズの添付ファイルを試してみたところ、だいたい 1MB を超えるとアップロードに失敗するようです。

やっぱりこれっぽいですね。

現状の設定の確認

どこか設定を間違えていないか確認します。 Roundcube は docker-compose で立ち上げているのですが、それには

  roundcubemail:
    （略）
    environment:
      （略）
      - ROUNDCUBEMAIL_UPLOAD_MAX_FILESIZE=30M

と添付ファイルのサイズは 30MB まで OK と指定してあります。

念のため、 php info を確認すると

[ユーザ名@NAS名 application]$ docker exec -it myrc /bin/bash
root@74a3150b44ab:/var/www/html# php --info | grep -i max_size
post_max_size => 30M => 30M
root@74a3150b44ab:/var/www/html# 
root@74a3150b44ab:/var/www/html# php --info | grep -i max_filesize
upload_max_filesize => 30M => 30M

post_max_size , upload_max_filesize とも 30MB になってます。Roundcube 側の設定はここまで見る限り問題なさそうです。

こういう時はログを手がかかりに調べるのが常套手段なので、 NAS の Roundcube コンテナのコンソールを見て、標準出力に出てるログを確認してみます。

あれ？何にも出てません。

さて、こまったぞ。

原因

当初は、 Roundcube 自体の問題かと思い、いろいろと調べてたんですが、なかなか原因がわかりません。そのうち、（どういう経緯かは覚えていませんが）ふと、プロキシサーバーのサイズ制限、といった話題を目にしました。

ん？今の docker-compose で立ち上げた Roundcube は https 化するのにリバースプロキシとして https-portal を使ってた、ということを思い出しました。

ひょっとしたら、これかも。と思い調べてみると、見事ありました。

file size upload limit introduced by https-portal? · Issue #115 · SteveLTN/https-portal · GitHub

https-portal はデフォルトでボディサイズを制限しているとのことです。なるほどね。

で、 https-portal でひっかっかてるんだったら、 Roundcube 側にログがでないのもうなずけます。ということで、 https-portal のログを調べてみると、それっぽいのがあります。

ほぼ、これが原因と考えてよいでしょうね。

解決方法

じゃあ、上の記事を参考にして、設定を変更しようと思ったのですが、具体的にどうすればいいのかな？ docker-compose.yml で設定変更できないかな？と思い、もうちょっと調べると、下記の記事が見つかりました。

Where to change docker nginx file upload limit? · Issue #173 · SteveLTN/https-portal · GitHub

どうも、 docker-compose.yaml の envirionment に書けば、反映されるようです。

ということで、 Container Station を開いて、『アプリケーションの編集』を押します。

docker-compose.yml が表示されるので、この内容に対して、

services:
  https-portal:
    （中略）
    environment:
    （中略）
      CLIENT_MAX_BODY_SIZE: 0

（後略）  

のように　CLIENT_MAX_BODY_SIZE を追加します（ 0 はサイズチェックを行わないになります）。

編集後、『適用』ボタンを押します。

しばらくすると、コンテナが再起動するので、起動後、もう一度新規メール作成を選び、 1MB を超える添付ファイルを選択したら、問題なく添付できました！もちろん、送信も問題なくできます。

ずばり、これが原因だったんですね。

参考

ちなみに、最初は Chrome で試してたんですが、この時は『サーバーエラー』とだけ出てきていたので、何のことかさっぱりわかりませんでした。

で、試に Firefox でやってみたところ、上述のように『 Request Entitiy too large 』と表示されたという次第です。 にしても、（何かほかの理由原因が潜んでいるのかもしれませんが）ブラウザでエラーメッセージが変わるはやめてほしいです。

SSMS を 19.1 にアップデートしたら、 SQL Server に接続できなくなった

RDS で SQL Server を動かしてるのですが、 SQL Server を触る必要があるとき SSMS (SQL Server management Studio ) を使っています。

で、いままで、SSMS 18.9.2 を使っていたのですが、お盆明けから次の作業が始まるのを機に、アップデートすることにしました。

SSMS のサイトをみると、最新版として 19.1 がリリースされています。まあ、特に 18.x 系を使わなければならない特段の理由もないので、こちらにアップデートしました（というより、 18.x をアンインストールして、 19.1 を入れなおしました）。

問題ないだろうと、たかをくくって、今までと同じようにサーバーにつなげると、

とエラーがでて接続できません。あれれ？

このままでは仕事にならないので、慌てて対応をおこないました。せっかくなので、その際の作業をメモっておきます。

状況の再確認

幸い SSMS は 19.x 系と 18.x 系を同時に使うことができます。なので、18.x 系の最新版 18.12.1 をインストールして接続できるか確認してみます。 SSMS 18.12.1 をインストールして同じ SQL Server につないでみると、あら不思議、問題なく接続できました。

ということで、 SSMS 19.x に特有の現象のようです。

エラーの内容を確認

改めて、 SSMS 19.x で表示されたエラーを確認してみます。『証明書チェーン』とあるので、 SSL 関係っぽい感じです。『詳細の表示』を押すと、

のように詳しい情報が見れて、参考となるリンク先も表示してくれています。このリンク先を見てみると、こちらのページにリダイレクトされ、今回の問題に該当する下記のページにたどり着きました。

SQL Server に接続するとエラー メッセージが表示される - SQL Server | Microsoft Learn

今回のエラーが起きるのは２つの場合があるとのことなのですが、確か、 SQL Server の設定は、 SSL を常に使うようにしていたはずです。一応、確認してみます。

SQL Server 側の設定を確認

SQL Server 側では、クライアントからの接続時に SSL を使うかどうかは、 下記のように RDS のパラメータグループで設定します。

Microsoft SQL Server DB インスタンスでの SSL の使用 - Amazon Relational Database Service

で、今接続しようとしている SQL Server インスタンスのパラメータグループの rds.force.ssl の値を見ると、

と『1』 (true) になってますね。ということで、 SSL 接続が強制されるという設定になっていました。

対応方法

ということで、先ほどの記事でいうところのシナリオ１に該当しているため、今回のエラーになったようです。

念のため、 SSMS がインストールされている Windows 上の証明書を見てみると、『ユーザー証明書の管理』、『コンピュータの証明書の管理』共に、Amazon の証明書はインストールされていませんでした。

なるほどね。

ということで、証明書をインストールしてやれば、問題なく接続できると思われます。やってみます。

証明書のインストール

RDS の証明書は、こちらのページからダウンロードすることができます。今回は、対象となる SQL Server を動かしている東京リージョンの PKCS7 形式のファイルをダウンロードします。

次に、『ユーザー証明書の管理』を立ち上げ、『信頼されたルート証明機関』上で右クリックして、

『すべてのタスク』から『インポート』を選択します。

『次へ』で証明書フィルを指定する画面に進みます。

『参照』でファイルを指定するのですが、この際に、ファイルの種類を適切なものを選択してやります。

今回は『PKCS #7 証明書』を選びます。ファイルを選択したら、証明書をどこに配置するかを尋ねられます。

とりあえずテストということで、今回はデフォルト（信頼されたルート証明機関）のままとします。

確認画面が表示されるので、問題がなければ『完了』をおすと、

のように、インストールしてよいか確認されるので、問題なければ、『はい』を押してインストールしていきます。無事にインストールできると、

のように、Amazon の証明書が一覧に出てきます。

テスト

この状態で、もう一度 SSMS 19.1 を使って接続してみます。すると、今度は、

というエラーが表示されます。『プリンシパル名』？

『プリンシパル名』がピンときてないのですが、今の接続時のサーバー名の書き方は、RDS のインスタンスのエンドポイント名が長ったらしいので、 自分のドメインの DNS で CNAME を割り当てて、それを指定しています。でも、証明書だと、ドメイン名がきっちり一致する必要があるので、これのことじゃないかな？と思われます。

ということで、CNAME の名前ではなく、 RDS で割り当てられたエンドポイント名で接続するように直すと、おぉ、問題なく接続できました。

別の方法

さきほどの記事には、もう一つの解決方法も載っていて、 SSMS ならサーバーへ接続する際に『オプション』を押して、

『接続プロパティ』の『サーバー証明書を信頼する』にチェックをつければ、問題なく接続できます。この方法だと、証明書のインストールも不要だし、CNAMEを使った接続でも問題ありません。

原因

さて、SSMS 18.x では問題なかったのに、 SSMS 19.x ではエラーになったのはなんでなんだろう？と疑問が残ります。 SSMS 19.x のリリースノートを見ても、ぴったりのものが見当たりません。

ただ、 SSMS 19.0 のリリースノートを見ると、 クライアントドライバーが変更になったという記述があります。 また、こちらの記事に、 SQL Serveer 用のいくつかのドライバーが、ある時期から暗号化のデフォルト値が変更になったという説明がありました。

ということから推測すると、 SSMS 19.x からの暗号化の扱いが変わったととらえることができそうですね。とはいえ、もやもやが残るなー。

大事なことなんだから、もうちょっとわかりやすく『変わったよ』と書いといてくれればいいのになー。

結局

で、結局どうするかですが、 SSMS でつなぐときは、『サーバー証明書を信頼する』にチェックをつける形でいこうと思います。