AWS SESでのメール送信（メルマガ・通常）

SESを使ったメール配信を作ったというより、作っていたWebアプリのメール配信機能でSMTPサーバーとしてSESを使った。

SESではバウンスメールが10%くらいになると出入り禁止になるという鉄の掟があるらしい（実際にはいきなり止まるわけではなくメール等で警告があるという噂もある）ので、バウンスを処理して、ダメなアドレスに何度も送らないようにしないといけない。

それは、↓こんなで何とかなった。

http://venzol.blogspot.jp/2015/05/amazon-ses-e-httpdocs.html


その後の話をまとめておく。

SES + SNS + SQSでどの程度のバウンスレートになったか？

もとのメールアドレスリストの品質にもよるだろうが、数％以内にはとどまっている。通常時は2%程度。

新しいアドレスが大量に投下された時は単純にそのアドレスリストのクオリティになるだろうから、どのくらいの品質があるかわからないリストであれば、一気に大量に送らないで小分けにしていった方がいいのかも知れない。（小分けにして、ちゃんと送れてる他のメールと混ざれば薄まる）

バウンスで多いもの

docomoとezwebの受信拒否機能によるバウンスが圧倒的に多い。これは盲点（抜け過ぎか？）だった。いや、そういうことがあるというのは予見していたが、問題はこれらの場合、（少なくとも俺がやっている業務では）受信拒否を解除してもらってメールを送る必要があるということ。

受信拒否の解除の連絡は、業務運用の方々の守備範囲なのでエンジニアたる俺には関係ない・・・ならよかったが、一度バウンスしてSESのSuppression List（ブラックリスト）に載ってしまったものは、手動で解除しなければならない。そして、この解除は、バッチやAPIでは出来ないようになっていて（キャプチャを入れなければいけない）、業務運用の方々がAWSのコンソールに抵抗ない場合でなければ、これがこちらの仕事になってしまう。

配信速度

現状、1万件/時間程度。SESの応答時間を早くすることは出来ないと思うが、スレッドを増やしてもあちらは遅くならないので、こちらがスレッド数を増やせばもっと早くできるはず。
SESの応答時間以外の処理時間もあり、それはどんなアプリでどんな機器なのかによるので一般論とは言えないが、自分のケースでは上記の性能のために16スレッドで動かしている。

反省というか、SESの使い方

メルマガのようなバルクでの配信をSESでやるとしても、通常の単発のメールは他のSMTPサーバーを使った方がいい。

たとえば、メルマガだとしてもその登録確認メールはSESでないので送っておき、それがバウンスしていない場合だけSESの方でも送るようにすれば、完全ではなくても、ある程度はSESで無駄にバウンス→Suppression List解除とやる手間は減らせるのではないか。


まあ、とりあえず根幹にある問題はスパム業者の跋扈と日本のケータイ会社のショボいフィルター機能（元で対処できないから端末レベルでの拒否設定に頼る）なのではないか、と苛立ちも募るが、そこは言っても詮無いことなのでどうでもいいや。くそ。