|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Oleg V. Nauman 2:5020/400 18 Jun 2005 16:44:00
To : Vadim Goncharov
Subject : Re: greylisting
--------------------------------------------------------------------------------
Vadim Goncharov <vadimnuclight@tpu.ru> wrote:
VG> Hi Victor Sudakov!
VG>
VG> On Fri, 10 Jun 2005 10:52:06 +0000 (UTC); Victor Sudakov wrote about
VG> 'greylisting (was: Re: ODBC & Oracle)':
>>> Вкратце - базируется на том, что спамер не будет переотправлять письмо.
>>> Принимающая машина запоминает айпи отправителя и некоторые заголовки
>>> письма
VS>> Hет, заголовки оно не запоминает. Запоминается триада из IP
VS>> отправителя, E-mail отправителя и E-mail получателя. Само письмо в
VS>> первый раз не принимается.
VG>
VG> Ага, уже прочитал. А иначе пришлось бы прнимать письмо, тогда весь смысл
VG> теряется.
VG>
>>> и выдает SMTP-код "занято, попробуй позже". И в следующий раз эту
>>> комбинацию пропускает беспрепятственно. Штука довольно мощная, но вот
>>> детали и почему оно так мало распространено, я не в курсе, самому
>>> интересно.
VS>> Во-первых, вызывает заметные задержки в хождении почты. Обычно принято
VS>> после получения 4xx приходить повторно через полчаса.
VG>
VG> Это может быть некритично. Поскольку задержка только в первый раз.
Это может быть критично. Поскольку ни один relay не обязан заново
"провернуть" очередь с задержанным сообщением в течении срока, отведенного
удаленной стороной до того как запись в greylisting забавке не будет
expired. То есть: на достаточно загруженных почтовых серверах, не успевающих
поднять из очереди это сообщение в течение срока отведенного ему удаленной
стороной, это сообщение грозит быть не доставленным никогда. Да и вовсе не
обязана отправляющая сторона повторять попытки доставки с того же
самого IP.
Hу а о том, что greylisting есть наглое использование чужих ресурсов
в собственных целях, лучше уж не вспоминать.
VG>
VS>> Во-вторых, хранение триад при большом почтовом трафике может быть
VS>> весьма накладным. Hапример, milter-greylist из портов отжирает десятки
VS>> мегабайт ОЗУ под свою базу.
VG>
VG> Оно в памяти что ли хранит? SQL-база имхо получше будет, а в случае
VG> нескольких MX для домена иначе и никак, должна быть общая greylist-база
VG> на всех.
VG>
VS>> В-третьих, есть почтовые сервера, несовместимые с greylisting
VS>> (например, у некоторых рассылок "mail from" может быть каждый раз
VS>> уникальный), для таких приходится прописывать явные исключения.
VG>
VG> Эти ССЗБ, как говорит
VG> http://projects.puremagic.com/greylisting/whitepaper.html - авторы
VG> таких софтин должны их фиксить (и в случае с приведенным там примером
VG> таки его авторы это фиксили). Генерирование уникального сендера для
VG> каждого письма всё же определенно bad idea.
Отнюдь. Может конкретно помогать в случае борьбы с проблемами доставки
почты. Для больших списков рассылки (да с изрядным количеством ролевых
accounts в них) это актуально.
Да и ничему не противоречит.
--
NO37-RIPE
--- ifmail v.2.15dev5.3
* Origin: ReIS Ltd. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
