LINUX.ORG.RU

Проблема с Sender ID


0

0

Документы, описывающие SPF-Classic (v=spf1) и Sender ID (spf2.0) находятся на рассмотрении в rfc-editor.org, однако документ Sender ID имеет некоторые противоречия с интерпретацией предыдущих стандартов, включая v=spf1.

В связи с этим, сегодня была подана апелляция в соответствующую инстанцию об удалении трёх букв и одного знака препинания из спецификации spf2.0.

Эта апелляция станет восьмой апелляцией в истории соотв. инстанции IESG.

>>> Подробности

★★★

Проверено: Shaman007 ()

P.S. В данном контексте слово из трёх букв не является матерным.

Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.

Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom", provided no record starting with "spf2.0" exists.

Читателю предлагается найти четыре отличия.

km ★★★
() автор топика
Ответ на: комментарий от km

>Читателю предлагается найти четыре отличия.
Ты такие задание diff_у давай, не напрягай честнОй народ.

sdio ★★★★★
()
Ответ на: комментарий от Deleted

Неправда. Четыре отличия, каждое по одному байту!
;-)

anonymous
()
Ответ на: комментарий от anonymous

> diff показывет построчные изменения.

vimdiff

wRAR
()

У меня стойкое ощущение, что автор новости курил что-то забористое, причем на пару с тем, кто эту новость пропустил. Давайте еще такие новости постить: "в текущей разрабатываемой версии mono, файле foo.c на 149 строчке был удален лишний пробел. Это уже 253 ревизия файла foo.c".

Даже если в новости и содержится какой-то смысл, важность его неплохо бы пояснить в ней же. А если практического смысла для заглавной страницы lorа нет, то нефиг такое пропускать. ИМО.

anonymous
()

SPF слишком малоэффективен, пока его не начнут использовать все, все его не начнут использовать потомучто пока он слишком малоэффективен.

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

При текущей реализации оно имхо больше проблем порождает чем решений.

realloc ★★★★
()
Ответ на: комментарий от realloc

мы это уже обсуждали. все его начнут использовать тогда когда MSN, AOL и ещё пара крупных контор (навроде Google) будет игнорировать правило "~"

aim1159 ★★★★★
()
Ответ на: комментарий от aim1159

> мы это уже обсуждали. все его начнут использовать тогда когда MSN, AOL и ещё пара крупных контор (навроде Google) будет игнорировать правило "~"

А они этого делать не станут, поа 95% (от общающихся с ними) у себя записи не пропишет, а они не пропишут. Вот и получается замкнутый круг.

realloc ★★★★
()
Ответ на: комментарий от aim1159

В какую это сторону они начнут игнорировать softfail ('~')?

km ★★★
() автор топика
Ответ на: комментарий от realloc

Ну ведь всегда нужно с чего-нибудь начать?

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

Влияет на производительность? Не сильнее SpamAssassin. :-) А ведь если письмо имеет статус SPF-fail, то оно просто не принимается, в итоге имеем выигрыш и в производительности (не надо будет вызывать SpamAssassin и/или антивирус), и в объёме ненужного трафика (письмо отвергаем сразу после MAIL FROM, или даже HELO/EHLO). Вы же всё равно узнаёте запись PTR, на один DNS-запрос больше, на один меньше -- разница небольшая.

Да и вообще, SPF пока ещё даже не был признан стандартом, а уже столько народу использует! И Яндекс, и Гугл, и AOL!

К.

km ★★★
() автор топика
Ответ на: комментарий от realloc

Ну как вы сами уже заявляли, многие записи-то прописывают, проблема в том, что далеко не все эти записи в данный момент проверяют. ;-)

km ★★★
() автор топика
Ответ на: комментарий от km

> Ну как вы сами уже заявляли, многие записи-то прописывают, проблема в том, что далеко не все эти записи в данный момент проверяют. ;-)

Я вот то же прописываю. :) А проверять пока смысла большого не имеет.

realloc ★★★★
()
Ответ на: комментарий от realloc

И я прописываю, насколько позволяют провайдеры, и проверял бы, да вот пока такой возможности нет (читай "провайдер не предоставляет данной опции").

А вот вы сами просто рассудите -- мне, например, очень часто приходит спам, который якобы отсылается с моего сервера (либо мой домен в HELO/EHLO, либо в MAIL FROM). Я могу прописать SPF для таких доменов. Так вся прелесть SPF в том, что такой спам, даже если никто кроме меня не будет использовать SPF, меня доставать не будет. ;-)

km ★★★
() автор топика

Народ, ставьте себе smc-milter для senmail или что-нибудь похожее для своего MTA. Простая проверка входящей почты на соответствие уже существующим правилам отправки почты (проверка обратного адреса и проч) останавливет около 90% спама безо всяких заморочек с DNS.

Shrike
()
Ответ на: комментарий от Shrike

Ну и посмотрел я описание "вашего" smc-milter, так у него заморочки с DNS ещё приличнее... SPF отдыхает...

km ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.