ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Почтовый прокси



Anton Yuzhaninov wrote:
> Hello Igor,
> 
> You wrote on Wednesday, February 14, 2007, 3:18:32 PM:
> 
> IS> Для SMTP модуль будет, но с другой функциональностью.
> IS> SMTP, в отличие от IMAP/POP3, масштабируется MX'ами.
> 
> Если есть планы этим занять в обозримом будущем могу описать какой
> функциональности бы хотелось.
> 
> Есть две разные задачи, для которых нужна разная функциональность:
> 
> 1. Клиентский smtp.
> 2. Входящие mx
> 
> 1. Клиентский smtp. Если посмотреть логи postfix, то 90% процентов
> нагрузки создают спамботы и вирусы которые даже не пытаются
> авторизироваться. Задача не допускать их до postfix.
> 
> Т. е. нужно:
> a. Прочитать helo/ehlo если клиент скажет это и запомнить.
> b. Авторизировать его на внешнем http-сервере аналогично тому как это
> сделано в pop3/imap. SASL Методы нужны те же что и в pop3 - LOGIN, PLAIN, 
> CRAM-MD5.
> c. Если авторизация пройдена, подключиться к бэкенду (postfix),
> передать ему команду
> XCLIENT ADDR=81.19.65.117 PROTO=ESMTP HELO=ivan.office.ru LOGIN=username
> В которой будут указаны клиентский ip, логин и др.
> 
> И после этого прозрачно проксировать данные между клиентом и
> постфиксом.
> 
> Ресолвинг для данной задачи не нужен.
> 
> 2. Входящие mx:
> 
> a. Принять от клиента команды helo (на входящих эту команду нужно
> требовать от клиента в обязательном порядке), mail from, rcpt to
> b. Отресолвить ip клиента, поискать его в RBL
> 
> c. На основании конфигурируемой комбинации проверок helo по regexp,
> mail from, rcpt to по списку (в виде bdb или cdb или просто in-memory
> хеш) и ip по RBL решить проксировать дальше или послать сразу. В каком
> виде делать эти ACL это нужно обсуждать отдельно. Но как минимум нужно
> почту на postmaster@ и abuse@ пропускать без дополнительных проверок.
> 
> d. Если решили проксировать, то подключиться к postfix указав в
> XCLIENT то что знаем про клиента и дальше прозрачно передавать все
> данные.
> 
> Для входящих mx в будущем неплохо бы иметь еще такую функциональность:
> Если IP нам не нравится (это проверять можно тоже по RBL, либо через
> статический список префиксов), то перед выдачей начального приветствия
> 220 делаем задержку в несколько секунд. Если он не дождавшись
> приветствия начал что то нам передавать - посылаем его.
> 

Еще полезно делать lookup MX или A домена отправителя и посылать тех, у
кого этого нет. Т.е. например в SMTP сессии:

mail from:<vasya@xxxxxxxxxxxxxxxxxx>

но verycooldomain.tld не имеет ни MX, ни A записи, то с вероятностью 99%
ничего хорошего оттуда не придет.

-- 
Konstantin Sorokin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



 




Copyright © Lexa Software, 1996-2009.