Электронная почта: особенности работы серверов ООО КРАФТ-С
Only Russian text available, sorry. You can use http://translate.google.com/ or http://translate.ya.com/ for translate it.
Преамбула. Так как абонентская почтовая система обслуживает множество клиентов, пожелания всех учесть не просто. Многое либо нельзя, либо сложно сделать индивидуально, и про это следует помнить. Полностью индивидуальные пожелания можно реализовать только на собственном почтовом сервере. Кроме того, следует заметить, что поведение других почтовых серверов, если оно выходит за рамки принятых стандартов, не может служить примером полного подражания. Это уточнение, в основном, касается методик и принципов борьбы со спамом.
Есть три основных процесса: приём сообщений почтовым сервером (SMTP) и помещение в ящик, передача сообщений клиенту (POP3 и IMAP4), приём сообщений от клиента для последующей отправки (SMTP). Данная статья описывает некоторые принципы выполнения этих процессов на почтовых серверах ООО КРАФТ-С. Описание первого процесса должно быть интересно тем, кто отсылает почту на наши сервера, описание второго и третьего процесса - нашим абонентам.
Приём сообщений почтовым сервером в ящик пользователя.
Приём сообщений может быть невозможен в силу технических или административных проблем, либо в силу классификации входящих сообщений, как спам. В случае отказа в приёме передающий почтовый сервер (сервер отправителя) обязан сформировать отправителю соответствующее уведомление, которое содержит ответ нашего сервера. Если отправитель не получает такого уведомления, это означает какую-то проблему на стороне самого отправителя (например с envelope from), либо проблему на сервере отправителя. Единственное исключение - это если наш пользователь сам настроил reject средствами Sieve, а, опять же, у отправителя неверно указан envelope from. Только в этом случае уведомление должен формировать наш сервер, но он не сможет его доставить. Если же уведомление приходит, то там есть то, или иное пояснение. Ввиду того, что Интернет - международная система, используется английский язык, однако фразы построены так, чтобы переводчики translate.ya.ru и translate.google.ru переводили сообщения об ошибках достаточно точно. Некоторые сообщения об ошибках содержат ссылки на более подробное пояснение, уже, в том числе, и на русском языке. Если причина из сообщения об ошибке отправителю непонятна, отправителю следует проконсультироваться, в первую очередь, у своего провайдера, или у своего ИТ-специалиста. Если вести речь о запрете приёма сообщений со стороны спам-фильтра, то описывать все нюансы принятия решения о приёме сообщения не представляется целесообразным, так как получится инструкция для спаммеров (следует уточнить только то, что процесс этот многоступенчатый, его результатом может быть пометка сообщения как спам, либо отказ в приёме, в зависимости от сработавших правил).
Если просле прочтения выше и ниже написанного у Вас остались вопросы, и Вы не можете задать вопрос на E-Mail support@kraft-s.ru из-за ниже описанных ошибок, Вы можете задать вопрос в группе kraft.support на nntp-сервере news.kraft-s.ru.
Далее - частичное описание некоторых сообщений об ошибках.
550 5.1.0 E-mail < name@example.com > hasn't been confirmed by its MX
Представлен фрагмент сообщения об ошибке, полное сообщение содержит какое-либо из дополнительных пояснений. Если почтовый сервер отправителя поддерживает многострочные ответы, то могут быть видимы и другие подробности (например, ответ сервера отправителя), в противном случае сервер отправителя отобразит только с последнюю строку многострочного ответа. Ошибка означает то, что не прошёл проверку E-Mail, указанный в envelope from. Отдельно следует упомянуть вариант
550-5.1.0 E-mail name@example.com hasn't been confirmed by its MX, data has been cached in a previous attempt.
550 5.1.0 Cache time 3600 sec since first attempt. Check a previous reject.
Это полный многострочный ответ сервера. Означает это то, что где-то в пределах часа произошла безуспешная проверка, и данные были закэшированы. Негативные ответы наши сервера кэшируют на час, ранее истечения этого срока повторное сообщение с таким обратным E-Mail не пройдёт, а истинную причину надо смотреть в первой ошибке за обозначенный интервал времени. К сожалению, возможность отображения исходной ошибки для закэшированного события, в данном случае, не поддерживается.
Примечание. Если принимающий почтовый сервер попадает в какой-нибудь чёрный список, а сервер отправителя этот чёрный список использует в качестве единственного критерия для блокировки, почта от такого сервера не будет принята. Известная ситуация - чёрный список backscatterer.org, организаторы которого считают основанием для размещения в том числе smtp callback.
450 4.4.1 E-mail < name@example.com > hasn't been confirmed by its MX
Аналогично предыдущей ошибке, только диагностирована временная ошибка. Как правило, это "MX does not respond", но может быть и что-то иное. Обычный пользователь увидит эту ошибку только в том случае, если E-Mail находится в очереди на отправку несколько часов.
550-5.5.2 SPF1 check failed: permanent error occurred.
550 5.5.2 You must check the SPF1-record of your domain @example.com for compliance it to RFC 7208
Данное сообщение означает, что в SPF-записи домена допущена ошибка, которая, согласно RFC 7208, должна трактоваться, как постоянная. Владельцу домена следует устранить данную проблему: если SPF-запись вообще используется, её следует писать правильно. При этом, отсутствие SPF-записи не оказывает на серверах компании ни положительного, ни отрицательного влияния. Самая распространённая ошибка на текущий момент - наличие более одной SPF1 записи. RFC 7208 предписывает иметь только одну запись такого вида (записей SPF2.0 может быть больше, но это предмет другого RFC, который имеет пока статус экспериментального; у нас 2.0 не проверяется). На втором месте обычные синтаксические ошибки из-за невнимательности. Встречается ошибка в виде использования несуществующих имён (иногда из-за опечаток: "v=spf1 include:_netblocks.goole.com ~all"). Стоит упомянуть, что несколько раз попадались ошибки в виде превышения глубины вложенности записей, хотя они не являются безусловно фатальными (лишнее просто игнорируется). Следует помнить, что система доменных имён инертна, и исправление TXT-записи не становится доступно мгновенно. Отдельно про "ptr:..." в SPF. Это, пока, не является ошибкой, однако не рекомендовано к использованию. В Интернет можно найти сайты, предоставляющие сервис проверки SPF-записи, например https://dmarcian.com/spf-survey/.
451-4.4.2 SPF1 check failed: temporary error occurred.
451 4.4.2 Possible DNS failure for domain example.com. You should check your DNS servers and SPF1-record.
Данное сообщение означает, что при проверке SPF1-записи произошла ошибка, трактуемая, как временная. Это может быть ошибка в самой записи, которая, согласно RFC 7208, трактуется, как временная, но, чаще, это означает наличие каких-либо проблем на одном, или нескольких DNS, на которых расположена зона (домен).
554 5.7.0 Spam detected by Spamassassin
Ошибка означает, что, во-первых, Ваш сервер не удовлетворяет общепринятым настройкам почтовых серверов: в случае полностью корректных настроек контент-фильтр Spamassassin на серверах компании не используется в настоящий момент. Во-вторых, Ваше сообщение распознано, как спам, причём с большой степенью вероятности. Используется два пороговых значения спам-рейтинга, при достижении первого порога сообщение только помечается, при достижении второго — не принимается.
451 4.7.0 You are greylisted for 600 seconds
Как и ошибка, связанная со Spamassassin, эта ошибка, в случае серверов ООО КРАФТ-С, означает наличие проблем в настройках почтового сервера отправителя. Обычный пользователь эту ошибку не увидит, увидеть её может только администратор почтового сервера. Для пользователя её наличие будет проявляться в задержке доставки сообщения на время 600 секунд и более (в зависимости от интервала обработки отложенной очереди на сервере отправителя).
550 5.1.1 < example@samaramail.ru >... User unknown or mailbox full
Ошибка не имеет отношения к проверке на спам, но упомянута тут ввиду неоднозначности. К сожалению, используемое программное обеспечение не предоставляет возможность разделить переполнение ящика и его отсутствие. Об окончательной причине придётся догадываться отправителю. Вероятно, проблема неточной идентификации ошибки будет устранена в будущем.
Одной из распространённых ошибок является попытка почистить ящик, с которым работали по протоколу IMAP, используя протокол POP. Подробности в разделе "Передача сообщений клиенту".
Пояснение по списку и доступности MX.
Список MX доменов может вызывать некоторые вопросы.
$ host -t mx sama.ru
sama.ru mail is handled by 10 mx.kraft-s.net.
sama.ru mail is handled by 20 mx-internal.sama.ru.
sama.ru mail is handled by 30 mx-backup.kraft-s.net.
MX-ы с приоритетами 10 и 30, фактически, одно и то же. Сделано это вот для чего. MX с приоритетом 20 работает только со списком доверенных сетей. Из-за этого, в случае возникновения на основном MX временной ошибки (любая 4xx, например, из описанных выше), в журнале почтового сервера и в уведомлении отправителю отобразится сообщение об ошибке, сформированное из-за недоступности MX 20, что не отразит реальную проблему. По-этому, третьим в списке снова указан основной MX (для удобства чтения журналов, с другим именем).
Передача сообщений клиенту.
Клиенты забирают сообщения по протоколам IMAP4 и POP3. В качестве имён могут использоваться mail.*, pop.*, pop3.*, imap.*, imap4.* (где * соответствует почтовому домену клиента). Принципиальных различий в именах на текущий момент нет, всё определяется выбранным протоколом. Имеется возможность использовать Sieve на стороне сервера. Следует помнить, что протокол POP3 работает только с INBOX
и не отображает сообщения в папках, если таковые были созданы ранее
посредством работы с ящиком по протоколу IMAP4. Сервер может
предоставить доступ к отдельно взятой папке по POP3, если использовать
конструкцию вида "имя+папка@домен" в качестве имени пользователя. Ниже описаны некоторые возникающие ошибки.
Logins must be at least 2 minutes apart (только POP)
Ввиду того, что частое соединение по протоколу POP создаёт излишнюю нагрузку на сервер, имеется ограничение на интервал проверки в 2 минуты. Для человека сделано исключение в виде возможности сделать несколько (десятков) попыток подряд, то есть, блокировка срабатывает не сразу. Счётчик попыток очищается по одной за установленный интервал. Чтобы иметь возможность снова сделать несколько попыток подряд надо некоторое время проверять ящик с интервалом, превышающим установленный.
Too many open connections (1 of 20 from example.com [10.1.1.1], 11 of 11 for name@example.com)
Сервер имеет ограничение по количеству одновременных соединений как с одного хоста, так и под одним именем пользователя с разных хостов. В данном примере ограничение по соединениям для example.com не достигнуто, однако достигнут лимит количества соединений для имени name@example.com с каких-то других хостов. Одной из причин возникновения проблемы может быть попытка работы с ящиком с из нестабильной сети (например мобильной). При этом, временно (до истечения лимита времени на неактивность), будет заблокировано соединение и из стабильной сети.
Существует ресурс webmail.kraft-s.ru, являющийся веб-версией IMAP клиента. Имеется возможность управлять правилами Sieve на сервере. Доступ к ресурсу webmail предоставляется по принципу "как есть", без гарантий его поддержки и работоспособности; ресурс использует самоподписанный сертификат, веб-браузер будет выдавать соответствующее предупреждение. По сути, это программное обеспечение Roundcube, которое можно установить самостоятельно на любом собственном веб-сервере и настроить для работы с любым IMAP-сервером.
Приём сообщений от клиента для последующей отправки.
Для отпавки сообщений рекомендуется использовать имя сервера вида smtp.* (где * соответствует почтовому домену клиента). Кроме порта 25, допустимо использовать порт 587. Существует два идентично настроенных сервера для отправки: relay1.hippo.ru и relay2.hippo.ru. Имена вида smtp.* обычно являются синонимами сервера relay1, но могут быть перенаправлены в случае необходимости на relay2.
Несмотря на то, что отправить из сетей ООО "КРАФТ-С" можно через любой сервер компании, связанный с абонентской электронной почтой, только smtp.* (relay1 и relay2) оптимизированы на отправку, а не на приём сообщений. И только при их использовании может быть использована отправка с авторизацией из чужих сетей. При настройке авторизации в качестве имени пользователя следует использовать полный E-Mail.
В экспериментальных целях имеется имя relay.hippo.ru, указывающее на оба сервера. Механизм DNS предусматривает псевдо-случайную выдачу IP-адресов по имени, если IP-адресов более одного. Таким образом, если использовать relay.hippo.ru, то отправка будет производиться случайным образом (с поправкой на кэширование данных DNS операционной системой пользователя) через оба сервера. Это может иметь некоторый смысл в случае проблем с одним из серверов relayN - от случая к случаю сообщения будут отправляться без дополнительных перенастроек. Хотя может быть удобнее просто указать другой сервер.
Так же, как и при приёме в ящик, может возникать ошибка
550-5.1.0 E-mail name@example.com hasn't been confirmed by its MX, data has been cached in a previous attempt.
550 5.1.0 Cache time 600 sec since first attempt. Check a previous reject.
Как видно из этого сообщения, время кэширования негативного ответа тут уменьшено до 600 секунд, в отличие от MX. Как правило, в данном случае, она связана с переполнением ящика клиента, который указывается в envelope from.
550 5.7.1 < name@example.com >... Relaying denied. IP name lookup failed [10.11.12.13]
Передача сообщения запрещена. В качестве причины указано отсутствие обратного имени у IP-адреса, однако его наличие ситуацию, в общем случае, не исправит. Просто это последняя проверка в цепочке других проверок на возможность приёма от Вас сообщения для дальнейшей ретрансляции, и это значит, что Вы не прошли ни одну из них. Как правило, это происходит в ситуации, когда Вы пытаетесь отправить сообщение не из наших сетей и не используете SMTP-авторизацию.
550 5.7.1 < name@example.com >... Relaying denied. IP name possibly forged [10.11.12.13]
То же самое, что и предыдущая ошибка. Отличие в том, что обратное имя есть, но не описано в прямой зоне.
550 5.7.1 < name@example.com >... Relaying denied. Proper authentication required.
Третий вариант сообщения финальной проверки. Отличие в том, что тут с обратным именем всё в порядке.
421 4.3.2 Too many open connections.
На серверах ограничено количество одновременных соединений с источниками сообщений. Для серверов, предназначенных для отправки сообщений, это ограничение составляет, на данный момент, 15. Если Вы увидели такое сообщение, имеет смысл понять причину. В подавляющем большинстве случаев это бывает вызвано попыткой рассылки спама посредством зараженного компьютера, но бывают и исключения. В случае обращения в службу поддержки сообщайте Ваш IP-адрес и время попытки. На данном этапе идентификация попытки по E-Mail не возможна.
421 4.3.2 Connection rate limit exceeded.
Кроме ограничения на количество одновременных сессий, существует и лимит на количество сообщений (точнее, попыток соединения с сервером) во временно́е окно (1 минута). На текущий момент лимит, так же, 15. Превышение количества попыток соединения может означать рассылку спама, так же, как превышение количества соединений. Если проблема не является обычной, следует проверить свои устройства. Идентификация попытки по E-Mail не возможна, как и в прдыдущем случае.
Примеры.
В разное время проблемы с электронной почтой были замечены у Apple, Nestle, Philips, AliExpress. Аргумент в виде "почта ходит на Google" и т.п. уместен мало, так как у нас просто отличаются принципы фильтрации. К примеру Google, в основном, использует контент-фильтрацию, пользуясь огромным объёмом материала, обращая мало внимания на повреждённую SPF-запись, и т.п. Далее будут примеры, зафиксированные на момент их публикации. В момент прочтения этого текста ситуация может быть уже исправлена.
1. Sony Mobile, 07.02.2017. E-Mail: questions.ru@support.sonymobile.com. Уведомление направлено.
$ host -t mx support.sonymobile.com
support.sonymobile.com mail is handled by 10 seldrele01.se.extranet.sonyericsson.com.
support.sonymobile.com mail is handled by 20 jptorele01.jp.extranet.sonyericsson.com.
support.sonymobile.com mail is handled by 5 seldsegame01.se.extranet.sonyericsson.com.
$ telnet seldsegame01.se.extranet.sonyericsson.com 25
Trying 37.139.156.28...
Connected to seldsegame01.se.extranet.sonyericsson.com.
Escape character is '^]'.
220 seldsegame01.se.extranet.sonyericsson.com ESMTP Ready
helo mx1.kraft-s.net
250 seldsegame01.se.extranet.sonyericsson.com Hello mx1.kraft-s.net (213.156.192.51)
mail from:<>
250 sender ok <>
rcpt to:< questions.ru@support.sonymobile.com >
550 Invalid - Please check envelope-address format for or questions.ru@support.sonymobile.com.
Нарушение документов: RFC 821 (он же часть STD 10), RFC 2821, RFC 5321
В документе RFC 1123 (он же часть STD 3) написано открытым текстом:
5.2.9 Command Syntax: RFC-821 Section 4.1.2
The syntax shown in RFC-821 for the MAIL FROM: command omits
the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
15). An empty reverse path MUST be supported.
Что должен был видеть отправитель:
550-5.1.0 Your MX replied "550 Invalid - Please check envelope-address format for or questions.ru@support.sonymobile.com.
550 5.1.0 E-mail < questions.ru@support.sonymobile.com > from host [37.139.156.25] hasn't been confirmed by its MX "seldsegame01.se.extranet.sonyericsson.com"
Итог: не проходит проверка smtp callback.
|
