Стратегии защиты почтового трафика

Фишинг

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

Возможные маски фишинга:

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

Важно, чтобы системы защиты обладали следующим функционалом:

Во взаимодействии с электронной почтой важен здравый смысл. Не стоит отвечать, переходить по ссылкам и открывать вложения подозрительных писем.

Распознание фишинга возможно по следующим параметрам:

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

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

URL-адрес может выглядеть как знакомая ссылка. Например, с заменой одной буквы домена, чтобы заставить сотрудника думать, что URL-адрес является законным.

Настройка IP и DNS

Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR

Это основные требования для запуска собственного почтового сервера.

Публичный статический IP-адресIP-адрес почтового сервера должен быть общедоступным и постоянным во времени. Убедиться в этом можно у хостинг или Интернет-провайдера.
Доменное имя указывает на IPDNS-запись публичного доменного имени почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS провайдера доменного имени.
IP указывает на доменное имяСамое главное, обратная DNS-запись (именуемая PTR) должна указывать на доменное имя почтового сервера по IP-адресу. Можно попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его. Его можно легко проверить по IP-адресу онлайн (например, тут), или с помощью команды ‘nslookup’ в Windows и команды ‘host’ в системах на основе UNIX.

Настройка MX записи в DNS

Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.

Например, если наш домен — mycompany.com, почтовый сервер — mail.mycompany.com, то запись DNS для mycompany.com будет:

Type	Host	Value	Priority	TTL
MX	@	mail.mycompany.com	10	1 min

где:

Priority (приоритет) используется, когда в домене более одного почтового сервера.
TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при отладке настроек.

Настройка DKIM записи в DNS

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

Понадобятся приватный и открытый ключи. Их можно создать с помощью онлайн-инструментов, например Power DMARC Toolbox — DKIM Record Generator, или с помощью команд OpenSSL (приведен пример для Windows):

Создать приватный ключopenssl.exe genrsa -out private.key 2048
Создать публичный ключ из приватногоopenssl.exe rsa -in private.key -pubout -outform der 2>nul | openssl base64 -A > public.key.txt

И запись DNS будет выглядеть так:

Type	Host	Value	TTL
TXT	selector._domainkey	v=DKIM1; k=rsa; p=public_key	1 min

где:

selector — самостоятельно выбранный идентификатор (например, mysrv), который будет использоваться в приложении почтового сервера (смотрите ниже).
public_key — открытый ключ, закодированный алгоритмом base64 (содержимое public.key.txt).
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Настройка SPF записи в DNS

Инфраструктура политики отправителя (SPF) — это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.

Тут запись DNS будет выглядеть так:

Type	Host	Value	TTL
TXT	@	v=spf1 a mx include:relayer_name -all	1 min

где:

relayer_name — имя необязательного внешнего почтового сервера-ретранслятора (смотрите ниже). Если не нужно — убирается вместе с «include:».
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Можно использовать удобный онлайн-генератор записи SPF.

Дополнительные записи DNS

Некоторые поля не обязательны, но желательно иметь.

DMARCЗапись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.
BIMIИндикаторы бренда для идентификации сообщений (BIMI) — это новый стандарт, созданный для того, чтобы упростить отображение логотипа рядом с сообщением. Кроме того, BIMI предназначен для предотвращения мошеннических электронных писем и улучшения доставки.
TLS-RPTTLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.
MTA-STSСтрогая транспортная безопасность агента пересылки почты (MTA-STS) — это новый стандарт, направленный на повышение безопасности SMTP, позволяя доменным именам выбирать строгий режим безопасности транспортного уровня, требующий аутентификации и шифрования.

Все эти записи кроме MTA-STS могут быть созданы с помощью Power DMARC Toolbox. Конфигурация MTA-STS похожа на , также описывалась на habr, и, наконец, может быть проверена с помощью Hardenize.

Что такое протокол SMTP и для чего он нужен?

Компания Протокол SMTP (простой протокол передачи почты) или также известный как «Простой протокол передачи почты» — это протокол, который используется, когда мы собираемся отправить электронное письмо через почтовый сервер. Этот протокол используется локальными почтовыми клиентами для отправки сообщений электронной почты на удаленный почтовый сервер, поэтому он действует только в исходящем направлении, в отличие от протокола POP3, который используется для получения электронных писем, этот SMTP используется для их отправки.

Этот протокол относится к прикладному уровню модели TCP / IP, использует протокол транспортного уровня TCP и использует разные порты в зависимости от того, зашифрован трафик или нет:

TCP-порт 25 для незашифрованного трафика.
TCP-порт 465 для зашифрованного SSL-трафика (SMTPS).
TCP-порт 587 в качестве альтернативного порта для SMTPS с TLS.

В настоящее время подавляющее большинство поставщиков услуг электронной почты поддерживают SSL / TLS, чтобы зашифровать и защитить все данные, которые отправляются по электронной почте, поэтому мы почти всегда будем использовать порты 465 и 587, в зависимости от того, как работает почтовый сервер. настроен. Например, в случае Gmail нельзя использовать TCP-порт 25, потому что он не имеет какого-либо типа шифрования, однако он поддерживает как порт 465 для соединений SSL, так и порт 587 для соединений TLS.

Протокол SMTP специально ориентирован на отправку электронной почты в «восходящем» или исходящем направлении от локального почтового клиента к почтовому серверу, чтобы позже отправить его конечному получателю. Конечно, локальный почтовый клиент будет хранить эти письма в разделе отправленных писем, независимо от того, используем ли мы Thunderbird или Windows Outlook.

SMTP позволяет аутентифицировать пользователя / пароль в виде открытого текста с порта 25, но в настоящее время немногие службы поддерживают этот протокол без использования какого-либо типа шифрования с целью обеспечения конфиденциальности аутентификации, а также отправляемой электронной почты. В последних версиях SMTPS мы можем использовать порты 465 или 587 для шифрования данных, аутентичности и проверки целостности отправленных сообщений.

Работа и обмен сообщениями

Работа протокола SMTP довольно проста, первое, что нужно иметь в виду, это то, что SMTP — это текстовый протокол, ориентированный на соединение, следовательно, это надежный протокол при использовании протокола транспортного уровня TCP. Почтовый клиент взаимодействует с сервером через серию сценариев для аутентификации, отправки сообщений и закрытия соединения, конечно же, почтовый сервер также ответит серией последовательностей команд в качестве ответа. В один и тот же сеанс SMTP может быть включено ноль или более транзакций, в каждой из этих транзакций у нас будет всего три сценария / ответа, которые:

ПОЧТА: устанавливает обратный адрес.
RCPT: устанавливает получателя сообщения, может выдаваться несколько раз в зависимости от количества получателей.
ДАННЫЕ: текстовое сообщение электронного письма, то есть его содержание. Он состоит из заголовка и тела сообщения.

После того, как мы правильно настроим почтовый клиент, электронное письмо будет написано непосредственно в самом почтовом клиенте, при нажатии кнопки «Отправить» начинается весь процесс:

Клиент установит соединение с SMTP-сервером, ожидая ответа от HELO для получения идентификатора сервера.
Клиент начинает общение с помощью команды MAIL FROM с адресом электронной почты, затем сервер проверяет правильность происхождения.
Клиент отправит сообщение RCPT TO, включающее адрес электронной почты получателя, в зависимости от получателей, у нас будет одно или несколько сообщений RCPT TO. Затем отправляется команда DATA, чтобы указать, что текст сообщения поступает построчно.
Если клиент больше не собирается отправлять электронные письма, он отправит команду QUIT для завершения сеанса SMTP.
В случае последующей отправки электронного письма весь процесс начнется заново.

Как только мы узнаем, что такое SMTP и как он работает, мы собираемся показать вам, как легко настроить его для отправки электронных писем через почтовый клиент, такой как Thunderbird или любой другой.

Ограничения, которые воздействуют на всю SMTP почту

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

Встроенные ограничения по содержимому (проверки заголовка) и (проверки содержимого письма), которые описаны в документе BUILTIN_FILTER_README. Эти проверки производятся во время приема почты, до помещения письма в очередь входящих сообщений ().
Внешняя (посредством сторонних программ) проверка содержимого до помещения в очередь, которая описана в документе SMTPD_PROXY_README . Эта проверка выполняется во время приема почты, до помещения письма в очередь входящих сообщений ().
Требование к клиентам отсылать команду HELO или EHLO перед использованием команды MAIL FROM или ETRN. Это может вызвать проблемы при работе с «доморощенными» почтовыми клиентами. По этой причине ограничение отключено по умолчанию (» = no»).
Запрет некорректного синтаксиса в командах MAIL FROM или RCPT TO. Это может вызвать проблемы при работе с «доморощенными» или древними почтовыми клиентами. По этой причине требование отключено по умолчанию (» = no»).

Запрет использования синтаксиса адресов RFC 822 (пример: «MAIL FROM: the dude <[email protected]>»).
Запрет использования адресов, которые не заключены в угловые скобки <> (пример: «MAIL FROM: [email protected]»).
Отклонение писем с несуществующим адресом отправителя. Эта форма фильтрации «на входе» может помочь в борьбе с «червями» и спамерами, но может вызвать проблемы при работе с «доморощенными» почтовыми клиентами, которые отсылают письма с несуществующим адресом отправителя. По этой причине данной ограничение отключено по умолчанию (» = no»).
Отклонение писем с несуществующим адресом получателя. Эта форма фильтрации «на входе» помогает содержать почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены. Это ограничение включено по умолчанию (» = yes»).

Практика и еще раз практика

В практической части мы рассмотрим конфигурирование описанных выше настроек безопасности на примере двух наиболее популярных почтовых серверов — опенсорсного Postfix на Debian (ну, или Ubuntu Server) и проприетарного Microsoft Exchange Server 2013+. Предполагается, что почтовые серверы у тебя уже установлены и настроены под твой домен, поэтому рассматривать будем только само конфигурирование фич на обезличенных данных.

Настраиваем SPF, DKIM и DMARC на Postfix (Debian)

Общий принцип работы нашего почтового сервера будет таков:

Принимающий сервер получает письмо с адреса [email protected], отправленное с сервера mx.example.com.
Сервер получателя делает запрос к DNS для домена example.com и ищет записи SPF и DKIM.
В случае если записей нет, письму проставляется статус neutral (конкретно по этим проверкам) и письмо проверяется дополнительными фильтрами.
В случае если записи обнаружены, проверяется, разрешено ли серверу mx.example.com отправлять почту домена example.com.
Если домен mx.example.com не найден в списке разрешенных, то или письмо отбрасывается, или ему устанавливается статус neutral.
Если домен mx.example.com таки найден в списке разрешенных, письму устанавливается статус Pass и повышается его рейтинг при прохождении других фильтров.

Ну что, погнали!

WARNING

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

Настройка SPF-записи

Если ты отправляешь все сообщения только с одного сервера (почтовые клиенты не считаются), то в SPF-записи будет достаточно указать IP-адрес этого сервера:

Описание опций:

— используемая версия SPF;
— принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. То есть, если никаких параметров не установлено, это автоматически ;
— отклонить (Fail);
— отклонение (SoftFail). Письмо будет принято, но будет помечено как спам;
— нейтральное отношение, то есть никаких действий не предпринимать;
— включает в себя все адреса серверов, указанные в MX-записях домена;
— опция позволяет указать конкретный IP-адрес или подсеть IP-адресов;
— указываем поведение в случае получения письма от конкретного домена;
— включает в себя хосты, разрешенные SPF-записью указанного домена;
— все остальные серверы, не перечисленные в SPF-записи.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

А получатель-то вообще существует?

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

reject_non_fqdn_recipient

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

smtpd_reject_unlisted_recipient = yes

Либо запрещающей опцией, имеющей тот же эффект:

reject_unlisted_recipient

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

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

reject_unauth_destination

Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию или добавить нечто вроде permit_mynetworks).

Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.

Немного о DNS

Когда-то на заре Интернета почта доставлялась непосредственно на узлы, указанные в почтовом адресе. То есть для доставки письма для [email protected] почтовый сервер искал IP адрес domain.com и пытался послать посылочку по найденному IP. Потом появились MX записи, которые разом решили большинство проблем подобной организации почтового взаимодействия. Однако некоторые программы всё ещё могут работать с A записями при доставке почты. Но у вас, конечно, есть хотя бы одна MX запись для вашего домена, не так ли?

MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей — Sender Policy Framework.

Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись

v=spf1 +mx ~all

Учтите, что письма могут идти через ретрансляторы. Многие почтовые домены в интернете являются всего лишь ретрансляторами. Поэтому жёсткий запрет в SPF записях, а так же отсеивание спама только исходя из SPF информации, являются крайне нежелательными. Однако всё же всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах.

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

Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.

Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:

Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
В качестве адреса в MX записи всегда должно стоять имя (не IP!) хоста, для которого существует A запись. То есть нельзя, чтобы в MX записи стоял IP или псевдоним (CNAME).

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

Подключаем SASL с авторизацией через sasldb ¶

SASL — это программный интерфейс, который позволяет в упрощённом режиме идентифицировать пользователей по логину и паролю.

Устанавливаем SASL:

Создаём конфиг:

Добавляем пользователя в sasldb:

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

Включаем авторизацию SASL в POSTFIX:

Так как база sasldb это обычный файл, а SMTPD по умолчанию запускается в chroot, то каждый раз после добавления или
изменения пользователя нужно выполнять перезапуск POSTFIX (чтобы нужные файлы скопировались):

Вместо sasldb можно ,
но это сложнее и по умолчанию работает с системными пользователями, что не очень удобно.

Безопасность

Закрываем доступ к папке POSTFIX’а, чтобы не было соблазна украсть базу пользователей sasldb:

Включение шифрования SMTP

Теперь вы можете включить шифрование SMTP, запросив бесплатный сертификат TLS от Let’s Encrypt для вашего домена (с помощью Certbot) и настроив Postfix для использования этого сертификата при отправке сообщений.

Certbot содержится в стандартном репозитории пакетов Ubuntu, но там может находиться не самая актуальная версия. Лучше использовать следующую команду для добавления официального репозитория:

Нажмите в диалоге для подтверждения. Обновите кэш диспетчера пакетов вашего сервера.

Установите последнюю версию Certbot:

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

Итоговый результат будет выглядеть следующим образом:

Теперь порт открыт, и мы можем запустить Certbot для получения сертификата:

Эта команда предписывает Certbot выдавать сертификаты с размером ключа RSA 4096 бит, запустить временный отдельный веб-сервер () для проверки и выполнить проверку через порт (). Перед запуском команды обязательно замените именем вашего домена и введите свой адрес электронной почты, когда система его запросит.

Результат будет выглядеть примерно следующим образом:

Как указано в примечаниях, ваши сертификат и файл закрытого ключа сохранены в каталоге .

Получив сертификат, откройте файл для редактирования:

Найдите следующий раздел: /etc/postfix/main.cf

Измените файл следующим образом, заменяя на ваше доменное имя, где это необходимо. При этом также будут изменены ваши настройки TLS для Postfix: /etc/postfix/main.cf

Закончив, сохраните и закройте файл.

Перезапустите Postfix, чтобы применить изменения:

Попробуйте отправить электронное письмо еще раз:

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

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

1. Как SSL / TLS защищают электронную почту

Secure Sockets Layer (SSL) и его преемник, Transport Layer Security (TLS), являются наиболее распространенными протоколами безопасности электронной почты, которые защищают вашу электронную почту во время ее перемещения через Интернет.

SSL и TLS являются протоколами прикладного уровня. В сетях интернет-связи прикладной уровень стандартизирует связь для услуг конечного пользователя. В этом случае прикладной уровень обеспечивает инфраструктуру безопасности (набор правил), которая работает с SMTP (также протоколом прикладного уровня) для защиты вашей электронной почты.

Далее в этом разделе статьи обсуждается TLS, так как его предшественник SSL полностью устарел в 2015 году.

TLS обеспечивает дополнительную конфиденциальность и безопасность для общения компьютерных программ. В этом случае TLS обеспечивает безопасность для SMTP.

Когда ваш почтовый клиент отправляет и получает сообщение, он использует протокол управления передачей (TCP — часть транспортного уровня, а ваш почтовый клиент использует его для соединения с почтовым сервером), чтобы инициировать «рукопожатие» с почтовым сервером.

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

Клиент отправляет «привет», типы шифрования и совместимые версии TLS на сервер электронной почты.
Сервер отвечает сервером TLS Digital Certificate и открытым ключом шифрования сервера.
Клиент проверяет информацию сертификата.
Клиент генерирует Общий секретный ключ (также известный как Pre-Master Key), используя открытый ключ сервера, и отправляет его на сервер.
Сервер расшифровывает секретный общий ключ.
Клиент и сервер теперь могут использовать секретный общий ключ для шифрования передачи данных, в данном случае, вашей электронной почты.

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

Оппортунистический TLS и Принудительный TLS

Оппортунистический TLS — это команда протокола, которая сообщает серверу электронной почты, что почтовый клиент хочет превратить существующее соединение в безопасное соединение TLS.

Время от времени ваш почтовый клиент будет использовать простое текстовое соединение вместо того, чтобы следовать вышеупомянутому процессу рукопожатия, чтобы создать безопасное соединение. Оппортунистический TLS попытается запустить рукопожатие TLS для создания туннеля. Однако в случае сбоя процесса рукопожатия Opportunistic TLS будет использовать простое текстовое соединение и отправлять электронную почту без шифрования.

Принудительный TLS — это конфигурация протокола, которая заставляет все транзакции электронной почты использовать стандарт безопасного TLS. Если электронная почта не может пройти от почтового клиента до почтового сервера, то для получателя электронной почты сообщение не будет отправлено .

IMAP

Протокол прикладного уровня для доступа к электронной почте IMAP используется многими почтовыми клиентами по умолчанию как более продвинутый, нежели POP3. Служит для приема и сортировки почтовых данных, в отличие от POP3, протокол не предусматривает хранение электронных писем на конечном устройстве, вместо этого данные всегда загружаются непосредственно с сервера при каждом просмотре почты пользователем. Опционально протокол поддерживает также и отправку почты с помощью команды APPEND, но поскольку команда не обеспечивает должного уровня безопасности, применения она не нашла.

Отправка почты наружу

Для отправки почты на другие почтовые серверы необходимо правильно сконфигурировать сервер, чтобы письма не попадали в СПАМ. Чтобы это сделать, выполняем инструкции ниже.

Настройки DNS для сервера

Многие почтовые серверы делают запросы в систему доменных имен для проверки легитимности почтового сервера, отправляющего почту

При настройке MTA очень важно правильно добавить необходимые записи в DNS

1. rDNS. Обратная зона используется для проверки соответствия имени сервера в приветствии с именем, которое возвращает NS сервер при запросе по PTR-записи.

И так, для создания записи в обратной зоне, необходимо написать письмо Интернет провайдеру, к сети которого подключен сервер или хостеру, если почтовый сервер настроен на VPS. IP-адрес нашего сервера должен вести на имя, которым приветствуется наш postfix — можно посмотреть командой:

postconf -n smtpd_banner

Если мы получим пустой ответ, то вводим:

postconf -n myhostname

Если и в этот вариант не вернет ответ, вводим:

hostname

2. А-запись. Также необходимо, чтобы имя сервера, которым представляется почтовый сервер разрешалось в IP-адрес.

Для этого заходим в консоль управления зоной нашего домена и создаем запись типа А для сопоставления имени сервера с IP-адресом, на котором слушает запросы данный сервер.

VRFY

Команда VRFY является сокращением от verify (англ. проверить — Прим. пер.). Ее можно использовать для определения возможности доставки сервером почты определенному получателю перед выполнением команды RCPT. Формат этой команды следующий:

VRFY username

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

Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты. Как администратор почтовой системы вы, можете проверить работоспособность адресов электронной почты двумя путями. Во-первых, с помощью команды DNS host, которая позволяет определить правильность доменного имени и наличие почтового сервера, обслуживающего домен. И во-вторых, можно зайти с помощью telnet на порт 25 почтового сервера и затем задать команду VRFY, которая определит правильность имени пользователя. В листинге 5.3 показан пример использования команды VRFY для проверки имен пользователей.

1 riley@shadrach riley$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.38.9.3; Thu, 26 Aug 1999 19:20:16 -050
6 HELO localhost
7 250 shadrach.smallorg.org Hello localhost 127.0.0.1, pleased to meet you
8 VRFY rich
9 250 <rich@shadrach,smallorg.org>
10 VRFY [email protected]
11 252 <[email protected]>
12 VRFY jessica
13 550 jessica... User unknown
14 QUIT
15 221 shadrach.smallorg.org closing connection
16 Connection closed by -foreign host.
17 riley@shadrach riley$

В строках 8–13 представлены результаты выполнения команды VRFY. В строке 8 делается попытка выполнить VRFY для локального пользователя rich. Ответ SMTP- сервера в строке 9 подтверждает, что пользователь с таким именем имеется в системе, и клиенту возвращается его полный адрес электронной почты. В строке 10 показан еще один вариант задания команды VRFY. Здесь клиент пытается выполнить команду VRFY для пользователя на удаленном компьютере. Ответ, полученный в строке 11 от системы shadrach, отличается от результата, полученного в строке 9. В разделе «Ответы сервера» значения кодов, возвращаемых сервером, обсуждаются более детально. В нашем случае отметим, что система shadrach уведомляет клиента о том, что почта будет пересылаться пользователю prez на удаленном сервере meshach.smallorg.org. Строка 12 отображает попытку проверить несуществующее имя в системе meshach. Ответ SMTP-сервера в строке 13 в пояснениях не нуждается.

Проверить существования пользователя используя Основы BASH скрипты, циклы, горячие клавиши и curl.$ echo -e «VRFY [email protected]\n QUIT» | curl telnet://mail.example.com:25
220 mail.1-talk.com ESMTP Postfix
252 2.0.0 [email protected]
221 2.0.0 Bye