SendGrid китайцам не указ

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

С прошлого года мы занимаемся разработкой и поддержкой одной из систем управления проектами с командой разработчиков, находящихся в Америке, Австралии, Болгарии и Украине. Для отправки уведомлений используется SendGrid. Достаточно очевидно, какого рода уведомления отправляются такой системой — регистрация, подтверждение почты, восстановление пароля,- но в основном это уведомления об обновлении системы другими пользователями — новый комментарий, новая задача и т.д. и т.п. Скажу сразу, что у нас был некоторый опыт работы с SendGrid. При добавлении возможности функционального мониторинга в Nerrvana мы стали использовать SendGrid, но количество почты, отправляемое нами, несоизмеримо меньше того, которое отправляет система управления проектами, и поэтому здесь мы впервые столкнулись с проблемами при его использовании.

Клиент находится в Китае, и, по иронии судьбы, это ведущая компания почтового маркетинга. Домен .asia. Двадцать сотрудников из этой компании зарегистрированы в нашей системе управления проектами. Некоторые сотрудники стали жаловаться на то, что они не получают уведомления. Тогда я полез в интерфейс SendGrid-a и начал своё расследование.
Вот что я увидел (скриншот):
Проблема, с которой мы столкнулись


Оказалось, что некоторые пользователи получают уведомления, другие — нет. Неполученным уведомлениям SendGrid ставит пометку «Drop» с причиной «Bounce». Это было очень странно — чем таким эти пользователи отличаются для почтового сервера этого домена от других? Понятие «Bounce» оказалось для меня новым и я также решил сначала разобраться, что же оно означает. Если это общепринятый стандарт — понять его, если нет — то прочитать, какой смысл вкладывает в него SendGrid.

Оказалось, что «Bounce» означает, что почтовый сервер принял почту, но не смог её доставить. Осталось выяснить, по какой причине происходят эти «Bounce», и я обратился в службу поддержки SendGrid с вопросом, почему это происходит и чем отличаются два типа Bounce, которые я нашёл на странице sendgrid.com/logs/index, играясь с фильтрами:

SendGrid's bounces


В ответ я получил ссылку на страницу документации — sendgrid.com/docs/Delivery_Metrics/index.html, а также узнал, что SendGrid делит Bounces на мягкие (soft) и твёрдые (hard). Также мне указали на страницу sendgrid.com/bounces, до которой я к тому времени ещё не добрался. На ней можно найти, когда же адрес попал в список Bounce, и можно удалять попавшие в этот список адреса. Тут впервые я подумал, что должен быть автоматический способ это делать, так как для наших объёмов было бы нереально просматривать списки, анализировать и очищать их вручную. Мне было сказано, что SendGrid не отправляет все последующие письма по адресам, попавшим в такой список, пока мы сами не удалим его из этого списка. «Ну и дела!» — в нелитературной форме подумал я, и снова написал в службу поддержки. Вопросов было море — хотя, казалось бы, SendGrid мог бы и расписать это подробненько в документации. Недостатка в средствах как бы у них не должно быть, согласно CrunchBase.

На мой взгляд, вполне логичным было бы в журнале активности сказать так:
— эта попытка отправки адресату «bruce.lee@our_client_domain.asia» привела к ответу «такому-то» -> помещаю адрес в список «Hard bounce»
— эта попытка отправки адресату «bruce.lee@our_client_domain.asia» игнорируется со статусом «Drop», так как адрес уже находится в списке «Hard bounce». Для того, чтобы просмотреть все попытки, которые были дропнуты и первичный ответ сервера перейдите по ссылке sendgrid.com/bounces/bruce.lee@our_client_domain.asia.

Тогда всё просто и понятно — видно почему, когда и куда что попало и сколько уже там находится. Видно, как обозначается soft и hard bounce и как показывается в интерфейсе следствие прошлого попадания в один из плохих списков. Появится связь между журналом активности и списками invalid, bounce, spam, доступных на странице Email Reports. То есть во всех случаях есть первопричина и последствия. Так покажите это по-человечески! Вопросы, которые у меня возникли, просто не появятся в этом случае.

Чтобы почта не попадала в список, мне посоветовали добавлять домены в приложение Address Whitelist, доступное для нашего уровня подписки — Silver, но это тоже не выход. Продолжать отправлять почту провайдеру, который внёс тебя в «чёрный» список (black listed you) без выяснения причин, как подход, нас не устраивал.

Далее было ещё интереснее. В отчётах я нашел первопричину — «550 Connection frequency limited». От клиента я знал, что их ESP — крупнейший ISP в Китае, QQ.com, а также о том, что клиент добавил наш домен в white list, и это не помогло. Клиент грозился перейти в Basecamp (что, конечно, неприятно). Далее клиент поделился информацией о том, что QQ имеет ограничение на получаемый объём почты каждым пользователем. Это объясняло, почему одни пользователи получали от нас почту, а другие — нет. Клиент пояснил, что QQ не разрешает мелким ESP (в данном случае — нам) посылать большие объёмы почты своим пользователям. Возник резонный вопрос — кто же является ESP в данном случае, мы или SendGrid? Оказалось, что мы, и это полностью наша проблема. QQ установил, например, что все отправители (кроме тех, которых они считают крупными) могут отправлять не более 10 писем в день каждому пользователю. По-видимому, как только один из наших пользователей получает от нас эти отнормированные QQ-ковские 10 писем, мы получаем дальше [550 Connection frequency limited] 'осибку', как бы сказал слуга Эраста Фандорина — Маса, и ждём наступления нового дня в Поднебесной, чтобы отправить очередную десятку. В дополнение к этому, мы также попадаем в bounce list SendGrid-а и отправка почты этому нашему пользователю прекращается, пока мы не удалим адрес из этого списка (мы знаем, что мы туда будем попадать регулярно).

Кстати, если сделать поиск по строке «550 Connection frequency limited» в Google, то вы сразу увидите, что все ссылки или упоминают QQ.com, или являются страницами самого QQ.com. То есть это известная проблема. Так и хочется сказать — «Я милого узнаю по походке, а QQ — по Connection frequency limited».

Ку-Ку дот ком


Почему SendGrid об этом ничего не знает и не предупреждает — «вы, ребята, посылаете почту QQ, имейте, блин, в виду что ....»? Почему SendGrid не договорится с QQ о том, чтобы для их (SendGrid-а) клиентов QQ принимал почту без ограничений, ну или хотя бы взял на себя роль посредника, являясь крупным игроком на этом рынке?

Далее клиент из Китая советовал нам прогнозировать (?!) количество почты, отправляемой всем нашим клиентам, обслуживаемым QQ, с тем, чтобы не отправлять много писем одним и тем же пользователям. Как вы себе это представляете? Я — никак. Или же обратиться к SendGrid за помощью, что мы и сделали.

SendGrid ответил, что, к сожалению, страница QQ — на китайском (то есть как бы о такой проблеме они впервые узнали от нас, а о существовании онлайновых переводчиков не знают до сих пор). Также они сообщили, что нам самим нужно связаться с QQ и отправить им наш исходящий IP адрес, и попросить снять ограничения на входящие письма от нас. Ещё SendGrid предложил купить за 20$ в месяц дополнительные IP адреса с тем, чтобы часть почты рассылать с них. «Хорошее» решение, только какова вероятность блокировки по IP со стороны QQ (может, они по домену блокируют)? На этом дело и закончилось.

Я написал в QQ, но никто оттуда не ответил и ничего с их стороны не изменилось. Я внёс домен этого клиента в white list в SendGrid с тем, чтобы ошибки типа bounce не вносили почту получателя в стоп-списки. Как вы понимаете, проблему это не решило. Просто мы пытаемся отправлять и дальше почту пользователям QQ после получения «550 Connection frequency limited» в надежде, что хоть что-то да и дойдёт, когда счетчик QQ сбросится для этого пользователя в ноль.

Именно этот и другие случаи привели нас к решению хранить у себя статусы отправки почты для их анализа и будущей автоматизации решения проблем. Стало понятно, что нужно собирать информацию о статусах отправленных писем в своей базе, ну а затем возвращаться к вопросу автоматизации решения почтовых проблем собственными силами.

Какие выводы можно сделать из описанной выше ситуации:

1) Sendrgid нисколько не защищает вас от блокировок на стороне почтового сервера пользователя. Если ваши клиенты жалуются на то, что не получают уведомления — проверьте, нет ли у их ESP ограничений, как у QQ.

2) Работники Sendgrid-а не знают китайского

3) При отправке писем через Sendgrid необходимо пользоваться Event webhook, либо регулярно проверять свой аккаунт в сервисе, чтобы оперативно реагировать на помещение ваших пользователей в Bounced список.
Метки:
Поделиться публикацией
Похожие публикации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 7
  • +3
    Насколько я вижу, основной источник проблемы тут как раз QQ. Во-первых, это у них стоит ограничение в 10 писем. Во-вторых, они при достижении этого ограничения отдают 5xx ошибку (а должны бы — 4xx), что означает, что запрошенное действие не может быть выполнено «потому что не может быть выполнено никогда». Разумеется, после такого ответа sendgrid отправляет адрес в hard bounce list.

    В качестве варианта решения для таких клиентов можно сделать опцию «получать дайджест раз в N часов».

    Кстати, письмо в QQ вы на китайском писали? Если нет, то может иметь смысл нанять китайца, который бы вам такое письмо перевел.
    • +1
      Вы правы, источник проблемы в QQ. Однако удивляет реакция Sendgrid на данную ситуацию — для них логичным было бы выступить в роли крупного ESP и договориться с QQ о повышении лимитов для своих клиентов, ну хотя бы для платных клиентов, которыми мы являемся.
      В качестве варианта решения для таких клиентов можно сделать опцию «получать дайджест раз в N часов».

      Да, это может решить проблему. Но при этом существующая система отправки писем потребует больших изменений.
      Кстати, письмо в QQ вы на китайском писали? Если нет, то может иметь смысл нанять китайца, который бы вам такое письмо перевел.

      Хмм, забавно. Нет, письмо писали на английском. Согласитесь довольно странно, если у такого крупного провайдера нет сотрудников, умеющих читать по-английски. Вообще шутки ради можно перевести письмо гугловым переводчиком, как месть за инструкции к китайской технике :)
      • +1
        Вы правы, источник проблемы в QQ. Однако удивляет реакция Sendgrid на данную ситуацию — для них логичным было бы выступить в роли крупного ESP и договориться с QQ о повышении лимитов для своих клиентов, ну хотя бы для платных клиентов, которыми мы являемся.

        А это принципиальная позиция Sendgrid: репутация их клиентов — штука отдельная от репутации самих Sendgrid, и они довольно последовательно этой позиции придерживаются, вплоть до выделения личных диапазонов ip адресов для клиентов. Поэтому вписываться за клиентов они не будут.

        Согласитесь довольно странно, если у такого крупного провайдера нет сотрудников, умеющих читать по-английски.

        Они-то наверняка есть, но, думаю, если сравнить масштабы вашей компании и QQ, вы им просто неинтересны. Настолько неинтересны, что вам даже ответить не удосужились. А письмо на китайском вам могло бы дать большие шансы на ответ. В конце-концов, это же от вас клиент может уйти.
      • 0
        В качестве варианта решения для таких клиентов можно сделать опцию «получать дайджест раз в N часов».

        Не вариант поскольку кроме дневного емайла система имеет разные виды настроек под уведомления, которые таким пользователям нужно запрещать. Здесь я описал только один случай. Например Hotmail заворачивает наши письма с ошибкой «550 Mailbomb Target» и это значит что уже при регистрации с домена hotmail. нам нужно говорить — у вас будут проблемы с получением почты. Опять же мы надеялись, что SendGrid помогает решить такие проблемы. Оказалось — нет. И ещё один пример. В Invalid списке SendGrid сейчас у нас 1500 адресов. Ошибка «Known bad domain», которую показывает SendGrid ни о чём не говорит. Я проверил — домен существует, MX записи прописаны и их несколько. Обратился в поддержку SendGrid и оказалось, что на самом деле SendGrid получает от GMail, который хостит почту этого домена сообщение:

        Delivery to the following recipient failed permanently:

        ХХХХХХ@joinvip.com

        Technical details of permanent failure:
        Google tried to deliver your message, but it was rejected by the server for the recipient domain joinvip.com by aspmx.l.google.com. [2a00:1450:4008:c01::1b].

        The error that the other server returned was:
        550-5.7.1 The user or domain that you are sending to (or from) has a policy that
        550-5.7.1 prohibited the mail that you sent. Please contact your domain
        550-5.7.1 administrator for further details. For more information, please visit
        550 5.7.1 support.google.com/a/bin/answer.py?answer=172179 ri6si1230950bkb.338 — gsmtp


        не имеющее ничего общего с «Known bad domain». Я бы хотел видеть сообщение, которое имеет смысл и может быть обработано программно. Согласны?
      • +1
        А это принципиальная позиция Sendgrid: репутация их клиентов — штука отдельная от репутации самих Sendgrid

        Беспокойство за свою безупречную репутацию вполне понятно. Но с позицией Sendgrid не могу согласиться, что и послужило причиной написания данного поста. Возможно я не прав, но когда я плачу деньги за сервис, то ожидаю увидеть со стороны этого сервиса хоть какую-то заинтересованность во мне и желание помочь мне решить мои вопросы. Здесь же отношение напомнило мне анекдот про цирковой номер с бочкой отходов жизнедеятельности в центре арены, подвешенным грузом под куполом и выходящим в конце артистом во всем белом.
        Они-то наверняка есть, но, думаю, если сравнить масштабы вашей компании и QQ, вы им просто неинтересны. Настолько неинтересны, что вам даже ответить не удосужились.

        Таки да, против фактов не попрешь
        А письмо на китайском вам могло бы дать большие шансы на ответ

        Пожалуй это будет даже интересно, займемся переводом. Если получим ответ, отпишусь об этом. Спасибо за совет.
        • +1
          Добрый день. C ребятами из SendGrid работаю очень тесно. В понедельник постараюсь выяснить, что знает ли SendGrid команда об этой проблеме и что собирается делать. Но я так понимаю, если они и добавят новый статус (и не будут добавлять email в bounced) для писем специально для QQ, это не решит проблему с доставкой писем. Что еще в таком случае предпринимать?
          • 0
            Но я так понимаю, если они и добавят новый статус (и не будут добавлять email в bounced) для писем специально для QQ, это не решит проблему с доставкой писем.


            Абсолютно верно. Переводим письмо к на китайский и повторим попытку. Я бы всё таки на месте SendGrid делил клиентов и направления деятельности клиентов с репутацией по каждому из них. То есть мы, например рассылаем и маркетинговые письма и письма уведомления. По каждому направлению у нас должен быть индех доверия нам SendGrid. Чем выше индех, тем проще должно быть нам использовать возможности и влияние SendGrid на провайдеров получателей начей почты.

            Вот тут можно видеть мою просьбу обновить всё таки документацию по Bounces, так как информация на этой странице не содержится в документации.

            Больше всего не хотелось бы превращать этот пост в жалобную книгу на SendGrid, а просто поразмышлять над тем, каким должен быть отличный сервис транзакционной отправки почты. Пока, к сожалению, этот сервис далёк от идеала — в день, когда мы обновили (прошедшие выходные), нашу систему на чтение результата отправки через АПИ о котором я писал мы выяснили, что SendGrid изменил формат отдаваемого ответа на JSON. Как такое может быть, ведь никто из нас не получал уведомление об этом? О таких вещах как-бы принято предупреждать заранее.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.