As I Please

MTのいんすとーるの練習と、その他びぼうろく・・・

タグ「Mail」が付けられているもの


let's encrypt のサーバ証明書を使っていて、iphoneのメールアプリでエラーが表示される件

let's encryptの無料サーバ証明書を、httpsサーバ(このサイト)や他サイトでも利用していて、webだけではなくて、smtp(s)でも流用できるので使っていた。
メールも受信(server)・送信(client) がデフォルトで smtps/starttls を利用するようになってきているようで、
グローバルにauthorized された証明書を使っているほうが、いろいろ良さそう。
imapsは相変わらずプライベートCA+証明書を利用しているけど。

先日、2021/09でlets encrypt の証明書のCA問題の影響を受けて、iOSの標準のメールアプリからメールサーバ(smtps)の接続がうまくいかない(メールが送れなく)なった。imapsでの接続でメールの取得・閲覧はうまくいっているに。
ということでいろいろ調べてみると、openssl 1.0.2 ではCA証明書への辿りの解釈に難があるよう。
で、問題を起こしているのは sendmail が共有ライブラリとして libssl.so をリンクしていてその中身が 1.0.2(またはそれ以前)のホストばっかり!ということに気づいた。opensslは 1.1系を /usr/local/bin/openssl にインストール,libssl.so は /usr/local/lib/ あたりにいたが、sendmailのを作成したときには /usr/lib/libssl.so あたり(/usr/bin/openssl は version 1.0.2!) の共有ライブラリをリンクしていた!
なので対応としては、

  1. openssl 1.1系列(今の最新は1.1.1l)をコンパイルして、共有ライブラリのバージョン(1.1.1)を用意する。
  2. sendmailを作成し直して、openssl(libssl.so or libssl.a) をリンクし直す。
ことに。
sendmailも8.15.2と思ったら、8.17.1が最新なのでこれも sourceから持ってきて recompileした。
$src/devtools/Site/site.config.m4 の設定をよくみて、、、。
EOLになってしまっている、FreeBSD-11.4だと、

APPENDDEF(`conf_smrsh_ENVDEF', `-DCMDDIR="\"/usr/local/libexec/sm.bin\""')
APPENDDEF(`conf_smrsh_ENVDEF', `-DPATH="\"/bin:/usr/bin\""')
define(`confEBINDIR',`/usr/local/libexec')
define(`confMANROOT',`/usr/local/man/cat')
define(`confMANROOTMAN',`/usr/local/man/man')
define(`confMBINDIR',`/usr/local/sbin')
define(`confSBINDIR',`/usr/local/sbin')
define(`confUBINDIR',`/usr/local/bin')
define(`confNO_STATISTICS_INSTALL',`True')
define(`confHFDIR', `/usr/local/share/sendmail')
APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_sendmail_ENVDEF', `-DDANE')
APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
APPENDDEF(`conf_sendmail_ENVDEF', `-DUSE_BLACKLIST')
APPENDDEF(`conf_sendmail_LIBS', `-lblacklist')
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DHASSRANDOMDEV')
APPENDDEF(`confINCDIRS', `-I/usr/local/include')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`confLDOPTS', ``-Wl,-rpath=/usr/local/lib'')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -DTLS_EC')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
APPENDDEF(`conf_sendmail_ENVDEF', `-DPICKY_HELO_CHECK')
sendmail-8.15のときとの違いは、、、'_FFR_TLS_EC' だったものが 'TLS_EC'と正規?なパラメータ名になったこと、くらいか。いつものように、milter,sasl2,あたりをlinkすることも忘れないように。

sendmailを展開した $srcトップ にて、'sh ./Build;sh ./Build install'
実はこの作業の前に FreeBSD 11.2 -> 11.4, perlの入れ直し、gccの入れ直しなど大工事あり・・・
それにしても、、、古い OSを使い続けるとどんどん大変になる。

imap , duplicate なメールの削除

dovecot imap サーバをメインに利用しているけど、フォルダにメールが溜まりすぎ(30000通オーバー)で、思い立ったときにサブフォルダとかにテーマ・カテゴリ別にごそっと(2000通くらい?)移動させると、時に(ちょくちょく?)サーバとの接続が切れてしまいメールが移動前・後のフォルダの両方に残ってしまうことが。。。これを繰り返してしまうと同じメールが10通くらい溜まってしまう。

こういう時には、Thunderbird のadd-on のRemove Duplicate Messagesを使っていたが、これも javascriptで動いているみたいで、メール総数が重いと imapサーバのセッションが切れてしまって使い物にならなくなってきた。
となると、command line で動く、デバッグも見られるようなツールをということで探したら、
Remove duplicate emails through IMAP from shell
gitはこちら
pythonで動くので汎用的、dry-run機能もあるので事前にちゃんと動くか確認できる(option -n)、途中で サーバとのセッションが切れてもそれまでに発見したduplicate mail には delete markをつけてくれるので、何回かトライすればOK,などなど。
80000通あったフォルダに対して実行したら3時間くらいかかって、20000通以下に整理してくれた。

imap , duplicate なメールの削除

dovecot imap サーバをメインに利用しているけど、フォルダにメールが溜まりすぎ(30000通オーバー)で、思い立ったときにサブフォルダとかにテーマ・カテゴリ別にごそっと(2000通くらい?)移動させると、時に(ちょくちょく?)サーバとの接続が切れてしまいメールが移動前・後のフォルダの両方に残ってしまうことが。。。これを繰り返してしまうと同じメールが10通くらい溜まってしまう。

こういう時には、Thunderbird のadd-on のRemove Duplicate Messagesを使っていたが、これも javascriptで動いているみたいで、メール総数が重いと imapサーバのセッションが切れてしまって使い物にならなくなってきた。
となると、command line で動く、デバッグも見られるようなツールをということで探したら、
Remove duplicate emails through IMAP from shell
gitはこちら
pythonで動くので汎用的、dry-run機能もあるので事前にちゃんと動くか確認できる(option -n)、途中で サーバとのセッションが切れてもそれまでに発見したduplicate mail には delete markをつけてくれるので、何回かトライすればOK,などなど。
80000通あったフォルダに対して実行したら3時間くらいかかって、20000通以下に整理してくれた。