_ MS の Office365 と超絶相性が悪いみたい。word やら excel やらじゃなくて、メールサービスとしての o365 ね。
_ spammer は配送効率を重視して送信失敗しても再送しないことが多いという仮定のもと、いったん 4xx で一時エラーを返してから、再送してきたメールだけを受け取るというのが greylisting。で、再送されてきたメールなのかどうかを判定するのに使われるのが送信元の IP アドレス。from、to、IP アドレスの3つセット(triplet)で判定するとか、IP アドレスだけで判定するとか流儀はあれど、いずれにせよ判定には必須。が、o365 は再送のたびに違う IP アドレスから送信してくるみたい。よって、greylisting をやってるサイトでは o365 からのメールは受け取れない。何回か何十回か再送試行してるうちにたまたま運よく以前使われた IP アドレスが再度使われた場合にかぎってのみ受け取れる。
_ postfix や qmail ではキュー管理とリモート配送が別プロセスで稼動するけど、o365 は同一ホスト内の別プロセスではなく、複数ホスト間でキュー管理とリモート配送を分担してる、みたいな内部アーキテクチャなんだと思う。たぶん。
_ なお、別ホストから再送する、という挙動自体は珍しくもなんともない。sendmail や postfix には fallback relay の機能があって、配送に失敗したメールを再送専用の別ホストに集めるなんてことはある程度大きな規模のメールシステムなら当たり前にやってる。ほとんどキューに溜めずにどんどんメールを吐き出すサーバと、大量の滞留キューを処理するのに特化したサーバで分けた方がパフォーマンスチューニングがしやすいんだ。そういうことをやってれば1回目と2回目の配送試行は別ホストからになる。が、fallback の fallback を持つことはないので、3回目以降の配送試行は2回目と同じで、つまり毎回 IP アドレスが変わるということはない。配送試行が1回余計に必要になるので fallback relay も greylisting と相性がいいわけじゃないけど、配送できないわけじゃない。配送不能という致命的な問題が起きる o365 のアーキテクチャとはこの点が大きく異なる。
_ MS のサポート情報では、受け取り側の管理者に連絡してホワイトリストに入れてもらえと書いてあるけど、ぶっちゃけこんな運用はまわらない。o365 はそれなりに利用者も拡大してきてるし、まあ greylisting 自体をやめてもらって別の方法で spam 対策してもらうのが手っ取り早いんじゃないかな。さよなら greylisting。