Проблемы с получением почтовых уведомлений и пути их решения

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

Важно понимать, что процесс доставки этих уведомлений зависит не только от корректности работы нашей системы, но и от:

  • корректности действий пользователей;
  • корректности работы их электронных почтовых ящиков;
  • корректности работы их почтовых клиентов (приложений), используемых для сбора почты.

По большому счёту, пользователь может не получить уведомление в двух случаях:

  • если уведомление не было отправлено на e-mail пользователя;
  • если электронный ящик (или почтовый клиент) пользователя перегружен или работает некорректно.

Рассмотрим основные причины возникновения таких ситуаций и пути их решения.

1. Уведомление не было отправлено на e-mail пользователя

Существует несколько причин, по которым уведомление может быть не отправлено на e-mail пользователя:

1.1. Пользователь допустил опечатку при вводе e-mail и все уведомления отправляются на e-mail с опечаткой. В этом случае существует два возможных сценария решения проблемы:

  • если пользователь авторизован, он может самостоятельно проверить и откорректировать e-mail в настройках учётной записи;
  • если пользователь не авторизован, он может обратиться в службу поддержки с просьбой откорректировать e-mail (потребуется предоставить подтверждение того, что он является владельцем учётной записи).

1.2. Отправка уведомления не предусмотрена, не активирована в настройках или не наступило условие, необходимое для отправки уведомления. Выявлять такие проблемы позволяет проверка настроек и соблюдение условий отправки уведомлений, например:

  • если пользователю не приходят уведомления о новых комментариях к публикации, это может быть обусловлено тем, что отправка уведомлений отключена на странице глобальных настроек, или, находясь на странице с публикацией, пользователь случайно нажал горячую клавишу «m» и локально отписался от получения уведомлений о новых комментариях к этой публикации;
  • если пользователю не приходит дайджест интересных публикаций по его хабам, это может быть обусловлено тем, что, за установленный им в настройках отправки дайджеста период, в хабах, на которые он подписан, не появилось новых публикаций.

1.3. Уведомление находится в очереди на отправку. Это может происходить в двух случаях:

  • если проводится масштабная рассылка уведомлений. Это касается только рассылок, так как важные уведомления (например, для подтверждения e-mail) отправляются через выделенные почтовые очереди;
  • если мы попытались доставить уведомление, но сервер получателя его не принял и «попросил» нас попробовать отправить это письмо позже. Такое развитие событий возможно, если на сервере получателя активен механизм «greylisting», который перегружен запросами, либо не имеет возможности принять письмо по какой-то иной причине. В таких ситуациях мы ставим письмо в очередь и некоторое время спустя повторяем попытку его доставить.

2. Электронный ящик (или почтовый клиент) пользователя перегружен или работает некорректно

Мы контролируем процесс доставки писем в почтовые ящики получателей с помощью стандартных механизмов (bounce messages / NDR / DSN / NDN). Однако очень важно понимать, что мы не можем как-либо повлиять на этот процесс, если источник проблемы с доставкой уведомления находится на стороне сервера получателя.

В некоторых случаях, сервер получателя может сообщить нам, что в процессе доставки уведомления произошла ошибка, например:

  • почтовый ящик не существует на сервере (invalid user / unknown user);
  • доставка в почтовый ящик административно запрещена / пользователь заблокирован (account disabled);
  • пользователь превысил дисковую квоту ящика / ящик переполнен (user quota exceeded);
  • почтовый сервер отклонил письмо из-за подозрения спама (suspect of spam);
  • маршрут до почтового ящика недостижим (unknown route);
  • иные аналогичные ошибки SMTP с кодами 5xx.

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

2.1. Если сервер получателя сообщил нам, что в процессе доставки уведомления произошла ошибка, то наша система прекратит отправку уведомлений на указанный пользователем e-mail. Это необходимо, чтобы почтовые сервера не принимали нас за спамеров, рассылающих уведомления, игнорируя предупреждения, полученные от сервера получателя.

Если наша система получила сообщение об ошибке и прекратила отправку почтовых уведомлений пользователю, то в верхней части сайта он увидит системное предупреждение: «Мы не можем доставить сообщение по указанному вами адресу e-mail. Чтобы разобраться, в чём дело, перейдите, пожалуйста, по ссылке». Для решения проблемы следует пройти по ссылке в уведомлении и следовать предложенной инструкции.

Если выполнение инструкции не помогло возобновить доставку уведомлений, то следует рассмотреть другие пути решения проблемы:

  • проверить корректность указанного e-mail и внести исправления, если в нём допущена опечатка;
  • обратиться в службу поддержки. Наши специалисты проверят историю отправки уведомлений на указанный e-mail и предоставят код сообщения об ошибке и MessageID. С этой информацией владелец почтового ящика сможет обратиться к администратору или специалистам службы поддержки своего почтового сервера, отклонившего уведомление, с просьбой разъяснить сложившуюся ситуацию;
  • заменить e-mail, указав вместо него почтовый адрес на другом почтовом сервере, работающем более корректно.

Не следует обращаться в службу поддержки с просьбами отключить проверку корректности доставки уведомлений, поскольку наша система не предусматривает такую возможность.

2.2. Если сервер получателя не принял уведомление и «попросил» нас повторить его отправку позже, то мы отложим отправку этого уведомления и некоторое время спустя повторим попытку его доставить. Такое развитие событий возможно, если на сервере получателя активен «greylisting», который перегружен запросами, либо не имеет возможности принять письмо по какой-то иной причине.

2.3. Если сервер получателя сообщил нам, что уведомление успешно доставлено, но получатель не обнаружил уведомления в папке «Входящие», это может быть обусловлено тем, что:

  • на сервере получателя существует временная задержка доставки писем в почтовый ящик;
  • у получателя активирована пересылка или другие персональные фильтры обработки входящих сообщений. Например, сервис «Google Mail» может автоматически перемещать уведомления от наших ресурсов на вкладку «Соцсети». В таких ситуациях рекомендуется проверять настройки имеющихся фильтров. В разных почтовых сервисах фильтры настраиваются по-разному, более того, кроме персональных фильтров в корпоративных почтовых системах могут действовать и групповые, срабатывающие ещё до попадания письма в ящик конечного получателя;
  • на сервере получателя сработал спам-фильтр, поместивший уведомление в папку-карантин.

Почему служебные уведомления попадают под действие спам-фильтров?

Большинство сервисов электронной почты стремится оградить своих пользователей от нежелательных сообщений (спама) и принудительно фильтрует их входящий почтовый трафик. Для этого было изобретено множество различных механизмов выявления спама. И, к сожалению, ни один из них не даёт 100% гарантии того, что почтовый сервер корректно определит, является ли уведомление спамом, или же гарантированно им не является.

Нам заведомо неизвестно, какими критериями оперирует тот или иной спам-фильтр. Как правило, такая информация составляет коммерческую тайну его разработчиков. Поэтому, получив от пользователя информацию о том, что наше уведомление подверглось воздействию чьего-либо спам-фильтра, мы можем лишь строить предположения относительно того, какие настройки этого фильтра привели к его несвоевременному срабатыванию.

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

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

Такие «поведенческие» алгоритмы выявления спама могут не учитывать распространённые ситуации, когда:

  • регистрируясь на нашем сайте пользователь допустил опечатку в e-mail и письмо для его подтверждения пришло другому пользователю;
  • пользователь зарегистрировался на нашем ресурсе по ошибке и не знает, как отписаться от получения новых уведомлений;
  • у почтового адреса сменился владелец и новый владелец воспринимает уведомления от наших ресурсов как нежелательные;
  • пользователь (как правило, заблокированный за нарушение правил ресурса) намеренно помещает уведомления от наших ресурсов в папки со спамом, чтобы ввести спам-фильтр в заблуждение;
  • пользователь случайно переместил письмо в папку со спамом.

На первый взгляд может показаться, что такие ситуации довольно редки. Но в нашем случае речь идёт о регулярной рассылке уведомлений десяткам тысяч различных получателей, осуществляемой на протяжении многих лет. Поэтому, в ситуациях, когда пользователь обнаруживает уведомления от нашего сервиса в папке со спамом, мы всегда рекомендуем переносить уведомления от наших сервисов в обычные папки и добавлять наши адреса в адресную книгу, в список «известных» (known senders), в целях улучшения статистики обучения спам-фильтра.

Групповые спам-фильтры Google

Пользователи наших ресурсов часто используют корпоративные решения «Google» («G.Suits» / «Google Apps») для организации почты на корпоративном домене. При этом они, как правило, создают так называемые «групповые» адреса (info@, sales@, hr@ и т.п.), которые производят пересылку входящих писем сразу на несколько адресов получателей. В «G.Suits» традиционная методика групповых почтовых алиасов заменена на так называемые «Google Groups», которые по своему характеру больше похожи на групповые листы рассылок (mailing lists).

Следует понимать, что «G.Suits» это самостоятельный продукт со своими механизмами, в том числе и для фильтрации спама. Письмо, пришедшее на адрес группы и отфильтрованное как спам, не появляется у конечного получателя в папке со спамом, а ждёт реакции в интерфейсе управления группой в разделе «Модерация». Сотрудники компаний, наделённые полномочиями по администрированию корпоративного «G.Suits», как правило, забывают своевременно проверять этот раздел. Поэтому мы рекомендуем нашим пользователям превентивно отключить механизм премодерации для своих групповых адресов в интерфейсе настроек «Google Groups».

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

Коллизии, возникающие при проверке спам-фильтров

Как уже говорилось, сомнительные с точки зрения спам-фильтров письма удаляются или помещаются в специальную папку-карантин. Название и расположение этой папки варьируется от сервиса к сервису. Типовые названия: «Spam», «Junk», «Спам», «Нежелательные».

Почтовые клиенты могут не скачивать содержимое таких папок на устройство пользователя, или даже автоматически удалять их содержимое. Таким образом, достоверно убедиться в отсутствии уведомления в папке-карантине можно лишь проверив её непосредственно через веб-интерфейс.

В интерфейсе сервиса «Google Mail» папка «Спам» скрыта за дополнительным спойлером, что затрудняет её проверку и, как следствие, приводит к появлению диалогов в духе:

— Мне не приходит уведомление для подтверждения регистрации! Отправлял несколько раз. Почта указана верно. В спаме ничего нет.

— Если Вы не обнаружили уведомления во входящих, пожалуйста, проверьте папку со спамом по ссылке

— Спасибо! Все письма были там.

Обращение в службу поддержки по вопросам, связанным с доставкой уведомлений

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

  • свой username на наших ресурсах;
  • адрес, на который ожидалось письмо;
  • характер ожидаемого уведомления (например, «письмо для подтверждения регистрации»);
  • примерный диапазон дат и времени.

Эти данные помогут нашим специалистам отыскать уведомление в истории отправлений и проследить его путь вплоть до передачи серверу, обслуживающему почтовый ящик получателя. При необходимости специалисты нашей службы поддержки сообщат пользователю данные (MessageID), необходимые для выяснения дальнейшей судьбы уведомления у службы поддержки почтового сервиса.