postfix メールキューのエラー 大量のメールを誤送信してしまい、遅延がひどい場合の措置

サーバ内のメール転送プログラム実行中にエラーが生じた際に、
エラー警告メールを送信し、エスケープする処理を盛り込んだのだが、
エスケープの記述をしくじり、エンドレス送信が生じてしまった。

2時間程経過した際に以上に気づき、即座にプログラムは停止させ、/var/spool/mail/配下の指定アドレスの中身は処理したのだが、
postfixのキューに大量の残骸が残ってしまった。
遅延の遅延の遅延を繰り返し、頑張って送ってきてはいるが、
1万数千単位のメールが何時までも送られてくるため、当該ユーザの
通常のメールにも遅延が生じてしまっている状態。

そこで、postfixのキューを何とかして、通常の状態に戻してみた。

幸い、該当のメールのサイズが2kBと非常に小さいもので、他の遅延が殆どなかったので、
さらっと内容を確認して、該当のメールだけを削除する。

qmgr キューマネージャーにてメッセージはキューを通過する。

格納されている先

/var/spool/postfix/incoming リモート受信した最新のメッセージ格納
/var/spool/postfix/active 処理中メッセージ
/var/spool/postfix/bounce　　配信できなかったメールID毎のログ 
/var/spool/postfix/corrupt　　postfixの形式に則ってないメッセージ格納 

/var/spool/postfix/deferred 配信不能だがリトライする。
/var/spool/postfix/hold 　　　　無期限保存する際利用
/var/spool/postfix/defer 一時的に配送不能なメッセージリトライする。

既に、 /var/spool/mail/配下の指定アドレスの中身は処理済みの場合、
問題は、

deferredとdeferに残骸が有ると、何度もリトライを繰り返してしまう点にある。

そこで、 defer配下をfindしてファイルサイズ2kのものをxargsで渡して削除 

# find /var/spool/postfix/defer/ -size 2k | xargs rm -rf

マジで全部消えるので、ほんとにそのサイズで大丈夫か？を確認すること 

※ -execだとファイルの数だけコマンドを投げる仕様のようで、時間がかかってしまう。

　　今回1万数千回の実行は xargs　の方が向いている。

同様に、deferredでも行う。

# find /var/spool/postfix/deferred/ -size 2k | xargs rm -rf

その後、 残った問題の無いものを強制送信。

# postfix flush

最後にキューをきれいにする

# postsuper -d ALL 

キューがきれいになったか確認

# postqueue -p
Mail queue is empty

これで、正常な状態に戻っている（はず）
小生の環境では、これで正常に配信されるようになった。

この方の解説が非常にわかりやすかった。ありがとうございます。
kazupon.com様

SUBARU XV DBA-GT7 CADデータ

現行のSUBARU（スバル）XVのCADデータが見つからず・・・。
平面図が欲しかったが、SUBARUさんも3面図のみの掲載・・・。
平面図を作成するために、結局全部書いてしまった・・・。

誰トク？なCADデータだが、約2,500台/月の販売実績だし、
ちょっとリコール出てるけど、車に問題はないし、
オーナー様にご利用頂ければと思い、公開。

FC2に「SUBARU_XV_DBA_GT7.zip」でアップロードしてます。(JW_CAD)

SUBARU（スバル）XV　2017年5月～　DBA-GT7型　2.0i-Sアイサイト

PHP 日本語メールの環境依存文字 文字化け対策

先般、SPF問題の解決の為、PHPMAILERにてメール送信を行うように仕様変更したが、
まだ、JIS-2022-JPの7bit問題が解決していない。

問題点としては、さまざまな環境のメールサーバやOSがアンドロイドでないフィーチャーフォン
（所謂ガラケー）では、8bitを許容していないようだが、ほとんどの動作環境下でUTF-8が
利用できるようになってきている。
と思われる。

そこで、今までは、JIS-2022-JP(7bit)の制約を受け、環境依存文字や半角カナ
が文字化けを起こす環境で運用を行っていたが、さすがに、ガラケーのみで
運用をするユーザが現役社会人である可能性は、万が一くらいでいいだろうと判断した。

前段が長くなってしまったが、
UTF-8でPHPMAILERのインスタンスを生成する際の記載をオボエガキ
前回との変更箇所をオレンジ表記

smtp送信テストPHP（UTF-8送信)

<?

require_once("/置いた所/vendor/autoload.php" );　//これを忘れると動かない！！
require_once("/置いた所/vendor/phpmailer/phpmailer/class.phpmailer.php"); //これを忘れると動かない！！

mb_language("japanese"); 

mb_internal_encoding("UTF-8");   
 

$to = "XXXX@gmail.com";
$subject = "SMTP587テスト";
$body = "smtpサーバ経由のメールテスト";

$from = "hoge@hogehoge.com";
$fromname = "送信テスト君";

$mail = new PHPMailer();//インスタンス生成
$mail->CharSet = "UTF-8";//UTF-8の宣言をすること
$mail->Encoding = "base64";//記述しないと正しく認識しないサーバが存在するらしい。

$mail->IsSMTP(); //smtp利用宣言
$mail->SMTPAuth = TRUE;//smtp認証宣言
$mail->Host = 'mail.xxxx.jp:587';    // ホストアドレス:ポート25or587
$mail->Username = 'hoge'; //smtp認証ユーザ
$mail->Password = 'hogehoge';  //smtp認証パス

$mail->AddAddress($to);

$mail->From = $from;
$mail->FromName = $fromname;

$mail->Subject = $subject;
$mail->Body  = $body;

$mail->AddAttachment('./hogefile.pdf');日本語は極力使わない！！

 

 //メールを送信
if (!$mail->Send()){
    echo("Failed to send mail. Error:".$mail->ErrorInfo);
}else{
    echo("Send mail OK.");
}

?>

大分後になって
$mail->CharSet = "UTF-8";
$mail->Encoding = "base64";
と宣言をするよりも、
$mail->CharSet = "iso-2022-jp";
$mail->Encoding = "7bit";
として、愚直に
mb_encode_mimeheader(mb_convert_encoding($fromname,"JIS","UTF-8"))
としたほうが、エンコード率が高いことが分かった。