FreeBSD で db5 -> db18 にしたお話。

FreeBSD の daily security run output に

Checking for packages with security vulnerabilities:
Database fetched: Sun Oct 30 03:18:04 JST 2022
db5-5.3.28_8: Tag: expiration_date Value: 2022-06-30
db5-5.3.28_8: Tag: deprecated Value: EOLd, potential security issues, maybe use db18 instead

と警告が出ていたのですが、その内 ports/UPDATING にアップデート方法が載るだろうとほったらかしにしていました。本日 UPDATING を見ても特に記載がないので自力で db18 に移行方法を調べました。
db5 の依存関係を調べると私の環境では

ruby30-bdb
cyrus-sasl2

が依存している事が分かりました。
で、/etc/make.conf に

DEFAULT_VERSIONS+= bdb=18

と記述して、試しに

cd /usr/ports/security/cyrus-sasl2
make deinstall reinstall clean

したのですが db18 依存になってくれません。
適当にググったら

DEFAULT_VERSIONS+= bdb=18
WITH_BDB6_PERMITTED=yes

との情報があったので試すと db18 依存になってくれました。
両方を再 make した後

pkg delete db5

すると db5 だけ削除できました。
めでたし、めでたしw

ED25519 の勧め

ssh で接続してサーバー管理をする。サーバー管理の現場ではごく一般的に行われている風景だが普通の人から見ると暗いディスプレイの中に文字が飛び交う、映画なんかで出てくるコンピュータを操る悪いハッカーそのものだろう。w
ssh 接続するにはその経路を暗号化する為の暗号方式が必要だ。現在の主流は rsa 2048 bit と言う暗号方式で、現在の最速スーパーコンピュータを使用しても現実的な時間で解析出来ないとされている。暗号の性能を示す指標として暗号強度と言うものがあるがこれは暗号化するためのキーが何通りあるかで示される。rsa 2048 bit は 112 bit の暗号強度を持つが、これは 2 の 112 乗のキーがあると言う意味になる。そのうちのの一つが正解の暗号キーとなる訳で、暗号強度を高めるにはすぐ想像がつく様に bit 数を増やせば良いのだが bit 数を増やすと暗号化・復号化の時間が増えるため実用性の観点から無闇矢鱈に増やせば良いと言うものではなくバランスを取らなければならない。暗号化にはそのやり方、アルゴリズムも重要だ。rsa 方式は大きな数字の素因数分解に効率的な方法が無いため基本的に総当たりでしか暗号キーを見つける事ができない事を利用しているのだが、開発が進められている量子コンピュータを使用すると効率的な素因数分解解析アルゴリズムが発見されており、量子コンピュータが実用化されると rsa 暗号は破られてしまう危険性が指摘されていてアメリカの NIST と言う研究機関が 2031 年以降は rsa 2048 bit の使用を禁止する声明を出している。そんな事もあって rsa 方式に代わる暗号アルゴリズムが幾つか提案されている。そのうちのひとつに暗号強度は 128 bit さらに暗号キーの大きさが rsa より短く、暗号化・復号化の時間も大差ないエドワーズ曲線デジタル署名アルゴリズム(EdDSA)の ED25519 がある。つまり、ED25519 がサポートされていれば置き換えない理由はあなたのやる気だけなのだ。という訳で皆さん ED25519 を使いましょう。ではでは

私が初めて FreeBSD を触ったのは FreeBSD 2.0 からだ。wiki を見ると FreeBSD 2.0 のリリースは1994年11月22日となっているのでもう30年弱のお付き合いとなる。Linux と言うチョイスも有ったのだが、現在と同様に多数のディストリビューターがありそれに迷うのを避けたのと、Unix の正統派 BSD like のオープンソースな事がポッと出の Linux に比べてこちらを選ぶのが通と言う思い込みがあった。当時勤めていた会社には 64kbps の専用線が引かれていたのだが(64kbps でも月１０万円近くしていた様に記憶している) FreeBSD をダウンロードするのに一晩かかった事を覚えている。右も左も分からないままメールサーバーを立ち上げ、会社のドメインを取って運用したのだが大変苦労した。それ以降 Linux に1−2年浮気した以外は FreeBSD で自分のサーバーを運用している。その頃は Linux と FreeBSD はライバル関係と言っても語弊はなかったのだが、最近の調査結果 を見ると、Web サーバーにおいて Unix が80%余りだが、FreeBSD のシェアは 0.2% と余りに寂しい状況だ。対して Linux は 37% と比較するのもおこがましいのが現実である。とは言うものの、Apple の Mac OS は FreeBSD を土台に作られていたり、Sony PS シリーズ、Yahoo のメインサーバー、さくらインターネットのレンタルサーバーなども FreeBSD だったりして決して Linux に劣ることのない性能を持っている。そんな FreeBSD の魅力を私の視線から述べるとすると

• 保守的だが高負荷時にも安定した動作性能
• ports 管理による柔軟なアプリ管理
• カーネルと OS 全体が一体となって開発されている(極端に言うと Linux はカーネルに各ディストリビューターが勝手に機能を付け加えて OS として成立させている)

あたりだろうか。uptime が3000日を超えている FreeBSD を見た事があるが、実際30年近く FreeBSD を触ってきた感想として少々手荒な事をしても FreeBSD は安定した動作が期待できる信頼感がある。ソースからコンパイルする port によるアプリ管理は細かいオプション制御が出来て私は重宝している。ただ、 FreeBSD は GUI 周りの整備が Linux に比べると差がある様に見える。単なる CUI 制御のサーバー性能比較では Linux に劣らぬどころか一部は優っていると思うのだが、やはり GUI でポチポチやれるのは一般受けが良いんだろうと想像している。まぁ、私の推察が正しいのかどうかは置いておいて、現実はシェア的には Linux の圧倒的勝利と行っても良いだろう。でも、世の中必ずニッチな勢力に目を向けてくれる人もいる。そこのあなた、一度 FreeBSD を触ってみませんか？ Linux との文化の違いを垣間見るだけでも結構面白いですよ。と、つぶやいてみますw。ではでは

CAPTCHA

CAPTCHA と言われてすぐにそれが何か分かる人はそう多く無いだろうが、上の「私はロボットではありません」やひん曲がったあるいはノイズの入った文字列の入力、信号機や横断歩道、バスの入ったパネルをチェックするなど、入力しているのが人間である事を認証するシステムを見たことのある人は多いだろう。CAPTCHA が使われ始めた初期の頃はほんのちょっと斜めになっていればコンピュータ(bot)は認識できなかったのが、AI 機械学習の進歩によりどんどん読める様になってきて、その為文字の加工具合やノイズの量が増えてきて人間にも判読できないまでになってきているんだそうだ。私も信号機のパネルを選ぶ時、ほんのちょっとだけ引っ掛かっているのは含めるのか否か、消火栓を選べと言われても国によって消火栓の形状が様々だったりして何度も繰り返しチェックを受けさせられてイライラした事が何度もある。Cloudflare によると CAPTCHA 認証に平均32秒かかっていて世界的にみると毎日500年間分の時間が無駄に費やされているんだとか。で、まぁ普通の人にはここまでの知識を「ふーん」で終わりにして、ちょっとした知識の見せびらかしや酒のつまみにすればいいんだけど、Wordpress でブログやホームページをやっている人はコメントやお問い合わせフォームに bot から spam を投稿される事への対策をする必要がある。うんで wordpress には最初からAkismet Spam Protection と言う対策プラグインが入っていてとても評判が良いのだがこれ無料で使う条件に営利を伴うサイトでない、アフェリエイトリンクを張っていないなどがある。つまり営利目的が含まれる場合は有料なのだ。私はケチなのでそんなの払いたく無い。でも spam 対策はしなければならないので出てくるのは無料で使える Google の reCAPTCHAでこれには v2 と v3 があり、皆さんがよくご覧になるのは上に表示されている v2 の「私はロボットではありません」だ。v3 では出ない。無料、Google 謹製である事、認証の難易度が高く無い初期の頃は使い勝手が良かったなどがおそらく理由で、2022年10月の段階では相当のシェアを持ちあちこちで見かける。勿論、Worpress 様にも多数のプラグインが用意されていてよりどりみどりだ。
そこへ2022年9月末に発表されたのが

Cloudflare Turnstile

Cloudflare Turnstile で、CAPTCHA に代わる認証方式としている。先に述べた様に Cloudflare によると、現在の CAPTCHA は認証に平均32秒かかっているのが Turnstile では1秒になるとのこと。これでいままでと認証精度が変わらないのなら大進歩だ。そしてすでに WordPress のプラグインも用意されている。Easy Cloudflare Turnstile がそれだ。私がお勧めするのだから勿論無料だ。ここから手順に従ってkeyを取得すればあっという間に WordPress に実装できる。導入動画が有ったのでリンクを貼っておく。

Turnstile 導入動画

2022年9月末発表なので実績が全然足りないが、この私のブログに早速導入した。皆さんも如何ですか？
何らかの原因で Tuenstile に人間判定してもらえなくてログインできなくなることがあるらしい。w
そのときは

Keep on mind, that in case of emergency, you can disable this plugin via FTP access, just rename the plugin folder.

の指示に従い wp-content/plugins/ 下にある wppool-turnstile-captcha-spam-filter をリネームすればプラグインが無効になるそうだ。万一の為に覚えておこう。
ではでは

gmail に於ける spf と転送の問題解決

独自ドメインのメール管理に gmail を使用しています。まず独自ドメイン用のメールサーバーを立ち上げます。普通このメールサーバーに対しメールクライアントでアクセスしますが、私の場合 gmail のインタフェース、機能を使ってメール管理・運用をしたいので、メールサーバーからgmail にメールを転送して読み書き、保存をして、メールを出す時は gmail からメールサーバーを経由、リレーしています。
なんでこんなことをしているかと言うと、gmail の優れた UI 、迷惑メールフィルタなどを使いたいからです。
ここで問題となるのが、単に転送するだけでは gmail で spf エラーが出る事です。その為、最初は gmail にメールを持ってくるのに pop3 を使っていたんですが、gmail の pop3 って最長1時間に1回位の頻度でしかチェックしてくれません。私同様これを不便と思う人がいる様で chrome の拡張機能で

• Gmail POP3 Auto Refresh
• Gmail POP Sync

などがあり、1分間隔でメールチェックをしてくれます。
が、これは gmail サーバーに負荷を与えますし、イリーガルな感が拭えません。下手するとアカウント ban されるかもしれません(まぁ、大丈夫だと思うけど)。なので、転送しても spf エラーにならない方法を調べてみると

• SPFと転送の相性問題に対する解決策の紹介

に大変参考になる記事が見つかりました。
ここに記述されている

• 単純方式（SPFと転送の相性問題に対する解決案の2つの方式）
• SRS（Sender Rewriting Scheme）

それぞれについて postfix での解決方法を記述しておく。
最初の解決方法は、Envelope from の書き換えで、postfix の main.cf に

sender_canonical_classes = envelope_sender
sender_canonical_maps = regexp:/usr/local/etc/postfix/sender_canonical

を加えて、sender_canonical に正規表現で

/@([a-zA-Z0-9_+\-\.]+)$/ @example.net

などと記述して転送サーバーが spf 対応しているドメインに書き換える事で問題を解決する。
但し、参照した記事にあるとおりエラーメールなどを本当の発信者に返すことが出来ない。

そこで2番目の登場となる。これは

• センダー・リライティング・スキーム（Sender Rewriting Scheme,SRS)

を使用した技術で、上の単に spf の認証が通るドメインに書き換えるのではなく、spf の認証を通り尚且つ元の差出人の情報も保持したまま転送できる。postfix 用に

• postsrsd

が開発されており私もこれを使用している。ソースを github からダウンロードして make して出来た postsrsd を /usr/local/sbin などに install(make install すると default でここに入る) して
postfix の main.cf に

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

を追加して、postsrsd を

postsrsd -D -u mailnull -p /var/run/postsrsd/postsrsd.pid -d mail.example.com -s /usr/local/etc/postsrsd.secret -f 10001 -r 10002 -t 1800

などとして起動。postfix も reload ないし再起動すれば

Oct 16 16:12:44 mail postsrsd[54963]: srs_forward: <example@example.com> rewritten as <SRS0=rQK4=2R=example.com=example@example.net>

の様に example.com -> example.net に元の情報を維持しつつ且つ spf 認証を通るアドレスに変換される様になる。以上、ご参考になると幸いです。ではでは

postfix + spf-engine + opendmarc + opendkim

定番の組み合わせに spf-engine https://launchpad.net/spf-engine を追加しました。spf-engine は以前よく使われていた pypolicyd-spf(開発終了) の後継であり更に spfmilter の機能も引き継いで現在も開発が続けられている spf ユーティリティです。
dmarc は spf か dkim のどちらかの認証に成功するとメールを pass を返します。
逆に言うと、spf, dkim 両方の認証に失敗した時 fail を返し、メールの受信者は送信者の dmarc 設定を参照、参考にしてそのメールの処遇を決めます。
実際に認証の可否を受け持つのは　dkim については opendkim が、spf-engine が無い場合は spf については opendmarc が担当します。その場合、dmarc は spf の認証について成功か失敗の二つしか返しません。そこでspf の認証についてより細かく制御する為に、spf 認証ユーティリティとして spf-engine を追加します。
spf-engine 以外にも spf ユーティリティとして以下の物が見つかりましたが

p5-Mail-SPF
postfix-policyd-spf-perl

spf-engine が最終更新が2022年2月と一番新しく現在も開発が続けられていて、またかつて広く使用されていた pypolicyd-spf の後継であることなどから2022年10月の段階では一番高機能で信頼できるユーティリティと私は判断しました。

spf 認証結果についておさらいしておきましょう。

spf-engine の主なパラメータとして次の様な物があります。

• HELO/EHLO コマンドから得た from 送信ドメインについて spf 認証

#  HELO check rejection policy. Options are:
#  HELO_reject = SPF_Not_Pass (default) - Reject if result not Pass/None/Tempfail.
#  HELO_reject = Softfail - Reject if result Softfail and Fail
#  HELO_reject = Fail - Reject on HELO Fail
#  HELO_reject = Null - Only reject HELO Fail for Null sender (SPF Classic)
#  HELO_reject = False - Never reject/defer on HELO, append header only. 
#  HELO_reject = No_Check - Never check HELO.

• SMTP の MAIL FROM (envelope From)の spf 認証

#  Mail From rejection policy.  Options are:
#  Mail_From_reject = SPF_Not_Pass - Reject if result not Pass/None/Tempfail.
#  Mail_From_reject = Softfail - Reject if result Softfail and Fail
#  Mail_From_reject = Fail - Reject on Mail From Fail (default)
#  Mail_From_reject = False - Never reject/defer on Mail From, append header only
#  Mail_From_reject = No_Check - Never check Mail From/Return Path.

• spf レコードが不正の場合

#  Policy for rejecting due to SPF PermError.  Options are:
#  PermError_reject = True
#  PermError_reject = False

• spf レコードが一時的に不正(dns サーバーが落ちているとかかな？)

#  Policy for deferring messages due to SPF TempError.  Options are:
#  TempError_Defer = True
#  TempError_Defer = False

その他、特定のドメインで Netural/Softfail が出た場合とか FQDN や IP アドレスでのホワイト・ブラックリストなど、dmarc では出来ない細かな spf 認証についての処理が出来ます。
実はよく使い方が分からない、理解出来ないパラメータもあります。w
自分のサーバーですので、万一正しいメールを弾いてしまっても自己責任と言う事で色々実験中ですのでその内おすすめ設定をアップできる様に頑張っている最中です。生暖かい目でご期待ください。
ではでは

FreeBSD certbot error ImportError: cannot import name ‘x509’ from ‘cryptography.hazmat.bindings._rust’ (unknown location)

FreeBSD で、2022/10/10 頃にアップデートされた py39-cryptography-38.0.1 が原因で certbot が動かなくなっています。一つ前の py39-cryptography-3.4.8 に戻せば動きます。
38.0.1 を削除してpkg install py39-cryptography とかすれば3.4.8 に戻せます。
portdowngrade-1.7 を使うのも良いでしょう。3.4.8 に戻したら取り敢えず

pkg lock py39-cryptography

としておくのが吉かもしれない。

Let’s encryptのコミュニティ

や

FreeBSD のバグレポート

で既に論議されているので近い内に修正されると思われますが、毎日 cron で certbot renew している人もいるでしょうから情報として共有しておきます。

Conoha VPS が2022年11月7日迄の期間限定で最大75%引きのキャンペーンを開催しています。これはお得です。普段は最大23%割引だから割引率が大幅に上がっている。
75%引きになるのは VPS割引きっぷ 36ヶ月契約の

– 3 CPU 2GBRAM 100GBSSD の通常、月 1,848 円が 460 円
– 4 CPU 4GBRAM 100GBSSD の通常、月 3,608 円が 879 円

の場合だ。36ヶ月分の先払いが必要だが、思わずグラっとくる人も多いのでは無いだろうか？
36ヶ月契約でなくても良い。VPS割引きっぷ 3ヶ月契約でも

– 3 CPU 2GBRAM 100GBSSD の通常、月 1,848 円が 660 円
– 4 CPU 4GBRAM 100GBSSD の通常、月 3,608 円が 1,190 円

になる。1ヶ月しか使わなくても、3 CPU の場合は 660 x 3 = 1,980 円なので、通常の 1,848 円に 132 円上乗せすれば3ヶ月使える。4CPU に至っては 1,190 x 3 = 3,570 円だから3ヶ月契約をした方が安い事になる。

何故、こんな大盤振る舞いをしているのか。
これは想像なのだが、レンタルサーバー大手のエックスサーバーが 2922年9月に VPS に参入してきた事が影響しているのではないかと私は考えている。Xserver VPS をご覧になるとわかるが、Xserver VPS はリリース記念キャンペーンをやっていてその価格が今回の Conoha VPS の割引価格と実に酷似している。つまり、Conoha がエックスサーバーに喧嘩をふっかけたのではないかと言うのが私の妄想ですw。
本当の理由は闇の中ですがユーザーにとっては嬉しい競争で、VPS を今使っている人も、これから使おうと思っている人も注目です。
私は 3CPU 2GB プランを来月11月の頭に契約するつもりです。みなさんも如何ですか？
なお、ここのバナーを経由して契約すると７００円のクーポンがプレゼントされますので宜しければお使いください。
ではでは

WordPress でブログを始めて1週間もしないうちにサーバー移転すると言う無計画さに自分でも呆れています。
バックアップを取って移転先に復元すれば良いんだろう？有名どころのバックアッププラグインがあるから簡単なんじゃ無いの？と思っていたんですが、それは元と移転先が同じURLを使う場合でした。
つまり、example.com で動いていた wordpress を移転先でも example.com で運用する場合ですね。これだと本当に updraftplus や all in one WP Migration などのダウンロード数が数百万のバックアップ、復元プラグインであまり考える事なく作業すれば良いです。私の場合もこうだったので updraftplus を使う事で何も悩む事無くサーバー移転は終了しました。
ここで辞めておけば幸せだったのですが、移行先のURLが違う場合、つまり example.com -> example.net みたいな場合もついでに練習しておこうと思ったのが運の尽き。データベースの中にある example.com を example.net に変換しなければならないんですが、単純に置換すれば良い訳では無く色々と面倒くさい事が分かりました。
取り敢えず本家のマニュアルWordPress の移行を読む。
ここには3つのやり方が書いてあります。

1. 移行した後、ダッシュボードにアクセス出来るならプラグインを使う。
2. コマンドラインで WordPress を制御できる wp-cli と言うツールを使う。wp-cliはwordpress公式のツール。
3. Search Replace DBと言うツールを使う。

ここで書いてある1のプラグインや3のツールは最終更新が2020年と最近は更新されていないし、wordpress 公式でも無い。2の wp-cli は wordpress 公式で現在も開発が続けられていることからこの中では一番信用できるツールではないかと私は推測しています。
次に先に書いた、all in one wp migration にはバックアップ時にデータベース内容の置換機能が付属している。migration と名乗っている事からURL変換を主な目的としているのだろうし、現在も頻繁に更新されていることからこちらも信用してよさそう。

と言う訳でどれ、実際にやってみようと結局は20回近くバックアップ復元の実験をした。
結果、私の結論としては次の二つが私の見る限り正常にバックアップ・復元(URL変更する)出来ており、今後自分が使用しようと思えるものであった。

まず、最初に URL 変換がない場合は

1. バックアップを取る。プラグインの updraftplus か all in one wp migration が良いだろう。
2. 移転先で wordpress の初期セットアップを行い、どちらかのプラグインを導入して復元すればお終いである。場合によっては wp-config.php のデータベース名やユーザー名、パスワードの修正が必要かもしれない。

まぁ、誰でもできる作業だと思う。問題は URL が変わる時だ。
私の最初のお勧めは updraftplus でバックアップして、そのまま移転先に復元してから wp-cli で

wp search-replace 'https://example.com' 'https://example.net'

する事である。

2番目は、all in one wp migration でバックアップする時データベースの内容を置換してくれる機能を利用する方法だ。その後、移転先で復元すれば良い。これは wp-cli と言う ssh 接続してコマンドを叩くと言う知らない人が見たらハッカーもどきの作業に比べれば難易度は格段に低いから普通の人にはこちらがお勧めだと思う。

なお、all in one wp migrastion はファイルの容量が 512MB を超えると有料版が必要になるが、こいつでバックアップするのはデータベースだけにしておけば、私の例だが10記事で2MB 行かないくらいだったので大雑把に3000記事位までは大丈夫と思われ、事実上無制限に近い。他のはどうするんだって？移転先で all in one wp migration が動く最小限の構成で立ち上げ、rsync で元からどさっとコピーしておいてからリストアすれば良い。

ちょっと普通の人には難しいかもしれないけど普段 ssh でやっている人には簡単だと思う。
1日朝から晩までバックアップ・復元実験に費やしたがこれで wordpress 引っ越しを頼まれても多分できると思われる。
ではでは

Postfix

ここ3日ほど、サーバー移転であれやこれやもがいていました。
どうやら、目安が立ったところで前からやろうと思っていた各種設定の整理整頓を始めます。
例えば Postfix。メールの送受信出来れば良かったのに、relay するから sasl 設定して、自己証明書で ssl して、SPF, dkim, dmarc も追加、let’s encrypt も入れて、ついでに spam 対策もやろうとかやっているうちにmain.cf がぐちゃぐちゃになってしまい、なんかちゃんと動いているからまぁ良いや、、、そのうちちゃんと綺麗に書き直そう、、、現在に至ると言うのが現状です。
今回のサーバー移転では移転先の環境を1からやったので　いやがおうにも(いやがうえにもが正しい言い方らしいw)整理する羽目になったのでした。って偉そうに言うほどのものでも無いけど、何をやっているかコメントを沢山入れたものをつくったので、恥ずかしげも無く公開する。
ちなみに私は Postfix の experimental release と言うそのまま直訳すると開発・実験版を使用している。
そんなもん、怖くて使えないって人も居るだろうが、中の人が言うには“it runs on all of Wietse’s systems so it is production quality.” 作者の Wietse さんシステムで動いていて、「製品品質」との事なのでと今までの経験上特にトラブルになったことも無いので結構安心して使っている。もしよろしければ皆様もどうぞ。

今回は let’s encrypt で証明書を取得済みを前提としている。また、今回は postfix の部分のみ、後日 opendkim, opendmarc, dovecot を別稿で追加するのでご了承頂きたい。

では私の main.cf と master.cf を次に。ご参考になったら幸いです。
では、今日はこの辺で失礼します。

main.cf

compatibility_level=3.8

# 信用するのはこのサーバーだけ mynetworks を設定すると無効になるので注意
# デフォルトだが書いておく
mynetworks_style = host

# 世界とメールのやりとりが出来る様に
inet_interfaces = all

# alias の在処
alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases

# コマンド追加
allow_mail_to_commands = alias,forward,include

# myorigin はこのサーバから出るメールはなんと名乗るか。@の後の事
mydomain = example.com
myhostname = www.example.com
myorigin = example.com

# @の後がどんなメールだったら受け取るか
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# メールの配送形式
home_mailbox = Maildir/

# デフォルトは postfix を使っている事を返すので分からない様にする
# 規約では bannerの最初は$myhostnameを記載しなければいけないので従う
smtpd_banner = $myhostname ESMTP

# メールアカウントチェック対策
# ユーザー存在確認されても答えない。
disable_vrfy_command = yes

# 接続後の挨拶（HELO）を強制
smtpd_helo_required = yes

# 誤作動防止とETRNコマンドも制限しておく
smtpd_delay_reject = yes
smtpd_etrn_restrictions =
        permit_mynetworks
        reject

# 自分の送信メールのヘッダからローカルIPを消す
header_checks= regexp:/usr/local/etc/postfix/header_checks
always_add_missing_headers = yes

# RCPT TO及びMAIL FROMで正しい文法を強制
strict_rfc821_envelopes = yes

# スパムの踏み台を防止（デフォルト）
allow_untrusted_routing = no

# 前もってコマンドを送ってくる無礼なやつは拒否！
smtpd_data_restrictions = 
    reject_unauth_pipelining

# 宛先不明は /dev/null
# デフォルトはそんな宛先無いよと言う返事を返すけど知らんぷりする。
# 管理者の意向次第だがこれを利用したスパムもある様なので私はこれで良いと思っている。
# 但し、typo したメール差出人は送ったのになーとなる事だけは覚えておこう。
local_recipient_maps =
luser_relay = unknown_user@localhost

# HELOコマンド受信時のホスト名による受信制限
# DNS に登録されていない、FQDNが解決できない、ホスト名の文法が不正の場合に拒否
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unknown_hostname
    reject_non_fqdn_hostname
    reject_invalid_hostname
    permit

# ドメインが解決できない、FQDNが解決できない場合に拒否
smtpd_sender_restrictions = 
    permit_mynetworks
    reject_unknown_sender_domain
    reject_non_fqdn_sender

# smtpd_recipient_restrictions = は古い書式
# ver2.10以降この記述でリレーの抜け穴を防止する
smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    defer_unauth_destination

# sasl 認証
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $mydomain

# cyrus の場合はこちら
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd

# dovecot の場合はこちら
#smtpd_sasl_type = dovecot
#smtpd_sasl_path = private/auth

# SMTP 配送のTLS 設定
smtp_tls_CAfile = /usr/local/etc/ssl/cert.pem
smtp_tls_key_file = /usr/local/etc/letsencrypt/live/example.com/privkey.pem
smtp_tls_cert_file = /usr/local/etc/letsencrypt/live/example.com/fullchain.pem
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2

# SMTP 受信のTLS 設定
smtpd_tls_CAfile = /usr/local/etc/ssl/cert.pem
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/letsencrypt/live/example.com/privkey.pem
smtpd_tls_cert_file = /usr/local/etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium

# 以下の暗号形式については mozilla さんにお任せ
# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem
# not actually 1024 bits, this applies to all DHE >= 1024 bits
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dhparam.pem

tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
tls_preempt_cipherlist = no


# opendkim と opendmarc
smtpd_milters =
        unix:/var/run/milteropendkim/milteropendkim.sock
        unix:/var/run/opendmarc/opendmarc.sock
non_smtpd_milters =
        unix:/var/run/milteropendkim/milteropendkim.sock
        unix:/var/run/opendmarc/opendmarc.sock

master.cf 必要部分のみ

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen
#smtpd     pass  -       -       n       -       -       smtpd
#dnsblog   unix  -       -       n       -       0       dnsblog
#tlsproxy  unix  -       -       n       -       0       tlsproxy
# Choose one: enable submission for loopback clients only, or for any client.
#127.0.0.1:submission inet n -   n       -       -       smtpd
submission inet n       -       n       -       -       smtpd
#  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
#  -o smtpd_reject_unlisted_recipient=no
#     Instead of specifying complex smtpd_<xxx>_restrictions here,
#     specify "smtpd_<xxx>_restrictions=$mua_<xxx>_restrictions"
#     here, and specify mua_<xxx>_restrictions in main.cf (where
#     "<xxx>" is "client", "helo", "sender", "relay", or "recipient").
#  -o smtpd_client_restrictions=
#  -o smtpd_helo_restrictions=
#  -o smtpd_sender_restrictions=
#  -o smtpd_relay_restrictions=
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING