Transactional email deadlock

Transactional email deadlock

Сегодня мне бы хотелось рассказать об одной истории, связанной с использованием SendGrid. В процессе расследования причин мне пришлось пообщаться со службой поддержки, и проблема, в общем-то, так и не решилась, но я продолжаю разбираться и надеюсь, что кто-нибудь из читателей сможет помочь ответить на вопрос, который я изложу в конце моего рассказа. Ну а тем, кто только собирается использовать системы, рекламирующие себя как транзакционная доставка почты (transactional email – SendGrid, MailGun, Mandrill), я надеюсь, этот пост поможет понять, какие проблемы они помогают решить, а какие нет, да и даст понимание о целесообразности использования таких систем в принципе.

Читайте продолжение в нашей статье на Хабре.

Print this post | Home

3 comments

  1. Craig Pfeffer says:

    I am experiencing the same issue, and I think I know what is causing this. SendGrid has several servers that are not DNSed correctly. If your recipient is checking RDNS that email will be blocked by the recipients spam filter and thus putting them on a blocked list in SendGrid.

    I did go to the link sendgrid.com/bounces and they have a settings option that allows you to automatically remove these after x number of days.

    I have placed a ticket with SendGrid asking about the DNS problem and will update this post with what I find out.

  2. Craig Pfeffer says:

    Update: I received a reply from SendGrid about the RDNS issue. They have been standing up new servers recently and their compliance team is behind getting DNS setup correctly.

  3. Igor Kryltsov says:

    Hi Craig,

    Thanks for sharing. Regarding: “They have been standing up new servers recently and their compliance team is behind getting DNS setup correctly.” – we saw this 5 months. Cannot be related to some recent changes by SendGrid to me. They have so many reasons for a bounce. I personally found their invalid, soft and hard bounce lists and rules around them very confusing and explanations from their support only make it worse.

    So we simply work with the API, see how it responds and fix our processing logic without trying to figure out why it works one way or another on SendGrid’s part of it. We also found that it is much easier to always clean all lists at SendGrid via API and have own stop lists and own logic of maintaining them. So every time SendGrid puts something into a stop list we remove it via API so they are always empty for us on their side.