Courier Mail Server Forum Index Courier Mail Server
www.courierms.ru
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Пожелание по дальнейшему развитию проверок.
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    Courier Mail Server Forum Index -> Courier Mail Server 3.xx
View previous topic :: View next topic  
Author Message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 23 Apr 2013 11:02 (Tue)    Post subject: Пожелание по дальнейшему развитию проверок. Reply with quote

Проверка наличия и соответствия PTR-записи очень мощное средство борьбы со спамом с зомбированных компов. Но хотелось бы не останавливаться на этом, а выполнять, по желанию, более глубокие проверки:

1. Проверка наличия PTR-записи (обратный резольвинг).
2. Проверка соответствия PTR-записи адресу коннекта (прямой резольвинг по найденной в п.1 записи).
3. Проверка соответствия адресу в командах HELO/EHLO адресу в найденной PTR-записи.
4. Проверка наличия MX-записи для домена, найденного в п.1 и соответствия ее IP-адресу коннекта.

П.п. 1 и 2 сейчас выполняются. П.п. 3 и 4 хотелось бы иметь опционально. Конечно, они могут привести к ложным срабатываниям, но иногда поток спама, с которым не справляются контекстные антиспам-фильтры, просто зашкаливает.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 23 Apr 2013 16:10 (Tue)    Post subject: Reply with quote

До HELO/EHLO пока не добрались. Сделаем. Пока надо вообще "обкатать" проверку PTR-записей.

Проверку MX-записи выполнять смысла нет, т. к. во многих случаях (для крупных почтовых систем — практически во всех) отправка почты ведётся с других хостов, не являющихся MX для домена отправителя.
Тут нужно использовать технологию SPF. Со временем, думаю, и её осилим.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 23 Apr 2013 16:22 (Tue)    Post subject: Reply with quote

NAMOR wrote:
До HELO/EHLO пока не добрались. Сделаем. Пока надо вообще "обкатать" проверку PTR-записей.

Проверку MX-записи выполнять смысла нет, т. к. во многих случаях (для крупных почтовых систем — практически во всех) отправка почты ведётся с других хостов, не являющихся MX для домена отправителя.
Тут нужно использовать технологию SPF. Со временем, думаю, и её осилим.


Опционально можно и проверку MX сделать. Не обязательно, конечно.

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

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

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 23 Apr 2013 17:22 (Tue)    Post subject: Reply with quote

Да, кстати, можно сделать "слабую" проверку MX-записей. Т.е. проверять не совпадение адреса MX-записи с IP коннекта, а просто ее наличие.

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

А если MX-записей нет, то кто, кроме бота, будет из этого домена этим заниматься?

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 23 Apr 2013 18:47 (Tue)    Post subject: Reply with quote

GrAnd wrote:
SPF, как я понимаю, работает уже не с командами SMTP, а с полями в заголовке? Так это ж еще муторошнее на лету их обрабатывать.

SPF работает не с полями в заголовке, а с TXT-записями в DNS. По приведённой мной выше ссылке всё написано.

GrAnd wrote:
А как насчет технологий GreyList и DSBL? Вроде бы DSBL сделать не сложно, только надо добросовестных провайдеров списков выбирать, а не SpamHaus, который раздает плюхи всем неугодным вручную.

GreyList — возможно, хотя эта идея энтузиазма у меня не вызывает. Я считаю, что спамера остановит только полный отказ принять его подключение или письмо от него. Временный отказ позволит спамеру повторить отправку позже. А рассказы о том, что спамеры не повторяют попыток отправки, считаю несерьёзными.

DSBL (скорее даже DNSBL). Идея отказывать клиентам из-за наличия их IP-адресов в каких-то там "чёрных списках", неизвестно кем и как составленных, мне совсем не нравится.
Сам когда-то сталкивался с проблемой, когда наш хостер попал в такой список и я не мог отправить письма клиентам. И всё из-за того, что принимающие сервера считали хостера спамером (и, вместе с ним, тысячи его клиентов!). Это ненормально и не может оправдываться никакой борьбой со спамом, если при этом страдает множество невиновных людей.
И про вымогательство денег составителями таких "чёрных списков" я читал.
В то же время можно не отказывать клиенту, если он находится в DNSBL, а начислять ему "штрафные баллы", а отказывать при превышении суммой баллов некоторого порогового значения.
В общем, отмечу себе. При случае основательней подумаю над этой идеей.

GrAnd wrote:
Да, кстати, можно сделать "слабую" проверку MX-записей. Т.е. проверять не совпадение адреса MX-записи с IP коннекта, а просто ее наличие.

Вот это уже более интересная мысль Smile Записал.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 23 Apr 2013 23:14 (Tue)    Post subject: Reply with quote

NAMOR wrote:
GreyList — возможно, хотя эта идея энтузиазма у меня не вызывает. Я считаю, что спамера остановит только полный отказ принять его подключение или письмо от него. Временный отказ позволит спамеру повторить отправку позже. А рассказы о том, что спамеры не повторяют попыток отправки, считаю несерьёзными.

Тоже так считаю ... По мне так GrayList гораздо спорная технология в отличие от DNSBL.

NAMOR wrote:
DSBL (скорее даже DNSBL). Идея отказывать клиентам из-за наличия их IP-адресов в каких-то там "чёрных списках", неизвестно кем и как составленных, мне совсем не нравится.

Наш сервер попадал много раз в BL. Но каждый раз по делу. Либо кто-то в сети был зомбирован на рассыл почты, либо релей через него шел из-за корявой настройки.
Сейчас антивирь ESET NOD32 у всех стоит. Так что мэйлботы теперь редкость. Но вот последний раз нас в BL включили, когда подобрали пароль одного из пользователей и стали на сервак заходить и рассылать письма от его имени.

Сейчас наш сервак находится под мощным потоком входящего спама. Каждое письмо идет в несколько адресов, по словарю. Большинство режется по PTR, что проходит - проверяется на число получателей. Если больше 2, то тоже удаляется.

Я в свое время одну идею пытался прикрутить к CMS. Наподобие "серых списков", только наоборот. Завтра опишу.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 24 Apr 2013 19:37 (Wed)    Post subject: Reply with quote

GrAnd wrote:
Да, кстати, можно сделать "слабую" проверку MX-записей. Т.е. проверять не совпадение адреса MX-записи с IP коннекта, а просто ее наличие.

Проверяю на практике.

IP-адрес клиента: 94.100.176.53
Имя клиента: smtp8.mail.ru
MX-запись для имени клиента: нет

IP-адрес клиента: 81.19.66.15
Имя клиента: maile.rambler.ru
MX-запись для имени клиента: нет

IP-адрес клиента: 77.88.46.8
Имя клиента: forward3.mail.yandex.net
MX-запись для имени клиента: нет

IP-адрес клиента: 94.100.176.134
Имя клиента: fallback6.mail.ru
MX-запись для имени клиента: нет

IP-адрес клиента: 62.141.94.173
Имя клиента: mail3.ks.pochta.ru
MX-запись для имени клиента: нет

IP-адрес клиента: 74.125.82.46
Имя клиента: mail-wg0-f46.google.com
MX-запись для имени клиента: нет

IP-адрес клиента: 195.182.194.165
Имя клиента: mlink-telemost.megalink.com.ua
MX-запись для имени клиента: нет

IP-адрес клиента: 85.255.19.85
Имя клиента: loopmail5.wip.element5.com
MX-запись для имени клиента: нет

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

Пояснение. Хосты, принимающие почту для конкретного домена, и хосты, отправляющие почту от этого же домена, в общем случае могут принадлежать совершенно разным доменам и подсетям. Как следствие, любые проверки, сопоставляющие между собой принимающие и отправляющие хосты домена, бессмысленны.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 24 Apr 2013 22:35 (Wed)    Post subject: Reply with quote

NAMOR wrote:
... предложенную проверку не проходят даже легальные почтовые сервисы.
Вывод: практического смысла проверка не имеет.

Да разве? Smile
Code:
C:\Documents and Settings\Андрей>nslookup
Default Server:  UnKnown
Address:  192.168.0.1

> set q=mx
> mail.ru
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
mail.ru MX preference = 10, mail exchanger = mxs.mail.ru

...
> rambler.ru
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
rambler.ru      MX preference = 10, mail exchanger = imx2.rambler.ru
rambler.ru      MX preference = 5, mail exchanger = imx1.rambler.ru
...
> mail.yandex.ru
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
mail.yandex.ru  MX preference = 0, mail exchanger = mx-corp.yandex.ru
mail.yandex.ru  MX preference = 10, mail exchanger = cronborg.yandex.ru
mail.yandex.ru  MX preference = 10, mail exchanger = rosenborg.yandex.ru
...
> pochta.ru
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
pochta.ru       MX preference = 10, mail exchanger = mx.qip.ru
...
> megalink.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
megalink.com    MX preference = 20, mail exchanger = antispam4.megalink.com
megalink.com    MX preference = 20, mail exchanger = antispam6.megalink.com
megalink.com    MX preference = 220, mail exchanger = tarbaby.junkemailfilter.com
megalink.com    MX preference = 0, mail exchanger = antispam0.megalink.com
megalink.com    MX preference = 20, mail exchanger = antispam1.megalink.com
megalink.com    MX preference = 20, mail exchanger = antispam2.megalink.com
megalink.com    MX preference = 20, mail exchanger = antispam3.megalink.com
...
> element5.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
element5.com    MX preference = 10, mail exchanger = smtp.wip.digitalriver.com
element5.com    MX preference = 20, mail exchanger = smtp.wip.digitalrivercontent.net
...
>exit
C:\Documents and Settings\Андрей>

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

Тут возникла путаница. Все эти IP являются адресами хостов, вернее, почтовых кластеров. А зачем хостам иметь MX-запись?

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 25 Apr 2013 0:58 (Thu)    Post subject: Reply with quote

GrAnd wrote:
Проверять наличие MX-записи надо же не у хоста, а у его домена. Возможно даже не у его домена, а у более высокого уровня.

Объясните мне, пожалуйста, как по имени хоста узнать, для какого домена запрашивать MX-записи?
Вот, например, подключился хост xena.servers.eqx.misp.co.uk. Какое имя домена указать в запросе MX-записей?
А для хоста relay.Adm.Yrg.kuzbass.net? Для delta.smtp.skif.com.ua?
Все эти хосты реально существуют и имеют правильные PTR- и A-записи в DNS.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 25 Apr 2013 12:53 (Thu)    Post subject: Reply with quote

NAMOR wrote:
GrAnd wrote:
Проверять наличие MX-записи надо же не у хоста, а у его домена. Возможно даже не у его домена, а у более высокого уровня.

Объясните мне, пожалуйста, как по имени хоста узнать, для какого домена запрашивать MX-записи?

А никак. Проверять следует все наддомены до второго уровня включительно.

Но такие длительные проверки и не нужны.
Либо сам исследуемый домен, либо его ближайший родительский домен будут иметь MX.
Либо (это будет касаться, в основном, мелких доменов второго уровня), это будет однократная проверка только для самого домена. Если кто-то развернул в домашних условиях домен, например, только для форума, а про почту не подумал, то эта проверка это покажет.

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

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 25 Apr 2013 15:47 (Thu)    Post subject: Reply with quote

GrAnd wrote:
Либо (это будет касаться, в основном, мелких доменов второго уровня), это будет однократная проверка только для самого домена. Если кто-то развернул в домашних условиях домен, например, только для форума, а про почту не подумал, то эта проверка это покажет.

Если он не подумал про почту, то у такого хоста либо вообще не будет PTR-записи, либо в ней будет имя хоста из домена провайдера (наподобие 62.183.18.142.modem-pool.kuban.ru). Но мы же хотим проверить на наличие MX-записи домен пользователя, а не провайдерский домен, который никакого отношения к домену пользователя не имеет и для которого, разумеется, существует MX-запись. А узнать имя домена пользователя в описанном случае невозможно.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 26 Apr 2013 16:47 (Fri)    Post subject: Reply with quote

Вот интересная статья с описанием достаточно гибких проверок IP-адреса и PTR, MX и TXT-записей:

http://habrahabr.ru/post/101628/

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
NAMOR
CMS Developer


Joined: 15 Oct 2005
Posts: 1079

PostPosted: 27 Apr 2013 15:24 (Sat)    Post subject: Reply with quote

Почитал. Хорошая статья, спасибо. И про вред DNSBL верно написано.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 27 Apr 2013 22:57 (Sat)    Post subject: Reply with quote

Я даже осилил все комментарии. Там много дельной критики и интересных предложений.
_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 28 Apr 2013 13:02 (Sun)    Post subject: Reply with quote

Заглянул так же ао ссылке "последняя и наиболее актуальная версия этой статьи". Там есть небольшое дополнение:
Quote:
Кроме того, современные версии Postfix по умолчанию отклоняют письмо не раньше RCPT TO команды. Это сделано для того, что бы в логах всегда можно было посмотреть полную информацию о письме - от кого и кому оно должно было придти.

Представляется логичным и в CMS все проверки по IP и конверту сделать после полного создания конверта непосредственно перед приемом тела письма с заголовками. Это позволит:

1. Контроллировать процесс блокировок по логам.
2. Все разнообразные проверки вынести в отдельные dll, в которые передаются данные из конверта + IP. Проверяющие dll сгруппированы в список. Вызываются по порядку следования в списке. Возвращают флаг прохождения проверки "Недоступно/Нет/Да/Неизвестно", преобразуемый CMS к вероятности "чистоты" письма. Как только произведение результатов проверок станет ниже порогового, письмо отсекается, либо включается механизм грейлистинга.

Например, три проверки (DNSBL, PTR, SPF) вернули флаги "Нет", "Да", "Неизвестно". CMS преобразует эти флаги к вероятностям, например, 0.8, 1.0, 0.9. Их произведение равно 0,72. Если пороговое значение установлено 0,7, то письмо пройдет. А если 0,75 - будет отвергнуто.

Недостаток: перед приемом тела письма невозможно применить байесовский или какой еще контекстный фильтр. Для этого нужно будет всё равно принять письмо целиком.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Courier Mail Server Forum Index -> Courier Mail Server 3.xx All times are GMT + 4 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group