подмена поля FROM

[broker 30]

как всем давно, давно известно основная прчина СПАМА - это недостаток в протоле SMTP, который позволяет произвольным образом указывать или не указывать совсем обратый адрес (т.е заполнять поле FROM).

данный недостаток, лёг в основу некоторого вида атак - mail СПУФИНГ.

последствия этого вылились не только в проблеме СПАМА, но и в ПРОБЛЕМЕ ФИШИНГА, а так же распрострении вредоносов (масс-майлеров)

Вопрос: какие есть методы борьбы с e-mail спуфингом?

самые простые:

1. проверять mx

2. для корпораций не принимать почту с домена home извне периметра

Должны ли этим заниматься Антиспамовые решения?

[Сергей Ильин 1538]

есть такая штука как SPF (или аналог от Microsoft CallerID), ее пытаются внедрить уже довольно давно, но работать это будет только при условии массового распространения.

Если крытко, то в DNS вносятся доп. записи для каждого домена, т.е. диапазон IP, с корорых может ходить почта, подписанная адресами с этого домена.

Кстати, я помню, что Яндекс заявлял, что стал поддерживать SPF на своем почтовом ресурсе.

Добавлено спустя 44 секунды:

Многие антиспам-решения уже поддерживают SPF.

[broker 30]

SPF

да это хорошее решение проблемы, но в теории может возникнуть ситуция подобная использованию RBL.

некоторым владельцам SMTP просто "всё-равно" попали их релее в RBL или нет.

Поэтому данный метод относится к вероятностным

[Кирилл Керценбаум 671]

Вопрос: какие есть методы борьбы с e-mail спуфингом?

1. DNS Lookup - хороший, но очень рискованный способ, так как не всегда это возможно.

2. Написание контентных фильтров, которые позволяют анализировать все тела письма, в том числе и чтобы поле TO не соответствовало полю FROM, пользуясь Perl скриптами это вполне возможно.

3. Использование Sender Policy Framework (SPF) и Sender ID, очень хорошая технология, но опять же мало поддерживаемая.

А вообще, это проблема разработчиков антиспам решений бороться с данным видом угроз, декларируется что например BrightMail технология (Symantec Mail Security for SMTP) умеет с этим бороться посредством Body Hash Filter, BrightSig2 Filter, IntSig Filter технологий.

[alk 0]

Должны ли этим заниматься Антиспамовые решения?

Учитывать результаты проверки MX, роутабельности обратного адреса, проверок по SPF и т.п. --- должны. Черные списки (от кого принимать или не принимать почту) это уже дело настройки почтовой системы, то есть дело системного администратора.

есть такая штука как SPF (или аналог от Microsoft CallerID), ее пытаются внедрить уже довольно давно, но работать это будет только при условии массового распространения.

Учитывая то, что после вмешательства Столлмена рабочая группа MARID прекратила свое существование, то массовое внедрение SPF или CallerID сомнительно.

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

2. Написание контентных фильтров, которые позволяют анализировать все тела письма, в том числе и чтобы поле TO не соответствовало полю FROM, пользуясь Perl скриптами это вполне возможно.

Содержимое конверта письма в тело письма может и не попасть. Соответственно, исследование тела письма в целях борьбы со спуфингом не очень эффективно.

3. Использование Sender Policy Framework (SPF) и Sender ID, очень хорошая технология, но опять же мало поддерживаемая.

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

BrightMail технология (Symantec Mail Security for SMTP) умеет с этим бороться посредством Body Hash Filter, BrightSig2 Filter, IntSig Filter технологий.

Насколько я понимаю, все перечисленные технологии к проверке валидности адресов отправителей отношения не имеют, это контентные сигнатуры.

[Кирилл Керценбаум 671]

Насколько я понимаю, все перечисленные технологии к проверке валидности адресов отправителей отношения не имеют, это контентные сигнатуры.

Совершенно точно, но именно эти контентные сигнатуры, содержащие в себе эвристические механизмы, должны бороться в том числе и со спуфингом

[broker 30]

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

Вы описали очень сложный механизм. Сложность его заключается в следующем:

-большинство провайдеров закрывают свободный доступ к SMTP т.е. появляется авторизация.

-провайдер отслеживает колличество отосланной почты.

-троян попавший на компьютер должен найти параметры авторизации и применить их.

Можно предположить, что троян таким образом будет отсылать по n писем. n < критического предела. Рано или поздно релей попадёт в RBL.

короче

rbl+контекстный фильтр отловят этот спам

А антивирус через неделю отловит троян