SMC Milter - Сравнительный анализ
Сравнительный анализ технологии AutoSPF
Выбор технологии SPF (Sender Policy Framework) в качестве аналога для сравнения с AutoSPF обусловлен общей идеологической схожестью решений. Технология автоматической верификации отправителя AutoSPF, во многом подобна популярной сегодня технологии SPF. Оба алгоритма предоставляют возможность получателю письма проверить легальность использования почтового сервера отправителя для отправки почты с указанного в сообщении адреса. Проверка дает вероятность того, что письму можно доверять. Основное отличие алгоритма AutoSPF заключается в том, что он готов к работе с существующей информацией, в отличие от алгоритма SPF, требующего поддержки технологии SPF на стороне отправителя. Оба алгоритма используют DNS записи для целей верификации сообщений, исходящих из данного домена. В случае использования технологии SPF администратор (владелец) домена, используя DNS публикует данные, описывающие возможные источники электронной почты с адресами отправителя из этого домена. В случае использования AutoSPF предполагается что записи DNS обычно изначально содержат достаточно информации для верификации отправителя и модификации почтовой системы на стороне отправителя не требуется. Технология SPF обладает большей гибкостью в настройке политики домена. С другой стороны, такая гибкость в настоящее время необходима в исключительных случаях, и на практике часто остается невостребованной. В таблицах 1 и 2 показаны результаты тестирования обеих алгоритмов на собранной за месяц статистике по письмам с опубликованной SPF-политикой домена. В таблице 1 все сообщения с SPF-статусом, отличным от Pass и Fail объединены в одну группу Other. В практическом использовании, такие сообщения в терминах SPF, можно упрощенно рассматривать как имеющие SPF-статус Softfail. Описание используемых SPF-статусов приведено в таблице 3. Поскольку алгоритм AutoSPF не используется для блокирования почты, в таблице 2 для сравнения в скобках указаны ближайшие SPF-статусы.
Таблица 1
| SPF-статус | Доля сообщений с таким статусом | |
|---|---|---|
| Нормальная почта | Спам | |
| Pass | 72.4% | 3.9% |
| Fail | 0% | 30.2% |
| Other (Softfail) | 27.6% | 65.9% |
Таблица 2
| AutoSPF-статус | Доля сообщений с таким статусом | |
|---|---|---|
| Нормальная почта | Спам | |
| Related (Pass) | 89.4% | 4.8% |
| Not Related (Softfail) | 10.6% | 69.8% |
| Unknown | 0% | 25.4% |
Таблица 3
| SPF-статус | Описание |
|---|---|
| Pass | Согласно SPF-политике, сообщение должно быть принято. |
| Fail | Была нарушена SPF-политика. Письмо рекомендуется отвергнуть. |
| Softfail | SPF-политика нарушена, но письмо рекомендуется принять. |
| Neutral | В SPF-политике нет жестких указаний, рекомендуется принять. |
| None | Домен отправителя не имеет SPF-записей. |
| PermError | Постоянная ошибка (например некорректная SPF запись) |
| TempError | Временная ошибка. |
Анализ опубликованных владельцами почтовых доменов SPF-записей показал, что большинство из них повторяют уже и так имеющуюся в DNS информацию. Так, например, алгоритмы показывают практически полное совпадение на результатов проверки алгоритмом AutoSPF почтовых сообщений, имеющих положительный статус проверки алгоритмом SPF. При этом, AutoSPF не требует публикации дополнительной информации в описании почтового домена отправителя. Алгоритмы верификации отправителя не предназначены для выявления спама и если отправитель почтового сообщения соответствует всем требованиям, предъявляемым к нему одним или другим алгоритмом - отправитель будет считаться верифицированным, а почтовое сообщение легальным. Собранная нами статистика показывает достаточно большое число таких писем (от 3 до 5%). Это еще раз подтверждает то, что проблема спама не может быть эффективно решена только программными методами.