(IT) 自ドメインの設定が参加しているメーリングリストの配信に影響があった話

趣味のランニングのチームのメーリングリストのサーバーの運営をしている。
そんなもん、Googleでも何でも適当な無料サービスがあるだろ、なんて指摘は全然承知はしているんだけど、Webサーバー用にドメインもあるので、だったらチームのドメインでPostfix運用してMLエンジンもいれてメーリングリスト運用しちゃおう、ってことになっちゃって。
広告が入るのがイヤ、ってのもメンバーの皆さんにあったりとか、過去の経緯もあったりで。

前置きここまで。で、このメーリングリストのサーバーからのメールの一部をドコモ様が拒否していることが発覚。
レジェンドMさんから「XXXX番とYYYY番が届いてねえぞ!」と怒りのLINEが。あ、MLなんて止めてLINEグループにしちまえ、なんてご指摘もご遠慮くださいね笑
調べてみたら、3月中旬くらいから送信者がオレの場合にだけ、ドコモ宛とicloud宛のメールが先方のサーバーの拒否(Usesr Unknown)でバウンスしてた。同じメーリングリストで他の人が送信した場合は同じ宛先でもドコモのサーバーは受け取ってくれているのに。
まあ、メーリングリストのメールって、本当の送信者のドメインと送信元のサーバーのドメインが違うので、あやしいといえば怪しいのは承知してるんだけど、なんでオレのだけ?
と思って更にログを調べてたら、icloudさんのバウンスのログにヒントがあった。ちなみにドコモのサーバーの拒否ログはこんな

to=<hogehoge@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.240]:25, delay=1.3, delays=0.09/0.02/0.1/1.1, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.240] said: 550 Unknown user hogehoge@docomo.ne.jp (in reply to end of DATA command))

「そんな人、知りません(プイっ)」みたいなログしか残らない。
これに対してicloudさんのログはヒント付き。

to=<hogehogehoge@icloud.com>, relay=mx02.mail.icloud.com[17.57.156.30]:25, delay=31, delays=0.1/0/1.9/29, dsn=5.7.1, status=bounced (host mx02.mail.icloud.com[17.57.156.30] said: 554 5.7.1 Your message was rejected due to shirao.net’s DMARC policy. See https://support.apple.com/en-us/HT204137 for info (in reply to end of DATA command))

「なんや、しらんけど、shirao.netのサーバーのDMARCポリシーがそうせえ、書いてるから拒否しとくわー。ちなみにここ参照な」ってことらしい。
ああ、なるほど。shirao.netの中の人が送信してると主張している割に送信元のサーバーが違うドメインだった場合は、拒否してくれ、ってDNSに書いた記憶があるわー。ってことでshirao.netのDNSのTXTレコードを確認。

_dmarc.shirao.net TXT v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@hogehoge.com; ruf=mailto:dmarc@hogehoge.com

これの「p=reject」ってところが「もし違うサーバーからshirao.netを語るメールが来ても信用しないで拒否してちょうだい」って意味。これを「p=none」に書き換えたらドコモ様も受信してくれるようになった。MLのドメインから来ても信頼してみてね、ってこと。
ただ、この設定は一時的にはいいけど、永続的に設定するのは非推奨らしいので、他の設定を調査を継続中。まあでも、とりあえずは解決した。
ドコモやicloudみたいな広義でのISP(Internet Service Provide(死語))は時々メール受信の判定ルールを好きなタイミングで緩めたり厳しくしたりするんで、こういうことがたまに起こるみたい。今回も3月中旬に急にこのDMARCの判定を厳密にするようになったっぽい。同じように困ってる人の助けになりますよう。あ、自分がメールで使ってるドメインのDNS設定いじれる人ってそんなにいないか笑

(IT) docomoドメインへのML配信エラー対応

いくつかのドメインのメールサーバーをAWS上で運用している。
どのドメインもSPFのみならず、DKIMやDMARCにも対応させて
一応なんとか運用している。
しかし、4月の中旬くらいからどうやらdocomo.ne.jpのメールサーバーの
仕様が変わったらしく、Mailmanを使ったMLの配信でbounceが発生する
ようになった。

/var/log/mailman/bouce の例としてはこんな。

date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: bbb@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: ccc@docomo.ne.jp current bounce score: 2.0
date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name: bbb@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name : ccc@docomo.ne.jp already scored a bounce for date 23-May-2018

これ、全部のメールがbounceしているわけではなくて、
i.softbank.jpから発信されて、当該ドメインのメールサーバーで
ML宛に配信されたメールがbounceするのだった。
正確にはaaa,bbb,cccの3人への配信がbnounceしていると書いてあるが、
実は、bbbとcccには実は届いていて、aaaにだけ届いていない。

同じタイミングの/var/log/maillogはこんな。

date server_name postfix/smtp[PID]: ID: to=<ccc@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<bbb@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<aaa@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))

maillogではaaaで拒否しているからbbbにもcccにも届いてないよ、って
ログだから、bounceファイルでもbounce処理していることが載っている
のだが、前述の通り実際にはbbbとcccには配信されている。

よって、bbbとcccをaaaの影響から外すために、全てのメールを
個別配信する設定に変更した。Mailmanはデフォルトでは同一
ドメインには、一度のセッションで複数のアドレスへ送っている
ようで、それが今回の問題の原因のようだった。

/etc/mailman/mm_cfg.py の最終行に以下の記述を追記。

VERP_PROBES = Yes
VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes

これで管理コンソールの「普通配送」のところに個別配信の
メニューが追加され「いいえ・はい・完全個人別配信」が選択できる。
完全個人別配信とすると、本文に名前を入れるなどのカスタマイズが
できるが、今回はそこまでしないので、「はい」を選択。

結果として、maillog上でもmailman/bounce上でも配信エラーは
aaaだけとなった。
aaaに配信されていないという根本原因は不明なままだが、とりあえず
他のメンバーがバウンス回数が多くて配信停止になるというリスクは
回避できたはずだ。

参考ページ:Mailman日本語情報「サイト管理の手引」