РАЗДЕЛЫ
Архив
|
Технология SPF — за и противАлексей Тутубалин, ЗАО «Ашманов и Партнеры» ≡ | архивная статья | 27.07.2004 13:14 Анализ предлагаемых решений и опыт практического использования метода SPF Аннотация: В статье анализируется антиспам-технология SPF (Sender Policy Framework), ее основные свойства, достоинства и недостатки. Помимо теоретического анализа, описан опыт практического использования этой технологии в имеющихся на сегодняшний день условиях. 1. Верификация отправителя и проблема спама Говоря о проблеме спама («мусорной почты») необходимо прежде всего определить обсуждаемое явление. В данной статье под спамом понимаются «анонимные массовые рассылки электронной почты, как правило, имеющие рекламный характер». Данное определение удовлетворительно определяет спам как массовые рекламные рассылки, производимые профессионалами для зарабатывания денег. А ровно от этого бизнеса сейчас и страдают все пользователи интернета. Прочая «нежелательная почта» (технические сообщения систем электронной почты, неанонимные рассылки с возможностью отписки, поздравительные открытки, посланные по ошибке письма) в данной статье как «спам» не рассматривается. Анализ технических данных приходящего спама показывает такие особенности:
1. Поддельный отправитель 2. Поддельные заголовки 3. Достаточно часто выдается и поддельный параметр SMTP HELO
Таким образом, складывается неутешительная картина – фильтрация по черным спискам (RBL) не дает достаточно хорошего результата (так как в большинство списков RBL адрес отправителя попадает уже постфактум – по факту рассылки), при этом количество ложных срабатываний (ложной классификации нормальных e-mail сообщений как спама) при использовании RBL составляет до единиц процентов. Подробнее см. статью автора «RBL-вред или польза». Раз фильтрация по IP-адресам работает плохо, то у разработчиков и администраторов антиспам-систем возникает понятное желание верифицировать другие параметры, передаваемые в SMTP-сессии: адрес отправителя и/или данных, предоставляемых в SMTP HELO. Для анализа этих данных не нужен доступ к тексту сообщения, "плохие" письма можно отвергать, не принимая их. К несчастью, протокол SMTP не предполагает верификации отправителя. Такие средства нужно разработать, обсудить, протестировать, принять как стандарт и повсеместно внедрить. За последний год было предложено около десятка различных технологий верификации отправителя. На сегодняшний день наибольшую известность получила технология SPF («>Sender Policy Framework», ранее она называлась «Sender Permitted From»). Помимо известности, началось ее относительно массовое внедрение, в том числе и у крупнейших игроков интернет-рынка (AOL, Google, Altavista, Earthlink и т.д.). В последние месяцы отмечена и активная PR-компания, нацеленная на всех пользователей Интернета: крупные игроки рынка сообщают о разработке (или процессе разработки) или внедрении (или начинающемся внедрении) подобных механизмов. Таким образом создаётся впечатление, что проблема спама если и не решена окончательно, то скоро будет решена (и именно тем или иным способом верификации отправителя). Все предлагаемые технологии верификации отправителя на сегодня имеют статус «предварительное описание» (в виде «internet draft» или RFC); в качестве общепринятых стандартов будут приняты одна или две технологии. Наибольшие шансы стать общепринятыми имеют SPF (как получившая относительно широкое распространение) и SenderID (технология, поддерживаемая Microsoft). На сегодняшний день вопрос о поддержке той или иной технологии в рамках отдельно взятой почтовой системы может быть сформулирован так:
Далее в статье вопрос, «какой механизм внедрять» не обсуждается, поскольку на сегодня поддержка в программном обеспечении реализована только для SPF. Ответу на остальные три вопроса (эффективность, риски, трудоёмкость) и посвящена данная статья. 2. Описание технологии 2.1 Общие принципы Технология верификации отправителя «Sender Permitted From» была предложена в 2003-м году. Спецификации несколько раз изменялись, последний вариант опубликован 11 июля 2004 года. Вместе со спецификациями менялось и название, так что сейчас технология называется «Sender Policy Framework». В январе 2004 г. о тестировании SPF объявила компания AOL, эта инициатива была поддержана и другими крупными участниками рынка. Суть технологии заключается в следующем: Публикуемые владельцем домена данные далее будут называться SPF-записью или SPF-политикой (так как владелец домена фактически публикует рекомендуемую им политику обращения с e-mail в зависимости от IP-адреса посылающей сообщение стороны). 2.2 Публикация SPF-политики Если какой-то домен (его владелец/администратор) хочет поддержать SPF для целей верификации сообщений, исходящих из данного домена (т.е. имеющих адрес отправителя в этом домене), то для этого в DNS-записи домена добавляется строка приблизительно такого вида:
Данный пример означает:
b. Сервера с именем www.another.domain.com В терминах технологии SPF, ‘ip4’, ‘a’, ‘all’ – это «механизмы» (mechanism), а префиксы (+,-,?,~) перед названием механизма так и называются «префиксы» (prefix). Поддерживаются такие механизмы (подробнее см. описание формата записей SPF):
При анализе SPF-записи все механизмы перебираются слева направо, и если какой-то из них описывает IP-адрес посылающей сообщение стороны, то механизм «сработал». Тогда следует выполнить действие, рекомендуемое владельцем домена. Действия определяются префиксами перед механизмами:
- (минус) запрещающий префикс, сообщение принимать не рекомендуется. ~ – «нейтрально-отрицательный» префикс, означающий «адрес посылающей стороны может быть не в разрешенном диапазоне). Сообщение рекомендуется «не отвергать, но возможно, подвергнуть дополнительным проверкам. ? – «нейтральный» префикс, указывает на принципиальную неполноту данных (то есть владелец домена не может указать все IP-адреса источников почты из своего домена). Кроме механизмов, определены следующие модификаторы:
exp:строка – определяет диагностическое сообщение, выдаваемое при неприеме почты. Таким образом, для поддержки SPF на посылающей стороне достаточно перечислить в DNS-записи все адреса почтовых серверов, посылающих почту "наружу", после чего протокол будет поддержан. Конечно, реализация сложных случаев (макросы с exists) потребует специального ПО, но для простых случаев exists не нужен. SPF-записи помещаются в стандартные для DNS записи типа TXT, следовательно, никакой модификации программного обеспечения DNS серверов и клиентов не требуется 2.3. Использование данных SPF при приеме почты Принимающая сторона по получении MAIL FROM: user@domain.name в SMTP-сессии делает DNS-запрос, получает SPF-запись и сравнивает IP-адрес посылающей стороны SMTP-сессии с SPF-политикой. Результатом является рекомендация по приему или отвержению письма. Нужно сказать, что имеющиеся на сегодня общедоступные реализации фильтрации спам-почты на базе технологии SPF на принимающей стороне воспринимают рекомендации буквально – отвергая сообщение, для которого сработал механизм с префиксом ‘-‘ и принимая в противном случае почту от отправителя. Для поддержки SPF на этапе приёма почты необходима модификация ПО почтового сервера. Необходимая функциональность реализована в библиотеке libspf2 (распространяется как OpenSource под лицензиями GNU и BSD – на выбор). Существуют также готовые наборы правок (патчей) и/или клиенты для большинства распространенных почтовых серверов (MTA). Резюме: Поддержка SPF на стороне отправителя: публикация SPF-политики домена может быть (в простом случае) произведена очень быстро, это не требует каких-либо существенных затрат.Поддержка SPF на этапе анализа принимаемой почты: анализ SPF-политики для принимаемой почты требует модификации ПО почтовых серверов, однако для основных вариантов и версий существуют готовые и работоспособные решения. Таким образом, решение о поддержке SPF должно приниматься на основании оставшихся критериев: того, приведет ли эта поддержка к (частичному) решению проблемы спама и не приведет ли она к каким-либо потерям «нормальной» почты. 2.4. Проблемы технологии SPF Помимо понятных достоинств, SPF и аналогичные технологии имеют весьма существенный недостаток: отправитель сообщения не знает его дальнейшего пути к получателю; если сообщение будет пересылаться (forward), то в процессе пересылки могут быть задействованы почтовые серверы, не указанные отправителем как разрешенные. Другими словами и крупными буквами: ПРИ БУКВАЛЬНОМ ИСПОЛНЕНИИ SPF-ПОЛИТИКИ МОЖЕТ БЫТЬ ОТВЕРГНУТА НОРМАЛЬНАЯ ПОЧТА (НЕ СПАМ). Эта проблема является настолько серьезной, что требует отдельного внимательного рассмотрения ниже. 2.4.1. Верификация отправителя и пересылка почты Сообщения электронной почты обычно пересылаются напрямую (end-to-end) от отправителя к получателю. Однако это не так в следующих случаях:
Оба случая не являются редкими или экзотическими: резервные почтовые серверы предназначены для повышения надежности почтовых систем; пересылка почты с адреса на адрес является широко используемой, например, для сбора сообщений с нескольких адресов в один почтовый ящик. Резервные почтовые серверы Резервные почтовые серверы используются для приема почты в случаях, когда основной почтовый сервер организации по каким-либо причинам недоступен. После восстановления доступности, резервный сервер доставляет почту на основной сервер. E-mail адрес отправителя при этом не изменяется. Предположим, мы доставляем почту с user@sender.com на user@receiver.com через резервный сервер backup.receiver.com: Sender.com -> backup.receiver.com -> receiver.com В момент приема на receiver.com будет проверяться SPF-политика домена отправителя (sender.com), а SMTP-сессия инициирована с backup.receiver.com. Но отправитель про резервные серверы получателя ничего не знает и адреса backup.receiver.com в своей политике не указал. В случае, когда для sender.com указана запретительная политика по умолчанию (-all), то receiver.com получает рекомендацию отвергнуть письмо. Таким образом, для нормального приема почты с резервных серверов необходимо предпринять следующие действия:
2. Основной почтовый сервер должен принимать почту с резервных серверов без SPF-проверки. В случае штатной пересылки почты внутри организации (скажем, с входного почтового сервера под Unix в почтовую систему под Windows) проверка SPF должна быть включена только на входном сервере. К сожалению, вышеперечисленные пожелания не всегда выполнимы. В частности, резервные почтовые сервера могут принадлежать другой организации (сервис-провайдеру или партнеру), которая не хочет реализовывать проверку SPF на них. В таких случаях, реализовать проверку SPF-политики для почты, приходящей через резервные серверы невозможно (на резервном сервере – отказываются, проверять во время получения почты с резервного сервера – не имеет смысла, так как отправитель про резервные серверы получателя ничего не знает). Пересылка почты Пересылка (forward) почты используется в интернете достаточно широко. Есть форвард-сервисы (обеспечивающие, например, "вечный" почтовый адрес), большинство бесплатных почт поддерживает пересылку, достаточно часто пересылку настраивают в "частном порядке". Как правило, при пересылке сохраняется исходный адрес отправителя – это необходимо, в частности, для корректной доставки квитанций о недоставке письма (bounce messages). Рассмотрим такую простую схему:
(пользователь user@sender.com шлет почту на user@mailbox.com, это сообщение пересылается "настоящему получателю" user@receiver.com). Если домен sender.com опубликовал SPF-политику (например – "вся почта идет только с mail.sender.com"), а почтовый сервис на receiver.com ее проверяет, то данное письмо будет отвергнуто, так как политика отправителя (sender.com) не предполагает, что письмо может перепосылаться (с mailbox.com). Эта проблема является ключевой при внедрении практически любой технологии верификации отправителя. Естественно, ее нужно каким-то образом решать, и на сегодня предлагаются такие решения: Достоинства и недостатки схемы с exists описаны в отдельном разделе ниже, а все остальные решения обладают очевидными недостатками:
2. Пересыльщик становится ответственным за пересланный спам. Другими словами, если на user@forwarder.com (см. пример) придет спам-сообщение, его отправитель будет подменен на что-то@mailbox.com. Во многих случаях такая подмена identity – неприемлема, ибо с точки зрения обычного пользователя mailbox.com становится "спамером". Помимо общих недостатков, есть и специфические для каждого из вариантов решения проблемы пересылок почты: А. Использование подмены отправителя приводит к таким дополнительным проблемам: Б. Передача дополнительных данных в SMTP-cессии приводит к тому, что необходимо модифицировать ПО почтовых серверов (причем, готовых решений на сегодня нет, есть только предварительные спецификации). Эта модификация должна быть произведена на всех пересылающих серверах и на всех принимающих серверах. В. Извлечение данных о пересыльщике из заголовков писем приведет к таким усложнениям: 2.4.2. Механизм exists Механизм exists предназначен для «тонкого» (fine-grained) управления SPF-политикой отправителя. Суть механизма заключается в следующем:
2. Полученное доменное имя проверяется на существование в DNS. 3. Если имя существует, то механизм сработал; если не существует – не сработал. Например, если в SPF-политике домена example.com присутствует строка ‘+exists:%{l}.%{i}._spf.example.com’, то для отправителя user@example.com и письма, посылаемого с адреса 127.0.0.1, будет составлено имя user.127.0.0.1._spf.example.com. Если на DNS-запрос для такого имени будет получен ответ, то письмо рекомендовано к получению. Таким образом, отправитель может сформировать DNS-записи для всех существующих пользователей своего домена в поддомене _spf.example.com, опубликовать политику ‘+exists:%{l}._spf.example.com’ и таким образом разрешить пересылку (forward) всех писем для существующих пользователей и запретить – для несуществующих. При реализации такого подхода придется смириться со следующими трудностями: Требуется либо поддерживать вручную в DNS-зонах списки возможных отправителей почты из домена, либо реализовать специализированное ПО для этой цели. Если отправитель рассылает много почты (сервис бесплатной почты, например), либо спамеры рассылают много почты от его имени, то использование exists совместно с макросами (включающими IP или имя пользователя) создаст большую дополнительную нагрузку на DNS-серверы отправителя. К сожалению, использование механизма exists создает и серьезные проблемы безопасности, как для отправителей, так и для получателей:
2. Возможность рассылки спама. Если реализация SPF-политики с механизмом exists разрешает пересылку почты, то эта же политика будет разрешать и спам – пусть и с валидными обратными адресами., так как верифицировать адреса можно через ту же политику. Ведь пересылку почты от user@domain невозможно отличить от посылки спама с поддельным отправителем user@domain. 3. Возможность отправителю следить за путем почты в системе получателя. Если недобросовестный отправитель создал SPF-политику с использованием exists и макросами %{l},%{i}, то при каждой проверке SPF-политики он будет получать данные: 2.4.3. Проблемы SPF – резюме На сегодняшний день SPF является несовместимой с пересылками почты, так как оба варианта решения "проблемы пересылок" неудовлетворительны: 2.5. Использование SPF для фильтрации спама Механизм SPF разрабатывался, в первую очередь, как средство борьбы со спамом. Предполагается, что прямое следование объявленной SPF-политике домена поможет, по меньшей мере, не принимать письма с подделанным адресом доменов, поддержавших SPF, как почтовых служб, так и других организаций. Рассмотрим подробнее, так ли это. 2.5.1. Использование SPF как "белого списка" Как следует из схемы работы SPF, E-mail сообщение рекомендовано принимать, если в SPF-политике указано, что с данного IP возможна посылка сообщения с данным адресом отправителя. По всей видимости, для таких сообщений должны быть ослаблены или выключены антиспам-фильтры (а в чем иначе может заключаться использование разрешительных SPF-политик?). Если же такая схема будет кем-либо реализована, то возможны следующие приёмы ее недобросовестного использования:
Таким образом, принимать на веру чужую разрешительную SPF-политику никак нельзя (особенно, если в ней записано +all, +ptr или указан широкий диапазон адресов). С другой стороны, наличие объявленной SPF-политики у крупных игроков рынка (таких как AOL и Hotmail) может сильно помочь отличить "настоящую" почту этих систем от "поддельной". Следовательно, чужие SPF-политики придется использовать выборочно (AOL используем, а super-puper-spamer.da.ru – не используем). Итак, возникает задача отбора «хороших» SPF-политик, ведения списка «хороших доменов» (вручную или через репутационные сервисы) и построения прочей необходимой инфраструктуры работы с SPF. 2.5.2. Использование SPF как "черного списка" Использование запрещающих SPF-политик (использование модификатора «-») ведет к уменьшению количества принимаемой почты (иначе, в чем тогда состоит запрещение?). Среди непринятой почты обязательно будет спам, а значит – количество дошедшего до получателей спама – уменьшится. В то же время, потери пересылаемой почты в данной схеме – возможны и обязательно будут (как показывают эксперименты, см. ниже). Другими словами, жесткие SPF-политики ("-all") можно использовать, только если есть абсолютная уверенность в отсутствии пересылок почты или в том, что все транзитные системы поддерживают SPF в том или ином виде (подмена отправителя, расширения SMTP-протокола). Подробнее об этом сказано выше. 2.5.3. Проблемы производительности Каждая проверка SPF-записи – это как минимум одно обращение к системе DNS, а при использовании механизмов "a", "ptr", "include","exists" возникают дополнительные обращения. Спецификация SPF явно указывает, что предельное количество обращений при проверке одного сообщения не должно превышать 20. Как известно по опыту эксплуатации RBL (которые тоже реализованы поверх механизма DNS), в условиях высокой загрузки почтовой системы добавление каждого нового RBL-сервиса (т.е. дополнительного DNS-запроса на каждое сообщение) заметно ухудшает ситуацию. Крупные почтовые системы вынуждены эксплуатировать локальные копии баз данных RBL, ибо дополнительные DNS-обращения становятся неприемлемыми с точки зрения нагрузки. А если какой-то DNS-сервер не отвечает, то это может означать остановку прохождения почты (DNS-таймаут может составлять 75-90 секунд, такое ожидание при потоке почты в сотни сообщений в секунду абсолютно неприемлемо). Заметим, что самостоятельное создание системными администраторами всего мира локальных копий SPF-записей для всех имеющихся доменов представляется абсолютно нереальным. Конечно, очень большая доля почты приходит с крупных почтовых сервисов и из крупных компаний, поэтому DNS-запросы к SPF будут повторяться, а значит, ситуация несколько облегчится за счет кэширования ответов DNS. В то же время, при использовании механизма exists, каждое новое письмо может порождать уникальное имя домена и соответственно – запрос, который не был сохранен в DNS-cache ранее. По мере распространения SPF в мире проблема количества DNS-запросов будет усугубляться, в пределе – каждое принимаемое и отправляемое сообщение будет вызывать DNS-запросы к SPF-политике, что потребует дополнительного оборудования на крупных почтовых системах и в больших корпорациях. 2.6. Выводы и рекомендации 2.6.1. Публикация SPF-записей Очевидно, что публикация SPF-записей не может ухудшить ситуацию со спамом. В то же время, слишком жесткая политика может приводить к потерям исходящей из вашей системы почты в процессе транзитной пересылки. Таким образом, можно рекомендовать публикацию SPF-политики с учетом следующих соображений:
2. Политика должна описывать все используемые исходящие адреса, если забыть какой-то исходящий сервер, то почта с него может необоснованно посчитаться спамом; 3. Механизм exists должен использоваться только при крайней необходимости, так как он порождает массу дополнительных проблем. 2.6.2. Использование SPF при приеме почты Буквальное следование чужим SPF-политикам может привести как к потерям почты, так и к пропускам спама. Таким образом, может быть рекомендовано использование SPF-данных как дополнительной информации для антиспам-фильтров, но окончательное решение о пропуске или отвержении сообщения только на основании SPF принимать не следует. 3. Опыт практической эксплуатации SPF 3.1. Описание эксперимента Прежде чем написать данную статью, автор провел практические исследования применимости SPF на практике в настоящее время. Для этого поддержка SPF была включена на личном почтовом сервере автора (домен lexa.ru) и на сервисе "Спамтест". Условия проведенного эксперимента необходимо описать более подробно: Lexa.Ru – личный домен автора, зарегистрированный в 1996-м году. С тех пор E-mail адрес автора не менялся и использовался практически повсеместно – в конференциях Usenet, при регистрациях на части сайтов, в форумах, публиковался на WWW-сайтах. В результате автор сейчас получает 600-1000 спам-сообщений в сутки. В эксперименте использовалась подборка спама за неделю (~3800 сообщений). Спам-сообщения в режиме реального времени отбирались антиспам-фильтром и были впоследствии специально просмотрены на предмет ложных срабатываний (которых не оказалось). Сервис Спамтест – это бесплатный сервис разметки спама, пересылающий почту пользователям. Из опыта известно, что пользователи тоже, как правило, ставят пересылку на "Спамтест". Таким образом, проблемы с пересылкой должны были проявиться максимально широко. Анализировались приблизительно 165 тысяч писем, прошедших через Спамтест в реальном времени. В обоих случаях поток почты анализировался в реальном времени, то есть состояние DNS было актуальным. Никаких решений на основе SPF-данных не принималось, SPF-статус сообщения просто записывался в лог-файл и заголовок сообщения. 3.2. SPF как фильтр спама Результаты потенциального использования SPF как спам-фильтра (для домена www.lexa.ru) приведены в таблице:
Таким образом, на сегодняшний момент SPF способно обнаружить 1.7% спама при 0.18% явных пропусков и 7% сообщений, для которых указана нейтральная политика. При этом не поддерживают SPF домены, трафик от которых составляет 91.5%. Если при увеличении популярности SPF эти соотношения сохранятся, то во всем спам-трафике будет ~80% "нейтральных" статусов, 18% обнаруженного спама и 2% явных пропусков. Естественно, с ростом популярности SPF общая картина должна измениться, но маловероятно, что средняя SPF-политика будет ужесточаться – в настоящее время SPF внедряют технологические пионеры ('early adopters'), которые, во-первых, все делают более аккуратно, а во-вторых, более озабочены проблемой детектирования спама, чем возможными потерями нормальной почты. При массовом внедрении приоритеты будут другие, и мы увидим гораздо меньшую долю '-all', чем сейчас. Отдельно хочется сказать о пропусках. Все зафиксированные нами пропуски использовали исходящий адрес в доменах с политикой '+all'. 3.3. SPF и проблема пересылок Чтобы не загромождать текст техническими деталями, результаты тестирования SPF на сервисе Спамтест суммированы в 4 группы: pass (SPF рекомендует принять письмо), fail (рекомендация "отвергнуть письмо"), not supported (SPF-статуса нет или ошибка DNS) и neutral (суммированы neutral и softfail). Статусы Spamtest – SPAM, Probable Spam, Not Detected – отвечают результатам классификации сообщений по содержанию и заголовкам (RBL при классификации не использовались). Результаты приведены в таблице:
Как видно из таблицы, при использовании пересылок (а на сервис Спамтест в основном пересылают почту) качество детектирования спама по SPF-данным не растет и составляет 1-1.5%. Если SPF поддержат все (а не 5-15% отправителей), то доля детектированных сообщений вырастет в 6-20 раз, т.е. до 6-30%. При этом рекомендация «пропустить спам» встречается вдвое чаще, чем «отвергнуть спам» – что происходит из-за того, что часть крупных почтовых сервисов (gmx.de, mail.ru) при пересылке подменяют адрес отправителя на свой (таким образом, упомянутые почтовые сервисы являются SPF-совместимыми). С точки зрения пропусков нормальной почты (статус Spamtest Not Detected), SPF ведет себя довольно плохо, отношение pass/fail 5:1 означает примерно 16 процентов ложных срабатываний при гипотетическом условии, что SPF поддерживают все отправители. 3.4. Выводы из экспериментов По результатам экспериментального использования SPF можно сделать такие выводы:
2. «Средняя» SPF-политика на сегодня является достаточно либеральной и включает или «?all», или «~all» – достаточно либеральные политики, что не позволяет на сегодня говорить об уверенной детекции спама. Доля обнаруженного спама не превышает 1-2%, что крайне мало. 3. SPF уже обходится спамерами. Пусть недобросовестное использование SPF сейчас обнаруживается в небольшом количестве, но и распространенность технологии на сегодня невелика. 4. Доля потенциальных ложных срабатываний на пересылках будет достаточно заметной. При повсеместном введении SPF – до единиц процентов. 4. Заключение В начале данной статьи были сформулированы вопросы, возникающие при внедрении дополнительных технологий электронной почты. В конце статьи сформулируем ответы на них: 1. Эффективность SPF как механизма фильтрации спама на сегодня крайне невелика. В настоящий момент доля распознаваемого спама составляет 1-2%; в случае повсеместного внедрения SPF качество распознавания может повыситься до 10-30%. При этом в механизме SPF имеются потенциальные проблемы, которые могут быть использованы спамерами для обхода SPF-фильтрации. 2. Трудоемкость внедрения:
b. Внедрение поддержки SPF при приеме почты требует модификации программного обеспечения почтовых серверов. Для большинства распространенных серверов такая поддержка уже существует. 3. Риски от внедрения SPF:
b. Учет рекомендаций SPF-политики отправителя при приеме почты в настоящее время чреват потерями почты, либо пропусками спама. 4. Прочие проблемы:
b. Технология SPF содержит проблемный механизм «exists», его использование может создать проблемы безопасности как для отправителей почты, публикующих политику с exists, так и для получателей, анализирующих ‘exists’ отправителя, а также рост нагрузки на почтовые системы. Кроме ответов на поставленные вопросы, можно сформулировать еще два дополнительных вывода: 5. Доверять SPF-политике произвольного домена не следует. Она может быть слишком мягкой – и тогда появится много спама с отправителем из этого домена. Она может быть излишне жесткой – и тогда будет теряться много почты при пересылках. Ясно, что над SPF должна появиться дополнительная инфраструктура, в виде списков «доменов с правильной политикой» или репутационных сервисов, или чего-то в этом духе. 6. SPF не может использоваться изолированно. Использование SPF-данных как указание «принимать» или «не принимать» данное сообщение без дополнительного анализа приведет к пропускам спама или потере почты. Следовательно, данные SPF должны использоваться как дополнительная информация для спам-фильтров, дополняя другие технологии фильтрации спама. комментарии(19) разделы: Материалы по теме
Другие |
Последние комментарии
Гость про Суд велел "Твиттеру" сдать сторонников WikiLeaks (12)
Гость про Книгоиздатели начали судиться с торрентами (2)
l_e_x_a про "ВКонтакте" принудительно протестирует пользователей (35)
andrey_kadetov про Google назвал Facebook "ловушкой без выхода" (6)
volv про День папуасского робошахтёра (14)
l_e_x_a про Русские кликботы признаны самыми активными (11)
все комментарии looli спрашивает: Земля вампиров смотреть онлайн в HD качестве looli спрашивает: Зеленый Фонарь смотреть онлайн в HD качестве looli спрашивает: Защитник смотреть онлайн в HD качестве looli спрашивает: Запретная зона смотреть онлайн в HD качестве looli спрашивает: Закон доблести смотреть онлайн в HD качестве looli спрашивает: Вышибала смотреть онлайн в HD качестве looli спрашивает: Встречный ветер смотреть онлайн в HD качестве looli спрашивает: Все любят китов смотреть онлайн в HD качестве |
Copyright © 2001-2020 «Вебпланета». При перепечатке ссылка на «Вебпланету» обязательна.