# Форум на русском языке  > Решения по информационной безопасности  > Антиспам  >  Реклама в картинках

## drongo

В последние время реклама в картинках стала очень популярной . Какие способы борьбы предлагаете ?P.S. Может кто аскьку у него украдёт ;D ;D ;D

From e-mail : [email protected]

----------

Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:

----------


## MOCT

> В последние время реклама в картинках стала очень популярной . Какие способы борьбы предлагаете ?


картинка же не в воздухе висит - надо анализировать то, как именно она вставлена в письмо.

----------


## drongo

> картинка же не в воздухе висит - надо анализировать то, как именно она вставлена в письмо.


From - Sun Jul 23 19:06:15 2006X-Account-Key: account6X-UIDL: 115361700814555X-Mozilla-Status: 0001X-Mozilla-Status2: 10000000Return-path: Received: from [80.68.242.232] (port=17751 helo=day.rbc.ru)    by mx19.mail.ru with esmtp     id 1G4STw-0004QE-00    for [email protected]; Sun, 23 Jul 2006 05:10:08 +0400Received-SPF: none (mx19.mail.ru: 80.68.242.232 is neither permitted nor denied by domain of yahoo.es) client-ip=80.68.242.232; [email protected]; helo=day.rbc.ru;Received: from ggaae (33.146.97.210)    by day.rbc.ru; Sun, 23 Jul 2006 05:10:08 +0400Date: Sun, 23 Jul 2006 05:10:08 +0400From: =?koi8-r?B?5MnNwQ==?= X-Mailer: The Bat! (v2.01)Reply-To: =?koi8-r?B?ZG96d2lsZXJnaXJs?= X-Priority: 3 (Normal)Message-ID: To: =?koi8-r?B?ZGFuMjg=?= Subject: =?koi8-r?B?8M/Nz9bFzSDOwcrUySDLzMnF?=    =?koi8-r?B?ztTP1y4=?=MIME-Version: 1.0Content-Type: multipart/mixed; boundary=&quot;----------00169651E87C&quot;X-Spam: Not detected------------00169651E87CContent-Type: text/html; charset=koi8-rContent-Transfer-Encoding: 8bitркввхмуцсбс 
------------00169651E87CContent-Type: IMAGE/GIF; name=&quot;=?koi8-r?B?M3JoeXJ0dXJ0dXJ0dS5naWY=?=&quot;Content-ID: Content-Transfer-Encoding: base64
Поможет ?что надо ? переслать письмо ?

----------


## MOCT

а это из какой программы в таком виде заголовки выдраны?

----------


## drongo

> а это из какой программы в таком виде заголовки выдраны?


mozila thunderbirdа как выдирать ?

----------


## MOCT

> mozila thunderbirdа как выдирать ?


не знаю, никогда им не пользовался :-)

----------


## pig

Нет, по этим заголовкам ничего не вычислить. Разве что зомби-источник.
А гадам можно в аську послать портрет Вардана с припиской "Я тебя жду"  :Smiley:

----------


## MOCT

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

----------


## GrAnd

> В последние время реклама в картинках стала очень популярной . Какие способы борьбы предлагаете ?


Если на Вашем почтовом сервере есть фильтрация по заголовкам, то обратите внимание на то, что в поле "Message-ID:" вместо идентификатора письма, вставляемого первым релеем, содержится совершенно незначащая информация, начинающаяся со слова "To:". Корректные почтовые серверы так не поступают. Обычно в этом поле содержится *уникальный_номер@домен_отправителя* в угловых скобках. Эту особенность можно использовать. Забейте в фильтр условие отвергать письма, у которых в данном поле нет "собаки", зато есть "To:".
Хотя, впрочем, можно обойтись только отсутствием собаки. Но будьте осторожны. Пару раз я сталкивался с парадоксом, когда это поле вообще не вставлялось в письмо-ответ, изготовленное в MS Outlook.

Раньше у меня как раз стояла проверка на отсутствие этого поля, но потом пришлось от нее отказаться. Во-первых, спамеры стали умнее и стали включать это поле в свои письма. А про "во-вторых" я уже написал.

P.S. Еще более надежным будет проверка отсутствия и "собаки" и точки в данном поле. Само поле "Message-ID" обязано присутствовать и быть корректным (проверяется наличием угловой скобки). Весь спам не вычистит, но %%30-40 наверняка.

----------


## GrAnd

```
X-Account-Key: account6
X-UIDL: 115361700814555
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-path: 
Received: from [80.68.242.232] (port=17751 helo=day.rbc.ru)
        by mx19.mail.ru with esmtp id 1G4STw-0004QE-00
        for [email protected]; Sun, 23 Jul 2006 05:10:08 +0400
Received-SPF: none (mx19.mail.ru: 80.68.242.232 is neither permitted nor denied by domain of yahoo.es) client-ip=80.68.242.232;
        [email protected];
        helo=day.rbc.ru;
Received: from ggaae (33.146.97.210)
        by day.rbc.ru; Sun, 23 Jul 2006 05:10:08 +0400
Date: Sun, 23 Jul 2006 05:10:08 +0400
From: =?koi8-r?B?5MnNwQ==?= 
X-Mailer: The Bat! (v2.01)
Reply-To: =?koi8-r?B?ZG96d2lsZXJnaXJs?= 
X-Priority: 3 (Normal)
Message-ID: 
To: =?koi8-r?B?ZGFuMjg=?= 
Subject: =?koi8-r?B?8M/Nz9bFzSDOwcrUySDLzMnF?=
        =?koi8-r?B?ztTP1y4=?=
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary=&quot;----------00169651E87C&quot;
X-Spam: Not detected
```

Разбил заголовок на поля и понял, что все, что я написал в предыдущем посте - туфта (сложно разбираться, когда все в одной строчке).
Поле "Message-ID" на самом деле пустое. Так что, использовать рекомендуемые правила не получится. Единственно, можно фильтровать как раз по этому признаку. Но велика вероятность ошибки - как я писал, в последнее время встречаются вполне легальные письма, в которых почему-то нет этого поля. Обычно это значит, что клиент (рассыльщик спама) подключился напрямую к серверу-приемнику. Но не факт. Некоторые сервера, почему-то не вставляют в некоторых случаях это поле. С другой стороны, рассыльщик спама может сам вставить это поле, либо воспользоваться промежуточным открытым релеем (хотя это для него и чревато), который вставит это поле.

----------


## pig

> Поле "Message-ID" на самом деле пустое.


Нет, это HTML-движок Мозиллы угловые скобки слопал при показе заголовков. Уж Return-path:, вставленный движком Mail.ru, пустым быть никак не может. Если письмо ещё не убито, его надо сохранить на диск в формате EML и открыть Блокнотом.

P.S. Message-ID вообще-то обычно отправителем генерится, так по стандарту положено. Некоторые почтовые серверы его вставляют в случае отсутствия, это тоже есть. Но далеко не везде.

----------


## prez

Робяты, а кто может четко разложить по полкам чайнику, каким образом в ящик (взлетный пример: [email protected]) падают спамерские письма, в заголовках которых [email protected] отсутствует, как класс? Ваще нигде нет. Ни Кому, ни От кого, нигде адреса нет. Везде прописано какое-то фуфло. Подозреваю, что возможно есть какие-то технические поля, в которых лежит реальный адрес, по которому принимающий сервак и раскладывает почту по ящикам. Но почему он тогда не включается сервером в заголовок письма в то же поле Кому? Почему в Кому стоят какие-то левые адреса? Как такое возможно?

----------


## GrAnd

> P.S. Message-ID вообще-то обычно отправителем генерится, так по стандарту положено. Некоторые почтовые серверы его вставляют в случае отсутствия, это тоже есть. Но далеко не везде.


Отправителем, это кем? Клиентской программой? Или сервером на стороне отправителя?
Едва ли первое. Ни в одном письме, которое принимается нашим сервером от локальных пользователей, еще нет этого поля. Зато в том же письме, которое затем этим сервером пересылается получателю, это поле уже присутствует и заполнено с указанием почтового домена, прописсаном в почтовом сервере, независимо от того, какие адреса стояли в учетке клиента.

Проверялось неоднократно.

Я могу и ошибаться, но IMHO, данное поле вставляется первым релеем, который принимает по SMTP данный пост. Если же спамер коннектится к серверу жертвы напрямую (что и бывает весьма часто), то на этот сервер пост приходит без этого поля, что может быть обнаружено. Затем этот сервер на стороне получателя вставляет это поле и клиенту оно приходит заполненным с указанием не домена отправителя, а локального домена. По этому признаку тоже можно попытаться вычислить спам уже самим клиентом.

В любом случае, перед установкой такого правила, надо набрать статистику - сколько писем приходят без поля "Message-ID", сколько из этого ложных срабатываний.

----------


## pig

> Робяты, а кто может четко разложить по полкам чайнику, каким образом в ящик (взлетный пример: [email protected]) падают спамерские письма, в заголовках которых [email protected] отсутствует, как класс?


Стандарт такой. Точнее, их два, и между собой они никак не связаны. Один на формат писем, другой на протокол доставки. Реальные адреса от кого и кому задаются командами протокола и в шапку письма могут попасть только по доброй воле почтового сервера, ставящего там свою отметку о приёме. А могут и вообще не попасть.




> Отправителем, это кем? Клиентской программой? Или сервером на стороне отправителя?


По правильному - клиентом. А серверам приходится исправлять ошибки плохо сделанных клиентов.




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


Странный у вас почтовый клиент. У меня TheBat! 2.10 их сам генерит. А вот сервер (Eserv/3) не обучен добавлять Message-ID. Как-то я этим не озадачивался.

----------


## GrAnd

> Робяты, а кто может четко разложить по полкам чайнику, каким образом в ящик (взлетный пример: [email protected]) падают спамерские письма, в заголовках которых [email protected] отсутствует, как класс? Ваще нигде нет. Ни Кому, ни От кого, нигде адреса нет. Везде прописано какое-то фуфло. Подозреваю, что возможно есть какие-то технические поля, в которых лежит реальный адрес, по которому принимающий сервак и раскладывает почту по ящикам. Но почему он тогда не включается сервером в заголовок письма в то же поле Кому? Почему в Кому стоят какие-то левые адреса? Как такое возможно?


Это же элементарно ...
Реальный получатель (и отправитель) регламентируются не полями в заголовке письма, а командами SMTP-протокола "MAIL FROM:" и "RCPT TO:", которым обменивается SMTP-клиент с SMTP-сервером при подключении.
Про команды SMTP-протокола можно вкратце прочесть например
http://www.codenet.ru/webmast/smtp.php и http://www.opennet.ru/docs/RUS/inet_.../smtp4414.html.

Спросите, для чего тогда нужны поля заголовка? Да просто для красоты, чтобы пользователь почтового клиента видел в письме от кого и кому, якобы, оно послано. За доставку же отвечают именно адреса в SMTP-командах. И они могут не совпадать с указанными в полях заголовка. И это не недочет и не ошибка, а необходимая особенность.
Если используется форвардинг или релей (это такие разновидности пересылки писем по цепочке), то без такой рассогласованности не обойтись.
Например, при релее (которым обычно пользуются большинство диалапщиков, юзающих почтовые сервера прова), сначала клиент отправителя посылает письмо на сервер-релей (ибо не имеет возможности прямой доставки письма получателю, а релей имеет). Пока что адреса в SMTP-командах совпадают с адресами в полях. Затем релей подключается к получателю (или к следующему релею) и вот тут-то адрес отправителя в команде "MAIL FROM:" уже начинает отличаться от первоначального и от указанного в поле "From:". Потому что отправителем уже является не клиент отправителя, а релей. Он сообщает свой адрес, чтобы сервер получателя или следующий релей могли на него ответить в случае неудачи. Имеется в виду не ошибка, которая может быть обнаружена в ходе обмена командами, а более отложенная. Например, если следующий релей не смог передать письмо дальше по цепочке в течение установленного времени. Либо почтовый ящик получателя переполнен - обычно это обнаруживается уже после окончания приема письма и попытке разместить его в п/я. Но во всяком случае, поле "From:" заголовка останется прежним и получатель сможет увидеть, кем письмо было написано (если он подписался настоящим адресом, разумеется).
Другой случай - форвардинг. Вы посылаете письмо на какой-то внешний почтовый ящик, а этот сервер настроен так, что все входящие на этот ящик письма он сортирует и перенаправляет на другие п/я - реальным получателям или следующим форвардерам. В этом случае при пересылке будет изменяться команда "RCPT TO:". Но поле "To:" в письме останется первоначальным. И получатель может по этому полю определить, с какого внешнего п/я был произведен форвардинг (на какой внешний п/я было первоначально отправлено письмо), и произвести окончательную сортировку.

Ну а спамеры легко подделывают все эти поля и, обычно, адрес в команде "MAIL FROM:". Им важнее тот массив адресов жертв, который они передают в командах "RCPT TO:"

----------


## GrAnd

> Реальные адреса от кого и кому задаются командами протокола и в шапку письма могут попасть только по доброй воле почтового сервера, ставящего там свою отметку о приёме. А могут и вообще не попасть.


Скорее, второе. Многие спецификации носят больше рекомендательный, чем предписывающий характер.



> По правильному - клиентом. А серверам приходится исправлять ошибки плохо сделанных клиентов.
> Странный у вас почтовый клиент. У меня TheBat! 2.10 их сам генерит. А вот сервер (Eserv/3) не обучен добавлять Message-ID. Как-то я этим не озадачивался.


Да пусть его будет "клиентом". Хотя ... "клиенты бывают разные!", так что уж если совсем хотите точно, то "почтовым клиентом".
Да чего там странного ... самые обычнве MSO и MSOE. Версии разные, так что за все отвечать не могу, но большинство ведет себя именно так.
Заинтересовали. Поставлю себе TheBat! и проверю.

----------


## pig

MSO вообще загадочный клиент. Какая-то версия даже From: в шапку не включала, пихала вместо этого Sender:

----------


## Alexey P.

Насчет "кто как борется с сабжем" - вот пришло письмо, 8 строк html, остальное картинка:
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on rmo
X-Spam-Level: *********************************
X-Spam-Status: Yes, score=33.0 required=5.0 tests=BAYES_99,
        DATE_IN_FUTURE_06_12,EXTRA_MPART_TYPE,HTML_90_100,  HTML_IMAGE_ONLY_08,
        HTML_MESSAGE,HTML_SHORT_LINK_IMG_1,MIME_HTML_MOSTL  Y,MPART_ALT_DIFF,
        RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL,UNPARSEABLE_REL  AY,URIBL_JP_SURBL,
        URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL autolearn=spam version=3.1.1
X-Spam-Report: 
        *  1.1 EXTRA_MPART_TYPE Header has extraneous Content-type:...type= entry
        *  1.7 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date
        *  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
        *      lines
        *  0.1 HTML_90_100 BODY: Message is 90% to 100% HTML
        *  1.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME
        *  0.0 HTML_MESSAGE BODY: HTML included in message
        *  3.1 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words
        *  2.0 MPART_ALT_DIFF BODY: HTML and text parts are different
        *  5.0 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
        *      [score: 1.0000]
        *  3.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
        *      [Blocked - see <http://www.spamcop.net/bl.shtml?125.57.32.64>]
        *  3.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
        *      [125.57.32.64 listed in sbl-xbl.spamhaus.org]
        *  2.0 URIBL_SBL Contains an URL listed in the SBL blocklist
        *      [URIs: morosytes.net]
        *  4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
        *      [URIs: morosytes.net]
        *  2.0 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
        *      [URIs: morosytes.net]
        *  3.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
        *      [URIs: morosytes.net]
        *  0.9 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image

----------


## GrAnd

> Насчет "кто как борется с сабжем" - вот пришло письмо, 8 строк html, остальное картинка:


Тут, как я погляжу, целый комплекс фильтров и блэклистов. И большинство из них распознают в данном посте спам.
Что это за комплекс такой, кстати?

8 строчек текста в html ... Этого более, чем достаточно даже для одного байесовского фильтра. А сабж о том, что зачастую в теле письма только теги изображения. Материала для байеса нет.
Впрочем, как мне кажется, данный комплекс сработает и в этом случае.

----------


## Alexey P.

Классика жанра, Spamassassin.
Для домашнего компьютера тяжеловат, а для почтового сервера, имхо, наилучшее и к тому же бесплатное решение. 
 Имеет смысл использовать, начиная с небольшой локалки, хотя под такое определение вполне подходит и квартирная сетка из двух - трех компьютеров. Не знаю, есть ли он под винду, в классическом варианте под *никсы.

----------

