URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID10
Нить номер: 3370
[ Назад ]

Исходное сообщение
"Спам не по адресу"
Отправлено Андрей , 12-Июл-07 16:46

Сервер FreeBSD, MTA Sendmail 8.14
Ко мне другим пользователям регулярно сыпятся спам письма с подобными заголовками:
From tdbp@rbc.ru Thu Jul 12 16:11:05 2007
Return-Path: <tdbp@rbc.ru>
Received: from 213.85.89.10 ([89.136.190.173])
    by first.mnfond.ru (8.14.0/8.13.3) with SMTP id l6CCAu7N002223;
    Thu, 12 Jul 2007 16:11:03 +0400 (MSD)
    (envelope-from tdbp@rbc.ru)
Message-ID: <00b101c7c473$5d49cfb0$0201fea9@awkward>
From: =?koi8-r?B?88zV1sLBINDPxMTF0tbLyQ==?= <tdbp@rbc.ru>
To: distort@annette.ru
Subject: =?koi8-r?B?8sHT09nMy8kgxd3FINzGxsXL1MnXzsXF?=
Date: Thu, 12 Jul 2007 07:57:22 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
    type="multipart/alternative";
    boundary="----=_NextPart_000_00AD_01C7C494.E3C2D930"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.1830
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
На сервере несколько виртуальных доменов. Все что надо прописано в конфигурации и соответствующих файлах virtusertable, genericstable, access, local-host-names, relay-domains и т.д.
Включена проверка по blackholes.mail-abuse.org и dul.ru, установлены локальные правила проверки поля To на "undisclosed-recipients;" или "undisclosed recipient" и правильности формата поля Message-ID.
В файле access напрямую прописаны все локальные почтовые адреса (через To:name@domen[TAB]OK) НО подобные письма с несуществующим e-mail адресом в поле ТО всеравно проходят.
Кто нибудь знает механизм рассылки подобной дряни? Как заставить sendmail не принимать письма с несуществующим адресом в поле TО заголовка?

Содержание

Спам не по адресу,DN, 12:37 , 16-Июл-07
- Спам не по адресу,Андрей, 17:05 , 20-Июл-07
  - Спам не по адресу,DN, 00:24 , 23-Июл-07
    - Спам не по адресу,Андрей, 14:02 , 06-Авг-07
      - Спам не по адресу,Kost, 10:57 , 17-Мрт-11

Сообщения в этом обсуждении

"Спам не по адресу"
Отправлено DN , 16-Июл-07 12:37

>Сервер FreeBSD, MTA Sendmail 8.14
>Ко мне другим пользователям регулярно сыпятся спам письма с подобными заголовками:
>
>From tdbp@rbc.ru Thu Jul 12 16:11:05 2007
>Return-Path: <tdbp@rbc.ru>
>Received: from 213.85.89.10 ([89.136.190.173])
^^^^^^^^^^^^^^^^
> by first.mnfond.ru (8.14.0/8.13.3) with SMTP id l6CCAu7N002223;
> Thu, 12 Jul 2007 16:11:03 +0400 (MSD)
> (envelope-from tdbp@rbc.ru)
>Message-ID: <00b101c7c473$5d49cfb0$0201fea9@awkward>
>На сервере несколько виртуальных доменов. Все что надо прописано в конфигурации и
>соответствующих файлах virtusertable, genericstable, access, local-host-names, relay-domains и т.д.
>Включена проверка по blackholes.mail-abuse.org и dul.ru, установлены локальные правила проверки поля To
>на "undisclosed-recipients;" или "undisclosed recipient" и правильности формата поля Message-ID.
>В файле access напрямую прописаны все локальные почтовые адреса (через To:name@domen[TAB]OK) НО
>подобные письма с несуществующим e-mail адресом в поле ТО всеравно проходят.
>Кто нибудь знает механизм рассылки подобной дряни? Как заставить sendmail не принимать
>письма с несуществующим адресом в поле TО заголовка?
И будут приходить ( RFC2505 ), пока не будете проверять "легетивность" sender'а.

"Спам не по адресу"
Отправлено Андрей , 20-Июл-07 17:05

>[оверквотинг удален]
>>Включена проверка по blackholes.mail-abuse.org и dul.ru, установлены локальные правила проверки поля To
>>на "undisclosed-recipients;" или "undisclosed recipient" и правильности формата поля Message-ID.
>>В файле access напрямую прописаны все локальные почтовые адреса (через To:name@domen[TAB]OK) НО
>>подобные письма с несуществующим e-mail адресом в поле ТО всеравно проходят.
>
>>Кто нибудь знает механизм рассылки подобной дряни? Как заставить sendmail не принимать
>>письма с несуществующим адресом в поле TО заголовка?
>
>И будут приходить ( RFC2505 ), пока не будете проверять "легетивность" sender'а.
>
Спасибо, идея понятна. Можете подсказать, как это сделать?

"Спам не по адресу"
Отправлено DN , 23-Июл-07 00:24

>>>Кто нибудь знает механизм рассылки подобной дряни? Как заставить sendmail не принимать
>>>письма с несуществующим адресом в поле TО заголовка?
>>
>>И будут приходить ( RFC2505 ), пока не будете проверять "легетивность" sender'а.
>>
>
>Спасибо, идея понятна. Можете подсказать, как это сделать?
E-mail основана на DNS именах.
Легитимность sender'а определяется наличием соответствием имена хоста в
прямой и обратной зоне DNS.
RFC 1033
There should be one A record for each address of a host.
PTR's should use official names and not aliases.

To add a new host to your zone files:
Edit the appropriate zone file for the domain the host is in.
Add an entry for each address of the host.
Optionally add CNAME, HINFO, WKS, and MX records.
Add the reverse IN-ADDR entry for each host address in the appropriate
zone files for each network the host in on.
RFC 1123
A canonicalized name either identifies a host directly or is an MX name;
it cannot be a CNAME.

RFC 2181
10.2. PTR records
  Confusion about canonical names has lead to a belief that a PTR
  record should have exactly one RR in its RRSet.  This is incorrect,
  the relevant section of RFC1034 (section 3.6.2) indicates that the
  value of a PTR record should be a canonical name.  That is, it should
  not be an alias.  There is no implication in that section that only
  one PTR record is permitted for a name.  No such restriction should
  be inferred.
  Note that while the value of a PTR record must not be an alias, there
  is no requirement that the process of resolving a PTR record not
  encounter any aliases.  The label that is being looked up for a PTR
  value might have a CNAME record.  That is, it might be an alias.  The
  value of that CNAME RR, if not another alias, which it should not be,
  will give the location where the PTR record is found.  That record
  gives the result of the PTR type lookup.  This final result, the
  value of the PTR RR, is the label which must not be an alias.
10.3. MX and NS records
  The domain name used as the value of a NS resource record, or part of
  the value of a MX resource record must not be an alias.
RFC2821:
4.3.1
[..]
   Note: all the greeting-type replies have the official name (the
   fully-qualified primary domain name) of the server host as the first
   word following the reply code.  Sometimes the host will have no
   meaningful name.  See 4.1.3 for a discussion of alternatives in these
   situations.
[...]
RFC1035:
3.5. IN-ADDR.ARPA domain
The Internet uses a special domain to support gateway location and
Internet address to host mapping.
The intent of this domain is to provide a guaranteed method to perform
host address to host name mapping,
and to facilitate queries to locate all gateways on a particular network
in the Internet.

Note that both of these services are similar to functions that could be
performed by inverse queries; the difference is
that this part of the domain name space is structured according to address,
and hence can guarantee that the appropriate data can be located without
an exhaustive search of the domain space.

Address nodes are used to hold pointers to primary host names
in the normal domain space.
Еще может быть запись в реверсной зоне, что хост
является SMTP релеем (MTAMARK _perm._smtp._srv.$4.$3.$2.$1.in-addr.arpa.),
Неплохо бы проверить наличее ящика из MAIL FROM: <...>  через
MX прямой зоны, выполнив callback.
Вам надо смотреть софт типа
http://www.snertsoft.com/sendmail/milter-sender/
http://www.milter.info/
К Сергею Вакуленко можно заглянуть
http://www.vak.ru/doku.php/proj/sendmail/antispam
Плюс фильтры типа SpamAssassin.

"Спам не по адресу"
Отправлено Андрей , 06-Авг-07 14:02

>[оверквотинг удален]
>MX прямой зоны, выполнив callback.
>
>Вам надо смотреть софт типа
>http://www.snertsoft.com/sendmail/milter-sender/
>http://www.milter.info/
>
>К Сергею Вакуленко можно заглянуть
>http://www.vak.ru/doku.php/proj/sendmail/antispam
>
>Плюс фильтры типа SpamAssassin.
Спасибо за помощь
Обнаружил в портах FreeBSD утилиту SPAMILTER, попробовал - работает!
По логике похоже на milter-sender но в отличие от оного включена в состав портов FreeDSD со всеми вытекающими отсюда последствиями.

"Спам не по адресу"
Отправлено Kost , 17-Мрт-11 10:57

Можно сделать так, но в целом пустой адрес адрес разрешен в RFC
Добавим в main.cf
header_checks = pcre:/etc/postfix/header_checks.pcre
Файл /etc/postfix/header_checks.pcre
# To:
/^To:.*undisclosed-recipients/ REJECT empty recipient field