Ошибки почтовой системы – это коды, которые присваиваются сообщениям во время получения или отказа в получении. Код ошибки позволяет выяснить причину, по которой возникла невозможность доставки почтового сообщения. Как правило, код ошибки представляет собой число, например #550 или #2001. Описание кодов ошибок приведено ниже.
Сообщения без кодов
Unroutable address
Не удалось определить сервер, на который нужно переслать почтовое сообщение. Возможные причины:
- Не существует или не делегирован домен, на который посылается почта
- Для домена не прописаны ни MX, ни A записи
- MX запись указывает на несуществующее имя
User unknown
Данного почтового ящика не существует, либо почтовый адрес указан с ошибкой
Transmission in progress. Stay tuned
Сообщение возникает при отправке писем почтовым клиентом. Это сообщение не нашей почтовой системы. Оно означает, что у пользователя в локальной сети есть антиспам или фаервол, который проверяет все отправляющиеся письма.
Over quota
LMTP
error after end of data: 552 5.2.2 Over quota
Ошибка возникает, в случае если у получателя переполнен почтовый ящик.
Сообщения с кодами
#1005
Sender verify callout failed
Проверка отправителя письма. Ошибка может быть либо полной, как указано ниже, либо сокращённой: «Sender verify failed [#1005]».
Ошибка присылается каким-либо сервером, который осуществил неудачную попытку отправить письмо нашему серверу.
Наш сервер указан в строчке «… while talking to mx3.сайт.:».
The following addresses had permanent fatal errors -----
Адрес [email protected] – это адрес получателя письма, он приведён только ради полноты информации.
Адрес отправителя [email protected] не прошёл проверку, о чём и написано в сообщении.
Для каждого письма производится проверка отправителя. Для этого наш сервер пытается подсоединиться к серверу, принимающему почту для домена отправителя (в примере – example.com) и отправить письмо с адреса «<>» на адрес отправителя (в примере [email protected]). Такие письма всегда должны приниматься, потому что именно так выглядят сообщения о неудачных доставках. Если сервер отвечает, что такого ящика не существует (в примере сервер, обслуживающий домен example.com, ответил «550-User unknown (200)») или по другим причинам отвергает попытку, то письмо с адреса [email protected] не принимается.
Проверка обратного адреса – это не защита от спама (хотя и помогает фильтровать его часть). Сервер должен иметь возможность послать отправителю сообщение в том случае, если он не смог доставить письмо получателю. Для гарантии этой возможности проверяется обратный адрес.
В настоящем случае Вы узнали о проблеме, потому что наш сервер не принял сообщение (сигнализируя о проблемах связи с доменом отправителя), а посылающий сервер сообщил об этом отправителю. Если бы наш сервер принял сообщение, не проверяя возможность обратной доставки, Вы не узнали бы о проблеме.
Письмо с неверным обратным адресом – это проблема, которую обязательно надо решать, но ни в коем случае не отключением средства, которое сигнализирует о ней.
#1004
Sorry, we don’t accept messages from the hosts without a PTR
record
Ошибка возникает, когда у узла отправителя отсутствует PTR
-запись.
#1007
We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1007]
или dynamic ip rejected [#1007]
Данная ошибка возникает у пользователей, использующих для своего подключения динамический пул адресов. Проверка осуществляется на основании IP-адреса пользователя (наличие в нём слов dial, ppp, pool, dsl, dynamic, static и другие вхождения).
#1008
Sender verify failed
В заголовке smtp-сесии mail from указан неверный обратный адрес (несуществующий домен, например).
#1009
We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1009]
Данная ошибка в основном возникает у пользователей использующих DSL
или DialUp подключения и отправляющих почту со своих локальных компьютеров, иными словами не использующих SMTP
-сервер своего провайдера. Проверка осуществляется на основе регулярного выражения для :
^({1,3}\D+){2}({1,3}[^\d\.]*).*\.(\w|-)+\.\w{2,4}$
Если вы по какой-то причине не можете использовать SMTP
-сервер вашего провайдера – напишите заявку в техническую поддержку с указанием вашего ip адреса, он будет добавлен в white-list.
#1014
Mail rejected, see http://www.spamcop.net/w3m?action=checkblock&ip=IP-адрес [#1014]
Мы используем DNS
-блеклисты spamcop.net для защиты от спама. Адрес отправителя находится в блеклистах spamcop.net
#1020
Relay not permitted
Совершена попытка отправить письмо на домен, который не обслуживается нашими почтовыми серверами.
#1024
Recipient verify failed
Проверка получателя письма. Ошибка возникает, если домен обслуживается нашими серверами, но такого адреса в домене не существует.
#1025
Recipient verify callout failed
Проверка получателя письма. Ошибка возникает, если удалённый сервер отвечает, что такого получателя не существует.
#1305
You are sending too many messages
Превышен лимит по отправке писем через smtp. Для повышения лимита необходимо обратиться в службу технической поддержки.
#2002
Authentication required
Для отправки требуется пройти аутентификацию по логину и паролю.
Примеры корректной настройки почтовых клиентов можно посмотреть
Примеры писем:
550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc
550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC
550 5.7.1 Email rejected per DMARC policy for ...
Проблема с доставкой сообщений связана с применением новой политики DMARC , связанной с ужесточением правил прохождения спам фильтров.
DMARC — это протокол защиты от спама и от несанкционированной рассылки почты от имени домена, основанный на существующих механизмах DKIM и SPF . Официальный сайт: dmarc.org .
Если вы получаете подобные приведённым выше сообщения, скорее всего, почта с сайта у вас отправляется от имени почтового ящика на базе @mail.ru , @bk.ru , @list.ru или @inbox.ru . Mail.Ru не принимает сообщения, отправленные через phpmail, если в почтовых заголовках числится ящик, принадлежащий mail.ru. Такие сообщения, согласно внедрённой Mail.Ru политике DMARC , отклоняются.
Как решить проблему
Решить проблему можно двумя способами:
Способ 1: изменить ящик, с которого отправляются сообщения
Обычно e-mail, от имени которого рассылаются почтовые сообщения, прописывается в административной части CMS. Также его можно изменить напрямую в скрипте, рассылающем сообщения (поле «From»).
Необходимо, чтобы сообщения рассылались с ящика на базе вашего доменного имени, например «[email protected]» , где domain.ru — ваш домен. .
Также, почтовый ящик необходимо изменить в файле php.ini :
Изменение ящика в php.ini
- 1 войдите в панель управления хостингом и откройте на редактирование файл php.ini : ;
- 2
найдите строку вида:
sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"
В данной строке вместо «[email protected]» укажите почтовый ящик, не относящийся к доменам @mail.ru , @bk.ru , @list.ru и @inbox.ru .
Желательно указать почтовый ящик на вашем домене, например, «[email protected]» , где domain.ru — ваш домен.Кроме этого, прописанный в php.ini почтовый ящик должен существовать. Если вы пользуетесь почтой на хостинге, создайте почтовый ящик на домене по и пропишите его в файле php.ini .
Способ 2: использовать SMTP-авторизацию
Вы можете рассылать сообщения от имени вашего почтового ящика на базе Mail.Ru, настроив SMTP-авторизацию. В этом случае все сообщения через ваш сайт будут отправлять напрямую с серверов Mail.Ru.
Проблема недоставки почтовых сообщений – типичная проблема, которую приходится расследовать.
Причина возникновения таких проблем в том, что состояние текущих стандартов и практик почтовых систем не позволяет гарантировать доставку сообщений или даже получить четкий комментарий о недоставке.
Более того, на различных этапах доставки сообщений присутствует большое количество ошибочно настроенных фильтров.
Обычно, к сожалению, никаких эксклюзивных мер по расследованию проблемы потери почты предпринять нельзя. Данная статья дает окончательный алгоритм действий, придерживаясь которого, вы четко поймете, где возникла проблема и как устранить её, если это возможно.
По каждому варианту дается дополнительный комментарий о том, имеет ли смысл дальнейшее расследование по проблеме или окончательное решение по проблеме можно вынести немедленно.
Проблема с отправкой сообщений с сайта
Пожалуйста, убедитесь, что вы точно выполняете все советы статьи .
Самое важное:
1) Обратный адрес письма должен быть зарегистрированным ящиком на нашем хостинге!
2) Массовые рассылки запрещены, по умолчанию, с сайта можно отправить до 500 писем в день.
3) Письмо должно соответствовать почтовым стандартам. Ваш скрипт самостоятельно формирует письмо и если оно получилось не очень качественным, оно будет принято нашим сервером, но его доставка не произойдет, т.к. его задержат фильтры нашей системы или у получателя.
Проблема с отправкой сообщений от человека
Ситуация 1
Письмо, которое вы отправляете, не присутствует в списке сообщений.
Это значит, наш почтовой сервер не принимал письмо. Причины могут быть следующие:
- Письмо не поступало на наш SMTP сервер: ваша почтовая программа не отправила сообщение. Источником или решением проблем может быть следующее -
- Настройки учетной записи вашей почтовой программы, точнее - настройки SMTP сервера. Помните, что SMTP сервер требует авторизации, тем же логином и паролем, что и сервер входящей почты.
- Антивирус, система безопасности, прокси-сервер.
- Письмо поступило в систему, но было отклонено, т.к. не содержало правильного обратного адреса. Обратный адрес письма должен точно соответствовать либо адресу названия ящика, либо одному из псевдонимов.
Ситуация 2
Письмо присутствует в списке сообщений в очереди.
Необходимо открыть «статистика доставки почты», «SMTP доставка».
Ситуация 2.1
Письмо присутствует в списке SMTP доставки.
Для одного сообщения может присутствовать несколько попыток доставки. Предварительные попытки могут быть неудачными, это нормально. Необходимо найти последний блок (строку), который имеет отношение к доставке вашего сообщения.
Ситуация 2.1.1
Блок «лог доставки» оканчивается сообщением 250 OK или любым другим сообщением, которое начинается с кода 250 (кроме последней строки «Connection closed normally» - её учитывать не нужно).
Это означает, что следующий в цепочке доставки почтовый сервер принял письмо и подтвердил факт получения сообщения. Все последующие вопросы о судьбе сообщения необходимо направлять администратору этого почтового сервера. Информация из блока «лог доставки», одновременно с датой и временем, поможет администратору понять судьбу сообщения и при необходимости устранить проблему.
Ситуация 2.1.2
Блок «лог доставки» оканчивается сообщением, которое начинается кодом, отличным от 250, либо сопровождается сообщением «Processing of job XXXXXXX incomplete or failed».
Это означает, что наш почтовый сервер не смог доставить сообщение адресату. При этом вы должны получить сообщение о недоставке почтового сообщения («возврат»). Дополнительная информация доступна из лога SMTP доставки, которую вы сейчас просматриваете.
- Сообщение может быть отклонено сервером получателя из-за некорректной фильтрации спама. Ответственность за возврат письма лежит на администраторе сервера, почтовый сервер которого принял решение о том, что письмо является спамом. Спам с адресов нашего почтового сервера не рассылается, поэтому решение об отклонении письма на основании IP адреса или иных формальных признаков является заведомо ошибочным.
Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Необходимо обратиться к администратору принимающего сервера.
Примеры сообщений о том, что почтовый сервер адресата отклонил сообщение по подозрению в спаме: - 591 your host is blacklisted
- 450 5.7.1
- 553 5.3.0 Spam blocked see: http://spamcop.net/ ...
- 550 5.7.0 Your server IP address is in the SpamCop database, bye
- 554 Service unavailable; Sender address blocked using list.dsbl.org
- 550-Message rejected because … (…)
- 591 your host is blacklisted, see ...
- Сообщение с кодом 4xx или 5xx, упоминающее слова spam, blocked, Spamcop, Spamhaus, RBL, SBL, XBL, SPEWS, policy analysis, denied, или аналогичные.
- Сообщение может быть отклонено сервером получателя в том случае, если адресат на сервере отсутствует, т.е. по причине ошибки адреса.
Уточните адрес до символа @.
Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Если вы считаете, что адрес точен, то необходимо обратиться к администратору принимающего сервера для уточнения причины отказа принять письмо.
Примеры сообщений об отсутствующем адресе: - 550
- 553 We do not relay without RFC2554 authentication
- 550 Message was not accepted -- invalid mailbox
- 554 … This account has been disabled or discontinued
- Сообщение об ошибке в почтовом адресе после символа @. Уточните почтовый адрес, а также то, что домен получателя активен и работает.
Примеры сообщения об ошибке после @: - Temporary error XXX (temporary MX resolution error) resolving "aaa.bb"
- Техническая ошибка при отправке сообщения. Вы можете попытаться отправить письмо повторно, либо уточнить у получателя, нормально ли работает его сервер электронной почты.
Вы можете обратиться к службе поддержки с просьбой прокомментировать ситуацию точнее.
Примеры сообщений о технических ошибках: - Error connecting to primary server "a.b.c.d"
- Error connecting to alternate server " a.b.c.d"
Ситуация 2.2
Письмо отсутствует в списке SMTP доставки. Обратитесь в службу поддержки.
Проблема с получением сообщений
Вам необходимо зайти в личный кабинет, выбрать «статистика доставки почты», «очередь сообщений» для нужного вам ящика.
ВАЖНО:
расследовать проблему такого вида можно только для сообщений, которые были доставлены в ящик непосредственно, без участия списка рассылки либо спам-фильтра. Если ваш ящик получает сообщение косвенным образом (через список рассылки), вам необходимо расследовать проблему для ящика, который является основным ящиком списка рассылки. Если включен спам-фильтр - его необходимо выключить.
Ситуация 3
Сообщение присутствует в списке.
Это означает, что сообщение было принято сервером и размещено в ваш почтовый ящик. Проблемы с получением такого письма связаны с вашей системой либо её настройками.
- Проверьте настройки системы фильтрации спама («полный список функций», «фильтрация нежелательных сообщений»). Если спам-фильтр включен, письмо могло быть перемещено либо отклонено (в зависимости от ваших настроек). Письмо также могло быть уничтожено вне зависимости от настроек, если содержало вирус.
Следует попробовать отключить фильтрацию почты либо проверить все ящики, куда могло быть перемещено письмо, если выбран такой режим. - Ваша почтовая система может вообще не принимать почту с нашего сервера. Для уточнения этого случая посмотрите содержимое вашего почтового ящика через веб-доступ к почте, см. ссылку напротив нужного ящика на странице «пароли на ресурсы» личного кабинета.
- Иногда почтовая система компьютера или организации принимает сообщение, а затем по какой-то причине удаляет его с сервера, никуда далее не передав и не сохранив. Вам необходимо обратиться к администратору вашей почтовой системы для расследования проблем такого типа.
Расследовать данную проблему с нашей стороны нет смысла, т.к. письмо было размещено в ваш ящик и могло быть удалено из него только с помощью команд с вашего компьютера с помощью протокола POP3 или IMAP.
Ситуация 4
Сообщение отсутствует в списке.
Это означает, что наш почтовый сервер не принимал сообщение.
Расследовать данную проблему с нашей стороны нет смысла. Это представляет собой проблему нашей почтовой системы только в том случае, если есть доказательства того, что сообщение было доставлено на наш сервер. Доказательством служит кусок лога SMTP клиента отправляющего сервера (случай, зеркально аналогичный ситуации 2.2.1 выше). Если такого доказательства нет, значит, расследовать данный случай недоставки должен администратор почтового сервера отправляющей стороны.
Также можно попробовать учесть различные обстоятельства работы вашего домена, которые могут привести к тому, что доставка почты на него вообще работать не будет.
- Убедитесь, что домен активен (DELEGATED), что DNS сервера соответствуют DNS серверам сайт (ns1.сайт, ns2.сайт).
- Если домен обслуживается другими DNS серверами, убедитесь, что MX запись домена показывает на наш почтовый сервер (если не сообщено иначе, это должен быть mail.сайт).
- Если домен обслуживается нашими DNS серверами, зайдите в «полный список функций», «редактор DNS зон», выберите домен, убедитесь, что стоит галка «1Gb..
- Убедитесь, что домен зарегистрирован более 3х дней назад.
Когда вы, находясь вне дома, отправляете сообщение электронной почты с помощью домашней почтовой учетной записи, это сообщение может вернуться с ошибкой 550, 553 или ошибкой ретрансляции. То же самое может произойти, когда вы, находясь вне офиса, пытаетесь отправить сообщение электронной почты с помощью рабочей почтовой учетной записи.
Описание
Ретрансляция происходит, когда почтовое сообщение отправлено на адрес электронной почты, домен которого (имя после символа @, например adatum.com) не обрабатывается протоколом SMTP или сервером исходящей почты, получающим от отправителя запрос на доставку сообщения. SMTP-серверу необходимо подключиться к другому SMTP-серверу, чтобы ретранслировать сообщение.
Если при отправке почтового сообщения возникает ошибка ретрансляции, ваш SMTP-сервер (исходящей почты) может вернуть ваше сообщение вместе с сообщением об ошибке, например, такого вида:
"Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <адрес эл. почты>. Тема: <тест>, учетная запись: <тест>, сервер:
Точный текст сообщения об ошибке будет зависеть от вашего поставщика интернет-услуг. Некоторые поставщики не возвращают сообщение об ошибке, когда определяют исходящие сообщения как нежелательную рекламу. В этих случаях все выглядит так, как будто ваше сообщение отправляется в обычном режиме (в Outlook остается в папке Исходящие и появляется в папке Отправленные ), но получателю оно не доставляется.
Ваше сообщение отклонено, поскольку SMTP-сервер (исходящей почты) не распознал вас как полномочного пользователя.
SMTP - это протокол (стандарты, используемые компьютерами для взаимодействия), который используется на большинстве серверов электронной почты для отправки сообщений в Интернете. Если вы используете почтовую программу (например, Outlook), которая позволяет хранить сообщения на компьютере, вам необходим доступ к SMTP-серверу для отправки сообщений.
Примечание: Веб-системы электронной почты (например, Windows Live Mail или Yahoo! Mail) работают иначе и не рассматриваются в этой статье.
Нежелательная почта и открытые ретрансляции
Рекламные сообщения, распространяемые без запроса, называют нежелательной почтой или спамом. Объем нежелательной почты продолжает расти, потому что ее отправка практически ничего не стоит тем, кто ее рассылает. Фактически отправителю даже не обязательно отправлять нежелательную почту через SMTP-сервер (исходящей почты) своего поставщика интернет-услуг.
При создании базовой структуры Интернета никто не предвидел, к каким последствиям приведет возможность отправлять миллионы нежелательных сообщений за ничтожно малую плату. Благодаря способности SMTP-серверов к ретрансляции отправители нежелательной почты маскируют ее подлинный источник, передавая ее через сторонние серверы, на которых разрешены такие открытые ретрансляции. В результате нежелательная почта как бы приходит с сайта, который ретранслирует сообщение и скрывает личность настоящего отправителя.
До недавнего времени большинство почтовых SMTP-серверов работали на основе доверительной открытой системы. В такой системе кто угодно откуда угодно может передать почтовое сообщение SMTP-серверу, а сервер должен принять его и переслать получателю или другому почтовому серверу, на котором находится почтовый ящик получателя. При такой открытой ретрансляции нет ограничений, запрещающих кому-либо отправлять почту через SMTP-сервер.
Ограничения поставщика интернет-услуг на ретрансляцию почтовых сообщений
По мере увеличения объемов нежелательной почты администраторы сети (люди, отвечающие за управление серверами поставщика интернет-услуг) начали вводить ограничения на своих почтовых SMTP-серверах. Эти ограничения не позволяют использовать почтовый сервер всем подряд. Представьте, что в вестибюле вашей организации есть телефон, доступный для всех, в том числе для тех, кто не является сотрудником организации. Теперь телефоном разрешено пользоваться только сотрудникам.
На сегодняшний день используются ограничения нескольких типов.
Требуется проверка подлинности SMTP. Так же как вы используете имя пользователя и пароль для доступа к POP3-серверу (входящей почты) и своим почтовым сообщениям, вам требуется ввести имя пользователя и пароль для отправки почтовых сообщений через SMTP-сервер. Обычно это те же имя пользователя и пароль, что и для POP3-сервера, но могут быть и уникальные.
Требуется сначала подключиться к POP3-серверу (входящей почты) поставщика интернет-услуг. Чтобы получить свои новые почтовые сообщения, вы обычно подключаетесь к POP3-серверу (входящей почты). Для доступа к почтовому ящику вам нужно ввести имя пользователя и пароль. Администратор сети может настроить сервер таким образом, что если вы сначала подключаетесь к POP3-серверу входящей почты и проходите проверку подлинности, он будет утверждать все запросы на отправку почтовых сообщений через SMTP-сервер исходящей почты, на котором в ином случае эта возможность будет ограничена.
Требуется подключение из авторизованного расположения в сети. Если вы из дома подключаетесь к поставщику интернет-услуг по телефонной линии, с помощью кабеля или через DSL-модем, подключение идет напрямую к сети поставщика. Вы заслуживаете доверия, поскольку у вас есть учетная запись с именем пользователя и паролем, которые предоставил поставщик интернет-услуг. Вам как клиенту разрешается использовать SMTP-сервер для отправки почтовых сообщений.
Требуется подключение с определенного IP-адреса или диапазона IP-адресов. Ваш поставщик интернет-услуг может разрешить доступ к SMTP-серверу людям, не подключенным к сети напрямую. Например, это может быть удаленный пользователь в офисе. Основная проблема состоит в том, что во многих местах используются динамические IP-адреса. При этом вы не можете быть уверены в том, что при каждом подключении у вас один и тот же IP-адрес. У некоторых организаций может быть зарезервирован блок или диапазон IP-адресов. Поставщик интернет-услуг может считать тех, кто подключается с этих IP-адресов, проверенными пользователями. Он может предоставить дополнительные сведения.
Возможных сценариев ретрансляции очень много. Ниже приведены самые распространенные ситуации. Возможно, одна из них похожа на вашу.
|
Ситуация |
Это ретрансляция? |
|
Вы дома, и у вас есть учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com , с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
|
|
То же, что и в первой ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com . |
Да, но она не блокируется. Вы подключаетесь напрямую к поставщику интернет-услуг и тем самым получаете полномочия для отправки почты через его SMTP-сервер (исходящей почты) на любые адреса, независимо от расположения почтового ящика получателя. |
|
Вы на работе. Ваш рабочий почтовый адрес оканчивается на @thephone-company.com , и у вас есть домашняя учетная запись поставщика интернет-услуг, адрес которой оканчивается на @proseware.com и с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
Нет. Ваша почта обрабатывается обычным способом. |
|
Вы остановились в гостинице или воспользовались в аэропорту интернет-терминалом, предоставляющим доступ в Интернет. У вас есть домашняя учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com , с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com . |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
Решения
Если ваша ситуация рассматривается как ретрансляция, вы должны отправить сообщение через сервер, к которому сейчас подключаетесь. То есть, если вы на работе или вне дома и не используете своего поставщика интернет-услуг для подключения к Интернету, но хотите отправить сообщение из своей домашней учетной записи, предоставленной этим поставщиком, вам нужно изменить параметры почтовой учетной записи, указав тот SMTP-сервер, который вы используете там, где находитесь (например, рабочий SMTP-сервер). Пошаговые инструкции см. в статье .
Если это не работает или вы предпочитаете использовать домашнюю учетную запись, вам нужно связаться со своим поставщиком интернет-услуг и спросить, доступны ли вам описанные ранее параметры. Что касается первых двух ограничений (требуется проверка подлинности SMTP и требуется сначала подключение к POP3-серверу входящей почты поставщика интернет-услуг), вы можете внести изменения в Параметры учетной записи в Outlook. Инструкции см. в статье Изменение параметров учетной записи электронной почты .
Сообщения по-прежнему не отправляются?
Вы изменили параметры SMTP в Outlook или нашли параметр, который разрешит вам отправлять почтовые сообщения. Но вы по-прежнему не можете отправить почту и получаете сообщение об ошибке.
Возможно, вы все сделали правильно, но администраторы сети используют еще какую-то функцию системы безопасности для предотвращения спуфинга удостоверений. Спуфинг удостоверений - это просто способ отправки почтового сообщения, при котором вы скрываете, кто вы.
В Outlook, как и в большинстве почтовых программ, можно указать "отображаемое имя" и обратный почтовый адрес, который появляется при ответе на ваше сообщение. В нежелательной почте эти поля почти всегда содержат ложную информацию. Вы правда верите, что сообщения о том, как быстро разбогатеть, пришли от супермодели или мирового лидера?
Чтобы предотвратить спуфинг удостоверений, некоторые поставщики интернет-услуг ограничивают возможность вставки ложной информации в поле адреса в ответах. Например, если доменное имя вашего поставщика интернет-услуг оканчивается на proseware.com, поставщик может запретить вам указывать обратный адрес [email protected] . Это ограничение используется не так широко, как описанные ранее, но может применяться ко всем пользователям независимо от их местонахождения и способа подключения. В этом случае альтернативы нет. Если администратор сервера использует этот способ, вы должны указывать в обратном адресе домен, соответствующий вашему текущему подключению.
Борьба со спамом - это головная боль всех ответственных администраторов почты. Чего только они не изобретают, чтобы любимым пользователям лучше жилось. Однако, как показала практика общения со многими системными администраторами, почему-то далеко не все представляют как правильно фильтровать спам.
Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности - контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.
А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.
Кстати: эта статья конечно ориентирована в первую очередь на администраторов, желающих сделать качественный фильтр спама. Однако с другой стороны она содержит очень важные сведения для тех, кому приходится просто работать с почтой, но кто плохо разбирается во всех тонкостях процесса электронной пересылки корреспонденции.
Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем - добро пожаловать под кат.
Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix
, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction
параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.
Немного об SMTP протоколе
Электронная почта имеет много аналогий с почтой обычной. Самое для нас главное сейчас то, что вся информация на электронном «конверте» представляет из себя всего лишь два адреса: получателя и отправителя, а также штампик почтальона, конверт доставившего.Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.
Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO , MAIL FROM и RCPT TO . То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем - адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.
Итак, что же надо делать, чтобы не принимать письма, заведомо являющиеся спамом? Пойдём по порядку.
Немного о DNS
Когда-то на заре Интернета почта доставлялась непосредственно на узлы, указанные в почтовом адресе. То есть для доставки письма для [email protected] почтовый сервер искал IP адрес domain.com и пытался послать посылочку по найденному IP. Потом появились MX записи, которые разом решили большинство проблем подобной организации почтового взаимодействия. Однако некоторые программы всё ещё могут работать с A записями при доставке почты. Но у вас, конечно, есть хотя бы одна MX запись для вашего домена, не так ли?MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей - Sender Policy Framework .
Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись
V=spf1 +mx -all
Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.
Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.
Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:
- Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP - обратно то же имя хоста.
- В качестве адреса в MX записи всегда должно стоять имя (не IP!) хоста, для которого существует A запись. То есть нельзя, чтобы в MX записи стоял IP или псевдоним (CNAME).
Если вы не соблюдёте одно из этих требований - приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены - то отправителю доверять не следует, а значит и принимать от него почту - тоже.
Ну а чтобы включить проверку PTR у себя, используйте опцию
Reject_unknown_client_hostname
Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.
Есть и менее жёсткое ограничение, задаваемое опцией
Reject_unknown_reverse_client_hostname
В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.
Проверяем приветствие
Итак, кто-то захотел передать вашему серверу письмо. Передача начинается с приветствия - заголовка HELO. В HELO должно быть указано полное доменное имя (FQDN) отправителя, соответственно если это не так - можете смело сразу же отказывать в принятии. В Postfix для этого служат две опции:Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая - от хостов, передающих не FQDN в HELO запросе.
Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция
Reject_unknown_helo_hostname
Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.
Отправитель - а стоит ли ему доверять?
Итак, сервер успешно вам представился, следующим пунктом программы идёт адрес отправителя. Из него тоже можно извлечь массу полезной информации. Сразу хочу заметить, что адрес отправителя вовсе не обязан быть из того же домена, что и сам сервер. Это распространённое заблуждение, поэтому имейте ввиду, что это не так. Один почтовый сервер спокойно может обслуживать несколько доменов.Однако если в адресе отправителя указан домен, который вовсе не существует, то письмо совершенно очевидно принимать не стоит. И уж точно не стоит принимать письмо, в котором в качестве обратного адреса указано нечто, вообще адресом не являющееся. За отказ в принятии для таких писем отвечают две опции:
Reject_non_fqdn_sender
reject_unknown_sender_domain
Первая - проверка адреса на написание, вторая - проверка существования домена.
Уже неплохо, но можно сделать кое-что ещё. Можно запросить сервер, обслуживающий указанный адрес отправителя, на предмет существования на нём пользователя с этим адресом. Действительно, вроде бы неплохая идея удостовериться в том, что обратный адрес действительно существует, иначе нам вполне может придти письмо от эфемерного фантома, о котором никто и не слыхивал.
Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.
За такую проверку обратного адреса отвечает опция
Reject_unverified_sender
Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны .
А получатель-то вообще существует?
Вот мы и дошли до последнего заголовка конверта - до получателя. Тут всё просто: во-первых, хорошо бы проверить, что переданная нам информация вообще является адресом электронной почты. Для этого служит директиваReject_non_fqdn_recipient
Кроме того нам бы не хотелось принимать почту на адреса, для которых у нас нет почтовых ящиков. Чтобы настроить такое поведение надо сначала создать список обслуживаемых ящиков, дальше рассказать о нём Postfix через один из *_recipient_maps параметров конфигурационного файла, ну а дальше либо воспользоваться параметром конфигурационного файла
Smtpd_reject_unlisted_recipient = yes
Либо запрещающей опцией, имеющей тот же эффект:
Reject_unlisted_recipient
В любом случае Postfix перестанет принимать письма для обслуживаемых доменов , если не существует ящика для получателя. Однако это ограничение никак не скажется на пересылке корреспонденции на адреса, которые не находятся в обслуживаемых доменах.
Ну и наконец можно вообще запретить открытую пересылку писем через ваш Postfix, оставив только возможность принимать письма на известные адреса. Для этих целей служит опция
Reject_unauth_destination
Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию). Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.
В качестве промежуточного итога
Вот так только на основе анализа трёх заголовков конверта можно отсеять огромное количество спама. Однако спамеры хитрые, поэтому этого всё же недостаточно.Грейлистинг
Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают - сервер временно недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто «упали» от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо.Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем при первом соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.
Блоклисты, или как делать не надо
Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) - чёрные списки узлов, замеченных в рассылке спама. Так вот, никогда не добавляйте никаких проверок DNSBL на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней - один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц.С ног на голову, или посмотрим с другой стороны баррикад
Фильтровать спам научились, теперь же я постараюсь свести воедино всю информацию на тему того, что же надо делать, что бы не попасть в спам.Для администраторов почтовых серверов:
- Всегда делайте MX записи ссылающимися на записи A.
- Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
- Хост из HELO заголовка должен иметь A или MX запись.
- Всегда создавайте SPF записи (да-да, это-то как раз не обязательно, но просто правило хорошего тона).
- Для всех писем, рассылаемых из обслуживаемого домена, ящик для обратного адреса должен существовать и принимать почту.
- Всегда посылайте почту только с существующим обратным адресом.
- Никогда не посылайте почту с неподконтрольного вам домена, не проверив правила SPF для него. Например gmail.com в текущий момент позволяет посылать письма от его имени любому серверу, а вот yandex.ru и mail.ru сообщают через SPF о том, что посылка от их имени со сторонних серверов должна вызывать на себя пристальное внимание, что истолковывается умными спамфильтрами как увеличение уровня оценки спама для данного письма.
- Никогда не посылайте почту через неправильно настроенные SMTP серверы. Проверить сервер на вшивость по списку выше - дело 5 минут, вам поможет утилита dig или nslookup .
Резюме
Конечно, предложенные настройки фильтруют не весь спам. Поэтому вполне возможно вам потребуется дополнительно использовать ещё и контекстный фильтр, который будет анализировать содержание писем, например,
Обзор Samsung Galaxy A7 (2017): не боится воды и экономии Стоит ли покупать samsung a7
Делаем бэкап прошивки на андроиде
Как настроить файл подкачки?
Установка режима совместимости в Windows
Резервное копирование и восстановление драйверов Windows