iPhoneで Postfix や Dovecot に付属の証明書が使えなくなった

iPhone/iPad の iOS 16.4.1 にすると、メールのSSLで信頼されない証明書を無理やり信頼することにして使うと方法がなくなったようです。

今までは無理やり信頼すればできました。
証明書のドメイン名などはどうでもよくて経路を暗号化したいだけのとき、今までは自分で作った証明書やメールサーバーに付属の証明書でもSSLを使うことができたのですが、これができなくなりました。

ドメイン名が違ったり署名なしの証明書はダメ、メールサーバー Postfix や Dovecot に付属の証明書ではSSLでメールが送受信できなくったということです。
あらら・・・

まあ当たり前の措置なのかもしれませんが・・・
自分のPCのメーラーと自分のサーバーの間の送受信では別にドメインの正当性を証明したいわけじゃなくて、経路を暗号化したいだけなんだけどな、と思わなくもないです。

sedによるtreeコマンドの代用

Linux コマンドの小ネタです。

GUIでツリー表示ができるファイルブラウザじゃなくて、SSHで入ってテキストベースのコンソールでディレクトリツリーの情報を得たいときや、その情報をテキストで抽出してメモしたいとき、普通は tree コマンドを使います。
でも tree コマンドは標準では入っていません。

それを sed を使って代用するワンライナーはこんな感じ

pwd; find . | sort | sed '1d;s/^\.//;s/\/\([^/]*\)$/|--\1/;s/\/[^/|]*/| /g'

これを /etc 直下で実行すると結果はこんな感じ

/etc
|--abrt
| |--abrt-action-save-package-data.conf
| |--abrt.conf
| |--gpg_keys.conf
| |--plugins
| | |--CCpp.conf
| | |--oops.conf
| | |--python.conf
| | |--vmcore.conf
| | |--xorg.conf
|--adjtime
|--aliases
|--aliases.db
|--alternatives
| |--cifs-idmap-plugin
| |--ld
| |--libnssckbi.so.x86_64
| |--mta
| |--mta-aliasesman
| |--mta-mailq
| |--mta-mailqman
| |--mta-newaliases
| |--mta-newaliasesman
| |--mta-pam
| |--mta-rmail
| |--mta-sendmail
| |--mta-sendmailman
|--anacrontab
|--asound.conf
|--at.deny
|--audisp
| |--audispd.conf
| |--plugins.d
| | |--af_unix.conf
| | |--syslog.conf
・
・
・

Postfix/Dovecot の TLS SNI対応

CentOS 8系から可能になった Postfix/DovecotメールサーバーのSSL/TLSをSNI対応。
(複数の証明書でマルチドメイン運用にする方法)

■ Dovecot TLS SNI対応

/etc/dovecot/conf.d/10-ssl.conf

# デフォルトの証明書(この記述も必要)
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem

# 以下を追加していく
local_name domain1.org {
  ssl_cert = </path/to/domain1_fullchain.crt
  ssl_key = </path/to/domain1_praivate.key
}
local_name domain2.org {
  ssl_cert = </path/to/domain2_fullchain.crt
  ssl_key = </path/to/domain2_praivate.key
}
・・・local_name を追加していく

他は通常のTLSの設定と同じ

■ Postfix TLS SNI対応

/etc/postfix/main.cf

# デフォルトの証明書(この記述も必要)
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key

# Postfix 3.4以上なら SNI可能
tls_server_sni_maps = hash:/etc/postfix/tls_server_sni_maps

他は通常のTLSの設定と同じ

証明書のマップファイル
/etc/postfix/tls_server_sni_maps

domain1 /path/to/domain1_praivate.key, /path/to/domain1_fullchain.crt
domain2 /path/to/domain2_praivate.key, /path/to/domain2_fullchain.crt
・・・

postmap -F hash:/etc/postfix/tls_server_sni_maps

★重要
証明書を更新時に postmap -F でマップdbを作り直す必要がある。

WordPressのバージョンのデフォルト

WordPressの設置依頼を受けたときは、PHPのバージョンにより、以下のバージョンを採用しています。

(2023年 9月現在)
特にWordPressのバージョン指定がない場合、
PHP 5.5以下では、WordPress 5.1系の最新版をインストールします。
PHP 5.6~7.0未満では、WordPress 5.5系の最新版をインストールします。
PHP 7.0~7.4未満では、WordPress 5.6系の最新版をインストールします。
PHP 7.4~8.xでは、WordPress 6.2系の最新版をインストールします。

※PHP 5.6以上なら WordPress 6.0以上を設置できます。特別に指定がある場合のみ設置します。

基本的に何でも新しいバージョンのほうがいいとは限らないです。
基本的に何でも新しいバージョンのほうが重くなりますし、評判が聞こえてくるまでの初期、過渡期はバグのリスクがありますので当サービスではできるだけ最新バージョンは避けることにしています。

ミドルウェアのバージョンのデフォルト

2021年3月より CentOS Stream 8 のサポート開始をいたします。

以下のサービスカテゴリに対象OSを追加しました。
サーバー初期構築/各種設定
サーバーマネージメント(保守契約)

(2021年3月現在)
特にミドルウェアのバージョン指定がない場合、
CentOS 7 では Apache 2.4 / PHP5.6 / MySQL 5.6 をインストールします。
CentOS 8 では Apache 2.4 / PHP7.4 / MySQL 8.0 をインストールします。

カスタムサーバー初期設定にてミドルウェアはバージョン指定が可能です。
ただし、バージョン指定は、OSの制限やミドルウェア同士の依存関係に制限がある等の理由でその組み合わせができないこともあります。

古い jcode.pl の修正方法

Perl のバージョンが 5.10 くらいまでは jcode.pl 同梱された CGI を使うことも多かったようですが、もう最近ではあまり見なくなりましたね。

サーバーに入っている Jcode.pm を使うのが普通だと思いますが、お客様のサーバー移転のために色々調査していて久しぶりに見かけました。
Perl のバージョンが 5.16 くらいに上がるとエラーを吐くようです。
うーん、どうしたもんか・・・。

defined(%hash) is deprecated at jcode.pl line ~

ネットに修正方法があったので、ポイントを転記しておきます。
どのサイトでも同じことを書いてますが、該当箇所はここ。

sub z2h_euc サブルーチン内
&init_z2h_euc unless defined %z2h_euc_inited;

sub z2h_sjis サブルーチン内
&init_z2h_sjis unless defined %z2h_sjis_inited;

いずれも、”unless defined %~” というのを使っています。ここがポイントです。これが引っかかっていますので、書き方を修正します。

修正は簡単で、”unless defined %” → “if !%” に書き換えるだけ。

sed コマンドでワンライナーでいけます。

sed -i "s/unless defined %/if \!%/g" jcode.pl

qmail サポート終了、Postfix へ移行のご案内

qmail サポートの既存サーバーへの特別措置終了と Postfix への特別移行プログラムのご案内です。

■ 経緯と特別措置終了について

qmail は、1998年に本家がサポートを終了した過去のメールサーバーソフトウェアです。
当サービスの保守契約ユーザー様には、qmail サポート終了を約1年前にご連絡しており、特別措置として既存サーバーに限り、保守・障害対応を行ってまいりました。

お早めに postfixへの切り替えをご検討くださいともお伝えし、はや1年。

そこで、今回のご連絡は、この特別措置を終了するお知らせです。

【重要】

期限:2021年1月末日をもちまして、現在 qmail でメール運用されている既存サーバーにつきましても qmail に関する部分のみを、サポート範囲外とさせていただきます。

それまでに qmail の運用から、postfix への移行を強くお勧めいたします。(強制するものではありませんが、メールの部分でのトラブルがあっても調査、障害対応を受けられなくなります)

そこで、postfix への特別移行プログラムをご用意しました。

■ 特別移行プログラム

通常、postfix/postfixadmin を初期設定する場合に当サービスでは以下の処理を行うため以下の料金になります。

・メールサーバー初期設定 1,000円
・バーチャルメールPostfixAdmin 追加 2,000円
・ドメインお引越し定型処理 2,000円 x ドメイン数
(自サーバー内のメールアドレスのみ移転と同じ処理)

これらの処理を、2021年1月末日までの間、既存の qmail運用ユーザー様限定の特別移行プログラムとして

全作業込み 3,000円/1サーバー

でお引き受けいたします。
(メールのお引越し作業が無料になります)

★条件として、パスワードが以下に見合うことが必要です。
──────────────────────────────────
現在 qmail/vpopmail で設定されているドメインの postmaster および全てのメールのパスワードが 6文字以上で、そのうちアルファベットが少なくとも3文字以上、かつ _ アンダーバー以外の記号文字が使われていないこと。
──────────────────────────────────

記号とは !”#$%&'()=~|`@{}[]+*;:,./\<>? などです。

ですので、
もしご依頼の際には現在運用中の postmaster およびメールアドレスのパスワードを条件に合うよう修正してからご依頼ください。

★ご注意事項として、
・メールシステム移行中はメールが送受信できません。
(概ね1~2時間)
・移行作業前にサーバーのメールボックスにあるメールはなくなります。
(直前にPOP受信してしまってください)
・MySQLのレプリケーションを利用している場合はメールドレスも MySQLのレプリケーションの影響を受けで同期されます。

お申し込み期限:2021年1月20日まで
対象は、当サービス保守契約中の qmail運用ユーザー様です。

■ 保守契約外のお客様のスポット作業料金

上記はあくまでも当サービスの当サービスの保守契約ユーザー様料金ですが、これをスポット作業(保守契約せずこのときだけのピンポイントでの作業依頼)として請け負う場合は以下の料金になります。

・サーバー内調査費用 1,000円(作業が出来るか出来ないかの判断費用)
・メールサーバー初期設定 1,000円
・バーチャルメールPostfixAdmin 追加 2,000円
・ドメインお引越し定型処理 2,000円 x ドメイン数
(自サーバー内のメールアドレスのみ移転と同じ処理)

※サーバー内調査費用は作業を請け負えないとわかった場合でも頂くことになります。
※サーバー内調査では yum コマンドを使用しリポジトリにアクセスします。
※SSH接続ができて、完全な root権限(root になれること)が必要です。

メールアドレス抽出の正規表現

■ Procmailで使えるメールアドレス正規表現

From、Return-Path などからメールアドレスを抽出する正規表現、意外と難しいです。
結論から言えば、正規表現一発ではできません。

例えば、こんな反則的なメールアドレスが実際にあったりして

Return-Path: <a-b-c._.d=efg@hogehoge.com>

例えば、メールアドレスらしきものが2つ含まれていたりして

From: "I-am@office.work" <a-b-c._.d=efg@hogehoge.com>

こんなやつも引っ掛けるには以下のようにします。

echo 変数 | grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

すると、こう展開されます。

echo '"I-am@office.work" <a-b-c._.d=efg@hogehoge.com>' \
| grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

結果
a-b-c._.d=efg@hogehoge.com

ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

スパムメールでは From はよく詐称されます。
From はあてにならないので From でブラックリスト判定するのは意味ないです。
やるなら Return-Path でブラックリスト判定のほうがマシ。
でも、ブラックリストを追加するのも疲れるしイタチごっこです。
もっとうまい方法がないか・・・

■ ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

From と Return-Path が違ったらもう削除してしまうなら以下


# ヘッダからメールアドレス抽出して変数へ

:0
* ^Return-Path:\/.*
RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^From:\/.*
ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^To:\/.*
ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

# スパム判定

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
/dev/null

でもこれだと、いろんなものが弾かれてしまいすぎ。
いやいや、それはちょっと厳しすぎると思う場合、
From と To が同じときスパム確定にするなら以下


ヘッダからメールアドレス抽出する部分は上記と同じ
・・・

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う - 目印を付けるだけ
:0fw
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
| formail -i "Procmail-Match-From-Return-Path: unmatch!" \
| formail -i "Procmail-Return-Path: $RETUERN_PATH" \
| formail -i "Procmail-From: $ORIGINAL_FROM" \
| formail -i "Procmail-To: $ORIGINAL_TO"

あとは、総務省の迷惑メール対策室へ自動で転送したり
From と Return-Path のドメインも判定したり・・・


######## ヘッダからメールアドレス抽出

:0
* ^Return-Path:\/.*
{
  RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  RETUERN_PATH_DOMAIN=`echo "$RETUERN_PATH"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^From:\/.*
{
  ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  ORIGINAL_FROM_DOMAIN=`echo "$ORIGINAL_FROM"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^To:\/.*
{
  ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
}

######## スパム判定

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
{
  # Return-Path ドメインが From ドメインを含まない
  :0fw
  *! $RETUERN_PATH_DOMAIN ?? $ $ORIGINAL_FROM_DOMAIN
  | formail -i "Procmail-Match-FromDomain-Return-Path: unmatch!"

  :0Efw
  | formail -i "Procmail-Match-From-Return-Path: unmatch!"

  :0fw
  | formail -i "Procmail-Return-Path: $RETUERN_PATH" \
  | formail -i "Procmail-From: $ORIGINAL_FROM" \
  | formail -i "Procmail-To: $ORIGINAL_TO"
}

# spamassassin
:0fw
*!^X-Spam.* 
| /usr/bin/spamc

:0c
* ^X-Spam-Flag: YES
{
  # 総務省の迷惑メール対策室へ転送
  # これで捨てずに自分も受信する

  SENDMAILFLAGS="-oi -f $RETUERN_PATH"
  ! meiwaku@dekyo.or.jp
}

こんな感じ。

qmail サポート対象外とします

今年から qmail をサポート対象外とします。

■ qmailとは

qmail とは、ライフサイクルを終えた旧式のメールサーバーです。
1998年に本家が開発サポートを終了しており、その後は有志によってのみ追加機能パッチなどが細々と出ておりましたが、さすがに昨今の時流には対応できていない過去の遺物になっています。
新しい驚異には対応できずセキュリティホール等の修正パッチもリリースされないため、特別な事情がない限り qmail は避けるべきです。

■ qmail の保守・障害対応について

2019年1月末をもって、当サービスでは保守・障害対応をしないこといたしました。
しかしながらどうしてもという事情がある方のために環境構築だけは特別料金で請け負う形を残しておきました。

・qmail/vpopmail/qmailadmin 構築

(メールサーバーをqmailにしバーチャルメール環境を追加します。ただしアフター保守・障害対応の対象外)
費用についてはこちらの料金表を参照ください。