Postfix и умный спам (как отсечь письма с некорректным адресом)

[folibis]

На серваке стоит Postfix под CentOS 5.2. В последнее время стал просачиваться спам.
Почему то Postfix его не отсекает хотя заголовки явно некорректные.
Вот, например, заголовок письма:

Код: Выделить всё

Return-Path: <bsgllsp@mail.ru>
X-Original-To: mymailbox@myserver.ru
Delivered-To: mymailbox@myserver.ru
Received: from myserver.ru (myserver.ru [127.0.0.1])
    by myserver.ru (Postfix) with ESMTP id 469957C074B;
    Wed,  3 Jun 2009 03:59:48 +1100 (VLAST)
Received: from server100.welcometelecom.ru (unknown [64.251.48.194])
    by myserver.ru (Postfix) with SMTP id 1FBBF7C074A;
    Wed,  3 Jun 2009 03:59:36 +1100 (VLAST)
Message-ID: <003e01c9e3a3$81f3c220$c85fa8c0@server100.welcometelecom.ru>
From: "=?utf-8?B?0JLQmNCfLdCX0JDQm9Cr?=" <bsgllsp@mail.ru>
To: anothermailbox@myserver.ru

X-Original-To: и To: явно не совпадают, как и
Received: from server100.welcometelecom.ru и From: <bsgllsp@mail.ru>
Но почему то Postfix смотрит не на X-Original-To, что было бы правильнее, а на To: и то же самое с Received:
В From: можно что угодно прописать а Received: это настоящий адрес, но почему то берется From:, что, мне кажется, неправильно.
Вот кусок лога

Код: Выделить всё

Jun  3 03:59:37 myserver postfix/smtpd[11863]: 1FBBF7C074A: client=unknown[64.251.48.194]
Jun  3 03:59:46 myserver postfix/cleanup[12546]: 1FBBF7C074A: message-id=<003e01c9e3a3$81f3c220$c85fa8c0@server100.welcometelecom.ru>
Jun  3 03:59:48 myserver postfix/qmgr[19373]: 1FBBF7C074A: from=<bsgllsp@mail.ru>, size=41123, nrcpt=9 (queue active)
Jun  3 03:59:48 myserver postfix/smtp[12551]: 1FBBF7C074A: to=<mymailbox@myserver.ru>, relay=127.0.0.1[127.0.0.1]:10027, delay=12, delays=12/0.01/0.09/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 469957C074B)
Jun  3 03:59:48 myserver postfix/qmgr[19373]: 1FBBF7C074A: removed

И конфиг:

Код: Выделить всё

postconf -n
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = scan:[127.0.0.1]:10027
daemon_directory = /usr/libexec/postfix
debug_peer_level = 10
debug_peer_list = mysql:/etc/postfix/debug.cf
header_checks = regexp:/etc/postfix/header.cf
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
local_transport = virtual
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 10000000
mime_header_checks = regexp:/etc/postfix/header_mime.cf
mydestination = localhost
mydomain = myserver.ru
myhostname = myserver.ru
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.2.0/24
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
receive_override_options = no_address_mappings
relay_domains = myserver.ru
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_helo_timeout = 60s
smtp_mail_timeout = 60s
smtp_rcpt_timeout = 90s
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = mysql:/etc/postfix/virtual_password.cf
smtp_use_tls = yes
smtpd_banner = Welcome to $myhostname ESMTP Mail Server
smtpd_etrn_restrictions = permit_mynetworks,    reject
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_helo_access hash:/etc/postfix/postmaster.cf,
check_sender_access hash:/etc/postfix/postmaster.cf,
reject_unknown_hostname,
reject_invalid_hostname,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_helo_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_helo_hostname,
reject_unknown_sender_domain,
reject_unverified_sender,
reject_unverified_recipient,
check_sender_access hash:/etc/postfix/allow.cf,
check_helo_access hash:/etc/postfix/allow.cf,
check_client_access pcre:/etc/postfix/access_pcre.cf,
check_policy_service inet:127.0.0.1:10023,
permit_auth_destination,
reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_timeout = 120s
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_received_header = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_session_cache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport.cf
unknown_local_recipient_reject_code = 450
virtual_gid_maps = mysql:/etc/postfix/virtual_gid.cf
virtual_mailbox_base = /var/maildir
virtual_mailbox_limit = 100000000
virtual_mailbox_maps = mysql:/etc/postfix/mailbox_maps.cf
virtual_uid_maps = mysql:/etc/postfix/virtual_uid.cf

Если кто знает как отсекать такие письма, был бы очень рад ...

[watashiwa_daredeska]

X-Original-To: и To: явно не совпадают,

И не обязаны.

Received: from server100.welcometelecom.ru и From: <bsgllsp@mail.ru>

И не обязаны. Я, например, частенько отсылаю письма со своим обратным gmail'овским адресом через свой собственный SMTP.

Postfix смотрит не на X-Original-To, что было бы правильнее, а на To:

Не правильнее. X-Original-To вообще ни к чему не обязывает. Да и на To: он не смотрит. Он смотрит на RCPT TO: -- envelope адрес.

Читайте RFC: http://www.ietf.org/rfc/rfc2821.txt, http://www.ietf.org/rfc/rfc2822.txt и др.

[Ленивая Бестолочь]

Received: from server100.welcometelecom.ru и From: <bsgllsp@mail.ru>

против такого частично поможет SPF.

[butch]

против такого частично поможет SPF.

а вы видели спф у мэйл.ру? =) ~all у них стоит =)
тут скорее коллаут поможет. но тож частично

[Ленивая Бестолочь]

ну - тут все зависит от вашей степени ярости :-)
~all - грубо говоря значит, что рекомендуется принимать только с этих хостов.
все зависит от того, как вы понимаете слово "рекомендуется".
было бы "?all" - тада да.


а за коллаут могут и забанить нынче.

[butch]

а за коллаут могут и забанить нынче.

это с каких это пор могут забанить за коллаут? =)))ничего плохого нет в том чтобы произвести попытку доставки. ведь коллаут - смтп сессия с mail from=<>, а такое вы точно должны до этапа отправки данных пропускать.

~all - грубо говоря значит, что рекомендуется принимать только с этих хостов.

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

[Ленивая Бестолочь]

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

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

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

ну - если так рассуждать, так спф вообще использовать не логично :-)

[butch]

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

ни. коллаут они не могут запретить. ибо коллаут начинается точно так же, как и отправка сообщения о невозможности доставить и тд. и по вашему кто то в здравом уме может запретить сессии с мэйл форм = <>?

ну - если так рассуждать, так спф вообще использовать не логично :-)

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

[Ленивая Бестолочь]

ни. коллаут они не могут запретить. ибо коллаут начинается точно так же, как и отправка сообщения о невозможности доставить и тд. и по вашему кто то в здравом уме может запретить сессии с мэйл форм = <>?

гм, да элементарно запрещается, было бы желание.
если начата smtp сессия, но до "DATA" она не дошла - значит это оно.

[watashiwa_daredeska]

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

Простите, а при чем тут провы? Если провайдер пускает изнутри наружу через свой релей почту с mail from: ...@mail.ru, то это его личные половые трудности, а если провайдер выпускает почту с mail from: ...@provider.ru, то все Ok. К заголовку From: в письме это не имеет, кстати, никакого отношения. Я шлю почту через свой собственный релей со вполне валидным SPF, указывая при этом произвольные обратные адреса в From:

[butch]

если начата smtp сессия, но до "DATA" она не дошла - значит это оно.

эмм... дык при коллауте дату никто и не отправляет =) и что же даст вам понимание того, что вот эта вот сессия, которая токо что закрылась была коллаутом? ведь больше для коллаута и не нужно, лиж бы вы ок ответили на rcpt to.
имхо, вы что то совсем не о том думаете.

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

Простите, а при чем тут провы?

это к ~all. популярным почтовикам никуда не дется. им не поставить -all, ведь многие отправляют письма через другие мта, не указанные в спф (естественно).
остальной бред про фром комментировать не буду, об этом в нашем дискусе с Ленивая Бестолоч... вроде и слова не было.

[watashiwa_daredeska]

это к ~all. популярным почтовикам никуда не дется. им не поставить -all, ведь многие отправляют письма через другие мта, не указанные в спф

Простите, я не понимаю, как это связано.
Вот пример. Я отправляю письмо From: me@mail.ru, To: myfriend@gmail.com через SMTP моего провайдера provider.ru, где я зарегистрирован как user. Таким образом, мой обратный envelope address будет user@provider.ru. При получении письма MTA gmail.com будет запрашивать SPF основываясь на envelope address, т.е. не у mail.ru, а у provider.ru. SPF mail.ru в этом сценарии вообще роялю не играет. А играть он начинает, если криво настроенный MTA провайдера криво релеит почту, позволяя указывать фальшивые обратные envelope address (ибо за их достоверность он не отвечает), т.е. фактически, являетя пособником спамеров.

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

Еще один адресочек в список тех, кому не отправлять письма. Или отправлять, но в последнюю очередь, когда нагрузка позволит выдержать коллаутный DoS.

[butch]

Простите, я не понимаю, как это связано.

те релеи, что я видел у провов, который закрывают 25тцп порт наружу для клиентов с серыми ип, делают опенрелей для всей своей подсети. никакой авторизации. пихай куда хочешь че хошь.

[watashiwa_daredeska]

те релеи, что я видел у провов, который закрывают 25тцп порт наружу для клиентов с серыми ип, делают опенрелей для всей своей подсети. никакой авторизации. пихай куда хочешь че хошь.

А вы не интересовались глубинным смыслом подобных манипуляций? Мне вот действительно интересно, какие бонусы это дает, кроме увеличения выброса парниковых газов и ускоренного наступления субтропического климата в Москве :)

[butch]

А вы не интересовались глубинным смыслом подобных манипуляций?

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

так думаю, сначала была идея отправлять с авторизацией, но после тестового пробега выяснили что юзерам всего этого не осилить, и нагрузка на суппорт возрастает многократно =)) вот и сделали опенрелей =)))

[watashiwa_daredeska]

думаю идея в том, чтобы не регить всех на своих почтовых серверах (хотя сделать форму для регистрации думаю не большая проблема)

Зачем форма для регистрации? Для выхода в Сеть нынче практически везде нужен VPN, а ему нужен логин, вот и давать пользователям SMTP с этим логином. Мой провайдер, во всяком случае, так делает.

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

Поставить свой исходящий SMTP в другой подсети, нежели пользователи, и нет проблем. Пусть хоть всех там перебанят.

Да и SMTP-авторизация для пользователей давно не новость -- все бесплатные почтовики ее используют, так что, просто банальная лень.
Надо, кстати, посчитать, сколько у меня нормальной почты идет с SOFTFAIL и NEUTRAL адресов.

[Ленивая Бестолочь]

butch , вот тут: http://www.postfix.org/ADDRESS_VERIFICATIO...tml#limitations прочитайте warning сверху.
он вполне обоснованный.

предположим я админ очень крупного почтового сервера www.mail.xx
у меня есть некоторое колличество машин и злое начальство, которое не любит покупать новое железо.
нагрузка на почтовые сервера постоянно растет из-за увеличения кол-ва пользователей, спамеров и мировой энтропии.
и надо оно мне, чтобы какая-то контора ЧП "Иванов и сын" решала СВОИ проблемы со спамом ЗА МОЙ СЧЕТ?
нагружая мои сервера постоянными callout-ами. да я с удовольствием настрою свой любимый MTA так, что после 10го письма без DATA с одного и того же релея он (релей) возглавит отряд идущих в /etc/hosts.deny. ну и еще письмо отправлю типа: "хотите жить - вырубайте колаут".

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

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

watashiwa_darede..., почти во всех известных мне питерских локалках всё, что идет на 25 порт прозрачно заворачивается на релей провайдера. без всякой авторизации. ключевое слово - прозрачно.
юзер вася думает, что настроил outlook на отправку с mail.ru и радуется, а на самом деле шлет через фиг знает что.

наверно, если серьезно заниматься антиспамом нужно строить систему на основе баллов и "?all" будет говорить о том, что если релей соответствует spf - нет претензий, а если нет - плюс балл.

[butch]

решала СВОИ проблемы со спамом ЗА МОЙ СЧЕТ?

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

[watashiwa_daredeska]

почти во всех известных мне питерских локалках всё, что идет на 25 порт прозрачно заворачивается на релей провайдера. без всякой авторизации.

А в чем отличие от открытого порта? В том, что теперь за спам банят вообще всю сетку без возможности для пользователей воспользоваться альтернативными SMTP? Или это требование ФСБ для перлюстрации?

[folibis]

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

[Ленивая Бестолочь]

folibis, так вам ответили уже :-)
по заголовкам вы обязаны такие письма принять.
хотите бороться со спамом - придется использовать другие методы: callout, greylists, spf, etc.

А в чем отличие от открытого порта? В том, что теперь за спам банят вообще всю сетку без возможности для пользователей воспользоваться альтернативными SMTP? Или это требование ФСБ для перлюстрации?

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

[watashiwa_daredeska]

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

Нечеловеческая логика какая-то. Настроить один раз авторизацию и вынести почтовик в другую подсеть -- тяжело, а вечно бороться со спамом с переменным успехом и ходить по граблям из-за нарушения правил (ну ладно, у mail.ru ~all, а ну у кого -all?) -- легко. Мне этого никогда не понять