Презентация на тему Методы верификации отправителя почтового сообщения

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

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

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

рассылок происходит с компьютеров пользователей («зомби-машины»)
Как правило, используется поддельный адрес отправителя.
Обычно в поддельном адресе используется существующий домен.

отсеять большую долю сегодняшнего спама.
Требования к проверке отправителя. Вред

должен быть меньше пользы, поэтому:
Проверка - дополнительное свойство. Без верификации электронная почта должна продолжать работать.
Возможность плавного перехода на новые технологии.
Возможность посылки единичного письма незнакомому получателю должна сохраниться.
«Нормальные» применения E-mail, включая «автоматических роботов», должны работать.

сервисы;
не решает проблему входящей извне почты.
Авторизация соединения между почтовыми

серверами разных организаций:
требуется обмен данными авторизации (пароли, ключи)
решает проблему только для «постоянных» связей

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

разового обмена почтой никто не будет меняться ключами.
Сервер-сервер: Yahoo Domain Keys
публикация ключей и политики их использования в DNS
требуется модификация почтовых серверов как для простановки подписи, так и для её верификации.

(reverse resolving в DNS):
Не требует изменения инфраструктуры, уже широко

применяется.
Отсутствие достоверных данных о структуре чужих сетей ограничивает применимость.
Новые методы
дополнительные данные в обратной DNS-зоне (MTA Mark, Selective Sender, MX Out)
дополнительные данные в DNS домена отправителя (SPF Classic, CallerID, SenderID, RMX)

домена
текст и заголовки сообщения подписываются
на приемной стороне подпись проверяется
Достоинства
«достоверность»

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

text = "t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4…”

Заголовки в письме:
DomainKey-Signature:

a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from...
b=Gjon4OA2c8NfLCBauZskv99Eks....

на публичном сервисе можно получить любое количество подписанных сообщений.
Неясно

что делать, если требуется изменить один из подписанных заголовков (например, Resent-From при пересылке).
Пропуск подписанных писем мимо фильтра породит злоупотребления, нужен отдельный рейтинговый сервис.

- список IP-адресов с которых может исходить почта данного

домена:
"v=spf1 +ip:192.168.0.0/16 +mx ?all“
Каждый элемент списка состоит из префикса и диапазона IP-адресов. Возможны такие префиксы:
+ pass - разрешающий префикс. +all почта «из данного домена» может приходить с любого адреса
- fail - запрещающий префикс. –ip:10.0.0.0/8 – почта не может приходить с этого адреса.
~ softfail «нейтрально-отрицательный» префикс. «Адрес может не быть разрешенным».
? neutral «нейтральный» - владелец адреса не может ничего сказать про данный IP.
В ходе SMTP-сессии реальный IP-адрес посылающей стороны сравнивается со списком от владельца домена, после чего принимается решение о статусе письма.

фальсификации адресов
Жесткая политика приводит к потерям при пересылках (forward)

писем: в процессе пересылки адрес отправителя сохраняется, а IP-адрес посылающей стороны – нет.
Для внедрения жестких SPF-политик требуется модификация ПО на почтовых серверах «третьих сторон».

со множеством ошибок.
«Политики по-умолчанию». Уровень поддержки технологии невысок, поэтому

существующие реализации технологии позволяют «придумать» политику домена если ее нет.
Потенциально-опасный механизм «exists» - отправитель письма может следить за его путем по вашей сети.
Спамеры уверенно осваивают SPF.

быстрее «нормальных» систем.
Распространенность SPF на сегодня недостаточна, чтобы быть

эффективным антиспам - средством.

не уверен) – 5-8% спама и около 1% нормальной почты.
Уровень поддержки технологии вырос с 8% в июле до 13% в октябре.

фильтра
Для фильтра SpamTest на большом потоке сообщений:
примерно для 0.5%

сообщений статус SPF более «жесткий», чем результат работы Spamtest.
Примерно для 0.4% сообщений, статус более «мягкий» (доля совпадает с долей «pass» в потоке спама).
Вывод: польза от SPF сомнительна.

не будут придумывать за вас.
публикация «жесткой» политики будет приводить

к потерям исходящей почты
публикация «мягкой» политики может привести к ее игнорированию получателями
Нужен нейтральный вариант, например:
+ip:10.0.0.0/24 ~all
+ip:192.168.0.0/24 ?all

только на основании SPF
Если первое условие соблюдено, то SPF

может быть полезным источником данных для антиспам-системы.
К несчастью, основные публично-доступные реализации SPF не удовлетворяют условию 1 (исключение: SpamAssassin)

SPF идеями.
SenderID – объединение SPF Classic и CallerID:
Базовые идеи

от SPF
Синтаксис от CallerID
Методика определения адреса отправителя – от CallerID
SenderID не был поддержан IETF и сообществом OpenSource, перспективы туманны.

стоит.
Частные решения возможны, например YDK может быть интересна сервисам

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