Борьба со спамом путем подтверждения сервера-отправителя. #256326

Предлагаю способ борьбы с почтовым спамом, который не потребует изменения протокола POP3/SMTP. Каждый почтовый сервер выбирает себе открытый и тайный ключ. Открытый ключ он любому желающему выдает по запросу. При отправке письма сервер подписывает письмо своим ключем. Таким образом, получатель, чтобы убедиться, что письмо пришло именно от данного сервера, достаточно проверить подпись с помощью открытого ключа. Письма, отправленные не с того сервера, что заявлены автоматически считаются спамом. Достоинство данного способа в том, что любой сервер может начать подписывать письма, не ожидая, пока к этому процессу подключатся другие, т.е. инициатива будет не со стороны клиента-пользователя, а со стороны почтовой службы. Достаточно, чтобы крупные почтовые узлы начали подписывать письма и после этого спам будут рассылать лишь пару маргинальных серверов, которых достаточно быстро можно будет включить в спам-листы. Другой вариант проверки подлинности сервера-отправлителя является менее надежным, но тоже имеет место быть. Например, сервер Б передает серверу А письмо, в котором содержится информация о том, что это письмо было передано на сервер Б с сервера В и сервер А начинает дальнейшую доставку письма отправителю. Однако при этом он может выборочно проверить, действительно ли были передачи в цепочке. Для этого может быть использовано или подпись сервером письма или же журнал отправленных сервером писем.

Ты чо...фиксин ? Щас 99% спама идет через зомби-сети. Троянчика поймал и усе - через тебя пойдет куча спама...

выключай уже свой "генератор бреда", хватит на сегодня

+1. Причем большичнство юзеров не знают, что спам отправляется с их компов :)

да ладно, отправитель то в таких письмах укаызвается не фиксин @ mail.ru а jkasdjflkasjd@mail.ru не гоните. Если сервер увидет, что с мыла васи пупкина идет 10000 одинаковых мессаг, он обрежет. Проблема счас в том, что нельзя подтвердить отправителя сам дурак пофиг, читай первую часть ответа

Майкрософт давно подобный бред предлагали.

короче ты вообще не в теме

не подобный и не такой, я в курсе не гони без аргументов

Сделай (Цы) Волшебник

В этом деле главное придумать. Не услышал не одного грамотного слова критики, одни понты голые

А я придумал каждое письмо дублировать голосовым подтверждением в операторский центр. И без подтверждения писем не отправлять. Ну как тебе идея ?

а что-нибудь понадежнее придумать не смог? очередной тупой наезд!

Ипанись. Ты хочешь сказать что твоя лажа с подтверждениями надежнее голосового ? А как насчет трояна имеющего встроенный СМТП сервер с реализзованным твоим алгоритмом подтверждения?

Ну так шифровать то они будут другой парой ключей.

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

Однако косяк такой - по какой то причине допустим в mail.ru произошла утечка тайного ключа. Они решили поменять пару ключей и ... пол страны свои письма отправили в спам.

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

еще критика по существу будет или чисто бряцанье медалями?

а что тут критиковать? обычная проверка отправителя в протоколах безопасного соединения с использованием несимметричного алгоритма шифрования.

типа небольшой кербер упрощенной модели.

Да лажа все это...Ты давай конкретику - алгоритм распиши. А не так что "Каждый почтовый сервер"...какой сервер ? SMTP или POP3 ? А IMAP забыл? По пунктикам распиши

И учти что посылая через SMTP сервер письмо на POP3 сервер, мы не предполагаем доступности его или промежуточного сервера SMTP. У промежуточных есть таймауты. Пичьмо то о недоступности приходит не сразу - оно долго еще везде шарится

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

Чувак, кто тебе сказал что троян не может указать в качестве первого - СЕБЯ, и реализовать весь твой алгоритм по подтверждению

Дык такие письма автоматом уходят в подозрительные - смтп сервера не часто новыя возникают... гыгыгы... зато гарантировано избавление от ошибок, когда нормальное письмо принимают за спам, ЕМЕЛЯ!

особенно если с нового смтп пришло 10000 весьма похожих друг на друга писем

гарантирована работа блек-листов... короче одни минусы и никаких напрягов для пользователя. Ключ передается в служебных полях письма. Меняется работа только smtp-серверов, а не клиентское ПО.

почему не применяется тогда, если это не ново?

А если 100 писем ? И кто сказал что это НОВЫЙ смтп ? Он может быть и старым - просто ранее с него не было писем. А если это была важная рассылка пользователям конторы из руководства холдинга...кастрация обеспечена.

дык ты забываешь про оборотную сторону - законные честные письма будут проходить сразу без спам-контроля (а сколько теряется писем на таком контроле), а вот такие будут контролироваться стандартными средствами (теми же что сейчас) и помечаться юзверю как ВОЗМОЖНО:СПАМ

И ваще - сисадмины плачутся что именно не могут проверить достоверность отправителя, понимаешь? а если я буду точно знать, что письмо отправлено с адреса 188.34.34.56, то я включу этот адрес раз и навсегда в блек-лист, если это спам....

А на linux.org.ru слабо завести такую тему?

я по злачным заведениям не бываю...

Уууу...фи. Слабак.

если идея стоящая, она сама пробьет себе дорогу!

Не пробьет.

Майкрософт со своими сигнатурами не смогла пробить...

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

пиши RFC, описание как его и куда вот тут: А там уже пошлют куда подальше более грамотно, чем на мисте.

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

+1

дарю идею - полный антикопирайт. ;-)

ага, а потом будешь вставлять свои ссылки, как здесь ;  ?  хехе... знаем мы Гения ...

Уже придумано давно "DomainKeys", я его ващето не юзают всеравно есть не достаток в том что письмо приходится принимать для того чтобы проверить его подпись ключем, я больше юзаю SPF он проверят что письмо действительно отправляетс от туда откуда указано в письме это отсеевевает 90% спама ну а дальше DNS-BL и анализ спама в письме, ну еще можно юзать Greylisting но на него не хватило и так 1-2% спама пролазить пока это меня удотворяет ...

ну дык письмо принимает робот, а время работы робота ничто по сравнению со временем работы человека. Вот ежели домейн кейз внедрено будет повсеместно, аминь. А домейн кейз входит в стандарт смтп?

Нет не входит это просто дополнение, все зависит от админа если он захочет то впишит запись если нет так нет ...

подробнее, это зависит от админа smtp-сервера? а почему тогда mail.ru не подписывает свои домены? И вкратце суть технологии - такая же как моя или другая, почему нужно письмо получать?

Это завист от админа DNS сервера домена, ключ вписывается в зону TXT домена, а письмо приходится получать потому что в заголовке письма содержится подпись в SMTP нет просто фичи которая бы до момента принятия письма можно было запросить сертификат ключа, на счет mail.ru я незнаю они юзают SFP так же как и я, а DomainKeys вроде юзает из крупных gmail.com и yahoo.com

оки, почитал тут Впечатляет. Однако лично мне сдается, что DK более надежный метод, чем SPF & Caller ID. ;-)

Нуда будет надежный когда все начнут его юзать, а SPF я уже щас могу юзать даже если нету запись в домене то применяю простое правило spf1= mx/24 a/24 -all и это проверяет что отправлитель пихает в EHLO так же From и его ИП

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

Если ты посмотри запись домена mail.ru то увидеш "v=spf1 ip4:194.67.57.0/24 ip4:194.67.23.0/24 ip4:194.67.45.0/24 ~all" тоесть при приеме почты от mail.ru мой почтовик проверить домен который записан в поле from после @ и сверит его со списокм ИП от куда пришла сессия если все ок то пропустит если нет пошлет на все четыре стороны

mail.ru так же может при приеме письма отменя проверить вытащив запись из DNS и убедится что я действительно владелец домена и шлю письмо с верного ИП

А подделать ип типа нельзя, да?

Как ты потделает его? если поделать заголовок TCP то обратно пакаты будут возврашатся туда куда поделаеш в заголовке а так соединение идет от TCP вот и почтовик знаеш с якого ИП пришел запрос на соединение ...

це понятно, а че, в запросе mailfrom не предусмотрено поле для комментария, куда можно впихнуть Domain Key?

по стандарту SMTP нет ...

мдя...