携帯向けメール配信システムのチューニング(docomo)
前記事の通り、今回の配信は途中で諦めざるを得なかったものの、問題には原因があるはず。
気になるのはdocomo宛の配信が（他より件数が多いとはいえ）遅く感じること。
docomoからの公式資料…といえるのは以下URLのみ。
同報メールを大量に送信されるお客様へ
●
まずは宛先不明件数が多いとペナルティ的に受信ブロックが発生するとのことなので、本日のメール送信ログから簡易的に送信エラー件数の比率を見てみる。
ログの行数
# wc -l /var/log/mail.log
335755
ログ中の正常送信を表す行数
# egrep -i 'status=sent' /var/log/mail.log > /tmp/maillog_sent
# wc -l /tmp/maillog_sent
43475
ログ中の送信失敗を表す行数
# egrep -i 'status=sent' /var/log/mail.log > /tmp/maillog_bounce
# wc -l /tmp/maillog_bounce
108
キャリア別の分割等はしていないが、全体で「0.25%」という事なのでほぼ問題ない認識。
アドレスクリーニングは適切と言って良さそう。
（ちなみに、deferredは1件しか発生していなかった）
●
配信地域を分ける、という対応についてはメールサーバ単独での対応は難しいので諦めざるを得ない。
（配信システム側の運用で対応できる可能性はある）
●
となると、SMTPセッション数が問題か。
送信が完了しないうちにSMTPセッションを要求をしすぎなのかも。
各種サイト*1 *2 *3を参考に、docomo用の設定を行うことにした。
以下を追記：
#
# for Mobile
#
docomo-smtp unix - - n - 1 smtp
-o smtp_destination_concurrency_limit=1 ((smtp_destination_concurrency_limit = 配送先ごとの並列送信数))
-o smtp_destination_recipient_limit=1 ((smtp_destination_recipient_limit = 1セッション内で配送するメールの数))
以下を追記：
docomo.ne.jp docomo-smtp:
速度向上のためにhashDBを作成
# cd /etc/postfix
# postmap transport
これを読み込むよう設定
以下を追記：
transport_maps = hash:/etc/postfix/transport
# /etc/init.d/postfix reload
とりあえず以上。今後値の調整を行なっていく。
ログを見て、エラーが出ていないことを確認すること。
■注意点
http://tmtm.org/postfix/tutorial/trap.html にあるが、
main.cfを書き換えた後は、reloadせずとも各デーモンごとで反映されるようになる。
main.cfの書き換えは一連の作業の最後に行うこと。
■ぼやき
はてブ、想像以上に捗るな…もっと早くから使っておくべきだったなー、と。
