Сегодня мне бы хотелось рассказать об одной истории, связанной с использованием 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.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 список.

Автор: deepshift

Источник