- Спам, грейлист и lost input channel,
 Medlar, 13:33 , 02-Фев-09 (1)>В процессе борьбы со спамом, анализируя логи сендмаила заметил что, спамеры после
>ответа грейлистинга Try again later, сразу делают lost input channelне понятно, покажите лог
- Спам, грейлист и lost input channel, slv, 14:03 , 02-Фев-09 (2)
Feb 2 00:20:34 gw sm-mta[91627]: n11KK9lE091627: Milter: to=<user@mydomen.ru>, reject=451 4.7.1 Try again later
Feb 2 00:20:34 gw sm-mta[91627]: n11KK9lE091627: lost input channel from 212-34-118-150.domolink.elcom.ru [212.34.118.150] to IPv4 after dataВ первой строке грейлист ответил, попробуй позже и естественно занес его в свою базу, во второй видим что спамер сразу отвалился, но так как он уже в базу грейлиста на ожидание попал, то в следующий раз его письмо дойдет (эту строку в логах не привожу).
Хочется как то научить грейлист или седмаил или еще кого-нибудь понимать, что за последовательностью таких действий однозначно кроется спам
- Спам, грейлист и lost input channel, Medlar, 15:20 , 02-Фев-09 (3)
>Feb 2 00:20:34 gw sm-mta[91627]: n11KK9lE091627: Milter: to=<user@mydomen.ru>, reject=451 4.7.1 Try again later
>Feb 2 00:20:34 gw sm-mta[91627]: n11KK9lE091627: lost input channel from 212-34-118-150.domolink.elcom.ru
>[212.34.118.150] to IPv4 after data Так логи не показывают
egrep n11KK9lE091627 maillog - вот это вся инфа по данному письму, которая меня и интересовала >
>В первой строке грейлист ответил, попробуй позже и естественно занес его в
>свою базу, во второй видим что спамер сразу отвалился, проверьте таймауты sendmail'a & фильтра
нужно привести их в соотвествие соединение не может так быстро стать lost input channel (опять-таки не знаю, когда началось соединение, лога _не_ _было_)
но так
>как он уже в базу грейлиста на ожидание попал, то в
>следующий раз его письмо дойдет (эту строку в логах не привожу).
>
>Хочется как то научить грейлист или седмаил или еще кого-нибудь понимать, что
>за последовательностью таких действий однозначно кроется спам
- Спам, грейлист и lost input channel, slv, 08:36 , 03-Фев-09 (4)
>Так логи не показывают
>egrep n11KK9lE091627 maillog - вот это вся инфа по данному письму, которая
>меня и интересовала Дело в том, что по месаджид выбирать из лога бесполезно, т.к. на этапе приема письма под управлением грейлиста у него одно ид, а когда его грейлист уже пропускает другое.
Ну да ладно пришлось попарсить логи (на основе IP-адреса спамера и обратного адреса) и выбрать реальное спамовое письмо. Лог из 2-х этапов: На этапе грейлиста: Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <gsa@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<gsa@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <calipso@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<calipso@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <pvs@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<pvs@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <psa@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<psa@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <slv@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<slv@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:52 gw milter-greylist: n0TA6QiQ028004: addr 154.180.broadband3.iol.cz[85.70.180.154] from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> to <postmaster@mydomen.ru> delayed for 00:15:00 (ACL 127)
Jan 29 14:06:52 gw sm-mta[28004]: n0TA6QiQ028004: Milter: to=<postmaster@mydomen.ru>, reject=451 4.7.1 Try again later
Jan 29 14:06:53 gw sm-mta[28004]: n0TA6QiQ028004: lost input channel from 154.180.broadband3.iol.cz [85.70.180.154] to IPv4 after data
Jan 29 14:06:53 gw sm-mta[28004]: n0TA6QiQ028004: from=<nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=IPv4, relay=154.180.broadband3.iol.cz [85.70.180.154] 2-ой этап, после грейлиста: Jan 29 14:37:03 gw milter-greylist: n0TAaaQJ071991: addr 85.70.180.154 from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> rcpt <psa@mydomen.ru>: autowhitelisted for 72:00:00
Jan 29 14:37:03 gw milter-greylist: n0TAaaQJ071991: addr 85.70.180.154 from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> rcpt <slv@mydomen.ru>: autowhitelisted for 72:00:00
Jan 29 14:37:03 gw milter-greylist: n0TAaaQJ071991: addr 85.70.180.154 from <nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com> rcpt <postmaster@mydomen.ru>: autowhitelisted for 72:00:00
Jan 29 14:37:04 gw sm-mta[71991]: n0TAaaQJ071991: from=<nca2571e2.0024672b-ca2571e2.00247e6e@pacbrands.com>, size=1422, class=0, nrcpts=3, msgid=<5751731993.14274705050959@pacbrands.com>, proto=ESMTP, daemon=IPv4, relay=154.180.broadband3.iol.cz [85.70.180.154]
Jan 29 14:37:12 gw sm-mta[72778]: n0TAaaQJ071991: to=<psa@mydomen.ru>, delay=00:00:09, xdelay=00:00:08, mailer=local, pri=121810, dsn=2.0.0, stat=Sent
Jan 29 14:37:21 gw sm-mta[72778]: n0TAaaQJ071991: to=<slv@mydomen.ru>, delay=00:00:18, xdelay=00:00:09, mailer=local, pri=121810, dsn=2.0.0, stat=Sent
Jan 29 14:37:29 gw sm-mta[72778]: n0TAaaQJ071991: to=<postmaster@mydomen.ru>, delay=00:00:26, xdelay=00:00:08, mailer=local, pri=121810, dsn=2.0.0, stat=Sent
>проверьте таймауты sendmail'a & фильтра
>нужно привести их в соотвествие
>
>соединение не может так быстро стать lost input channel (опять-таки не знаю,
>когда началось соединение, лога _не_ _было_)
Причем здесь таймауты, технических проблем у меня нет, у меня проблема спама! Тем более что "lost input channel" - это насколько я знаю, не обязательно разрыв по таймауту, а нарушение последовательности команд смтп-сессии.
- Спам, грейлист и lost input channel, Medlar, 13:21 , 03-Фев-09 (5)
>Причем здесь таймауты, технических проблем у меня нет, у меня проблема спама!
>Тем более что "lost input channel" - это насколько я знаю,
>не обязательно разрыв по таймауту, а нарушение последовательности команд смтп-сессии. ДА ВЫ ПРАВЫ таймауты здесь не при чем
С sendmail-конфы: Claus Assmann: Networking problem or the sender just hang up (telnet?) Per Hedeland: The most common cause of this message by far in today's e-mail world is
spamware that simply drops the connection on any error ("User unknown",
"Relaying denied", whatever). >спамеры после ответа грейлистинга Try again later, сразу делают lost input channel Здесь нужно разбираться и разбираться. Почему возник отлуп Try again later.
Ведь это говорит о том, что в данный момент фильтр недоступен. Почему он недоступен?
Перегруженность системы, нет ресурсов, что-то еще? Посмотрите, какой флаг выставлен в строке определения greylist'a
Наверное, F=T? "... The following flags may be set in the filter description.
R Reject connection if filter unavailable
T Temporary fail connection if filter unavailable
If neither F=R nor F=T is specified, the message is passed through sendmail
in case of filter errors as if the failing filters were not present..." Если судить по второй цитате, спамер, получив от вас незапланированный ответ (TAL),
сразу обрывает связь. По всей видимости (я не использую GL), greylist так написан, что при обрыве связи он все равно принимает отправителя, то есть заносит в базу. То есть на временную ошибку он реагирует положительно, как например, поступают и dnsbl-проверки. Если это действительно так, то ИМХО тут нужно раговаривать с разработчиком, как это исправить; ну или найти самому и исправить Кстати, может попробовать велеть фильтру делать reject (F=R)?
Хотя из второй цитаты опять-таки следует что ответом будет LIC и то же самое. А если не использовать этот флаг вовсе как в доке написано?
- Спам, грейлист и lost input channel, slv, 14:15 , 03-Фев-09 (6)
>Здесь нужно разбираться и разбираться. Почему возник отлуп Try again later.
>Ведь это говорит о том, что в данный момент фильтр недоступен. Почему
>он недоступен?
>Перегруженность системы, нет ресурсов, что-то еще? Да нет нормально все тут, это принцип работы грейлиста - генерить временную ошибку, заставляя повторить передачу через некоторое время. Я просто вообще в принципе хотел узнать, использует ли народ такой подход, который я описал, для определения спама и как.
- Спам, грейлист и lost input channel, Medlar, 11:00 , 04-Фев-09 (7)
>>Здесь нужно разбираться и разбираться. Почему возник отлуп Try again later.
>>Ведь это говорит о том, что в данный момент фильтр недоступен. Почему
>>он недоступен?
>>Перегруженность системы, нет ресурсов, что-то еще?
>
>Да нет нормально все тут, это принцип работы грейлиста - генерить временную
>ошибку, заставляя повторить передачу через некоторое время. Ага, понятно, тогда с этим придется смириться.
И причина пропуска не в lost input channel, а в том, что сама технология GL направлена против zombie хостов (Most spam is not sent out using RFC compliant MTAs; the spamming software will not try again later. ) В вашем же случае спамер приходит еще раз и это полностью нивелирует работу GL.
То есть GL может охватить только часть спама, самого тупого и примитивного. Да, вы можете использовать технику "стрельбы в догонку", то есть анализ maillog'а
на предмет IP, оборвавших соединение, но где гарантия, что это именно спамер, а не сетевая проблема, о чем говорил Claus Assmann?
>
>Я просто вообще в принципе хотел узнать, использует ли народ такой подход,
>который я описал, для определения спама и как.
- Спам, грейлист и lost input channel, LS, 09:49 , 25-Фев-09 (8)
>[оверквотинг удален]
>>
>>Да нет нормально все тут, это принцип работы грейлиста - генерить временную
>>ошибку, заставляя повторить передачу через некоторое время.
>
>Ага, понятно, тогда с этим придется смириться.
>И причина пропуска не в lost input channel, а в том, что
>сама технология GL направлена против zombie хостов (Most spam is not
>sent out using RFC compliant MTAs; the spamming software will not
>try again later. )
>именно так. >В вашем же случае спамер приходит еще раз и это полностью нивелирует
>работу GL.
>То есть GL может охватить только часть спама, самого тупого и примитивного.
> ну тупо-спамеры отсекаются все-же, а вот те клиенты , что подхватили инфекцию тут пролезут по любому - за них легальные smtp всю работу сделают - будут стучаться и продезут в конце-концов. >
>Да, вы можете использовать технику "стрельбы в догонку", то есть анализ maillog'а
>
>на предмет IP, оборвавших соединение, но где гарантия, что это именно спамер,
>а не сетевая проблема, о чем говорил Claus Assmann?
>
>>
>>Я просто вообще в принципе хотел узнать, использует ли народ такой подход,
>>который я описал, для определения спама и как. конечно используют. первая линия обороны. хотя не всегда и не всем подходит. некоторые "легальные" smtp после токого отлупа повторно не стучаться. или у конторы может быть несколько smtp, которые будут стучаться в greylist по очереди. как результат - задержка или недоставка вполне нормального письма. так что каждый для себя решает - надо ли оно...
- Спам, грейлист и lost input channel, zerot, 11:20 , 25-Фев-09 (9)
вы интересную тему подняли. век живи век учись
решение в лоб - парсить лог и формировать черный список, как вы и писалиоднако я бы порекомендовал выстроить многоуровневую оборону, как описано у меня в статье http://www.ourorbits.org/itview/articles/mailsystem.shtml с большой вероятностью прошедшие через дыру в lost_connection будут остановлены проверкой существования отправителя, что позволит автоматически (с минимальным задействованием времени и ресурсов администратора) получить результат
- Спам, грейлист и lost input channel, zerot, 11:29 , 25-Фев-09 (10)
еще вдогонкусудя по куску лога, спамер в вашем случае отрабатывает довольно корректно с позиций логики "серых списков" он пытается отправить письмо один раз, получает временную ошибку и эмулирует работу нормального почтового сервера - отправляя письмо повторно через полчаса. Все остальное здесь вторично - серые списки должны пропускать письма такого отправителя а дальше вам необходимо проверять входящие другими методами ...
- Спам, грейлист и lost input channel, LS, 11:36 , 25-Фев-09 (11)
>еще вдогонку
>
>судя по куску лога, спамер в вашем случае отрабатывает довольно корректно с
>позиций логики "серых списков"
>
>он пытается отправить письмо один раз, получает временную ошибку и эмулирует работу
>нормального почтового сервера - отправляя письмо повторно через полчаса. Все остальное
>здесь вторично - серые списки должны пропускать письма такого отправителя
>
>а дальше вам необходимо проверять входящие другими методами ... это опять просто "попиздеть"? в той ссылке даже на искосок просчитать нечего. молодец! афтар!!! PS сорри за грубость - сорвался
- Спам, грейлист и lost input channel, zerot, 22:19 , 23-Мрт-09 (13)
>это опять просто "попиздеть"? в той ссылке даже на искосок просчитать нечего.
>молодец! афтар!!!
>
>PS сорри за грубость - сорвался это в смысле пообщаться с разделяющими мои взгляды
остальным желаю свалить из моей жизни или сдохнуть со всем своим родом. Жить никому не мешаю, ничего не навязываю, но еврейские приёмы общения, как и их носителей, из списка людей по своим понятиям вычеркиваю - имею право иметь своё мнение
- Спам, грейлист и lost input channel, Medlar, 13:30 , 25-Фев-09 (12)
спасибо, интересная статья.Пара вопросов. Про КАС:
"У отдельных пользователей количество спама за день могло доходить до нескольких
десятков (и даже около сотни) писем. "
Речь идет о непомеченном спаме? По milter-sender. Есть ли у него кэш (чтобы не гонять зря запросы по уже отметившемуся
отправителю)? И как вы смотрите на потенциальную возможность попадания ВАШЕГО сервера в черные списки на других серверах за постоянные sender-check'и?
А если обратный адрес подделан и письмо отправляется
с третьего сервера? ВЕдь вы отправите тестовое письмо не на этот третий сервер, а на
адрес отправителя, почтовый сервер которого и не отправлял письмо.
Какой здесь все-таки механизм: проверка существования юзера на mx-е домена-отправителя или на сервере-отправителе?
И как во втором случае быть с транзитными релеями - они ведь не обязаны знать о существовании отправителя транзитной почты? По поводу SpamAssassin просто ремарка. В этом году вряд ли мы купим коммерческий антиспам, стало быть, SA - это будет наше все на следующий сезон.
- Спам, грейлист и lost input channel, zerot, 22:28 , 23-Мрт-09 (14)
>"У отдельных пользователей количество спама за день могло доходить до нескольких
>десятков (и даже около сотни) писем. "
>Речь идет о непомеченном спаме? да, именно не помеченный спам >По milter-sender. Есть ли у него кэш (чтобы не гонять зря запросы
>по уже отметившемуся
>отправителю)? у использованной версии кэш есть. Продукт называется milter-sender и в настоящее время, к сожалению, продается автором за деньги. Но коллеги находили аналоги >И как вы смотрите на потенциальную возможность попадания ВАШЕГО сервера в
>черные списки на других серверах за постоянные sender-check'и? эта техника описана в недрах RFC (ссылку за давностью не нарою влёт, ищите в инете). Т.е. попытка отправки с пустого отправителя <> вполне должна отрабатываться. Если кто то строит свою антиспам систему без учета этого, это нужно принимать или не пользоваться данной техникой. Однако опыт нескольких контор, окученных такой многоуровневой системой, в т.ч. довольно крупных - говорит о том, что обращений к администраторам по поводу указанного симптома не было ни разу Также нужно отметить, что использование кэша снижает количество подобных поверочных обращений >А если обратный адрес подделан и письмо отправляется
>с третьего сервера? ВЕдь вы отправите тестовое письмо не на этот третий
>сервер, а на
>адрес отправителя, почтовый сервер которого и не отправлял письмо.
>Какой здесь все-таки механизм: проверка существования юзера на mx-е домена-отправителя или на
>сервере-отправителе? насколько я понимаю - именно на mx домена. Причем указанная вами особенность - одна из причин, почему стоит выстраивать многоуровневую систему антиспама >И как во втором случае быть с транзитными релеями - они ведь
>не обязаны знать о существовании отправителя транзитной почты?
>
>По поводу SpamAssassin просто ремарка. В этом году вряд ли мы купим
>коммерческий антиспам, стало быть, SA - это будет наше все на
>следующий сезон. ну, удачи вам. К сожалению я за последние 3 года погружения в корпоративный Lotus и Oracle начинаю отмечать, что UNIX решения немного отодвигаются в приоритетах, но будущее все же за использованием открытых решений на типовых задачах ... :)
|
Версия для распечатки
Спам, грейлист и lost input channel, 
