gmailにspamの烙印を押されたので、SPFレコード、DKIMを設定する。

 SPFレコードの設定

# nano /var/named/hoge-co.jp.db

末尾に

hoge-co.jp.              IN      TXT    "v=spf1 +ip4:xxx.xxx.xxx.xxx +mx ~all"
　　※xxx.xxx.xxx.xxxはメールサーバのIPv4アドレス
を追加

BINDを再起動
# service named restart

 

OpenDKIM のインストール
# yum install -y –-enablerepo=epel opendkim

ディレクトリ作成
# mkdir /etc/opendkim/keys/hoge-co.jp
# opendkim-genkey -D /etc/opendkim/keys/hoge-co.jp -b 2048 -d hoge-co.jp -s 20220505

-b　1024以上でないとgoogleは認めてくれないが大きければ良い訳ではないようなので、2048とした。
-d　一般的にはメールアドレスの@より後ろのドメイン名を指定
-s　管理しやすい任意の文字列を指定　とりあえず日付

念のためパーミッションを変更

# chmod 700 /etc/opendkim/keys/*/
# chmod 600 /etc/opendkim/keys/*/*

設定ファイル修正
# nano /etc/opendkim.conf

Mode sv　　　s→svに変更
Syslog  yes
SyslogSuccess   yes
LogWhy  yes
UserID  opendkim
Socket  inet:8891@localhost
Umask   007
# Statistics    /var/spool/opendkim/stats.dat
SendReports     yes
SoftwareHeader  yes
Canonicalization        relaxed/relaxed
# Domain        example.com
#Selector      default　　コメントアウト
MinimumKeyBits  1024
KeyFile /etc/opendkim/keys/default.private

KeyTable        /etc/opendkim/KeyTable　の#を外し有効化

SigningTable    refile:/etc/opendkim/SigningTable　の#を外し有効化
AlwaysAddARHeader true　追加

保存して閉じる

#nano /etc/opendkim/KeyTable

20220505._domainkey.hoge-co.jp hoge-co.jp:20220505:/etc/opendkim/keys/hoge-co.jp/20220510.private

保存して閉じる

#nano /etc/opendkim/SigningTable

*@hoge-c.jp 20220505._domainkey.hoge-co.jp

保存して閉じる

起動と自動起動化

# systemctl start opendkim
# systemctl enable opendkim

postfixに関連付け

#nano /etc/postfix/main.cf

 

smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_unauth_pipelining,reject_invalid_hostname,check_sender_access hash:/etc/postfix/check_backscatterer,check_policy_service unix:private/policyd-spf
 

 

末尾に
milter_protocol = 2

# OpenDKIM　smtpdが利用するmilter定義
smtpd_milters = inet:localhost:8891
# smtpd以外が利用するmilter定義
non_smtpd_milters = $smtpd_milters
# milterがメールを受信時のデフォルト動作
milter_default_action = accept

を追加し、保存して閉じる

再起動
# postfix reload

DKIM 公開鍵レコード設定

自動的に255文字以下に分割してくれているので、加工してDNSに記載する。

ADSPをDNSに設定
#nano /var/named/hoge-co.jp.db　に
20220505._domainkey.hoge-co.jp.  IN      TXT     ( "v=DKIM1; k=rsa; "
          "pごにょごにょ～"
          "ごにょごにょ～");
_adsp._domainkey.hoge-co.jp.  IN TXT "dkim=unknown"　を追加。

　

BINDを再起動
# service named restart

上手くいかねぇ・・・。

https://de-vraag.com/ja/71638753

同じような症状があったので、参考にさせてもらいようやく何とか上手くいった・・・。

postfixユーザーをopendkimのグループに所属させないと、ソケットが通らない。

こんなの分からねーですよ・・・。6時間位かかった・・・。

# usermod -aG opendkim postfix

# cat /etc/group
　opendkim:x:989:postfix　所属した。

先人によると、このデーモンに不具合があるらしく、
# nano /lib/systemd/system/opendkim.service

　ExecStart=/usr/sbin/opendkim $OPTIONS　
この$OPTIONSの宛先がおかしいことがあるらしい。
$OPTIONS　の先を探しに行っ足りしたが、上手くいかず、それに嵌った。

/var/run/opendkim/opendkim.pid
/var/run/opendkim/opendkim.sock　この定義ファイルを読み込ませたいのだが、

warning: connect to Milter service inet:localhost:8891: Connection refused
上記エラーがかえって来る。


最終的に、先人の方々の知恵を借り、力技でゴリ押した。

ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock -p inet:8891@localhost

User=opendkim
Group=opendkim

とした。

暫くして、SPFレコード、DKIMレコード共に支障なく浸透したことを確認後、
セカンダリDNSと同期をとるために、ゾーン定義（/var/named/hoge-co.jp.db）のシリアル値を更新して

@       IN      SOA     ns.hoge-co.jp. root.hoge-co.jp. (
                                2022050500 ; serial値
                                1H      ; refresh (3 hours)
                                900     ; retry (1 hour)
                                5D      ; expire (2 weeks 6 days)
                                1D      ; minimum (1 day)
                                )

保存して
BINDを再起動。

※googleさんは、セカンダリDNSの設定も併せて見に行くようで、
　プライマリDNSとセカンダリDNSがきっちり同期とれていないとメールを弾く仕様にレベルアップしているようだ。

DNSが浸透したらgoogleさんがメールを許容してくれるようになった。

とりあえず、OpenDMARCのインストールまでは行った。

# yum install opendmarc
# nano /etc/opendmarc.conf

が、今のところgoogleさんはDMARCは必須としていないので、設定は今後様子を見て行う。

CentOS7(RHEL 7)のemergency mode

WEBサーバの稼働日が399日目だったが、
javaのアプリケーションの安定動作の為、定期的に再起動を掛けている。
利用者のセッション情報を上手く離さないままで正常に終了しない状態が続くと
応答を繰り返す可能性があるが、利用者への配慮でタイムアウト時間をかなり長めに取っていることにも起因している可能性がある。
正常時は、正しく返す応答が、中途半端にセッションを有したまま、再起動が掛かってしまい、当然セッションがないので、応答が次々と繰り返られれば、
短い時間でスレッドの上限に達し、ヒープ領域の食事を延々を行い、
ヒープ領域を食い尽くし、FULLGCが起こる原因になりかねない。
タイムアウト時間の見直しは課題として、検討を行うとして、

前段が長くなったが、上記の状態に陥り、load averageが7近くまで上昇してしまい、
各アプリケーションが自然に停止してしまった為、止むを得ずWEBサーバ
の再起動を行ったのだが、およそ一年前にコンソールから追加できないディスク領域の拡張依頼をしたのだが、その際、fstabが修正されておらず、今回の症状となったようだ。

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again to
boot into default mode.
Give root password for maintenance (or type Control-D to continue):

と表示された・・・。

rootでログインし、
# mount -a でどのマウントが引っかかっているか原因を探る。

mount: special device /dev/sd?/　 does not exist　となったので、

/etc/fstab　の構成と比較し、 /dev/sd?のドライブレターと齟齬が生じている箇所を
修正する事となる。

複数のドライブに不具合が生じている際は、正しいマウント先を確認しながら
fstabの修正が必要となるので、注意のこと。

尚、不可解な点が一点あり、fstabの先頭に\が記載されていた。
コンソールからの追加では、自動的にfstabが書き換わる仕様だが、
エンジニアが介入する特殊なディスク領域拡張にはおそらく対応していない為、
作業マニュアル等の中に、作業開始時にシステムの破損を防ぐため、
fstabの先頭に\を記載し、上書き保存　のようなルールがあるのではないか？
事実、ドライブの構成を確認しながらfstabを修正する破目に陥ったので、
最も効率的にリスクを回避できるので、上記のルールを策定した人は、
とても頭の良い方だと素直に尊敬できる。

https://www.symmetric.co.jp/blog/archives/65
https://atmarkit.itmedia.co.jp/ait/articles/0711/27/news122_3.html
の記事が大変参考となった。感謝いたします。