iPhone/iPad の iOS 16.4.1 にすると、メールのSSLで信頼されない証明書を無理やり信頼することにして使うと方法がなくなったようです。
今までは無理やり信頼すればできました。
証明書のドメイン名などはどうでもよくて経路を暗号化したいだけのとき、今までは自分で作った証明書やメールサーバーに付属の証明書でもSSLを使うことができたのですが、これができなくなりました。
ドメイン名が違ったり署名なしの証明書はダメ、メールサーバー Postfix や Dovecot に付属の証明書ではSSLでメールが送受信できなくったということです。
あらら・・・
まあ当たり前の措置なのかもしれませんが・・・
自分のPCのメーラーと自分のサーバーの間の送受信では別にドメインの正当性を証明したいわけじゃなくて、経路を暗号化したいだけなんだけどな、と思わなくもないです。
CentOS 8系から可能になった Postfix/DovecotメールサーバーのSSL/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の設定と同じ
/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の設置依頼を受けたときは、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の制限やミドルウェア同士の依存関係に制限がある等の理由でその組み合わせができないこともあります。
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 およびメールアドレスのパスワードを条件に合うよう修正してからご依頼ください。
★ご注意事項として、
・メールシステム移行中はメールが送受信できません。
（概ね１～２時間）
・移行作業前にサーバーのメールボックスにあるメールはなくなります。
（直前にPOP受信してしまってください）
・MySQLのレプリケーションを利用している場合はメールドレスも MySQLのレプリケーションの影響を受けで同期されます。
お申し込み期限：2021年1月20日まで
対象は、当サービス保守契約中の qmail運用ユーザー様です。
上記はあくまでも当サービスの当サービスの保守契約ユーザー様料金ですが、これをスポット作業（保守契約せずこのときだけのピンポイントでの作業依頼）として請け負う場合は以下の料金になります。
・サーバー内調査費用 1,000円（作業が出来るか出来ないかの判断費用）
・メールサーバー初期設定 1,000円
・バーチャルメールPostfixAdmin 追加 2,000円
・ドメインお引越し定型処理 2,000円 x ドメイン数
(自サーバー内のメールアドレスのみ移転と同じ処理)
※サーバー内調査費用は作業を請け負えないとわかった場合でも頂くことになります。
※サーバー内調査では yum コマンドを使用しリポジトリにアクセスします。
※SSH接続ができて、完全な root権限（root になれること）が必要です。
今年から qmail をサポート対象外とします。
qmail とは、ライフサイクルを終えた旧式のメールサーバーです。
1998年に本家が開発サポートを終了しており、その後は有志によってのみ追加機能パッチなどが細々と出ておりましたが、さすがに昨今の時流には対応できていない過去の遺物になっています。
新しい驚異には対応できずセキュリティホール等の修正パッチもリリースされないため、特別な事情がない限り qmail は避けるべきです。
2019年1月末をもって、当サービスでは保守・障害対応をしないこといたしました。
しかしながらどうしてもという事情がある方のために環境構築だけは特別料金で請け負う形を残しておきました。
(メールサーバーをqmailにしバーチャルメール環境を追加します。ただしアフター保守・障害対応の対象外)
費用についてはこちらの料金表を参照ください。
サーバー初期構築／各種設定／サーバーマネージメント（保守契約）に関して
お客様のお申し込みからの作業の流れは以下のとおりです。
お送りしたメールにはお客様のサーバー情報をご記入頂くフォーマットがあります。
ご記入頂く情報は以下の項目です。
・対象サーバーIPアドレス: ・接続用アカウント(ユーザー名): ・接続用アカウントパスワード: ・root パスワード: ・SSHポート番号:
※ユーザー名は、SSHユーザー名あるいはFTPユーザー名です。
※お送りしたメールに指定のフォーマットでご返信を頂きます。
これはお申し込みの作業が可能かどうかを判断する重要な作業になります。
特殊な環境になっている場合やインストール済みのミドルウェアバージョン等によって、稀にご依頼の作業ができないような環境もあります。それを判断するものです。
これはお申し込みから30分程度で完了することが多く、大抵１時間以内です。
ここで初めてお申し込み確定・ご成約となり、費用のお支払いへと進みます。
作業は数時間（１時間～半日）で完了することが多く、大抵１日以内です。
サーバー初期構築／各種設定／サーバーマネージメント（保守契約）に関して
当サービスのご利用条件は以下のとおりです。
・対象OS: CentOS Stream 9（RHEL9系）以降 ・インターネット経由でSSH接続が可能であること ・root権限あり（SSHでログイン後 root で作業ができること） ・Parallels Panel, Plesk, cPanel がインストールされていないこと ・中継機器等のパケットフィルタリングでポートが閉じていないこと
特に、インターネット経由でSSH接続が可能であることは重要です。
これは、OSインストールとネットワークの初期設定は請け負っていないことを意味します。
当サービスがサーバー初期構築／各種設定として想定しているのは、専用サーバーあるいはVPSあるいはクラウドのインスタンス生成後、Webサーバーとして機能するためのミドルウェア（Apache、MySQL、メール関連やFTP機能等）の設定がされていない状態からそれを初期設定していく作業の代行です。
サービス一覧はこちら
⇛ サーバー初期構築／各種設定のページ
また、当サービスがサーバーマネージメント（保守契約）として想定しているのは、サーバーをクリーンに保つための日々の目立たない地味な管理作業（各種サービスが正常稼働しているか、問題はないかのリアルタイム状態監視と不具合発生時の即対応）および、ユーザー作成、Webサイトのバーチャルドメイン設定（サイト開設時の初期設定）、メールのバーチャルドメイン設定、MySQLデータベース作業等々諸々の作業代行です。
サービス一覧はこちら
⇛ サーバーマネージメント（保守契約）のページ
◎フルマネージメントの作業代行サポート範囲参照
先日明らかにされたセキュリティアラート: CVE-2017-3136/3137/3138
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性
対策実施について
原文はこちら
CVE-2017-3136（英文）
https://kb.isc.org/article/AA-01465
CVE-2017-3137（英文）
https://kb.isc.org/article/AA-01466
CVE-2017-3138（英文）
https://kb.isc.org/article/AA-01471
JVNVU#97322649
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性
http://jvn.jp/vu/JVNVU97322649/index.html
本件の問題点と対策は以下の通りです。
前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回はさらに突っ込んでGoogleのGmailの厳しい判定が迷惑な問題について書きます。
参考）
一括送信ガイドライン – Gmail ヘルプ
https://support.google.com/mail/answer/81126
Googleだけに限ったことではないですが、Gmailはシェアが多いのでトラブルが目立ちます。
トラブルというのは【Gmailに送ると届かない】という問題です。
これはGmailが、迷惑メール対策として判定が厳しいためです。
Googleは最近、自分たちのガイドラインに【何が何でも従わせる】という強引なやり方をするようになりました。
事実、Googleのガイドラインに従わないメールはリジェクト（受信拒否）されるトラブルが多く、最近 Gmail / G Suite(旧 Google Apps)のメールに関して問い合わせが多いです。
仕事の取引先からの必要なメールでもGoogleのガイドラインに反していると届きません。
迷惑メールフォルダに振り分けられるならまだしも、勝手にリジェクトされて気付かないままになります。