鯖缶不定期日記＠feelkind.com

当サイトではGNU mailmanを使って複数のメーリングリスト（ml）の管理をしています。
・・・が、久しぶりにmlを新規追加しようとしたらmailmanに怒られてしまい何も出来ない状況でした（泣）
具体的には
「現在 hogehoge.com で外部に公開されている Mailman メーリングリストはありません。」
とか、新しいメーリングリストを作成しようとすると
「エラー: 仮想ホストが不明です: hogehoge.com」
といったエラーが出て先に進む事が出来ませんでした。
1時間ほど悩んだ結果、mailman/adminに対してのURL指定が誤っていたと解りました。

誤：hogehoge.com/mailman/admin
正：www.hogehoge.com/mailman/admin

誤の方だと何となく反応して動いてそうに見えるのですが、実mlを拾ってくれず新規mlの作成も出来ず、シクシクな状態に陥ります。

そもそも最後にmlをセッティングしたのは2年ほど前？なので頭～完全に抜け落ちていた模様です（呆）。

まぁでも原因と対処が解ってめでたしめでたしと言うことで一件落着しました(^^)

当サイトはいくつものバーチャルドメインを設定しており、SSL証明書にはLet’s Encryptを利用しているのですが、最後に追加したバーチャルドメインに対してLet’s Encryptさんから更新不可の旨のメールが届きました。

－－－

Hello, Your certificate (or certificates) for the names listed below will expire in 19 days (on 2024-02-14). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors. We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let’s Encrypt’s current 90-day certificates, that means renewing 30 days before expiration. See https://letsencrypt.org/docs/integration-guide/ for details. hogehoge.jp www.hogehoge.jp

－－－
基本的に他のバーチャルドメインと全く同じセッティングにしてあるのですが、「何故ここだけ？」の状況に陥った次第。。

各種設定を見直してもおかしいところは無さそう・・で#certbot renew dry-runの後にApacheのログを見てみると401（Unauthorized）が多数発生している。。

何だこれはとgoogle先生でサーフィンしていると「BASIC認証が云々」という話を見つけました。

ああ、そうだ、最後に追加したhogehoge.jpドメインのWebは現在工事中でトップに.htaccessでBASIC認証をかけていたんだぁ～と気付きました。

そこで.htaccessを一時的に_.htaccessにリネームしてBASIC認証を解除した上でcertbot renew dry-runを実行するとサクッと通りました。

もちろんその後の本番更新#certbot renewも正常終了し、一件落着。
その後_.htaccessを.htaccessにリネームして再びBASIC認証を有効化した次第です。
構築中などで一時的にトップページに認証をかけていた事を忘れているとLet’s Encryptさんから叱られる・・・というお粗末な話でした。

CentOS7.9でWebminを愛用していますが、先の記事でメールサーバについて書いたように、Webminに関してもSSL証明書の正しいセッティングを怠けており、ブラウザの例外許可で運用していた次第です（阿呆）。

https://hogehogewebmin.com:12345

等でアクセスした際、「例外を許可する」で怠けていたわけですか、こちらもブラウザ(seamonkey)の不具合の為にこの怠けが許可されなくなったのでググって正しくしました。

Wibminの初期設定では/etc/webmin/miniserv.confに「なんちゃって証明書」・・・

keyfile=/etc/webmin/miniserv.pem

・・・がセッティングされているので、これをそのまま使い続けていたという怠け者だった状況を修正。。

keyfile=/etc/letsencrypt/live/maindomain.com/privkey.pem
certfile=/etc/letsencrypt/live/maindomain.com/fullchain.pem

と変更追記し、
#systemctl restart webmin
にてwebminを再起動後、Winなブラウザから・・・

https://maindomain.com:12345

・・・で警告されること無くアクセス出来ることを確認しました。

ただ、今までは・・・
https://192.168.1.2:12345
・・・のようにIP固定でアクセスしていたのですが、Let’s EncryptではIPな証明書は取得出来ない模様です。

他の先達者様・・・
https://asnokaze.hatenablog.com/entry/2021/01/18/232358
・・・によると、ZeroSSLを使えばIPな証明書も取得出来るようですが、今回は見送り（苦笑）

下記は参考にさせて戴いたサイトです。

CentOS7.9ベースでpostfix&postfixadmin&dovecotの複数バーチャルドメインメールサーバ環境を構築・利用していますが、今さらながらWindowsメーラで受信した際、「不正なSSL証明書」だとか「なりすまし証明書」だとかメーラに文句を言われることがあり（というか、必ず言われる）、今まではメーラ側で「例外を承認」として騙してアクセスしていたのですが、メーラ（Seamonkey）側の不具合の関係で例が承認が正しく出来なくなったので、根本解決策をググりました。

各ドメインの証明書に関してはLet’s Encryptで取得し、Webベースでの動作は確認されています。つまり、/etc/letsencrypt/live/・・・の配下にはhoge1.comやhoge2.jpなどのドメイン名ディレクトリが有り、その中には・・・
cert.pem
chain.pem
fullchain.pem
privkey.pem
・・・の証明書キーデータが存在している状況で、お約束であるcronによる自動更新もなされています。

で、本件の問題の根本はdovecot側のSSL証明書に関する設定記載が正しくされていなかったことにありました。
まず、/etc/dovecot/dovecot.conf内の・・・

ssl_cert = </etc/letsencrypt/live/mail.hoge1.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.hoge1.com/privkey.pem

の2行は「##」を先頭に付けてコメントアウトします。

その後、/etc/dovecot/conf.d/10-ssl.conf内に・・・

＃
＃maindomain.com
＃
local_name mail.maindomain.com {
ssl_cert = </etc/letsencrypt/live/mail.maindomain.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.maindomain.com/privkey.pem
}

＃
＃hoge1.com
＃
local_name mail.bbsm.jp {
ssl_cert = </etc/letsencrypt/live/mail.hoge1.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.hoge1.com/privkey.pem
}

＃
＃hoge2.jp
＃
local_name mail.flute.work {
ssl_cert = </etc/letsencrypt/live/mail.hoge2.jp/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.hoge2.jp/privkey.pem
}

・・・といった感じで追記します。
（全角”＃”は半角”#”に読み替えて下さい）
その後、dovecotを再起動します。

＃systemctl restart dovecot
＃systemctl status dovecot ←正しく起動していることを確認

検証としては、別のメーラ（今回はThnderbirdを新規インストール）にて、これらのドメインのメールセッティングを行い、受信時に「不正な証明書・・・」といった「警告が出ないこと」を確認し、問題無かったのでＯＫとしました。

今さらながらですが、当初のセッティング時に単一サーバー内で複数ドメイン運用する際、メールサーバにも複数ドメイン分のSSL証明書セッティングが必要であるという事を理解していなかった阿呆なセッティングを是正した次第です（＾＾；）

下記は参考にさせていただいた先達者のサイトです。

昨年末にVine6.x(x86)鯖からCentOS7.9(x64)鯖に環境移行構築をした際、主立ったパッケージはCentOS7.9の物に置き換えました。
その際の一つがDNSサーバ「bind」（起動名named）だったのですが、セキュリティ向上の目的で、namedでは無く、named-chrootがお勧め・・・とあり、この手法を使いました。

＜参考サイト＞
https://mseeeen.msen.jp/bind-chroot-important-point/
https://qiita.com/You_name_is_YU/items/81b97179518236e1a5f2

通常Linuxサーバを公開目的で設置する場合は固定IP(V4)を1つ以上設定してDNS登録するのが一般的です。

当家の鯖もこの「固定IP1」で「55.66.77.88」（仮定）といったアドレスをプロバイダから借用し、長年にわたって運用してきたのですが、2021年4月より速度向上目的で、

JPNE(日本ネットワークイネイブラー株式会社)の提供する『「v6プラス」固定IPサービス」』

という仕組みに契約変更をしたところ、固定IPアドレスが変更となりました。
新しいアドレス（仮定）は「11.22.33.44」との連絡があり、その変更の為に
/etc/named.conf
/var/named/・・・
のファイル群を変更して開通日に変更起動したのですが、何故か、/var/named/default.log
に怪しげなエラーが出ていました。

－－－－－/var/named/default.log抜粋ここから
zone 0.0.127.in-addr.arpa/IN/localnets: loaded serial 2021041103
out-named.rev:4: ignoring out-of-zone data (22.33.44.in-addr.arpa)
out-named.rev:5: ignoring out-of-zone data (11.22.33.44.in-addr.arpa)
zone 88.77.66.55.in-addr.arpa/IN/globalnet: has 0 SOA records
zone 88.77.66.55.in-addr.arpa/IN/globalnet: has no NS records
zone 88.77.66.55.in-addr.arpa/IN/globalnet: not loaded due to errors.
zone 255.168.192.in-addr.arpa/IN/localnets: loaded serial 2021041103
－－－－－/var/named/default.log抜粋ここまで

88.77.66.55は旧固定アドレス「55.66.77.88」の逆表記で、設定ファイル群からは全て抹消したはずなのに、何故かゾンビのように蘇っていたのです。

昔からの神師匠に泣きついて、リサーチを進めたところ、コメント類（named.confでは「#」「;」で無く「//」が正解？）や日本語表記（SHIFT-JISは論外、UTF-8もダメ、EUC限定）による誤動作懸念などもアドバイス戴き、削れる物は全て削ったはずなのに、やはりダメ。

何故だか解らず、鯖のファイル群の文字列総ナメリサーチをしても「55.66.77は過去ログなど以外ではひっかからず、途方に暮れていたところ、「named-chroot」を使っているなら、その先「/var/named/chroot/」の確認はしたか？との決定的なアドバイスをいただき、調べてみたら見事にビンゴでした。

いままで鯖缶的には（ステレオタイプに）・・・

/etc/named.conf
/var/named/関連ゾーンファイル等

・・・があれば、named-chrootは勝手に上記のファイルを/var/named/chroot配下にコピーして動いてくれると思っていました。

実際、CentOS7.9に最初にnamed-chrootを仕掛けた時も、Vine6の/var/named/から持ってきた内容ほぼそのままでコピーして動いていたので、良しと考えていたのですが、調べてみたら・・・

「/var/named/chroot/etc/named.conf」ファイルが先祖返り（更新されておらず）
旧セカンダリDNS「hogehoge.2nddns.com」の記述や、
「view “globalnet” {」セクションに、
「zone “88.77.66.55.in-addr.arpa”{ //#→feelkind.comの固定IPの逆記述;」
の記述が見事に残ってました。←これが今回の騒動の原因。

つまりnamed-chroot君は初回起動時は/etc/named.confのコピーを自力で持ってくるけれども、二回目以降はこのプロセスをサボリ、IP変更など必要な場合は
/var/named/chroot/etc/named.conf
にも/etc/named.confの内容を手動でシンクロさせてやらなければならないと学習しました。

本件、忘れぬよう、/var/named/配下に・・・

「注意_named.conf___をいじったら、etc配下のnamed.conf、var_named_chroot_etc_named.confも上書きシンクロさせること」

・・・というコメントファイルを設置しておきました。

これらの修正結果、現在は・・・

#systemctl stop named-chroot
#systemctl start named-chroot
#systemctl status named-chroot
#cat /var/named/default.log

・・・等、全て正常な挙動になりました。

少し何かを変えると大きなハマり穴が待っている・・・Linux系の宿命でしょうか（Ｔ＿Ｔ）

CentOS7.9自宅鯖・・・

JPNE(日本ネットワークイネイブラー株式会社)の提供する

『「v6プラス」固定IPサービス」』
https://www.jpne.co.jp/service/v6plus-static/
を使う為にELECOMの無線ルータ「WRC-1167GS2」を導入。

昨日からセッティングをしている中で、web/mail/mlなど全て動作OKだったのですが、何故かftpのパッシブ（pasv）モードだけがどうにもこうにも動作しない（良く有るファイル一覧の直前でハングする）状態でハマる。

そもそも鯖側のftpセッティングは固定IPの部分を見直しただけで他は何も変えていないはず・・・。 いろいろ試してた結果、何故か当該ルータのWebUIに「ルータの再起動」が無い事に気付く。

まさかなぁ・・と思いつつ、ACアダプタを引っこ抜いてルータの電源を切断、数秒後に繋いで強制的に再起動させてみたら・・・ftpの問題はウソのように解決（爆）

ELECOMさん、頼みますよ～ ネットワーク機器は真っ当なファームにして下さい（Ｔ＿Ｔ）

セッティングがいろいろと細かいメーリングリストサーバmailman、迷惑メール予防のDMARCでdnsのzoneファイル内のセッティングを「p = quarantine」にしたらVer.2.1.15以前のパッケージではLAN to WANが配信出来なくなった胸を先に記載しました。
暫定対策としてはdnsのzoneファイルを「p = none」のセッティングで運用すればOKだったのですが、「p = quarantine」だったら折角DMARCの認証が通る妥当なメールサーバとして認めていただける・・・
https://www.valimail.com/
・・・のに、なんか逃げているようで嫌だったので、「p = quarantine」の設定挙動を確認しました。

＜DKIM/DMARCセッティングの参考サイト＞
Postfix + SSL + IPv6 + ClamAV + SpamAssassin + SPF + DKIM + DMARCの構築方法 – 蒲田ネット
https://blog.kamata-net.com/archives/12797.html


mailman Ver.2.1.16以降で「p = quarantine」をセッティングした際に、何がどのようになるか・・・は下記のサイトを参考にしました。


＜mailmanとDMARC系の関係参考サイト＞

MailmanとDMARC – pikesaku’s blog
https://pikesaku.hatenablog.com/entry/2017/01/22/015336

DMARCに関するメーリングリストでの対応策
https://paperzz.com/doc/5846439/dmarc%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%83%A1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%AA%E3%82%B9%E3%83%88%E3%81%A7%E3%81%AE%E5%AF%BE%E5%BF%9C%E7%AD%96

などなどを踏まえて、当家メーリングサーバmailman Ver.2.1.34でのmm_cfg.pyの追加内容が下記です。

－－－－－－－以下、2021/03/21のmm_cfg.py追記内容
###########
###########2021/03/21 DMARC Setting系
###########
##https://pikesaku.hatenablog.com/entry/2017/01/22/015336

###
#####プライバシーオブション[送信者フィルタ]の部
###

##DEFAULT_DMARC_MODERATION_ACTION
##送信元ドメインのDMARCポリシーが、Rejct or 隔離であった場合の動作を定義
##0 = Accept (承認)
##1 = Munge From (From を書き換え)
##2 = Wrap Message (メール内に添付)
##3= Reject (拒否)
##4 = Discard (破棄)
##
##Webメニュー／DMARC 拒否/隔離ポリシーを持つドメインからの投稿に対する動作。
##(dmarc_moderation_actionの詳細) ※こちらで0以上の数値を指定すると、Webメニューではそれ以下には設定出来ない。

DEFAULT_DMARC_MODERATION_ACTION=0

##
##DEFAULT_DMARC_QUARANTINE_MODERATION_ACTION DMARCポリシーが隔離の場合、Rejectと同じように扱うかYes/No
##
##Webメニュー／From: ドメインの DMARC が p=quarantine のときも p=reject のときと同様にdmarc_moderation_action をメールに適用する
##(dmarc_quarantine_moderation_actionの詳細)

DEFAULT_DMARC_QUARANTINE_MODERATION_ACTION=Yes

###
####全体的オプション の部
###

##DEFAULT_FROM_IS_LIST
##DMARC_MODERATION_ACTIONがAcceptではないMLへの投稿に対するデフォルトのアクションを設定する。
##0: 何もしない
##1: FromヘッダをMLアドレスと置き換え
##2: FromをMLにしたメールに元メールを添付して送付
##
##Webメニュー／From: ヘッダーのメールアドレスをリストの投稿アドレスに置き換え、 元の From: ドメインの DMARC あるいは類似のポリシーにより 生じる問題を緩和します。(from_is_listの詳細)

DEFAULT_FROM_IS_LIST=0

###
####Webメニュー／無し？
###

##REMOVE_DKIM_HEADERS
##FROM_IS_LISTが1,2の場合にDKIMヘッダを削除する。理由は、Fromヘッダや添付ファイル化した時に、シグニチャが壊れてしまう可能性があるため Yes/No
##Webメニュー／無し？

REMOVE_DKIM_HEADERS=Yes

#####
##下記は多分あるだろう想像。。
##DEFAULT_dmarc_quarantine_moderation_action Yes/No
##Webメニュー／From: ドメインの DMARC が p=quarantine のときも p=reject のときと同様にdmarc_moderation_action をメールに適用する
##(dmarc_quarantine_moderation_actionの詳細)

DEFAULT_dmarc_quarantine_moderation_action=Yes

##DEFAULT_dmarc_none_moderation_action Yes/No
##Webメニュー／From: ドメインの DMARC が p=none のときも p=quarantine のときと p=reject のときと同様 dmarc_moderation_action を メールに適用する
##(dmarc_none_moderation_actionの詳細)

DEFAULT_dmarc_none_moderation_action=Yes

##DEFAULT_first_strip_reply_toの Yes No
##Webメニュー／もし、Reply-To:ヘッダがメールに付けられていたら、 それを取り除きますか? もしそうなら、Reply-To:ヘッダ が Mailman によって付けられたか、はじめから付いていたかに かかわらず取り除かれます。
##(first_strip_reply_toの編集)

DEFAULT_first_strip_reply_to=Yes
－－－－－－－以上、2021/03/21のmm_cfg.py追記内容

メーリングリストサーバは利用環境によってセッティングが異なってきますので、この事例通りの追記をするとハマるかも知れませんが、一応備忘録＆参考として記載しておきました。

先回の投稿で、DKIM/DMARC系のセッティングを先行してしまった為に、ローカルドメインユーザからmailmanメーリングリストに投稿できなくなった旨の話を記載しました。
暫定対策としてはdnsのdmarcセッティングを「p=none」とすれば問題無い為、それで稼動させてましたが、いずれハマり時期がやってくるかもと思い、mailmanのVerUpを行いました。

2021/03/19時点のCentOS7.9では「#yum install mailman」でインストールされるmailmanのバージョンは「2.1.15」です。そしてdmarc問題を解決する為には先記の参考サイト情報では「2.1.16」以降のバージョンが必要となってました

本日mailmanの最新バージョンを・・・
http://ftp.gnu.org/gnu/mailman/
・・・にて確認したところ、「2.1.34」（タイムスタンプ：2020-06-26 20:24）が2.1系の最終バージョンとしてstableになっている模様なので、こちらを使ってソースリビルドすることにしました。

ただ、参考にさせて戴いたサイトではwebサーバがapacheでは無くnginx環境だったり、mailmanのインストール先が/home/mailmanだったりと、こちらの環境とは相違していた為、読み替えや若干のアレンジが必要でした。
また、今まで使っていたyum版のmailmanとの競合などもあり、例によってトライアンドエラーで行った手順を記載しておきます。

1.yumインストールしたmailman2.1.15を使っている場合は、まず現環境のバックアップとして・・・

/etc/mailman/
/var/lib/mailman/
/var/spool/mailman/

・・・の内容をどこかにコピーしておきます。

2.競合を防ぐ為「#yum remove mailman」を実行し、旧mailmanを削除します。

3.旧mailmanの痕跡を完全消去します。
当方では過去に何度もmailmanのインストール・アンインストールを繰り返した苦い経験がある為、/etc/配下に「mailman_erase.sh」というシェルスクリプトを作成して実行しました。
－－－/etc/mailman_erase.shここから

#!/bin/sh
rm -rf /etc/mailman
rm -rf /etc/cron.d/mailman*
#rm -rf /httpd/conf.d/mailman.conf
rm -rf /usr/lib/mailman
rm -rf /var/lib/mailman
rm -rf /var/spool/mailman
rm -rf /var/run/mailman
userdel mailman >>null

－－－/etc/mailman_erase.shここまで

4.この後、ローカルサーバにて最新mailmanのbuildプロセスに入ります。
今回はmailman本体群を「/usr/lib/mailman/」配下へインストール、データ類は「/var/lib/mailman/」配下で運用することを前提に「.configure」プロセスの際に下記のオプションでbuildを行いました。
「./configure –prefix=/usr/lib/mailman –with-var-prefix=/var/lib/mailman fix=/var/lib/mailman –with-cgi-gid=apache」
※apache2.4ではsuExecな環境で動く為、このオブションbuildはキモです。

5.途中関連フォルダ（/var/lib/mailman/等）が無いとか、パーミッションが違うなどのエラーが発生した場合は都度対処し、「.configure」プロセスを再実行します。
エラーが無くなった後「make && make install」にてbuildを完了させます。

6.build完了後はバックアップしておいたファイル群をリストアするのですが、yum標準インストールのフォルダとは異なっている為、注意が必要です。
mailmanの設定ファイル「mm_cfg.py」は以前は「/etc/mailman/」配下でしたが、今回は「/usr/lib/mailman/」配下へリストアします。
同様にメーリングリストのデータファイル群は「/var/lib/mailman/」配下へリストアします。

7.参考サイトの通り、新mailmanを起動する前には「mailman」メーリングリストの作成が必須です。また、「aliases」関係も以前は「/etc/mailman/」に有った物が、「/var/lib/mailman/data/」配下に移ってますので、こちらのディレクトリにて「/usr/lib/mailman/bin/genaliases」の実行と、/etc/postfix/main.cf内のalias関係のフォルダ設定を書き換えます。具体的には下記3カ所になるかと思います。
－－－
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases

alias_database = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases

virtual_alias_maps =
hash:/var/lib/mailman/data/virtual-mailman,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf
－－－

8./etc/postfix/main.cfの修正が完了したら、/etc/postfix/配下で「newaliases」を実行、また、/var/lib/mailman/data/配下で「/usr/lib/mailman/bin/genaliases」を実行し、aliases関係を新しく整えておきます。

9.#systemctl restart postfixにてpostfixを再起動、特に問題無ければ、新mailmanの起動プロセスを参考サイトの通り行い、システムrebootした時の為に、chkconfig、あるいはsystemctl用として/etc/systemd/system/mailman.serviceファイルを作成します。
後者の方法であれば、従来通り「#systemctl start mailman」「#systemctl status mailman」「#systemctl enable mailman」などが使えます。

10.旧mailmanのセッティングが戻っているかをmailmanの管理画面「http://example.com/mailman/admin」で確認、問題無さそうであればテスト用メーリングリストの作成～メーリングリストへのメール配信などで挙動を確認します。

11.無事配信された場合はmailmanの管理画面で新mailmanで増えたセッティング
「プライバシー・オプション… の部 -> [送信者フィルタ]」などを確認します。

12.ここまでのプロセスが問題無く完了すれば多分mailman的にはVerUp.完了です。
dmarcに関しては翌日以降に新たにリサーチして考えましょう(^_^;;)


＜本件で参考にさせて戴いたサイト＞
メーリングリストサーバー構築(Postfix+Mailman編) – CentOSで自宅サーバー構築
https://centossrv.com/postfix-mailman.shtml

メーリングリスト、mailman 2.1.29　セッティング | サーバーレシピ
https://server-recipe.com/1245/

Mailman 2.1.34へのアップデートとcgid_module | サーバーレシピ
https://server-recipe.com/2506/#toc1
※
https://teratail.com/questions/254310
によると、2021/03/19時点では「cgid_module」では無く「cgi_module」が推奨されているようなので、結果の差違は無視して問題無さそうです。

先日の記事で「CentOS7.9、postfix環境で難関のdkimシグネチャを付加」を書きましたが、実はこの後2～3w程度ドハマりしていました。
一番大きなポイントはメーリングリストサーバ「mailman」でローカルドメイン（LAN内アドレス）からメール送信（メーリングリストへの配信）が出来ない（消失したように見える）事でした。
光ルータ（HGW）交換時の初期不良？や、その他、複数のトラブルがまるで同時多発テロのように発生していた為、最後まで悩みまくり、ググりまくった結果、本日やっとポイントが見えましたので、忘れぬようにこちらに記載しておきます。
CentOS7.9でyumインストールできるmailmanパッケージは2021/03/17時点で2.1.15でしたが、実はこのバージョンのmailmanではdmarcのセッティングによっては上記のようにLAN内から配信できないケースがあると解りました。
特に当鯖ではバーチャルドメイン環境（postfixadmin+mysql(MariaDB)）を併用している為、余計にわかりにくかったのかも知れません。

下記は参考にさせて頂いたサイトです。

Postfix + SSL + IPv6 + ClamAV + SpamAssassin + SPF + DKIM + DMARCの構築方法 – 蒲田ネット
https://blog.kamata-net.com/archives/12797.html

こちらで提示されている方法でdkim/dmarcを優先させる為に「p = quarantine」の設定を行うと、上述のようなハマリになるのですが、この現象はdns(named/bind)でのセッティング内容の為、世界伝播には時間がかかり、セッティング後、すぐには露見しません。
まるで昨年から猛威を振るっているCOVID-19の様に潜伏期間が有り、dmarc系の総本山まで伝播完了後に初めて露見する仕組みでした。

疲れまくりましたが、一応2つの解が見つかったと思います。

１．mailmanのバージョン（現時点の最新ソースは2.1.34）を下記サイトなどを参照し、ソースインストールしてバージョンアップする。
　メーリングリストサーバー構築(Postfix+Mailman編) – CentOSで自宅サーバー構築
　https://centossrv.com/postfix-mailman.shtml

２．dnsゾーンファイルのdmarcに関する設定を「p = quarantine」では無く「p = none」としてdnsのシリアル桁上げ、世界伝播までおとなしく待つ。

とりあえず、ネガティヴ対策ですが、２．から開始してます。
（明日以降１での恒久対策を検討します）


以下、本件の解決の為に参考にさせて頂いたサイトなど。
－－－
Mailman 2.1.16以降でFromを書き換えるオプションが追加されたん（´・ω・） ｽﾈ
https://pao.moe/@nukosu/105894787247364204

MailmanとDMARC – pikesaku’s blog
https://pikesaku.hatenablog.com/entry/2017/01/22/015336

送信ドメイン認証技術の利用について
https://www.iajapan.org/anti_spam/event/2014/conf0214/pdf/sess1/sakuraba.pdf

当家のサーバ、postfix環境で相当以前から、spfに関しては追記していたのですが、dkimに関してはイマイチ理解出来ず、本日まで放置していました（呆）

少し時間が出来たので、今回dkim回りを整備してみました。
この際、参考にさせて頂いたWebサイトは下記の2サイトです、どうもありがとうございました＿（＾＿＾）＿

「Postfix + SSL + IPv6 + ClamAV + SpamAssassin + SPF + DKIM + DMARCの構築方法 – 蒲田ネット」
https://blog.kamata-net.com/archives/12797.html

「CentOSのPostfixで迷惑メール判定されないようDKIMを設定する レムシステム エンジニアブログ」
https://www.rem-system.com/dkim-postfix04/

実際には上記参考サイト様の環境とは違い、当家サーバはpostfix+dovecot+postfixadmin+mysqlなマルチ（バーチャル）ドメインな送受信環境にspamassassin+amavisが絡んでいる、bind(named)はnamed-chrootなので、相当覚悟して臨んだのですが、kamata-netさんの記事がとても解り易く「なんちゃって管理者」でも何とかdkimを付与した上で、下記2つの検証サイトで、合格点をいただく事が出来ました。

「Email Sender Identity Verification, Authentication & Security Solutions | Valimail」
https://www.valimail.com/

なりすまし対策ポータル ナリタイ
https://www.naritai.jp/

改めて感謝いたします、ありがとうございました＿（＾＿＾）＿