Технология SPF — внедрять или подождать?

Содержание:

Введение

1. Эффективность SPF как антиспам-средства

    1.1 SPF-статусы в потоке почты

    1.2 SPF как независимое антиспам-средство

    1.3 Использование SPF совместно с другими антиспам-средствами

          Выводы

2. SPF и пересылки почты

          Выводы

3. SPF-политики «по умолчанию»

4. SPF Classic? SPFv1?? SPF2.0??? Технология на марше…

5. Прочие проблемы

    5.1 SPF и DNS

    5.2 SPF-метод exists и безопасность

6. Поддерживать ли SPF прямо сегодня?

    6.1 Публикация SPF-записей

    6.2 Использование SPF при приеме почты

Введение

В последние месяцы технология SPF (Sender Policy Framework) получила мощную публичную поддержку во многих изданиях. Вероятно, наиболее существенную роль в этом сыграла поддержка стандарта SPF/SenderID компанией Microsoft — в результате многие западные игроки интернет-рынка поспешили «засветиться» вместе с Микрософтом.

В большинстве публикаций верификация отправителя с помощью SPF преподносится как «серебряная пуля» — как технология, способная решить проблему спама раз и навсегда. На самом деле это не совсем верно, или даже совсем неверно, поскольку SPF, решая одни проблемы, создает другие (это вообще свойство любых новых технологий).

Наличие серьезных проблем в применении стандарта SPF при практическом отсутствии критических публикаций вынудило автора написать статью «Технология SPF — за и против». В это статье много внимания было уделено как проблемам SPF, так и рекомендациям по относительно безболезненному их решению.

Вышеуказанная статья вызвала бурные отклики, на которые нужно ответить. Кроме того, автором были накоплены дополнительные данные о применимости SPF в сегодняшних условиях. Все это требует повторного обращения к данной теме. Таким образом, настоящую статью следует рассматривать как дополнение (или как продолжение дискуссии) к предыдущей статье.

Чтобы не заставлять читателя перечитывать предыдущий текст, необходимо здесь (максимально кратко) изложить самые общие сведения об SPF:

1. Технология SPF предназначена для верификации отправителя электронного письма.
2. Верификация отправителя происходит путем сравнения данных отправителя о возможных источниках письма из данного домена с реальным IP-адресом отправляющей стороны (в SMTP-сессии).
3. Данные о возможных источниках (SPF-политику) публикует администратор домена путем внесения дополнительных записей в систему DNS.
4. Результатом анализа SPF-политики на принимающей стороне является SPF-статус сообщения, который может иметь одно из следующих значений:
   • Pass — отправитель сообщения не подделан (согласно анализу SPF-политики).
   • Softfail — сообщение не отвечает «жестким» критериям достоверности отправителя, но нельзя и быть уверенным, что отправитель подделан.
   • Fail — отправитель подделан.
   • Прочие варианты (None, Neutral , Unknown, Error) — не вдаваясь в детали скажем, что все эти варианты примерно эквивалентны, и можно считать, что в данных случаях SPF-политика отсутствует.

5. 1. Эффективность SPF как антиспам-средства

   При использовании SPF в качестве антиспам-средства результат анализа SPF-политики можно использовать несколькими способами:

   • Использование «впрямую», без учета прочих свойств сообщения (SPF-fail: отвергаем письмо, pass: пропускаем).
   • Использование совместно с другими средствами анализа. Полученные из анализа SPF-политики данные могут быть учтены в комплексной антиспам-системе как дополнительные свойства письма; решение о классификации письма как спама будет приниматься с учетом других параметров сообщения.

   Первый способ, очевидно, будет применяться в простых антиспам-системах, возможно, по очереди с другими жесткими методами (например, сначала проверяем по RBL, если письмо не отвергнуто, — по SPF, потом по Байесу; другими словами, все используемые антиспам-методы независимы друг от друга). Далее этот случай рассматривается в разделе «SPF как независимое антиспам-средство».

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

   Такое поведение характерно для сложных антиспам-систем, применяемых в первую очередь в крупных почтовых сервисах и у провайдеров (ISP). В таких организациях антиспам-система критична для бизнеса, и на ее настройку можно потратить значительные ресурсы. Этот случай рассмотрен ниже, в разделе «Использование SPF совместно с другими антиспам-средствами».

   Независимо от способа использования политик SPF, эффективность технологии SPF будет определяться распространенностью самой технологии, и «средней» по Интернету SPF-политикой.

   Определить эти параметры можно только экспериментальным путем — анализируя доступные потоки почты.

   1.1. SPF-статусы в потоке почты

   Автор проанализировал SPF-статусы у 20464 спам-сообщений и 990 не-спам сообщений, пришедших к нему в течение 5 недель летом 2004 года. Обе выборки были просмотрены вручную, с тем, чтобы в выборке спама не было нормальных сообщений и наоборот.

   Было получено следующее распределение статусов SPF:

   Таблица 1

   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%

   Из этих данных следуют два интересных вывода:

   • Довольно много спам-сообщений (0.42% из 10.66%) c точки зрения технологии SPF являются легальными (статус pass).
   • Считать сообщения спамом только на основании статуса softfail нельзя, это может дать почти 1% ложных срабатываний.

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

   1.2. SPF как независимое антиспам-средство

   Автор имел возможность проанализировать SPF-статус 8 миллионов E-mail сообщений, полученных на одном из крупных почтовых сервисов в течение нескольких дней августа. Из рассмотрения были исключены сообщения от пользователей системы, рассматривался только поток из внешнего мира.

   Согласно полученным данным, SPF-статус отличный от none (none означает, что SPF не поддержан на стороне отправителя) для данного потока почты имеют на сегодня 8.35% всех сообщений. Все прочие SPF-статусы распределились таким образом:

   Таблица 2

   Статус сообщения по SPF	Доля таких сообщений в общем потоке почты
   Softfail	3.244%
   Pass	2.327%
   Fail	1.456%
   Neutral	0.801%
   Unknown	0.514%
   Error	0.012%

   Как видно из таблицы, интересный с точки зрения борьбы со спамом статус (pass или fail) имеют 3.8% всех сообщений.

   Это и есть оценка сверху эффективности SPF в качестве антиспам-решения на сегодняшний день. Каким бы способом не учитывалась политика SPF в антиспам-средствах, только одно сообщение из 26 имеет сколько-нибудь «интересный» статус.

   1.3. Использование SPF совместно с другими антиспам-средствами

   Рассматривая использование SPF в качестве источника дополнительных данных для комплексной антиспам-фильтрации, необходимо учитывать современный уровень технологий фильтрации спама — без использования SPF.

   Вот каковы в настоящее время средние параметры подобных систем:

   • Качество распознавания спама — на уровне 85-98% и более.
   • Доля ложных срабатываний — 0.01% и ниже.

   Как говорилось выше, при использовании SPF совместно с другими способами фильтрации спама польза от заключения фильтра, основанного на проверке политики SPF, будет крайне небольшой — поскольку значимый SPF-статус имеют всего несколько процентов сообщений. Из показателей «обычных» фильтров видно, что при этом большая часть спама может быть определена и без использования SPF-данных.

   Следовательно, нам интересны только те случаи, когда SPF-статус письма и результат анализа по другим признакам противоречат друг другу — тогда вклад от SPF может оказаться существенным для изменения классификации сообщения.

   В таблице приведены данные классификации рассматриваемой подборки из 8 млн. сообщений, проверенных фильтром Spamtest, и их SPF-статусы. В таблице 3 приведены данные только по тем письмам, которые имеют статус по SPF, отличный от нейтрального статуса (т.е. neutral, none или ошибка). Доли показаны относительно всего потока почты.

   Таблица 3

   Статус Spamtest	Статус SPF
   	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%

   Жирным шрифтом в таблице выделены те случаи, когда статус по SPF и статус, полученный анализом других признаков письма, противоречат друг другу.

   Как мы видим, SPF может помочь антиспам-фильтру «поймать» спамерское письмо менее чем в 1% всех случаев — это и есть оценка сверху эффективности SPF как добавки к имеющемуся антиспаму.

   Впрочем, с тем же успехом SPF может, наоборот, помешать анализу. Как показано выше, ложный (с точки зрения классификации спам/нормальная почта) статус Pass был получен для 0.42% спам-сообщений, и ровно эту величину мы видим в таблице 3 (0.277 + 0.161%).

   С точки зрения улучшения качества антиспам-системы, интереснее всего сочетание Not Spam/SPF fail и Not Spam/SPF softfail в таблице 3. В эти категории попадают:

   • Пересылаемые (forward) сообщения c жесткой политикой отправителя (для статуса fail), либо пересылаемые сообщения с мягкой политикой отправителя (softfail).
   • Спам, пропущенный фильтром.

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

   Вместе с тем, SPF обладает несомненной пользой как способ обратной связи между антиспам-фильтром и отправителями не-спам сообщений (включая сюда подписные массовые рассылки). В частности, при детектировании сообщений по частотности (повторяемости) подписные неанонимные рассылки (не спам) и спам-сообщения воспринимаются антиспам-системой одинаково. Использование SPF как списка разрешенных поможет такие случаи различить. Впрочем, не следует забывать, что этот механизм будет доступен всем, в том числе и спамерам (и для рассылки спама уже используется).

   Выводы

   1. Использование SPF в качестве самостоятельного спам-фильтра на сегодня неэффективно. Общий уровень поддержки технологии находится в пределах 10% от общего почтового трафика, а сообщений с таким SPF-статусом, который можно использовать для независимой от других свойств письма классификации сообщения, — вообще единицы процентов.
   2. Использование SPF в качестве дополнения к имеющейся комплексной антиспам-системе еще менее эффективно — доля сообщений, на которых SPF дает вклад в классификацию спам/не-спам, составляет в лучшем случае 1%, причем эта величина того же порядка, что и уровень ошибочной классификации письма на основании SPF.
   3. Таким образом, заметный вклад в качество антиспам-системы может дать только использование SPF в качестве защиты от ложных срабатываний (то есть в виде списка разрешенных, возможно с небольшим весом). При этом следует учитывать, что SPF-механизм доступен для использования всеми, в том числе и спамерами.

   2. SPF и пересылки почты

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

   В качестве посредников могут выступать:

   • Сервисы пересылки сообщений (почтовые сервисы, сервисы «одноразовых» адресов, просто пересылка почты со старого рабочего адреса).
   • Резервные почтовые серверы (backup relays).
   • Почтовые серверы провайдера — в случае, когда пользователь использует собственный адрес, а почту шлет через сервер провайдера.

   Во всех этих случаях в проверке 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 не наблюдается.

6. Пересылаемых писем действительно не так много — оценка «в районе одного процента» дает правильный порядок величины. Хотя даже 1% — довольно много, если сравнивать с уровнем ложных срабатываний хороших антиспам-систем (0,01% — 0,0001%).

   Проблема в том, что у тех, кто использует пересылку, доля пересылаемых писем во всем объеме их почты может быть и 100% (был старый адрес, стал новый, а на старом — пересылка). Если вдруг на их реальном адресе появится жесткая проверка SPF (если, например, ее включит провайдер), то такие пользователи начнут терять входящую корреспонденцию. Сначала — немного (т.к. проверка SPF поддержана малым числом отправителей), потом все больше и больше. При этом и на стороне отправителя, и на стороне конечного получателя все хотят как лучше.

8. Идея о том, что отправитель сообщения прочтет квитанцию о недоставке, поймет, куда на самом деле нужно доставлять сообщение, и переадресует его, требует развернутого комментария:
   1. Системные администраторы — поймут. Но Интернет продолжает расти, доля совсем новых пользователей — довольно большая, а вот они точно не поймут. Да и стандартная (предлагаемая по умолчанию) SPF-квитанция отсылает на англоязычный spf.pobox.com, что для Рунета — не решение.
   2. Собственно, если способ с квитанцией кажется разумным, то почему не внедрить TMDA или какой-то другую карантинную систему с запросом подтверждения от автора письма? Отправитель прочтет квитанцию, нажмет кнопку «я не спамер», и письмо дойдет.

      Однако системы с подтверждением считаются неприемлемыми — потому что порождается много паразитного трафика, а на кнопку подтверждения почти никто не нажимает. Почему же гораздо более сложные действия (прочитать квитанцию, перенаправить письмо по другому пути) — приемлемы?

      Насколько мне известно, те же люди, которые всерьез защищают идею «отправитель прочитает квитанцию», являются одновременно жесткими противниками систем с подтверждениями.

10. Довольно часто встречается случай, когда сообщение является важным для получателя, но практически безразлично для отправителя. То есть отправитель письмо написал, отправил и тем считает свой долг выполненным, а если получатель не может их получить — то это его проблема. В этой ситуации отправитель читать квитанцию и перепосылать письмо не будет.
11. Остаются еще автоматические системы — заказы в интернет-магазинах, регистрация на сервисах и т.п. Ирония заключается в том, что для общения с такими системами часто используются «одноразовые» адреса — пригодные для получения регистрационного письма и не более того. Это делается для предотвращения спама на регистрационный адрес. Одноразовые адреса, естественно, делаются через механизм пересылки.

• Отправитель мог указать -all вовсе не по той причине, что он не любит пересылки. Так рекомендуется в документации, а о проблеме пересылок он мог и не задуматься. Более того, SPF-политику часто формулируют одни люди (системные администраторы), а страдают от нее — другие (сотрудники той же организации).
• То, что пользователи теряют какое-то количество почты самостоятельно (наиболее часто встречающаяся оценка — 0.1%) не означает, что прочие почтовые технологии должны тоже терять почту. Не стоит усугублять проблему.
• То, что какие-то способы фильтрации спама не хороши, не означает, что нужно делать так же плохо в других системах фильтрации.
  

  Выводы

  Несмотря на все описанные выше ужасы, решение, пригодное для массового внедрения отправителями, имеется. Оно заключается в публикации мягкой SPF-политики по умолчанию (т.е. политика должна заканчиваться на ?all или ~all). Судя по всему, так сейчас все и делают — доля статусов softfail и neutral втрое выше, чем у fail (табл. 2). Проблема только в том, что это резко снижает эффективность SPF.

  Второе решение заключается в широком использовании exists — но на сегодня для этого нет готовых решений, придется программировать самостоятельно. Exists, впрочем, создает свои проблемы (см. раздел 5.2).

  Мнение автора: имеющиеся проблемы с пересылаемой почтой приведут к массовому внедрению более мягких SPF-политик, чем это могло бы быть сделано. Авторам технологии SPF следовало бы решить проблему заранее (или выбрать другую технологию), а сегодняшняя ситуация приведет к тому, что SPF будет куда менее полезной для борьбы со спамом, чем это было бы возможно.

  3. SPF-политики «по умолчанию»

  Суть проблемы «политики по умолчанию» заключается в следующем:

  • Стандарт SPF сейчас поддерживает достаточно мало отправителей, поэтому его эффективность невелика.
  • Сам механизм — достаточно удобен, хочется его использовать для всей поступающей почты.
  • В результате, во многих поддерживающих SPF почтовых серверах можно задать «политику по умолчанию» (обычно ее называют best guess) — т.е. при отсутствии SPF-политики у домена, почтовый сервер попытается ее угадать сам.

  Сама по себе идея умолчаний — не так плоха, если используются такие значения, которые не могут ухудшить ситуации. Другими словами, если используются только разрешительные умолчания (например, ‘a/24 mx/24 ?all’).

  Однако, разрешительные умолчания не решают задачи борьбы со спамом (так как ничего не запрещают), а цель внедрения SPF — именно антиспам.

  В результате, в настоящий момент массово внедряются умолчания вида ‘a/24 mx/24 -all’, означающие, что почту от домена можно принимать из подсети (диапазона IP-адресов), где расположен сервер домена (обычно это Web-сервер), а также из подсети, где расположены почтовые серверы домена, и более ниоткуда. Таким образом, если у какого-то отправителя почтовые серверы «на прием» и почтовые серверы «на отправку» расположены в разных подсетях, то почта с такого домена приниматься не будет, даже если она легальна.

  Данная проблема не связана с технологией SPF как таковой, она связана с конкретными реализациями технологии и конкретными системными администраторами, которые настраивают излишне-жестокие правила фильтрации. Похожая проблема связана с использованием «политических» RBL-списков (SPEWS и подобные).

  Таким образом, с учетом «угадывания» SPF политики на принимающей стороне публикация какой-либо (мягкой) 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 августа текущего года.

  К удивлению автора, новая версия протокола несовместима со старой, в частности:

  • Предлагается публикация SPF-данных в специальном типе DNS-записей SPF2. При этом допускается публикация в предлагавшемся ранее типе записей TXT.
  • Предлагается новая спецификация версии протокола: вместо старой строки версии (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», оспариваются следующие тезисы:

  • Поддержка SPF при приеме почты создает избыточную нагрузку на DNS, что может быть проблемой.
  • SPF-правило ‘exists’ является проблемой с точки зрения безопасности получателя почты.

  Полученная критика требует ответов, которые приведены далее.

  5.1. SPF и DNS

  Поддержка SPF на стороне получателя вынуждает почтовый сервер получателя делать DNS-запросы для получения SPF-политики отправителя. Конечно, почтовый сервер делает и другие DNS-запросы, например, получает имя посылающего сервера по его IP-адресу (это необязательно, но практически всегда делается), а также, возможно, делает запросы к RBL.

  Как известно на примере RBL, крупные почтовые сервисы вынуждены кэшировать DNS-запросы, то есть держать у себя локальные копии используемых RBL-списков, а не обращаться к ним удаленно. Это делается именно по той причине, что DNS-запрос может быть достаточно долгим. Скажем, при потоке в 100 сообщений в секунду, каждая лишняя секунда ожидания в почтовом сервере добавляет 100 лишних копий почтовой программы на принимающей стороне. А ведь DNS-таймаут в стандартном DNS-клиенте — до 75 секунд.

  Но в отличие от RBL- баз, сделать локальную копию всех SPF-записей всего мира — мягко говоря, затруднительно.

  Таким образом, мы создаем второй «тяжелый» DNS-запрос, т.е. увеличиваем нагрузку минимум вдвое.

  В случае нормального функционирования DNS, создаваемая SPF дополнительная нагрузка может быть и приемлемой. А может быть — неприемлемой, если без SPF загрузка почтового сервиса и так была близка к предельной.

  Проблемы начнутся, например, если DNS-сервер домена отправителя не отвечает. Более того, таким образом совершенно нетрудно провести DoS-атаку на получателя почты, так как DNS-серверы, к которым будет обращаться SPF-модуль на приемной стороне, выбираются именно отправителем (подстановкой нужного домена отправителя). Делается это так: выбираем (или делаем) домен с DNS-сервером, который не отвечает на запросы, затем шлем письма с отправителем из такого домена и наблюдаем, как почтовые серверы получателя ждут окончания DNS-таймаутов.

  5.2. SPF-метод exists и безопасность

  При использовании метода exists, предусмотренного стандартом SPF, отправитель может, при правильном использовании 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 заключается в двух независимых действиях:

  • Публикация SPF-записей для домена. Это затрагивает исходящую из домена почту.
  • Поддержка SPF в почтовом сервере при приеме почты. Включение такой поддержки повлияет на процесс приема почты.

  6.1. Публикация SPF-записей

  Публикация SPF-политики, несомненно, полезна. Даже если вы не страдаете от спама, рассылаемого от имени вашего домена, явное описание легальных источников почты из вашего домена может помочь прохождению легальной почты от вас через антиспам-фильтры, особенно если на принимающей почту стороне используют додумывание SPF-политики за вас (best guess).

  Описывая SPF-политику, следует явно включить в нее все ваши серверы, с которых может исходить почта. Более простое решение заключается в описании всего адресного пространства.

  Ваша SPF-политика должна быть «мягкой» т.е. оканчиваться на ?all или ~all. В противном случае, у вас могут возникнуть проблемы с теми письмами из вашего домена, которые пересылаются (forward) на пути к адресату.

  Слишком мягкая политика «по умолчанию» тоже может быть воспринята неверно. Если в вашей SPF-политике будет указано +all (т.е. вы явно хотите сказать всему миру, что письма из вашего домена могут приходить откуда угодно), то есть неплохой шанс, что такая политика будет проигнорирована — ибо домены с такими SPF-записями уже используются спамерами.

  6.2. Использование SPF при приеме почты

  При использовании SPF на стадии приема почты необходимо учитывать такие соображения:

  • Распространенность SPF в настоящее время невелика, не более 10% сообщений (в среднем потоке) будут иметь SPF-статус.
  • Использовать статус softfail как признак спама не следует, достаточно большая доля нормальной почты имеет такой статус.
  • Возможны ложные срабатывания на пересылаемой (forward) почте.
  • Заметное количество спам-почты уже сейчас имеет статус pass, имеет смысл игнорировать ‘+all’ в SPF-политике отправителя.

  Другими словами, использовать SPF в качестве дополнительного признака при фильтрации спама — можно. Принятие решений на основе только SPF не принесет большой пользы при фильтрации спама, но может привести к отвержению нормальной почты.