ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


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


  ПРОГРАММЫ 



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












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

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

Re: [inet-admins] Re: =?koi8-r?Q?=5Binet-a?==?koi8-r?Q?dmins=5D_Re=3A_=5Binet-admins=5D_Re=3A_=5Binet-admins=5D_Re=3A?==?koi8-r?Q?_=5Binet-admins=5D_Re=3A_=5Binet-admins=5D_Re=3A_=5Binet-admin?==?koi8-r?B?c10g68/Myd7F09TXzyDQz8zV3sHUxczFyiDPxM7Px88g0MnT2M3BLg==?=



On Wed, Feb 27, 2002 at 10:43:38PM +0300, Alex Tutubalin wrote:
Alex>  
Alex>  > > Я могу сказать как это выглядит с передающей стороны. В двух словах -
Alex>  > > отвратительно т.к следующая попытка delivery производится MTA далеко
Alex>  > 
Alex>  > Вот-вот. А оно тебе надо?
Alex>  Мне оно не надо т.к. рассылка не моя, а (неназываемого) заказчика
Alex>  > Мухин мне в описаной ситуации предложил выбор из трех альтернатив - 
Alex>  
Alex>  Проблема в том, что существует масса сервисов бесплатной почты, которые
Alex>   - не принимают по длинному списку т.к. не любят спаммеров
Alex>   - не могут раздавать своим клиентам т.к. не знаю кому из них это надо
Alex>   - произведение "числа рассылок на число сервисов почты" слишком велико,
Alex>    чтобы реально можно было договориться.
Alex>  
Alex>  Поэтому проблема таки существует и приделывание интеллекта 
Alex>  к анализу логов - единственное решение. Потому как без этого имеем
Alex>  lexa@webserver1:~# mailq |wc
Alex>      3021    6412  186889
Alex>  
Alex>  - и это на самом деле всего-то два письма :). Примерно на 60 тысяч
Alex>  адресов они разослались мгновенно, а остаток будет ползти еще несколько
Alex>  дней. Впрочем постфиксу это пофигу.

Попробую систематизировать.

Проблемы, связанные с отсутствием ограничений на число получателей на нашей 
стороне:

1) пользователь, отправляющий по длинному списку, нагружает провайдера 
непропорционально своей плате за услуги

2) при наличии ограничений на приемной стороне -- проблемы с передосылкой 

Проблемы, связанные с наличием ограничения:

3) прием почты из мира для большого количества своих клиентов,
подписанных на один и тот же лист, связан с проблемами передосылки
и наматыванием внешнего трафика

4) отправка своими пользователями, ведущими большие списки,
связана с проблемами передосылки

Пути решения:

(1) -- ограничения таки нужны в default случаях; размер ограничения
определяется терпимостью провайдера

(2) -- таки нужен интеллект или смиряемся с тем, что на некоторые
узлы отправка почты связана с перманентными проблемами

(3) -- на прием почты из мира никаких ограничений

(4) -- для спец. пользователей -- спец. релей

Собственно решение:

Три релея (не обязательно на разных машинах) -- один для отправки
default пользователями, второй -- для отправки спец. пользователями,
третий -- для приема из мира. Как вариант, второй релей может быть
smart host'ом для первого.

Интеллект, обрабатывающий логи второго релея и варьирующий количество
получателей в письме в зависимости от домена. По идее должен иметь
две составляющие -- анализирующую (самопал) и исполняющую (тоже самопал?
как минимум для формирования очереди на отправку).

-- 
-------------------------------------------------------
 Dmitry Cherkasov   ISP "Intercom"   (380)44 251-12-88
   http://www.intercom.net.ua    DC1-UANIC CHD1-RIPE



=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.