Unsolicited message error

Время прочтения
10 мин

Просмотры 51K

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

Проблемы с чёрным списком Gmail? Вы пришли по адресу.

Используя описанный ниже процесс, мы успешно разрешили почти все случаи включения в чёрный список Gmail, с которыми сталкивались.

Процесс удаления из чёрного списка Gmail

Если вы примените этот подход, то сможете тоже удалить свой IP из чёрного списка Gmail.

Мы рассмотрим:

• Критерии внесения в чёрный список Gmail
• Почему меня внесли в чёрный список?
• Наш процесс расследования
• Ошибки Gmail SMTP
• Инструкции по удалению из чёрного списка Gmail
• Получение помощи

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

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

Критерии внесения в чёрный список Gmail

Gmail не разглашает подробности своего процесса фильтрации. Если бы они сделали это, то спамеры быстро нашли бы способ обойти фильтры.

Но мы узнали некоторые типичные причины, по которым Gmail может отвергать почту с вашего сервера.

Самые типичные причины следующие:

• Рассылка большого количества писем.
• Внезапные изменения в объёме рассылаемых писем.
• Отправка письма на адрес «спамовой ловушки».
• Отправка писем неизвестным пользователям.
• Включение IP-адреса сервера в публичный блеклист
• Пользователи Gmail пометили ваши письма как спам.
• Использование нового IP-адреса при отправке писем.
• Некорректные настройки DNS.

Если ваш сервер делает что-нибудь из перечисленного, то вы как будто рассылаете спам. В результате Gmail может заблокировать IP-адреса вашего сервера.

Исследование ReturnPath, наш собственный опыт и мнения других экспертов по доставке писем указывают на то, что Google может использовать сигналы от этих публичных чёрных списков:

• pbl.spamhaus.org — чёрный список содержит диапазоны динамических и не серверных IP. Попасть сюда серверу трудно.
• sbl.spamhaus.org — чёрный список содержит письма, которые Spamhaus пометил как спам.
• xbl.spamhaus.org — чёрный список содержит ботов и эксплойт-агентов.
• cbl.abuseat.org — чёрный список содержит письма, отправленные в спам-ловушки или которые пользователи пометили как спам.

Можете использовать поиск Multi-RBL для проверки этих и других списков. Включение в эти списки — явный индикатор, что на вашем сервере какая-то проблема со спамом.

Почему меня внесли в чёрный список Gmail?

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

• Спамеры эксплуатируют веб-приложение (>90%).
• Скомпрометированный пароль или компьютер клиента (~5%).
• Неправильные практики использования электронной почты, такие как слепое перенаправление почты на Gmail (~5%).

Более чем в 90% случаев хакеры используют незащищённые веб-приложения для рассылки спама.

В таких случаях объём спама, жалобы пользователей или другие причины приводят к срабатыванию фильтров чёрного списка Gmail. Они начинают блокировать ваш сервер, чтобы защитить своих пользователей от спама. Мы видели, как спамеры рассылают спам через SSH-туннели.

Даже в отсутствие проблем с безопасностью ваш сервер всё равно может выглядеть как спамерская система.

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

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

Наш процесс расследования чёрного списка Gmail

Вот процесс, который мы используем в нашем платном сервисе по удалению из чёрного списка Gmail:

• Проверьте серверные логи на предмет ошибок 500.
• Проверьте почтовые логи на предмет блокировки другими почтовыми провайдерами и публичными чёрными списками.
• Поищите Excessive SMTP Authentications, особенно от перемены IP для одного и того же пользователя.
• Если у вас есть скрипты PHP, то сконфигурируйте PHP для для журналирования вызовов mail с помощью mail.log ini.
• Проверьте свой IP любимым инструментов для проверки IP в чёрных списках.
• Проверьте репутацию своего почтового сервера на SenderScore.org.
• Проверьте, что пользователи не перенаправляют массово почту на Gmail и родственные домены.
• Проверьте наличие любых новостных рассылок или списков рассылки, которые рассылаются с сервера.
• Убедитесь в корректности записей, связанных с DNS (PTR, DKIM, SPF).
• Посмотрите старые логи и сравните, вырос ли объём писем.

Этот процесс может занять время, особенно на нагруженном сервере. Рекомендую начать с проверки компрометации пользователей. Хотя такие случаи встречаются относительно нечасто, но их гораздо легче выявить, чем проблемы с веб-приложением.

Например, на конфигурациях Plesk/Postfix можно соединить вместе команды шелла таким образом:

grep sasl_username /var/log/maillog|awk {'print $NF'} |sort |uniq -c |sort -n

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

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

Изучая историю почтового сервера, обращайте внимание на следующее:

• Новые ошибки 500 и 421 от других почтовых провайдеров
• Внесение IP в публичные чёрные списки
• Изменения в коде отклика чёрного списка Gmail
• Ваш SenderScore

Обычно такое расследование выявляет скомпрометированный веб-скрипт или пароль пользователя. Ситуацию можно исправить, если изменить или удалить скрипт или просто изменить пользовательский пароль.

Когда вы устранили корневую причину проблемы, начните отслеживать объём почты с сервера и коды отклика от Gmail. Если вас не удалят из чёрного списка, то можно отправить запрос в Google.

В большинстве ситуаций, с которыми мы сталкивались, такой запрос никогда не приходилось отправлять. Исправление корневой причины и проблем с DNS обычно приводит к исключению из чёрного списка в течение 3-5 дней.

Ошибки Gmail SMTP

Чёрные списки блокируют вашу почту, и она не попадает в папку «Спам» (см. нашу статью о том, почему почта попадает в папку «Спам»).

Если вы в чёрном списке, почтовый провайдер будет давать отлупы SMTP с кодом 421 или 550.

Их можно обнаружить в журнале сервера:

Пример ошибки 550
Remote_host_said:_550-5.7.1 Our_system_has_detected_an_unusual_rate_of
unsolicited_mail_originating_from_your_IP_address.
_To_protect_our users_from_spam,_mail_sent_from_your_IP_address_has_been_blocked.
Please_visit_http://www.google.com/mail/help/bulk_mail.html
_to_review_our_Bulk_Email_Senders_Guidelines

Пример ошибки 421
421-4.7.0 unsolicited mail originating from your IP address.
To protect ourn421-4.7.0users from spam, mail sent from your IP address has been temporarilyn4
21-4.7.0 rate limited. Please visit http://www.google.com/mail/help/bulk_mail.n421 4.7.0 html
to review our Bulk Email Senders Guidelines. l41si55243084eef.158 - gsmtp

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

Ниже полный список кодов ошибок Gmail.

Коды ошибок Gmail SMTP

Please resend your message at a later time. If the user is able to receive mail at that time, your message will be delivered. Try again later.

To protect our users from spam, mail sent from your IP address has been temporarily blocked. Review our Bulk Email Senders Guidelines. This error occurs if the sender account is disabled or not registered within your Google Apps domain. To protect our users from spam, mail sent from your IP address has been blocked.

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

Инструкции по удалению из чёрного списка Gmail

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

Если вы остановили поток спама со своего сервера, Gmail обычно автоматически разблокирует ваш IP в течение 3-5 дней.

Если нет, то может понадобиться связаться с ними для помощи.

В таком случае используйте эту форму для связи. Не забудьте сначала войти в свой аккаунт Gmail/Google перед отправкой формы.

Инструкции по заполнению формы для удаления из чёрного списка Gmail

Настоятельно рекомендую заполнить все поля, хоть они и не обязательны. В ваших интересах дать сотрудникам группы удаления из чёрного списка Gmail настолько полную информацию, насколько это возможно, и показать, что вы не являетесь спамером.

Краткое описание

Будьте точны и лаконичны. Например, я обычно использую такой текст:

На сервере было скомпрометировано веб-приложение, которое отправляло спам на Gmail. Мы удалили это приложение с сервера. После удаления приложения мы больше не видим, чтобы неавторизованная почта отправлялась на Gmail.

Полные заголовки

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

Используйте текстовый файл (.txt), если возможно. Избегайте специфических форматов Windows и Mac.

Журналы сервера

Скопируйте только необходимую часть серверного журнала. Всего двух-трёх записей будет достаточно. Они должны выглядеть как примеры ошибок 550 и 421, приведённые выше.

Поиск MX

Хотя это необязательное поле, но это ключевой показатель, что DNS на вашем сервере работает. Успешный результат будет похож на это:

<br data-mce-bogus="1">
[jeffh@office ~]$ host -t mx gmail.com
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.

Подключение по Telnet

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

<br data-mce-bogus="1">
[jeffh@office ~]$ telnet alt4.gmail-smtp-in.l.google.com 25
Trying 2800:3f0:4003:c01::1a...
Connected to alt4.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP c68si3349613vkd.85 - gsmtp

Запрос ping

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

<br data-mce-bogus="1">
[jeffh@office ~]$ ping -c5 alt4.gmail-smtp-in.l.google.com
PING alt4.gmail-smtp-in.l.google.com (64.233.190.26) 56(84) bytes of data.
64 bytes from ce-in-f26.1e100.net (64.233.190.26): icmp_seq=1 ttl=43 time=169 ms
64 bytes from ce-in-f26.1e100.net (64.233.190.26): icmp_seq=2 ttl=43 time=169 ms
64 bytes from ce-in-f26.1e100.net (64.233.190.26): icmp_seq=3 ttl=43 time=169 ms
64 bytes from ce-in-f26.1e100.net (64.233.190.26): icmp_seq=4 ttl=43 time=169 ms
64 bytes from ce-in-f26.1e100.net (64.233.190.26): icmp_seq=5 ttl=43 time=169 ms
--- alt4.gmail-smtp-in.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4175ms
rtt min/avg/max/mdev = 169.448/169.487/169.600/0.523 ms

Дополнительная информация

Это поле не ограничено по размеру, но будьте лаконичны. Я обычно перечисляю здесь какие-то необычные проблемы или указываю, что клиент раньше отправлял заявку на удаление из чёрного списка, но не почистил сервер перед этим.

Отправить форму

После заполнения всех полей можно отправить форму. Вы должны увидеть следующее:

Обычно обновление происходит в течение пяти рабочих дней.

Имейте в виду, что по-лёгкому всё решить не получится. Если вы сразу поспешите на страницу формы для удаления из чёрного списка, не почистив сервер, скорее всего, вас снова внесут в список.

В июле 2015 года Google запустил Gmail Postmaster Tools. Они похожи на инструменты веб-мастера, но только для электронной почты. Если вы управляете электронной почтой для своего домена или клиентов, то может захотите зарегистрироваться.

Получение помощи

Используя такой процесс мы решили все* проблемы с внесением в чёрный список Gmail, с которыми сталкивались.

*На самом деле было несколько случаев, когда проблему не удалось решить. Проблема? Клиент вёл платный список рассылки без подтверждения адресов электронной почты. Если вы действуете как спамер, то Gmail будет считать вас спамером и внесёт в чёрный список.

Модератор: xM

FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri Jan 29 17:32:33 KRAT 2010     root@jabber.npatp.local:/usr/obj/usr/src/sys/my_kernel_20102901_IPSEC
exim-4.71           High performance MTA for Unix systems on the Internet

18 Aug 2014 | Автор: dd |

На той неделе перестали проходить письма на Gmail, возвращаясь с ошибкой о том что они признаны спамом:

<XXX@gmail.com>: host   gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a] said: 550-5.7.1   [MY_IPv6 12] Our system has detected that this
550-5.7.1  message is likely unsolicited mail. To reduce the amount of spam sent   
550-5.7.1 to Gmail, this message has been blocked. Please visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
550-5.7.1 more information. eb7si14952579wib.80 – gsmtp

Причем, больше всего в этом порадовала тема, что гуглеводы вместо того чтобы направить человека в какой нить раздел  false/positive или инициировать диалог для внесения в белые списки, просто переправляют на гайдлайн с описанием того, как надо писать письма и настраивать сервер для поддержки: DKIM, SPF, DMARC.

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

На используемого почтаря у меня были настроены A и MX записи, прописаны реверсивный адрес и SPF запись, правда для IPv4.

Пришлось имевшуюся запись вида
v=spf1 a mx ptr ip4:IPv4 -all

поменять на
v=spf1 a mx ptr ip4:IPv4 ip6:IPv6 -all

но это не дало вообще никакого результата.

Ставить DKIM я не собирался, т.к. подобные проверки считаю от лукавого, ибо они рассчитаны только на маркетологов пришедших в бизнес массовых почтовых рассылок только позавчера, ибо у нормальных рассыльщиков как раз все настройки вроде PTR-записи или SPF фильтров подняты. Тогда как в период моего сисадминства неоднократно сталкивался с тем, что в небольших конторах либо админ слыхом не слыхивал про такую черную магию как даже PTR, либо же его и вовсе не было, т.ч. white-list’ы разрастались до нескольких сотен доменов партнеров.

По этой причине попытался понять, в чем же дело и почему сервак представляется для GMAIL по IPv6. Забиндил интерфейс на определенный IP, добавив в конфиг Postfix /etc/postfix/main.cf строку
smtp_bind_address = IPv4
но ошибка не убралась.

Указал в явном виде хостнейм почтаря, который он объявлял в хелло, чтобы проверка PTR проходила корректно:
myhostname = mail.odminblog.ru

Собственно в этом же ключе порезал служебную информацию в заголовках писем postfix но это тоже ничего не дало. При этом во всех логах мой почтарь представлялся именно по IPv4 и только гугель дропал письма с ссылкой на IPv6.  Таким образом решил отключить использование IPv6, для чего в конфиге подправил строку описания протоколов, закомментировав все и разрешил только IPv4 и удалил соответствующую SPF-запись из DNS:
#inet_protocols = all
inet_protocols = ipv4

И вот после закрытия версии 6 протокола IP, письма перестали дропаться и стали корректно доставляться. Причем самое интересное, что даже удаление SPF записи не влияло на корректность доставки писем.

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

Поковырявшись в тырнете, обнаружил что эта проблема иметт место быть где то с начала 2013 года, когда Google включил поддержку IPv6 и обновил правила фильтров, после чего письма стали отбраковываться по тем или иным причинам: у кого то с руганью на PTR запись, у кого то с ссылками на то что отправитель не поддерживает требования для работы по IPv6. Причем народ по тредам писал, что данная проблема оставалась даже при корректной работе всей счастливой связки Gmail: SPF + DKIM + DMARC

Так что я отдельно порадовался тому, что не стал убивать время на прикручивание всего этого УГ и нашел более изящное решение, при котором отключается поддержка IPv6 только для Gmail.

Для этого добавляем в файлы следующие записи:
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
gmail.com smtp-ipv4:

/etc/postfix/master.cf:
smtp-ipv4      unix  —       —       —       —       —       smtp -o inet_protocols=ipv4

После чего пересобираем табличку для транспорта и рестартим почтовый сервис:
# postmap /etc/postfix/transport
# /etc/init.d/postfix restart

GMAIL отбрасывает письма как спам, 8.8 out of 10 based on 5 ratings

Теги: postfix

Symptoms

• Mail forwarded to Gmail is rejected:

  Our system has detected that this message
   550-5.7.1 is likely unsolicited mail. To reduce the amount of spam sent to 
   550-5.7.1 Gmail, this message has been blocked. Please visit 550-5.7.1 
   http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 
   5.7.1 more information. ho13si622251wib.49 - gsmtp (in reply to end of DATA 
   command)

  ---

  MailEnable: Message could not be delivered to some recipients.
   The following recipient(s) could not be reached: 
   Recipient: [SMTP:[email protected]] 
   Reason: Remote SMTP Server Returned: 550 See http://spf.pobox.com/why.html?sender=***(#5.7.1)

• The following error log can be found in /var/log/maillog :

  postfix/smtp[4907]: 02A25158106B: to=<[email protected]>, relay=mx1.example.com[203.0.113.2]:25, delay=22, delays=0.45/0.04/10/12, dsn=5.7.1, status=bounced (host mx1.example.com[203.0.113.2] said: 550 5.7.1 <[email protected]>: Recipient address rejected: Please see http://www.openspf.net/Why?s=helo;id=example1.com;ip=203.0.113.3;r=mx1 (in reply to RCPT TO command))

  ---

  postfix / smtp [21756]: 6EB2880CAD5E: to = <[email protected]>, relay = mx1.example.com [203.0.113.2]: 25, delay = 0.64, delays = 0.05 / 0.01 / 0.15 / 0.43, dsn = 5.0.0, status = bounced (host mx1.example.com [203.0.113.2] said: 550 Rejecting for Sender Policy Framework (in reply to RCPT TO command))

• Similar issue may occur with other public mail services, like Hotmail etc.

• The message can be also placed to the spam folder.

Cause

SPF record is not set properly.

Resolution

Using Plesk Interface

1. Log in to Plesk.

2. Go to Domains > example.com > DNS Settings.

3. Check the syntax of SPF record according to the article How to check whether a domain has a correctly set SPF record?

   If a domain does not have an SPF record, add it by clicking Add Record, selecting TXT Record Type:

   v=spf1 +a +mx -all:

Using SSH/RDP connection

Connect to the server via SSH/RDP and execute the following command in the Command Prompt or Linux Shell:

on Windows :

C:> plesk bin dns –add example.com -txt “v=spf1 +a +mx -all”

on Linux :

# plesk bin dns –add example.com -txt “v=spf1 +a +mx -all”

Note: if SPF record was updated recently wait till proper SPF record will be propagated 12-24h