今日は、
SendGridの使用に関連した1つの話をしたいと思います。 理由を調査する過程で、私はサポートサービスに相談する必要があり、問題は一般にまだ解決できませんでしたが、それを整理し続け、読者の一人がこの問題の良い解決策を提供してくれることを願っています。 さて、トランザクションメール配信（
トランザクションメール -SendGrid、MailGun、Mandrill）として自分自身をアドバタイズするシステムを使用しようとしている人のために、この投稿が解決に役立つ問題とそうでない問題の理解に役立つことを願っています。原則としてそのようなシステムを使用することの妥当性。
昨年以来、アメリカ、オーストラリア、ブルガリア、ウクライナにある開発者チームとプロジェクト管理システムの開発とサポートを行っています。 通知を送信するには、SendGridが使用されます。 登録、メールの確認、パスワードの回復など、このようなシステムによってどのような通知が送信されるかは明らかですが、基本的にはこれらは他のユーザーによるシステムの更新に関する通知です（新しいコメント、新しいタスクなど）。 など SendGridの使用経験があることをすぐに言います。
Nerrvanaに機能的な監視機能が追加された
ため、SendGridの使用を開始しましたが、送信するメールの量はプロジェクト管理システムによって送信されるメールの量よりもかなり少ないため、使用時に最初に問題が発生しました。
クライアントは中国にあり、皮肉なことに、メールマーケティングのリーディングカンパニーです。 ドメイン.asia。 この会社の20人の従業員がプロジェクト管理システムに登録されています。 一部の従業員は、通知を受け取っていないと訴えました。 次に、SendGridインターフェイスにアクセスして調査を開始しました。
一部のユーザーは通知を受け取り、他のユーザーは受け取らないことが判明しました。 受信した通知の場合、SendGridは「ドロップ」に「バウンス」の理由を付けます。 それは非常に奇妙でした-これらのユーザーは他のユーザーとこのドメインのメールサーバーでどのように違いますか？ 「バウンス」の概念は私にとって新しいものであることがわかりました。また、最初にそれが何を意味するのかを理解することも決めました。 これが一般に受け入れられている標準である場合-それを理解するために、そうでない場合-SendGridがその意味を読んでください。
「バウンス」とは、メールサーバーがメールを受け入れたが、配信できなかったことを意味することが判明しました。 これらの「バウンス」が発生する理由を確認することは残っており、SendGridサポートに連絡して、これが発生する理由と、フィルターを使用して
sendgrid.com/logs/indexで見つけた2種類のバウンスがどのように
異なるかについて質問しました：
これに応じて、ドキュメントページへのリンク（
sendgrid.com/docs/Delivery_Metrics/index.html ）を
受け取り 、
SendGridがバウンスをソフトとハードに分割していることも発見しました。 彼らはまた、
sendgrid.com / bouncesのページを
教えてくれましたが、それまでには到達していませんでした。 その上で、アドレスがバウンスリストにあったときを見つけることができ、このリストのアドレスを削除できます。 私たちのボリュームがリストを表示し、それらを手動で分析およびクリーニングすることは非現実的であるため、ここで初めて、これを自動的に行う方法があるべきだと考えました。 私たちがこのリストからそれを削除するまで、SendGridはそのようなリストにあるアドレスにそれ以降のすべての文字を送信しないと言われました。 「うん！」-私は非文学的な形で考え、再びサポートサービスに書きました。 多くの質問がありました-SendGridはこれをドキュメントで詳細に説明できたように見えますが。
CrunchBaseによると、資金があるべきではないかのように資金が不足している。
私の意見では、アクティビティログでこれを言うのは非常に論理的です。
-この宛先「bruce.lee@our_client_domain.asia」に送信しようとすると、「to-and-such」への回答が得られました->「Hard bounce」リストにアドレスを追加しました
-宛先「bruce.lee@our_client_domain.asia」へのこの送信試行は、アドレスが「ハードバウンス」リストにすでにあるため、ステータス「Drop」では無視されます。 ドロップされたすべての試行とプライマリサーバーの応答を表示するには、
sendgrid.com / bounces / bruce.lee @ our_client_domain.asiaにアクセスします。
そうすれば、すべてがシンプルで明確になります。なぜ、いつ、どこで何がそこに行き、どれだけがすでにそこにあるのかがわかります。 ソフトバウンスとハードバウンスがどのように表示され、不良リストの1つで最後にヒットした結果がインターフェイスにどのように表示されるかを確認できます。 アクティビティログと[電子メールレポート]ページで使用可能な無効なバウンススパムリストの間にリンクが表示されます。 つまり、すべての場合に根本的な原因と結果があります。 だから人間に見せて！ この場合、私が持っている質問は表示されません。
メールがリストに含まれないようにするために、サブスクリプションレベル（シルバー）で使用できる
アドレスホワイトリストアプリケーションにドメインを追加することをお勧めしましたが、これもオプションではありません。 理由を明確にすることなく、ブラックリストに含まれている（ブラックリストに記載されている）プロバイダーにメールを送り続けることは、アプローチとしては不幸でした。
さらにそれはさらに面白かった。 レポートで、根本的な原因-「550接続頻度が制限されている」を見つけました。 クライアントからは、彼らの
ESPが中国最大の
ISPであるQQ.comであり、クライアントがドメインをホワイトリストに追加したこともわかりましたが、これは役に立ちませんでした。 クライアントはBasecampに行くと脅迫しました（もちろん不快です）。 さらに、クライアントは、QQが各ユーザーが受信するメールの量に制限があるという情報を共有しました。 これにより、一部のユーザーがメールを受信し、他のユーザーがメールを受信しなかった理由が説明されました。 クライアントは、QQでは小さなESP（この場合は私たち）がユーザーに大量のメールを送信することを許可していないと説明しました。 合理的な疑問が生じました-この場合、ESPは私たちですか、それともSendGridですか？ 私たちはそうであることが判明し、これは完全に私たちの問題です。 たとえば、QQは、すべての送信者（大規模と見なされる送信者を除く）が各ユーザーに1日あたり10文字までしか送信できないことを確立しています。 明らかに、ユーザーの1人がこれらの正規化されたQQメッセージを私たちから受信すると、East Fandorin-Masの召使が言うように、さらに[550接続頻度制限]エラーが発生し、中王国に新しい日が来るのを待っていますさらに10を送信します。 これに加えて、SendGridのバウンスリストにも到達し、このリストからアドレスを削除するまで、このユーザーへのメールの送信は停止します（定期的にアクセスできることはわかっています）。
ちなみに、Googleで「550 Connection frequency limited」という行を検索すると、すべてのリンクがQQ.comに言及しているか、QQ.com自体のページであることがすぐにわかります。 つまり、これは既知の問題です。 言いたいことは-「私は私の歩き方、そしてQQ-私は接続頻度が制限されていることで私の愛を認識しています。」
SendGridがこれについて何も知らず、警告しないのはなぜですか-「皆さん、QQメールを送信しています。 なぜSendGridは、QQが（SendGrid）クライアントの制限なしにメールを受け入れるか、少なくともこの市場の主要なプレーヤーである仲介者の役割を果たすQQに同意しないのですか？
さらに、中国のクライアントは、同じユーザーに多くの手紙を送らないように、QQがサービスを提供するすべてのクライアントに送信されるメールの量を予測する（？！）ことを勧めました。 これをどう思いますか？ しません。 または、SendGridにお問い合わせください。
SendGridは、残念ながら、QQページは中国語であると回答しました（つまり、私たちからこのような問題について最初に学んだようですが、オンライン翻訳者の存在についてはまだ知りません）。 彼らはまた、私たち自身がQQに連絡して発信IPアドレスを送信し、私たちからの受信文字の制限を削除するよう要求する必要があると述べました。 また、SendGridは、一部のメールが送信されるように、追加のIPアドレスを月額20ドルで購入することを提案しました。 「良い」ソリューションですが、IPによってQQからブロックされる可能性はどれくらいですか（ドメインによってブロックされる可能性があります）。 これで問題は終わりました。
私はQQで書きましたが、そこから誰も答えず、彼らの側で何も変わっていません。 バウンスなどのエラーが受信者のメールをストップリストに追加しないように、SendGridのホワイトリストにこのクライアントのドメインを入力しました。 ご存知のように、これは問題を解決しませんでした。 このユーザーのQQカウンターがゼロにリセットされたときに少なくとも何かが来ることを期待して、「550接続頻度制限」を受信した後、QQユーザーにメールを送信しようとします。
分析のためにメールを送信し、問題解決の将来の自動化のステータスを保持する決定に至ったのは、このケースと他のケースでした。 データベースに送信されたレターのステータスに関する情報を収集し、メールの問題の解決を自分で自動化する問題に戻る必要があることが明らかになりました。
上記の状況からどのような結論を導き出すことができますか：
1）Sendrgidは、ユーザーのメールサーバー側でのブロックからあなたをまったく保護しません。 顧客が通知を受け取らないと苦情を言った場合は、ESPにQQのような制限があるかどうかを確認してください。
2）Sendgridの労働者は中国語を知らない
3）Sendgridを介してレターを送信する場合、
イベントwebhookを使用するか、サービスのアカウントを定期的に確認して、ユーザーをバウンスリストにすばやく配置する必要があります。