2.1. Ограничения на использование почтовых трансляторов
Несанкционированное использование хоста в качестве почтового транслятора (Mail Relay) означает кражу ресурсов транслятора и подвергает риску репутацию владельцев такого транслятора. Может также оказаться невозможным отфильтровать или заблокировать спам без одновременного блокирования легитимной почты.
Следовательно, агент MTA должен обеспечивать контроль за использованием транслятора и возможность отказа в доступе к нему.
В сессии SMTP мы имеем 4 элемента с разным уровнем доверия к каждому из них:
- "HELO Hostname" — легко и часто подменяется.
- "MAIL From:" — легко и часто подменяется.
- "RCPT To:" — корректное или, по крайней мере, намеренно заданное значение.
- SMTP_Caller (хост) — IP-адрес отправителя (нормально), FQDN (может быть нормально).
Поскольку 1. и 2. легко подменить и это часто происходит, мы не может полагаться на эти параметры для проверки полномочий (авторизации) при использовании нашего хоста в качестве почтового транслятора.
Агент MTA должен быть способен контролировать доступ к функциям почтового транслятора на основе комбинации:
- "RCPT To:" адрес (домен).
- SMTP_Caller FQDN-имя хоста.
- SMTP_Caller IP-адрес.
Предлагается следующий алгоритм проверки:
- a) Если "RCPT To:" содержит один из «наших» доменов, локальное доменное имя или имя домена, для которого мы обеспечиваем пересылку почты (дополнительный MX), доступ к транслятору разрешается (Relay).
- b) Если SMTP_Caller проверен по IP-адресу отправителя или FQDN (зависит от уровня доверия к DNS), доступ к транслятору разрешается (Relay).
- c) Доступ к транслятору не разрешается.
При выполнении п. a) нужно быть уверенным, что все типы SMTP source routing (официальные [@a,@b:[email protected] ], с помощью '%' и пути uucp '!') полностью удалены до выполнения проверки или, по крайней мере, принимаются во внимание при проверке.
Сайт, реализующий такую проверку, должен осознавать, что он может блокировать корректно адресованные сообщения, особенно в тех случаях, когда они исходят от систем, работающих по отличному от SMTP протоколу, или направлены в такие системы. До реализации такого правила следует аккуратно убедиться в том, что приняты во внимание все используемые алгоритмы маршрутизации почты, другие почтовые системы и иные специальные случаи. Каждая из таких систем может потребовать выполнения специальных мер.
Примером подобной почтовой системы может служить X.400 с ее адресами типа:
"/c=us/admd= /prmd=xyz/dd.html-822=user(a)final/"@x400-gateway
Другим примером является DECnet MAIL-11, которая использует адреса в форме:
"gateway::smtp%\"[email protected] \""@mail-11-gateway
Во всех случаях конфигурация должна поддерживать шаблоны для FQDN и классы адресов IP, следует также поддерживать форму "адрес/маска" для бесклассовых адресов IP. Примерами могут служить domain.example и *.domain.example; 10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.
Конфигурации следует позволять получение шаблонов и данных для принятия решений из внешних источников (например, из текстового файла или базы данных). Следует поддерживать возможность включения в эти данные регулярных выражений.