Технология SPF — внедрять или подождать?
В течение последних месяцев, технология SPF (Sender Policy Framework) получила мощную PR-поддержку во многих изданиях. Вероятно, существенную роль в этом сыграла поддержка стандарта SPF/SenderID компанией Microsoft — многие западные игроки интернет-рынка поспешили «отпиариться» вместе с MS. При этом, существенная часть публикаций рассматривает верификацию отправителя как «серебряную пулю» — технологию, способную решить проблему спама навсегда. В то же время, SPF, решая одни проблемы, создает другие (это вообще свойство новых технологий).
Наличие серьезных проблем в SPF при практическом отсутствии критических публикаций, вынудило автора написать статью «Технология SPF — за и против», в которой достаточно много внимания было уделено как проблемам SPF, так и рекомендациям по относительно безболезненному их решению.
Вышеуказанная статья вызвала ряд требующих ответа откликов, кроме того были набраны дополнительные данные о применимости SPF в сегодняшних условиях. Все это требует повторного обращения к данной теме.
Настоящую статью следует рассматривать как дополнение (или как продолжение дискуссии) к предыдущей статье. Чтобы не заставлять читателя перечитывать предыдущий текст, необходимо максимально кратко изложить самые общие сведения об SPF:
1. Технология SPF предназначена для верификации отправителя E-mail письма.
2. Верификация происходит путем сравнения данных о возможных источниках письма из данного домена с реальным IP-адресом отправляющей стороны в SMTP-сессии.
3. Данные о возможных источниках (SPF-политику) публикует администратор домена путем внесения дополнительных данных в систему DNS.
4. Результатом анализа SPF-политики является SPF-статус сообщения, который принимает одно из следующих значений:
o Pass — отправитель сообщения не подделан (согласно анализу SPF-политики)
o Softfail — сообщение не отвечает «жестким» критериям достоверности отправителя, но нельзя быть уверенным, что отправитель подделан.
o Fail — отправитель подделан.
o Прочие варианты (None,Neutral , Unknown, Error) — не вдаваясь в детали, все эти варианты эквивалентны, можно считать что SPF-политика отсутствует.
1. ЭФФЕКТИВНОСТЬ SPF КАК АНТИСПАМ-СРЕДСТВА
При использовании SPF в качестве антиспам-средства, результат анализа SPF-политики можно использовать несколькими способами:
o использование впрямую, без учета прочих свойств сообщения (SPF-fail: отвергаем письмо, pass: пропускаем).
o Полученные из анализа SPF-политики данные могут быть учтены в комплексной антиспам-системе как дополнительные свойства письма; решение о классификации письма как спама будет приниматься с учетом других параметров сообщения
Первый способ, очевидно, будет применяться в простых антиспам-системах, возможно в сочетании с другими жесткими методами (сначала проверяем по RBL, если письмо не отвергнуто — по SPF, потом по Байесу; другими словами все используемые антиспам-методы независимы друг от друга). Далее этот случай рассматривается в разделе «SPF как независимое антиспам-средство».
Второй способ заключается в том, что сначала производится получение данных от всех используемых антиспам-методик, а затем — их комплексный учет (например, как в SpamAssassin — каждое правило дает сколько-то «очков», решение о статусе письма принимается по сумме очков). Такое поведение характерно для сложных антиспам-систем, применяемых в первую очередь в крупных почтовые сервисах и ISP (в таких организациях антиспам-система критична для бизнеса, на ее настройку можно потратить значительные ресурсы). Этот случай рассмотрен ниже, в разделе 1.3.
Независимо от способа использования, эффективность технологии SPF будет определяться распространенностью самой технологии и «средней» SPF-политикой. Определить эти параметры можно только экспериментальным путем — анализируя доступные потоки почты.
1.1. SPF-статусы в потоке почты
Автор проанализировал SPF-статусы у 20464 спам-сообщений и 990 не-спам сообщений, пришедших к нему в течение последних 5 недель. Обе выборки были просмотрены вручную, чтобы в спам-выборке не было нормальных сообщений и наоборот. Автор отдает себе отчет, что выборка личной почты может быть смещенной и готов анализировать другие выборки, если ему их предоставят.
Получено следующее распределение статусов SPF:
SPF-статус |
Доля сообщений с таким статусом |
|
Спам |
Нормальная почта |
None |
89.34% |
91.86% |
Softfail |
4.57% |
0.85% |
Fail |
3.21% |
0 |
Neutral |
1.45% |
1.11% |
Unknown |
0.93% |
0.12% |
Pass |
0.42% |
5.88% |
Error |
0.08% |
0.15% |
(табл. 1)
Из этих данных следуют два интересных вывода:
o Довольно много спам-сообщений (0.42% из 10.66%) c точки зрения технологии SPF являются легальными (статус pass).
o Считать сообщения спамом только на основании статуса softfail нельзя, это может дать почти процент ложных срабатываний.
1.2. SPF как независимое антиспам-средство
Автор имел возможность проанализировать SPF-статус 8 миллионов E-mail сообщений, полученных на одном из крупных почтовых сервисов в течение нескольких дней августа. Из рассмотрения были исключены сообщения от пользователей системы, рассматривался только поток из внешнего мира.
Согласно полученным данным, SPF-статус отличный от none (none означает что SPF не поддержан на стороне отправителя) для данного потока почты имеют на сегодня 8.35% всех сообщений. Все прочие SPF-статусы распределились таким образом:
Статус сообщения по SPF |
Доля таких сообщений в общем потоке почты |
Softfail |
3.244% |
Pass |
2.327% |
Fail |
1.456% |
Neutral |
0.801% |
Unknown |
0.514% |
Error |
0.012% |
(табл. 2)
Как видно из таблицы, интересный с точки зрения борьбы со спамом статус (pass или fail) имеют 3.8% всех сообщений. Это и есть оценка сверху эффективности SPF в качестве антиспам-решения на сегодняшний день. Каким бы способом не учитывалось SPF в антиспам-средствах, только одно сообщение из 26 имеет сколько-нибудь «интересный» статус.
1.3. Использование SPF совместно с другими антиспам-средствами
Рассматривая использование SPF в качестве источника дополнительных данных для комплексной антиспам фильтрации, необходимо учитывать достигнутые без использования SPF характеристики подобных систем (по данным их авторов):
o Качество распознавания спама — на уровне 85–98% и более (по данным авторов таких систем).
o Доля ложных срабатываний — 0.01% и ниже.
При использовании SPF совместно с другими способами фильтрации спама польза от SPF будет крайне небольшой — значимый SPF-статус имеют всего несколько процентов сообщений, при этом большая часть спама может быть определена и без использования SPF-данных.
Следовательно, нам интересны только случаи, когда SPF-статус письма и результат анализа по другим признакам противоречат друг другу — тогда вклад от SPF может оказаться существенным для изменения классификации сообщения.
В таблице приведены данные классификации рассматриваемой подборки из 8 млн. сообщений фильтром Spamtest и их SPF-статусы. В таблице 3 приведены данные только по тем письмам, которые имеют отличный от нейтрального (т.е. neutral, none и ошибки) статус по SPF. Проценты показаны относительно всего потока почты.
Статус SPF |
Статус Spamtest |
|
Pass |
Softfail |
Fail |
Not Spam |
1.889% |
0.293% |
0.292% |
Probable Spam |
0.161% |
0.165% |
0.124% |
Spam |
0.277% |
2.786% |
1.039% |
(табл. 3)
Жирным в таблице выделены те случаи, когда статус по SPF и статус по другим признакам противоречат друг другу. Как мы видим, SPF может помочь антиспам-фильтру менее чем в 1% всех случаев — это и есть оценка сверху эффективности SPF как добавки к имеющемуся антиспаму.
Впрочем, с тем же успехом, SPF может наоборот помешать анализу. Как показано выше, ложный (с точки зрения классификации спам/нормальная почта) статус pass был получен для 0.42% спам-сообщений и ровно эту величину мы видим в таблице 3.
С точки зрения улучшения качества антиспам-системы, интереснее всего сочетание Not Spam/SPF fail и Not Spam/SPF softfail в таблице 3. В эти категории попадают:
o Пересылаемые (forward) сообщения c жесткой политикой отправителя (для статуса fail), либо пересылаемые сообщения с мягкой политикой отправителя (softfail)
o Спам, пропущенный фильтром.
Какой-либо дополнительной информации, позволяющей разделить эти два случая SPF нам не дает. Другими словами, принять решение о статусе письма антиспам-фильтр должен на основании других данных — как и в случае отсутствия SPF у отправителя.
Вместе с тем, SPF обладает несомненной пользой как способ обратной связи между антиспам-фильтром и отправителями не-спам сообщений (включая сюда подписные массовые рассылки). В частности, при детектировании сообщений по частотности (повторяемости) подписные неанонимные рассылки (не спам) и спам-сообщения воспринимаются антиспам-системой одинаково. Использование SPF как «белого списка» поможет такие случаи различить. Впрочем, не следует забывать, что этот механизм будет доступен всем, в том числе и спамерам (и для рассылки спама уже используется).
1.4. Выводы
1. Использование SPF в качестве отдельного антиспам-фильтра на сегодня неэффективно. Общий уровень поддержки технологии находится в пределах 10% от общего почтового трафика, а сообщений с таким SPF-статусом, который можно использовать для независимой от других свойств письма классификации сообщения — вообще единицы процентов.
2. Использование SPF в качестве дополнения к имеющейся комплексной антиспам-системе еще менее эффективно — доля сообщений на которых SPF дает вклад в классификацию спам/не-спам составляет в лучшем случае 1%, причем эта величина того же порядка, что и уровень ошибочной классификации письма на основании SPF.
3. Таким образом, заметный вклад в качество антиспам-системы может дать только использование SPF в качестве защиты от ложных срабатываний («белого списка», возможно с небольшим весом). При этом следует учитывать, что SPF-механизм доступен для использования всеми, в том числе и спамерами.
2. SPF И ПЕРЕСЫЛКИ ПОЧТЫ
Проблема пересылок почты является наиболее серьезным препятствием на пути внедрения SPF. Суть ее заключается в том, что при пересылке почты через «посредников», третье (и далее) звено пересылки получают сообщение вовсе не с тех адресов, которые разрешены SPF-политикой отправителя. При этом, отправитель как правило не знает, через каких посредников пройдет его письмо и не может добавить их список к своей SPF-политике.
В качестве посредников могут выступать:
o Сервисы пересылки сообщений (почтовые сервисы, сервисы «одноразовых» адресов, просто пересылка почты со старого рабочего адреса).
o Резервные почтовые серверы (backup relays)
o Почтовые серверы ISP в случае, когда пользователь использует собственный адрес, а почту шлет через сервер провайдера.
Во всех этих случаях, в проверке SPF участвует адрес (домен) отправителя и IP-адрес пересыльщика. В результате, если в SPF-политике отправителя указано ‘… список… -all’, то это прямое пожелание отправителя не принимать пересылаемые письма. Как правило, отправитель желает несколько иного.
Для решения проблемы пересылок предложены такие решения:
1. Изменение программного обеспечения на тех машинах, которые занимаются пересылкой таким образом, чтобы они пересылали письмо уже от своего домена. Наиболее известным предложением на эту тему является SRS (Sender Rewriting Scheme, www.libsrs.org).
2. Изменение SMTP-протокола: сохраняя адрес отправителя в неприкосновенности, передавать дополнительный атрибут «пересылается от имени такого-то» и проверка по SPF дополнительного атрибута.
3. Пересыльщики должны добавлять дополнительные заголовки в сообщение (многие это уже делают), а на приемной стороне нужно пытаться извлекать адрес пересыльщика оттуда.
Все три способа требуют модификации программного обеспечения почтовых серверов везде, где может происходить пересылка. То есть практически везде.
Следует заметить, что сохранение адреса исходного отправителя в процессе пересылки используется, например, для доставки почтовых квитанций (о недоставке или о доставке).
Таким образом, простая подмена адреса отправителя на транзитном сервере не годится, нужен более сложный механизм, чтобы обеспечить доставку квитанций обратно вдоль всего пути, но не открыть при этом «открытый релей» на исходного отправителя.
Модификация SMTP-протокола является более разумным решением, проблема в том, что имеющиеся предложения пока являются только предварительными версиями описаний. Реализаций нет.
Извлечение необходимых данных из заголовков письма не требует изобретения новых сущностей, но означает, что письмо нужно сначала принять, потом определить транзитного отправителя, а потом — принять решение о приеме письма.
Резюмируя: на сегодняшний день не существует легкого решения проблемы совместимости SPF и легальных пересылок почты. Предлагаемые решения далеки от совершенства, вероятность их массового внедрения за короткое время представляется невероятной.
Тот факт, что из-за SPF сегодня происходит недоставка почты глупо подвергать сомнению — происходит и прецеденты автору известны.
Проблема пересылок является наиболее болезненной для технологии SPF и сторонников ее внедрения, наибольшее число откликов на первую статью касалось именно этой проблемы. Объединяя похожие возражения, получаем такие мнения:
1. Большинство пересыльщиков уже поддержали подмену отправителя. А остальные — обязательно сделают это очень быстро, за один-два года.
2. Пересылаемой почты очень немного, около 1%. Проблема пересылок раздута.
3. Если пересылаемое письмо не будет принято, то отправитель получит квитанцию, прочитает ее и будет знать, куда на самом деле нужно слать почту. И перешлет ее туда. Таким образом, проблема касается только писем, генерируемых автоматическими системами, а это совсем немного.
4. Раз отправитель указал в политике -all, значит такова его воля, письмо должно быть утеряно.
5. Пользователи сами теряют много почты, на этом фоне потери пересылок будут незаметны.
6. Другие способы антиспам-фильтрации, например черные списки, имеют еще большую долю ложных срабатываний.
Отвечаю по порядку:
1. Кто-то из пересыльщиков SRS наверняка поддержал. Но вообще, таких немного. Проанализировав лог с данными одного миллиона сообщений (адресов From), автор обнаружил только два домена, поддержавших «классический SRS» (по From: SRS1=…), всего с них обнаружено 30 писем (на миллион). Тогда как доля пересылаемого трафика составляет порядка 1%, то есть 10 тысяч на миллион. Понятно, что кроме классического SRS есть другие методы формирования транзитных адресов, но SRS сейчас активно продвигается и результаты должны бы быть более впечатляющими.
Однако значимой поддержки SRS не наблюдается.
2. Пересылаемых писем действительно не так много — оценка «в районе одного процента» дает правильный порядок величины. Хотя даже 1% — довольно много, если сравнивать с уровнем ложных срабатываний хороших антиспам-систем.
Проблема в том, что у тех, кто использует пересылку, доля пересылаемых писем может быть и 100% (был старый адрес, стал новый, на старом — пересылка). Если вдруг на их реальном адресе появится жесткая проверка SPF (ISP включил), то такие пользователи начнут терять входящую корреспонденцию. Сначала — немного (т.к. SPF поддержан малым числом отправителей), потом все больше и больше. При этом, и на стороне отправителя и на стороне конечного получателя все хотят как лучше.
3. Идея о том, что отправитель сообщения прочтет квитанцию о недоставке, поймет куда на самом деле нужно доставлять сообщение и переадресует его требует развернутого комментария:
a. Системные администраторы — поймут. Но интернет продолжает расти, доля совсем новых пользователей — довольно большая, а они точно не поймут. Да и стандартная (предлагаемая по умолчанию) SPF-квитанция отсылает на англоязычный spf.pobox.com, что для рунета не решение.
b. Собственно, если способ с квитанцией кажется разумным, то почему не внедрить TMDA или какой-то другой способ запроса подтверждения от автора письма ? Отправитель прочтет квитанцию, нажмет кнопку «я не спамер» и письмо дойдет.
Однако системы с подтверждением считаются неприемлемыми — дескать много порождаемого трафика, на кнопку никто не жмет. Почему же более сложные действия (прочитать квитанцию, перенаправить письмо) — приемлемы ?
Насколько мне известно, те же люди, которые всерьез защищают идею «отправитель прочитает квитанцию», являются одновременно жесткими противниками систем с подтверждениями. Парадокс.
c. Довольно много сообщений являются важными для получателя, но практически безразличны для отправителя. То есть отправитель их написал, отправил и тем считает свой долг выполненным, если получатель не может их получить — то это его проблемы. В этой ситуации перепосылать ничего не будут.
d. Остаются еще автоматические системы — заказы в интернет-магазинах, регистрация на сервисах и т.п. Ирония заключается в том, что для общения с такими системами часто используются «одноразовые» адреса — пригодные для получения регистрационного письма и не более того. Это делается для предотвращения спама на регистрационный адрес. Одноразовые адреса, естественно, делаются через механизм пересылки.
4. Отправитель мог указать -all вовсе не по той причине, что он не любит пересылки. Ему так порекомендовали в документации, а о проблеме пересылок он не задумывался. Более того, SPF-политику часто формулируют одни люди (системные администраторы), а страдают от нее — другие (сотрудники той же организации).
5. То что пользователи теряют какое-то количество почты самостоятельно (наиболее часто встречающаяся оценка — все-таки 0.1% а не 3–5%) не означает, что прочие почтовые технологии должны тоже терять почту. Не стоит усугублять проблему.
6. То, что какие-то способы фильтрации спама нехороши, не означает что нужно делать так же плохо.
Несмотря на все описанные выше ужасы, решение, пригодное для массового внедрения отправителями имеется. Оно заключается в публикации мягкой SPF-политики по умолчанию (т.е. политика должна заканчиваться на ?all или ~all). Судя по всему, так сейчас все и делают — доля статусов softfail и neutral втрое выше чем у fail (табл. 2). Проблема только в том, что это резко снижает эффективность SPF.
Второе решение заключается в широком использовании exists — но на сегодня для этого нет готовых решений, придется программировать самостоятельно. Exists, впрочем, создает свои проблемы (см. раздел 5.2).
Мнение автора: имеющиеся проблемы с пересылаемой почтой приведут к массовому внедрению более мягких SPF-политик, чем это могло бы быть сделано. Авторам технологии следовало бы решить проблему заранее (или выбрать другую технологию), сегодняшняя ситуация приведет к тому, что SPF будет куда менее полезной для борьбы со спамом, чем это было бы возможно.
3. SPF-ПОЛИТИКИ «ПО УМОЛЧАНИЮ»
Суть проблемы «политики по умолчанию» заключается в следующем:
o SPF сейчас поддерживает достаточно мало отправителей, поэтому эффективность невелика.
o Сам механизм — достаточно удобен, хочется его использовать для всей почты.
o В результате, во многих поддерживающих SPF почтовых серверах можно задать «политику по умолчанию» (обычно ее называют best guess) — т.е. при отсутствии SPF-политики у домена, почтовый сервер попытается ее угадать сам.
Сама по себе идея умолчаний — не является плохой, если используются такие значения, которые не могут ухудшить ситуации. Другими словами, используется только разрешительные умолчания (например, ‘a/24 mx/24 ?all’). Однако, разрешительные умолчания не решают задачи борьбы со спамом (т.к. ничего не запрещают), а цель внедрения SPF — именно антиспам.
В результате, достаточно массово внедряются умолчания вида ‘a/24 mx/24 -all’, означающие, что почту от домена можно принимать из подсети (диапазона IP-адресов), где расположен сервер домена (обычно это Web-сервер), из подсети где расположены почтовые серверы домена и более ниоткуда. Таким образом, если у какого-то отправителя почтовые серверы «на прием» и почтовые серверы «на отправку» расположены в разных подсетях, то почта с такого домена приниматься не будет, даже если она легальна.
Данная проблема не связана с технологией SPF как таковой, она связана с конкретными реализациями технологии и конкретными системными администраторами, которые настраивают излишне-жестокие правила фильтрации. Похожая проблема связана с использованием «политических» RBL-списков (SPEWS и подобные).
Таким образом, публикация какой-либо (мягкой) SPF-политики может оказаться лучше, чем ее отсутствие.
4. SPF CLASSIC ? SPFV1 ?? SPF2.0 ??? ТЕХНОЛОГИЯ НА МАРШЕ….
Официальный сайт по SPF (spf.pobox.com) предлагает два описания стандарта — marid-protocol-00 (текущая версия протокола по версии spf.pobox.com), от 11 июля 2004 года и ‘SPF-classic’ от мая того же года.
Одновременно, рабочая группа MARID предлагает уже более новую версию стандарта SenderID — marid-protocol-02 от 13 августа текущего года.
К удивлению автора, новая версия протокола несовместима со старой, в частности
o Предлагается публикация SPF-данных в специальном типе DNS-записей SPF2. При этом допускается публикация в предлагавшемся ранее типе записей TXT.
o Предлагается новая спецификация версии протокола: вместо старой строки версии (v=spfv1) предлагается новая (spf2.0/pra). Новая спецификация версии является несовместимой с имеющимися реализациями протокола (libspf, libspf2, rmspf)
При этом, описание SPF-classic официально устаревает в сентябре 2004, marid-protocol-00 — в январе 2005.
Возникает резонный вопрос: какая версия протокола должна быть выбрана, если я прямо сегодня хочу опубликовать SPF-записи в DNS ? SPF-Classic или SPF/2.0 ? Первая — поддержана в программном обеспечении, но устаревает через месяц. Вторая — нигде не поддержана пока, но это явный mainstream.
Ответа на этот вопрос у автора нет, он просто хочет обратить внимание читателей на тот факт, что описание технологии еще явно не устоялось, слишком раннее внедрение имеющихся реализаций может привести к тому, что через небольшое время придется перевнедрять.
5. ПРОЧИЕ ПРОБЛЕМЫ
В публикации сотрудников Яндекса «Для чего нужен SPF», автора ругали за такие тезисы:
o Поддержка SPF при приеме почты создает избыточную нагрузку на DNS, что может быть проблемой.
o SPF-правило ‘exists’ является проблемой с точки зрения безопасности получателя почты.
Полученная критика требует ответов, которые приведены далее.
5.1. SPF и DNS
Поддержка SPF на стороне получателя вынуждает почтовый сервер получателя делать DNS-запросы для получения SPF-политики отправителя. Конечно, почтовый сервер делает и другие DNS-запросы, например получает имя посылающего сервера по его IP-адресу (это необязательно, но практически всегда делается), возможно делает запросы к RBL.
Как известно на примере RBL, крупные почтовые сервисы вынуждены держать у себя локальные копии используемых RBL-списков, а не обращаться к ним удаленно. Это делается именно по той причине, что DNS-запрос может быть достаточно долгим. Скажем, при потоке в 100 сообщений в секунду, каждая лишняя секунда ожидания в почтовом сервере добавляет 100 лишних копий почтовой программы на принимающей стороне. А ведь DNS-таймаут в стандартном DNS-клиенте — до 75 секунд. Но вот сделать локальную копию всех SPF-записей всего мира — затруднительно. Таким образом, мы создаем второй «тяжелый» DNS-запрос т.е. увеличиваем нагрузку минимум вдвое.
В случае нормального функционирования DNS, создаваемая SPF дополнительная нагрузка может быть и приемлемой. А может быть — неприемлемой, если без SPF загрузка почтового сервиса была близка к предельной.
Проблемы начнутся, например, если DNS-сервер домена отправителя не отвечает. Более того, таким образом совершенно нетрудно провести DoS-атаку т.к. DNS-серверы к которым будет обращаться SPF-модуль на приемной стороне выбираются именно отправителем (подстановкой нужного домена отправителя) — выбираем (или делаем) домен с DNS сервером, который не отвечает на запросы, затем шлем письма с отправителем из такого домена и наблюдаем как почтовые серверы получателя ждут окончания DNS-таймаутов.
5.2. SPF-метод exists и безопасность
При использовании метода exists, отправитель может, при правильном использовании SPF-макросов, получать следующие данные со всех пунктов пересылки сообщения:
1. IP-адрес пересылающей стороны (будет в DNS-запросе)
2. E-mail отправителя (в DNS-запросе)
3. IP-адрес получателя (в адресе, с которого пришел DNS-запрос).
Естественно, все эти данные приходят только с тех почтовых серверов, где включена поддержка SPF.
Таким образом если кто-либо хочет изучить структуру пересылки почты внутри какой-то компании, то он может а) выбрать домен, создать к нему SPF-запись с exists; б) послать сообщение с отправителем из выбранного домена. Приемлемо это или нет — пусть решают специалисты по безопасности.
Вторая проблема связана с верификацией спам-баз. Используя exists, можно быстро проверить адреса в домене (опубликовавшем запись с exists) на актуальность. На это обычно возражают, что путем посылки почты тоже можно провести такую проверку. Однако:
1. сегодняшние почтовые сервера с такой практикой борются, вставляя задержку перед ответом на mail from. То есть проверять даже по 10 адресов в секунду не получится. А через exists — получится.
2. Провести проверку через exists можно полностью анонимно, используя многочисленные DNS-серверы, разрешающие запросы всем желающим (лог-файлов на DNS-запросы обычно не ведут). В случае верификации через SMTP анонимности нет.
6. ВЫВОДЫ. ПОДДЕРЖИВАТЬ ЛИ SPF ПРЯМО СЕГОДНЯ ?
Поддержка SPF заключается в двух независимых действиях:
o Публикация SPF-записей для домена. Это затрагивает исходящую из домена почту.
o Поддержка SPF в почтовом сервере при приеме почты. Включение такой поддержки повлияет на процесс приема почты.
6.1. Публикация SPF-записей
Публикация SPF-политики несомненно полезна. Даже если вы не страдаете от спама, рассылаемого от имени вашего домена, явное описание легальных источников почты из вашего домена может помочь прохождению легальной почты от вас через антиспам-фильтры, особенно если на принимающей почту стороне используют додумывание SPF-политики за вас (best guess).
Описывая SPF-политику, следует явно включить в нее все ваши серверы с которых может исходить почта. Более простое решение заключается в описании всего адресного пространства.
Ваша SPF-политика должна быть «мягкой» т.е. оканчиваться на ?all или ~all. В противном случае, у вас могут возникнуть проблемы с теми письмами из вашего домена, которые пересылаются (forward) на пути к адресату..
Слишком мягкая политика «по умолчанию» тоже может быть воспринята неверно. Если в вашей SPF-политике будет указано +all (т.е. вы явно хотите сказать всему миру, что письма из вашего домена могут приходить откуда угодно), то есть неплохой шанс, что такая политика будет проигнорирована — ибо домены с такими SPF-записями уже используются спамерами.
6.2. Использование SPF при приеме почты
При использование SPF на приеме почты необходимо учитывать такие соображения:
o Распространенность SPF в настоящее время невелика, не более 10% сообщений (в среднем потоке) будут иметь SPF-статус.
o Использовать статус softfail как признак спама не следует, достаточно много нормальной почты имеют такой статус.
o Возможны ложные срабатывания на пересылаемой (forward) почте.
o Заметное количество спам-почты уже сейчас имеет статус pass, имеет смысл игнорировать ‘+all’ в SPF-политике отправителя.
Другими словами, использовать SPF в качестве дополнительного признака при фильтрации спама — можно. Принятие решений на основе только SPF не принесет большой пользы при фильтрации спама, но может привести к отвержению нормальной почты.
Другие
версия для печати