1.4. Использование данных DNS
В документе используются термины «имя хоста» (host name) и «доменное имя» (domain name) которые следует трактовать как полные доменные имена хостов — FQDN, т. е., имена, возвращаемые DNS в ответ на запрос PTR (.IN-ADDR.ARPA) для преобразования IP-адреса в доменное имя, или имена, указываемые в записях MX для домена (RFC1034 [5], RFC1035 [6]).
Использование FQDN вместо адресов IP в этом документе обусловлено исключительно удобством восприятия. Однако такое использование жестко связано в DNS и записями .IN-ADDR.ARPA (PTR). Поскольку эти сведения легко подменить путем подстановки записей в кэш серверов DNS или использования спамерами собственных серверов имен, работать с доменными именами следует осторожно, проверяя соответствие прямого и обратного преобразования. Использование Secure DNS (RFC2065, [7]) упрощает ситуацию, делая невозможной подставку .IN-ADDR.ARPA.
Одна из рекомендаций связана с проверкой поля "MAIL From:" (envelope originator) с помощью DNS (исходя из предположения о существовании данных DNS для домена отправителя). При использовании такой проверки следует принимать во внимание ряд обстоятельств:
- Такая проверка может привести к значительному росту числа DNS-запросов и связанному с этим увеличению нагрузки на серверы DNS. Кроме того, использование такой проверки дает злоумышленникам возможность организации DoS-атаки на сервер DNS путем простой генерации многочисленных сообщений.
- Следует отметить, что при негативном кэшировании в DNS можно использовать подставные отклики DNS для организации атак на службы (denial of service — DoS). Например, если известно, что сайт использует проверку FQDN для SMTP-команд "MAIL From:", атакующий может использовать негативные отклики DNS для эффективной блокировки приема почты из одного или многих источников. Учет этого обстоятельства требует осторожности при выборе сервера DNS, используемого для проверки адреса отправителя, с целью минимизации риска получения подставных откликов.
- Для ранних версий программ рассылки спама проверки FQDN может оказаться вполне достаточно, поскольку такие программы используют совершенно произвольные значения в командах "MAIL From:" и сообщения от таких программ практически полностью блокируются, благодаря проверке с использованием DNS. Такая проверка может использоваться и сегодня, но уровень эффективности существенно понизился за счет использования программами рассылки реальных или правдоподобных имен в командах "MAIL From:".
С другой стороны, сайты, не имеющие достаточно хорошего соединения с DNS, могут сталкиваться с проблемами при получении легитимной почты из-за тайм-аутов при обращении к серверу DNS во время проверки поля "MAIL From:". Однако данные DNS обслуживаются в асинхронном режиме и могут кэшироваться, поэтому достаточно высока вероятность получения запрошенной информации даже при возникновении тайм-аута.
В более современных версиях программ рассылки спама проверка "MAIL From:" может не дать столь очевидного результата, поскольку программы спамеров также совершенствуются и зачастую используют реальные адреса (легитимность такого использования выходит за пределы рассмотрения данного документа).
1.5. Где блокировать спам — в SMTP, в RFC822 или в UA
Нашим основным предположением является то, что решение о приеме или отбрасывании сообщения должно приниматься на уровне SMTP и агент MTA должен принимать решение об отказе в процессе диалога SMTP. Такой подход позволяет избавиться от приема ненужных сообщений. Кроме того, при таком подходе ответственность за принятие окончательного решения передается отправителю сообщения — он получает соответствующий код возврата от SMTP и может обрабатывать его с учетом своих задач.