форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Блокирование спама на этапе соединения в sendmail"

Сообщение от opennews (??) on 22-Апр-05, 10:21

Dmitry Zubov описал (http://dz.dn.ua/spam/antispam.html) достаточно жесткую схему фильтрации спама на почтовом сервере работающем под управлением sendmail (FreeBSD). Схема предусматривает блокировку хостов без обратной зоны или  несовпадении "PTR" и "A" записей, подключение проверки в DNSBL системах, обратную проверку существования адреса через milter-sender. URL: http://dz.dn.ua/spam/antispam.html Новость: http://www.opennet.ru/opennews/art.shtml?num=5368

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Андрей (??) on 22-Апр-05, 10:21

Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации!!! На одном и том же хосте может быть пачка адресов из одной и той же сетки, плюс за каждым из них может числиться набор имен. И резолвер у сендмыла, да и не только у него, это прощелкивает на счет раз :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Аноним on 22-Апр-05, 10:28

Уважаемый! Вы как давно делали такую фильтрацию? В курсе ли Вы что Yandex, etc не говорят Вам действительную информацию о пользователях?...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Zerg (??) on 22-Апр-05, 10:41

>Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации!!! Стрелял, а затем добивал бы прикладом тех, кто у себя это настроить не может. Ненавижу! ИМХО: политика отлупа на стадии соединения, наиболее верная ... Главное при этом соблюдать осторожность при выборе "черных списков". Всякие там спам-ассасины - штука конечно полезна, но на бабки ты уже попал ... Письмо, то сервак получил. А когда этих писем 20-30 тысяч ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Андрей (??) on 22-Апр-05, 12:01
	dig ns.catalysis.ru dig caty.catalysis.ru dig -x 193.124.35.68 Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое время. Еще раз повторюсь, резолверы на таких вещах рушатся. Отлуп на стадии соединения, правда, самое верное решение. Вот только реализация этого отлупа может быть разной.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 22-Апр-05, 13:11
	>Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое Неправильно, то что в RFC[2]821 нет _четкого_ описания что является "main hostname" для multi-homed хостов. Зато в 2821 четко сказанно: An SMTP server MAY verify that the domain name parameter in the EHLO    command actually corresponds to the IP address of the client.    However, the server MUST NOT refuse to accept a message for this    reason if the verification fails: the information about verification    failure is for logging and tracing only. Т.е. любители резать HELO строем и песнями идут в сад. >время. Еще раз повторюсь, резолверы на таких вещах рушатся. Шутите?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 09:47
	>Зато в 2821 четко сказанно: > An SMTP server MAY verify that the domain name parameter in >the EHLO >   command actually corresponds to the IP address of the >client. >   However, the server MUST NOT refuse to accept a >message for this >   reason if the verification fails: the information about verification > >   failure is for logging and tracing only. >Т.е. любители резать HELO строем и песнями идут в сад. Полностью согласен. Однако вопрос в том как резать. Можно проверять валидность предоставленного helo (например не домен получателя), можно проверять чтобы это был не ip-адрес, а [ip-адрес], как требует RFC. В таких случаях смело можно рубить. Дальнейшая проверка (горячо обсуждаемые здесь совпадения по обратной зоне , черные списки и т.д. ) должна использоваться не для разрыва связи, а для применения задержек в ответах. Большинство спамеров отвалится за нарушение последовательности команд. Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту, но вот это уже их проблемы. Хочу отметить что задержки должны быть не для всех, а только для подозрительных клиентов. При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем равен нулю.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 10:00
	>Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту, >но вот это уже их проблемы. Хочу отметить что задержки должны >быть не для всех, а только для подозрительных клиентов. >При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем >равен нулю. Тут есть одно большое, но - это замечательно работает на не больших релеях, а тяжелый релей из-за этих пауз в моменты спамерской активности моментально упрется в собственный лимит на количество одновременных сессий.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 10:41
	>>Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту, >>но вот это уже их проблемы. Хочу отметить что задержки должны >>быть не для всех, а только для подозрительных клиентов. >>При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем >>равен нулю. >Тут есть одно большое, но - это замечательно работает на не больших >релеях, а тяжелый релей из-за этих пауз в моменты спамерской активности >моментально упрется в собственный лимит на количество одновременных сессий. Максимальное число открытых соединений - настраиваемый параметр. По большому счету он оказывает влияние на требования к аппаратному обеспечению сервера. Если одного сервера недостаточно, можно поставить дополнительные и прописать их в MX. Основной сервер при достижении определенного уровня нагрузки начинает рубить соединения. По идее в таком случае клиент ищет следующий MX и шлет почту через него. Я такую схему лично не проверял, но вроде бы в этом и заключается смысл MX записей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 10:51
	У меня и так четыре frontend'a на MX вы предлагаете мне поставить еще 4. Дело в самом способе - вместо того, что бы быстренько послать клиента нафиг/ принять его почту, вы предлагаете висеть и нифига не делать. Повторюсь: pre-gretting и прочие паузы для нагруженных релеев не приемлемы, на маленьких - работают очень хорошо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 11:21
	>У меня и так четыре frontend'a на MX вы предлагаете мне поставить >еще 4. >Дело в самом способе - вместо того, что бы быстренько послать клиента >нафиг/ принять его почту, вы предлагаете висеть и нифига не делать. > >Повторюсь: pre-gretting и прочие паузы для нагруженных релеев не приемлемы, на маленьких >- работают очень хорошо. Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой потери валидной почты. Если у вас получается отсеять спам с приемлемой эффективностью без этой меры и такой подход приводит к снижению затрат на оборудование/содержание/трафик, тут и спорить не стану. Отмечу только что для меня при фильтрации спама основное требование - полное отсутствие потерь валидной почты по вине моего сервера. Сервер действительно слабонагруженный, поэтому метод вполне устраивает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 11:31
	так у вас возможны точно те же проблемы, что и у меня, только вероятность их возникновения существенно ниже :) Плюс требуется очень небольшое изменение спамерского софта, для обхода пауз - им пофиг, что зомби загнется от тысяч параллельных конектов...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 11:41
	>Плюс требуется очень небольшое изменение спамерского софта, для обхода >пауз - им пофиг, что зомби загнется от тысяч параллельных конектов... Пока что легче для спамеров оказывается не обходить задержки, а терять небольшой процент успешно отправленного спама от полной рассылки. Вводить реакцию на задержки в расылочный софт имеет смысл когда процент серверов с задержками станет достаточно большим. Но в этом случае упадет количество писем, отсылаемое спамером (или его затрояненной жертвой) в единицу времени. Это не может не радовать :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 12:02
	Боюсь нам с вами от этого легче не будет - число зомбированных сетей растет как на дрожжах, они возьмут свое количеством. Но пока работает - грех не использовать любую возможность :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 12:05
	>Боюсь нам с вами от этого легче не будет - число зомбированных >сетей растет как на дрожжах, они возьмут свое количеством. Но пока >работает - грех не использовать любую возможность :) Предлагаю на этом закончить дискуссию, налить по кружечке пива и выпить за кончину спамерского дела. Которой все равно не произойдет, но уж очень хочется )
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 12:09
	За это и водки можно :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 12:12
	>За это и водки можно :) Тогда придется закуску искать, а мне сегодня обед не привезли ) Пойду найду в спаме рассылку про пиццу ))))))))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от uldus (ok) on 25-Апр-05, 13:37
	>Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой >потери валидной почты. И вам не попадались отсылающие скрипты с небольшим таймаутом или MTA админ которых по незнаю или злому умыслу баловался настройками таймаутов ? Встречал сервер который обрабатывает сотни списков рассылки, там таймаут на HELO несколько секунд, непрошло десяток писем - автоотписка, ибо в рассылке заинтересованы получатели, а серверу важнее успеть разослать все письма как можно скорее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Merry Monk on 25-Апр-05, 14:08
	>>Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой >>потери валидной почты. > >И вам не попадались отсылающие скрипты с небольшим таймаутом или MTA админ >которых по незнаю или злому умыслу баловался настройками таймаутов ? Если админ по незнанию, а тем более по злому умыслу балуется таймаутами, согласитесь, это полностью его право и его ответственность. Если клиент (будь то скрипт или некорректно настроенный MTA) нарушает требования протокола, я не чувствую своей вины в том что такому клиенту будет отказано в обработке почты. >Встречал сервер который обрабатывает сотни списков рассылки, там таймаут на HELO несколько >секунд, непрошло десяток писем - автоотписка, ибо в рассылке заинтересованы получатели, >а серверу важнее успеть разослать все письма как можно скорее. Опять же, речь идет о нарушении протокола, в соответствии с которым клиент должен ожидать ответа сервера в течение нескольких минут. Я на своем сервере использую задержку в 20 секунд (обращаю внимание на то что задержка включается только для клиента с подозрительным именем или попавшего в черные списки, для остальных клиентов задержка отсутствует). На мой взгляд это достаточно небольшое время с точки зрения корректного МТА с одной стороны, и вполне достаточное для того чтобы вызвать ошибку синхронизации в работе некорректно натсроенного клиента.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Agp (??) on 25-Апр-05, 13:05
	to unk: А какими вы методами пользуетесь против спама?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 13:25
	reject клиента и MX/NS домена из MAIL по "мягким" RBL, greylisting + встречная проверка по "жестким" rbl, reject на высокие баллы антиспама после DATA
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Agp (??) on 25-Апр-05, 13:55
	>reject клиента и MX/NS домена из MAIL по "мягким" RBL, greylisting + >встречная проверка по "жестким" rbl, reject на высокие баллы антиспама после >DATA антиспам после DATA - какой ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 14:03
	>антиспам после DATA - какой ? spamassassin без Байеса + человек пишущий под него правила
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 03:09
	>dig ns.catalysis.ru >dig caty.catalysis.ru >dig -x 193.124.35.68 > >Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое >время. Еще раз повторюсь, резолверы на таких вещах рушатся. > >Отлуп на стадии соединения, правда, самое верное решение. Вот только реализация этого >отлупа может быть разной. А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или caty.catalysis.ru
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 10:10
	>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или >caty.catalysis.ru Какая разница, как был прописан MX, когда проблемы с эмитером??? Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 15:31
	>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или >>caty.catalysis.ru >Какая разница, как был прописан MX, когда проблемы с эмитером??? >Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя... > Я нормально спросил. Хамить необязательно. У вас там caty.catalysis.ru описан как CNAME. Соответственно нельзя ставить caty.catalysis.ru в качестве MX-а. Это говорят даже на дешевых курсах по сетевому администрированию. Но больше всего удивляет наличие PTR записи кторая указывает на имя описаное как CNAME. Такой фокус вместо одного запроса к ДНС заставляет делать два. Второй как раз на преобразование CNAME записи. Вы сами себе придумали грабли. А если быть точным, то это напоминает установку костыля там где не надо. Для MX-а должно совпадать прямое и обратное преобразование ДНС. Даже при наличии двух и больше интерфейсов с разными ИП адресами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 16:45
	>>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или >>>caty.catalysis.ru >>Какая разница, как был прописан MX, когда проблемы с эмитером??? >>Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя... >Я нормально спросил. Хамить необязательно. Где вы хоть каплю грубости увидели? >У вас там caty.catalysis.ru описан как CNAME. Не у меня, но не суть. (Ваши высказывания верны, но к делу не относятся) Прочитайте внимательно - у Андрея была проблема с _исходящей_ почтой. Причем тут MX?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 17:20
	>>>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или >>>>caty.catalysis.ru >>>Какая разница, как был прописан MX, когда проблемы с эмитером??? >>>Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя... >>Я нормально спросил. Хамить необязательно. >Где вы хоть каплю грубости увидели? Сорри, среагировал на "любителей резать все подряд". > >>У вас там caty.catalysis.ru описан как CNAME. >Не у меня, но не суть. (Ваши высказывания верны, но к делу >не относятся) >Прочитайте внимательно - у Андрея была проблема с _исходящей_ почтой. >Причем тут MX? Он отправлял почту со своего домена, но сам в собственном домене был прописан неправильно. Ибо тот, кому он отправлял почту, иного способа проверки валидности почтового сервера и домена, с каторого отправляется почта, кроме как через ДНС не имеет. Вот тут и проблема. Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не прошел элементарную проверку. Не совсем понятно назначие этого CNAME в качестве MX-а когда есть прекрасная запись типа ns.catalysis.ru. Этого хватило бы на что угодно. Даже на multi-homed  в качестве релея.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 18:12
	>Вот тут и проблема. >Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не >прошел элементарную проверку. Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr() и gethostbyname()
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 18:37
	>>Вот тут и проблема. >>Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не >>прошел элементарную проверку. >Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr() и gethostbyname() Только не обижайтесь. --- Удаленный хост получает соединение на 25 порт и получает команду mail from: vasya@catalysis.ru Почтовый сервер делает проверку типа dig catalisys.ru MX Получает ответ elm.catalysis.ru Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 Получаем elm.catalysis.nsk.su Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su Обрываем соединение. --- Какие с этим алгоритмом проблемы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 19:04
	>Удаленный хост получает соединение на 25 порт и получает команду >mail from: vasya@catalysis.ru >Почтовый сервер делает проверку типа dig catalisys.ru MX >Получает ответ elm.catalysis.ru >Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 >Получаем elm.catalysis.nsk.su >Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su >Обрываем соединение. >--- >Какие с этим алгоритмом проблемы? Простите, но это не алгоритм, а бред вашего воображения. (объяснять почему не буду - похоже все очень запущенно)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 19:08
	>>Удаленный хост получает соединение на 25 порт и получает команду >>mail from: vasya@catalysis.ru >>Почтовый сервер делает проверку типа dig catalisys.ru MX >>Получает ответ elm.catalysis.ru >>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 >>Получаем elm.catalysis.nsk.su >>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su >>Обрываем соединение. >>--- >>Какие с этим алгоритмом проблемы? >Простите, но это не алгоритм, а бред вашего воображения. >(объяснять почему не буду - похоже все очень запущенно) Взаимно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 19:10
	>>>Удаленный хост получает соединение на 25 порт и получает команду >>>mail from: vasya@catalysis.ru >>>Почтовый сервер делает проверку типа dig catalisys.ru MX >>>Получает ответ elm.catalysis.ru >>>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 >>>Получаем elm.catalysis.nsk.su >>>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su >>>Обрываем соединение. >>>--- >>>Какие с этим алгоритмом проблемы? >>Простите, но это не алгоритм, а бред вашего воображения. >>(объяснять почему не буду - похоже все очень запущенно) >Взаимно. Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 20:01
	>>>>Удаленный хост получает соединение на 25 порт и получает команду >>>>mail from: vasya@catalysis.ru >>>>Почтовый сервер делает проверку типа dig catalisys.ru MX >>>>Получает ответ elm.catalysis.ru >>>>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 >>>>Получаем elm.catalysis.nsk.su >>>>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su >>>>Обрываем соединение. >>>>--- >>>>Какие с этим алгоритмом проблемы? >>>Простите, но это не алгоритм, а бред вашего воображения. >>>(объяснять почему не буду - похоже все очень запущенно) >>Взаимно. >Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru? Прекрасно. Вот чего я не понимаю, так это почему почтовики класса mail.ru или назовем их freenail, не могут позволить себе приделать авторизацию для релея через себя с любых адресов. Тогда и SPF можно будет запустить в более жестком режиме.Главноя проблема состоит даже не в этом алгоритме или любом другом. А в том, что никого на сегодняшний день не заботит возможность отправки спама третьими лицами с использованием обратных адресов из домена, защищаемого от приема спама, сервера. На мой почтовый сервер ежеминутно приезжает около 10-20 писем с подделаными адресами под известные freemail-ы типа mail.ru, yahoo.com,  и.т.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 24-Апр-05, 20:41
	>>>>>Какие с этим алгоритмом проблемы? >>>>Простите, но это не алгоритм, а бред вашего воображения. >>>>(объяснять почему не буду - похоже все очень запущенно) >>>Взаимно. >>Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru? >Прекрасно. Вы ничего не понимаете, дело не в free, и не в их объемах, не в SPF и авторизации, а в том, что MX и эмиттер могут быть совершенно разными машинами и сравнивать адрес MX-а из "MAIL" c адресом клиента - малограмотный бред. Смотрите ваш алгоритм: petya@mail.ru 1) dig +short mail.ru MX: mxs.mail.ru 2) (клиент mx7.mail.ru) dig +short 194.67.23.27: mx7.mail.ru 3) mxs.mail.ru != mx7.mail.ru: REJECT, пинки от начальства, плевки коллег, вылетаете с работы, занавес.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Андрей (??) on 25-Апр-05, 07:49
	>Удаленный хост получает соединение на 25 порт и получает команду >mail from: vasya@catalysis.ru >Почтовый сервер делает проверку типа dig catalisys.ru MX >Получает ответ elm.catalysis.ru >Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71 >Получаем elm.catalysis.nsk.su >Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su >Обрываем соединение. >--- >Какие с этим алгоритмом проблемы? Вот теперь смотрите: 1 у меня есть 2 домена catalysis.ru и catalysis.nsk.su, за которыми стоит одна и таже сеть. 2 письма на xxx@catalysis.ru и xxx@catalysis.nsk.su должны попадать одному и тому же юзеру. 3 юзер сам по собственному желанию выбирает, с какого адреса он шлет почту: xxx@catalysis.ru или xxx@catalysis.nsk.su 4 я должен иметь 2 PTR записи для адреса 193.124.35.71 -- по одной для каждого домена. В противном случае один из доменов перестает работать. Это эмпирический факт. Имеем: 1 при не правильной организации проверки на принимающей стороне ~25% писем будет отбиваться. 2 если заставить постфикс на моем серваке всегда говорить только один домен, то перестает работать второй (отдельные умельцы проверяют строку из HELO и домен адресата, блин!, давил бы.) 3 единственный разумный вариант проверки по обратному резолвингу: а) видим, что мейл фром: user@domain.com б) проверяем список МХов для domain.com в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники и добавляем к списку г) проверяем, есть ли IP, с которого идет коннект, в этом списке. Если есть принимаем письмо, если нет, отбриваем. Все бы ничего, да только шаг В никто не выполняет :( Берут первый попавшийся адрес и считают что это единствено возможный вариант.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 08:58
	>3 единственный разумный вариант проверки по обратному резолвингу: > а) видим, что мейл фром: user@domain.com > б) проверяем список МХов для domain.com > в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники >и добавляем к списку > г) проверяем, есть ли IP, с которого идет коннект, в этом >списке. Если есть принимаем письмо, если нет, отбриваем. У вас та же проблема, что и у предыдущего господина. Почему вы так упорно хотите что бы MX и эмиттер были одной машиной? Ваш алгоритм точно так же обламывает все крупные релеи - в сад.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Андрей (??) on 25-Апр-05, 09:20
	>>3 единственный разумный вариант проверки по обратному резолвингу: >> а) видим, что мейл фром: user@domain.com >> б) проверяем список МХов для domain.com >> в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники >>и добавляем к списку >> г) проверяем, есть ли IP, с которого идет коннект, в этом >>списке. Если есть принимаем письмо, если нет, отбриваем. >У вас та же проблема, что и у предыдущего господина. Почему вы >так упорно хотите что бы MX и эмиттер были одной машиной? >Ваш алгоритм точно так же обламывает все крупные релеи - в >сад. Я этого не хочу. Просто конкретно в моей ситуации, этого хватило бы :) Но даже в моей ситуации, масса почтовиков отбивает...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 09:34
	>>У вас та же проблема, что и у предыдущего господина. Почему вы >>так упорно хотите что бы MX и эмиттер были одной машиной? >>Ваш алгоритм точно так же обламывает все крупные релеи - в >>сад. >Я этого не хочу. Просто конкретно в моей ситуации, этого хватило бы >:) Если не хотите, и понимаете, то зачем пишете, да еще называете "единственно правильным"... Все что можно проверить в плане DNS из "MAIL FROM" - это сам факт существования MX или A для этого домена. Все. >Но даже в моей ситуации, масса почтовиков отбивает... Я вам уже говорил - использовать multi-homed хост в качестве эмиттера опасно  т.к. фактически существующие почтовые RFC этого не предусматривают.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Осторожный on 04-Июл-05, 11:26
	>Вот теперь смотрите: > >1 у меня есть 2 домена catalysis.ru и catalysis.nsk.su, за которыми стоит >одна и таже сеть. > >2 письма на xxx@catalysis.ru и xxx@catalysis.nsk.su должны попадать одному и тому же >юзеру. > >3 юзер сам по собственному желанию выбирает, с какого адреса он шлет >почту: xxx@catalysis.ru или xxx@catalysis.nsk.su nsk.su - устаревшая зона Поэтому выход такой: Оставляешь адреса только xxx@catalysis.ru Почта на xxx@catalysis.nsk.su пересылается на xxx@catalysis.ru У пользователя НЕТ ВЫБОРА - его адрес xxx@catalysis.ru Предупреждаешь всех пользователей, чтобы они сообщили всем своим абонентам что адреса xxx@catalysis.nsk.su устарели и больше не стоит их использовать. Всячески это дело рекламируется. Через год вставляешь автоматический redirect. Это когда почта автоматически не пересылается, а абонент получает сообщение, что слать почту нужно на xxx@catalysis.ru Делал переезд с одного домена в другой В СПЕШНОМ ПОРЯДКЕ Можно сказать в соседнем институте кстати :) И ничего - все живы
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Андрей (??) on 25-Апр-05, 06:19
	Дмитрий, >Я нормально спросил. Хамить необязательно. во-первых, хамящий анонимус к моему Институту отношения не имееет, и со мной ничего общего не имеет так же :) >У вас там caty.catalysis.ru описан как CNAME. >Соответственно нельзя ставить caty.catalysis.ru в качестве MX-а. >Это говорят даже на дешевых курсах по сетевому администрированию. В те далекие времена caty было именем хоста, а ns был CNAME'ом. >Но больше всего удивляет наличие PTR записи кторая указывает на имя описаное >как CNAME. Такой фокус вместо одного запроса к ДНС заставляет делать >два. >Второй как раз на преобразование CNAME записи. >Вы сами себе придумали грабли. А если быть точным, то это напоминает >установку костыля там где не надо. >Для MX-а должно совпадать прямое и обратное преобразование ДНС. >Даже при наличии двух и больше интерфейсов с разными ИП адресами. Поверьте на слово, плс, изначально так и было сделано. Гарантировано работает только один вариант, понятно даже какой :) Любой другой вариант, приводит к тому, что какой-нибудь удаленный хост перестает принимать почту, прибегает юзверь и начинает жалабно голосить. Полный перебор всех возможных комбинаций в настройках ДНСа, показывает, что для _любой_ конфигурации, найдется хотя бы один хост, который будет гнусно отказываться принимать почту.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Аноним on 22-Апр-05, 10:45

вот если бы статью опубликовали типа "Блокирование спама на этапе создания письма"  как бы было замечательно :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Спам"

Сообщение от dubanoze (??) on 22-Апр-05, 10:50

greylist рулит :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "RE: greylist рулит :) - вот именно! Самое верное решение 550..."
	Сообщение от Банзай (??) on 23-Апр-05, 21:41
	Надо - дошлешь через часок.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Dmitry U. Karpov on 22-Апр-05, 10:51

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "один раз в день звонил бы по одному из спам-писем "
	Сообщение от Банзай (??) on 23-Апр-05, 21:46
	то он умер бы с голоду - не хватило бы веремени на еду.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Nikola (??) on 22-Апр-05, 10:57

Ув. Dmitry U. Karpov, если каждому звонить ты попадёшь на ещё одни бабки, плюс испортишь себе нервы. Нафига это надо? А статья хорошая.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Dmitry U. Karoiv on 25-Апр-05, 22:37
	Я делаю один звонок в день (ну, три, если хочется поругаться). Звонок местный (подавляющее большинство русскоязычного спама рекламирует московские фирмы). Неужели остальным спамополучателям трудно повторить мой подвиг?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Alex_SPb on 26-Апр-05, 17:58
	>Звонок местный Отучаемся говорить за всю сеть. >(подавляющее большинство русскоязычного спама рекламирует московские фирмы). Вот именно. Буду я каждому дерьму из Питера в Москву звонить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Блокирование спама на этапе соединения в sendmail"

Сообщение от DAV on 22-Апр-05, 11:58

To Zerg >ИМХО: политика отлупа на стадии соединения, >наиболее верная ... --- Так и до геноцида недалеко:) Типа, расстреливать всех с карими глазами, и не нужно тратится на дальнейшую проверку личности...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Блокирование спама на этапе соединения в sendmail"

Сообщение от orm (??) on 22-Апр-05, 12:39

Отбрасывать на основе отсутствия обрятной зоны - неправильно. Мы обратную зону и провайдера выбиваем уже месяц, и дело двигается со скрипом. А провайдера поменять не можем. Никак. А по поводу отсылать к создателям списков - вы когда нить пробовали из http.dnsbl свой адрес вытащить? У меня не получилось, хотя никаких проксей с момента моего прихода на работу не осталось. Проблема решилась только пивом админу, чтоб он отдал нам незабаненный ip из пула провайдера. В общем хуже спама может быть только антиспам - я (как пользователь) предпочитаю получить 50 писем спама и 1 нужное письмо, чем не получить ничего. А все проблемы у пользователей от того, что локальный bayes в клиенте настроить не могут. А проблемы админов (перегрузка серваков, большой трафик) пользователей касаться не должны :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 22-Апр-05, 13:14
	>bayes в клиенте настроить не могут. А проблемы админов (перегрузка серваков, >большой трафик) пользователей касаться не должны :) Вы знаете, если отключить вирус/спам фильтры, то нагрузка на сервера упадет в разы, а за трафик заплатите вы как пользователь...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Все, что вы сказали - чушь собачачья!"
	Сообщение от Банзай (??) on 23-Апр-05, 21:54
	> провайдера выбиваем уже месяц, ???????????? Это супер! Святопевздевевский Узел Электрической Связи? Модемы на педальной тяге? И кизяке в дежурном режиме в темное время суток? > вы когда нить пробовали > из http.dnsbl свой адрес вытащить? 30 минут на любой случай. > 50 писем спама и 1 нужное письмо, > чем не получить ничего. Деловые письма теряются значительно реже. Напрмер - никогда. > А проблемы админов (перегрузка серваков, > большой трафик) пользователей касаться не должны :) У админов нет проблем. Проблемы с потерей рабочего времени у юзеров. Пользователи ТРЕБУЮТ быть избавленными от гавна, которое ты, скот, валишь им в ящики. > хуже спама может быть только антиспам Похоже ты тот самый спамер и есть? Убил бы!!!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "OpenNews: Блокирование спама на этапе соединения в sendmail"

Сообщение от demon (??) on 22-Апр-05, 13:03

Блокирование на этапе соединения - правильная вещь, но пользоваться ею надо с умом. Наличие обратной зоны (без разницы что там записано) - практически обязательное условие для почтового сервера. А если какой-то провайдер не может этого обеспечить - это проблема провайдера и его клиента. И ее надо решать, а не ссылаться на трудности. Совпадение А и PTR - это было бы замечательно хорошо, но уж слишком много проблем с этим. Лучше проверять HELO и существование домена указанного в HELO в принципе (неважно куда этот домен глядит). Процент ошибочных срабатываний из-за неправильной настройки оправляющего сервера небольшой, и проблема обычно решается достаточно быстро, т.к. зависит только от админа сервера. Кроме того можно отбрасывать соединения с PTR-ами явно сделаными для DIALUP-ов, ADSL-ей и проч. Хотя и тут случаются ошибки, но их можно занести в исключения. DNSBL - это гадость. Неоднократно сталкивался с неадекватным поведением. Думаю, что отсеивание 80% спама на этапе содинения - это хороший показатель. Далее должен работать спамассассин.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от orm (??) on 22-Апр-05, 14:13
	>Блокирование на этапе соединения - правильная вещь, но пользоваться ею надо с >умом. Абсолютно согласен. Не понимаю админов, которые пихают все подряд списки без разбора. Например админы mtu-net.ru :) >Наличие обратной зоны (без разницы что там записано) - практически обязательное условие >для почтового сервера. А если какой-то провайдер не может этого обеспечить >- это проблема провайдера и его клиента. И ее надо решать, >а не ссылаться на трудности. Как её решить, если интеренет дает арендатор помешения, и других провайдеров в здании нет и не будет никогда? Сменить офис? (варианты радио этзернета и АДСЛ не катят) Или поместить сервер на площадку и настраивать SMTP relay? К тому же с обратными зонами всегда гимор - как правило их держат первичные провайдеры провайдеров (во загнул!), а нашему провайдеру (да и любом провайдеру средней руки) ради клиента списываться с саппортом первичного прова накладно (время его работников - эт тоже деньги). Хотя своего мы уговорили, он отписался, теперь ждем что ответят. Судя по всему ждать долго придется, такие запросы обычно в посл. очередь обрабатывают. Наверно придется звонить :) >Совпадение А и PTR - это было бы замечательно хорошо, но уж >слишком много проблем с этим. Лучше проверять HELO и существование домена >указанного в HELO в принципе (неважно куда этот домен глядит). Процент >ошибочных срабатываний из-за неправильной настройки оправляющего сервера небольшой, и проблема обычно >решается достаточно быстро, т.к. зависит только от админа сервера. Согласен. >Кроме того можно отбрасывать соединения с PTR-ами явно сделаными для DIALUP-ов, ADSL-ей >и проч. Хотя и тут случаются ошибки, но их можно занести >в исключения. Тоже вариант. Только следить тщательно надо. >DNSBL - это гадость. Неоднократно сталкивался с неадекватным поведением. Можно использовать, только очень осторожно, следить за логами, разрешать нужные сервера... И ни в коем случае не посылать к создателям списка, ибо это как правило бесполезно (если обращаются к нам, значит с создателями списка скорее всего уже ничего не вышло) >Думаю, что отсеивание 80% спама на этапе содинения - это хороший показатель. Я согласен и на 70%, лишь бы нужная почта ходила :) >Далее должен работать спамассассин. Я склоняюсь к тому, чтоб дальнейшая фильтрация была на стороне и под контролем клиента.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Zerg (??) on 22-Апр-05, 13:11

>В общем хуже спама может быть только антиспам - я >(как пользователь) предпочитаю получить 50 писем >спама и 1 нужное письмо, чем не получить ничего. А >все проблемы у пользователей от того, что локальный >bayes в клиенте настроить не могут. А проблемы >админов (перегрузка серваков, большой трафик) >пользователей касаться не должны :) Конечно не должны ... если пользователь платит за траффик. Но обычно почему то оной пользователь начинает возмущаться! >Так и до геноцида недалеко:) > Типа, расстреливать всех с карими глазами, > и не нужно тратится на дальнейшую проверку >личности... ну тут не карие глаза, а шрам во всю морду, да еще оная морда и небритая :) а если серьезно, то я пробовал, обходиться без "черных списоков"  ... пипец полный!!!! ... абсолютный ... Когда адреса можно взять с сайта, и при этом сами пользователи ведут себя не осторожно ... Топ 10 у меня - не менее 500 на человека в день. Траффик+нервы+ресурсы(из проверки на спам и вирус) улетают в трубу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zerg (??) on 22-Апр-05, 13:12
	ИМХО ОСНОВНAЯ ПРОБЛЕМА: это то, что держатели некоторых черных список уроды ... И выписаться от туда не практически не возможно :(. Даже если ты все исправил, то все равно тебя оттуда не выпишут. Такое часто бывает в отношениях заруб. черный список <-> русский "штрафник". Причем даже зачастую причину отказываются назвать. ЗЫ: все идет по грифом "ИМХО"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Kazan on 22-Апр-05, 13:33

Zerg, ты не прав. Нельзя по несовпадению ДНС-информации отшибать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от illi on 22-Апр-05, 14:40
	Похоже, автор держит маленький почтовый сервер для себя одного в своей полностью администрируемой подсети, проблемы пользователей его не волнуют, и переписывается только со своими 10(100) знакомыми. Т.е. поддержка сервером нескольких почтовых доменов или получение почты с серверов мелких контор, не могущих прописать обратную зону - исключаются.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zerg (??) on 22-Апр-05, 17:29
	>Похоже, автор держит маленький почтовый сервер для себя одного в своей полностью >администрируемой подсети, проблемы пользователей его не волнуют, и переписывается только со >своими 10(100) знакомыми. >Т.е. поддержка сервером нескольких почтовых доменов или получение почты с серверов мелких >контор, не могущих прописать обратную зону - исключаются. грубовато сказано! если не сказать по хамски ... по крайней мере мне так показалось ... извините если ошибся. Если контора не может прописать себе обратную зону ... то пошли они в зад! Простите за грубость, но это правильно ... Давайте принимать без реверса, далее не пользоваться черными списками, далее не сканировать на вирусы (а вдруг важное письмо), и прочее ... Прописание реверса - это всего лишь правильно оформленное письмо к провайдеру, и все. Мля! слов нету !!! Что такое 40 000 писем в день ?! из них 99% спам ? так фигня ... зато серди них обязательно одно и супер важное ! Ну ладно я понимаю : кривые "черные списки" ... ну элементарные вещи, то можно делать ? реверс например!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zerg (??) on 22-Апр-05, 17:39
	ИМХО: обязательно надо использовать "черные списки" , проверка реверса, milter-sender, spamassassin Как мне кажется - это оптимальная комбинация. Народ, поверьте плиз, личный пример, насчет рекламного агенства: spamassin далеко не всегда помогает, а поток дерьма без использования первых 3 ступенек просто колоссален!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Ghost (??) on 22-Апр-05, 18:01
	Если вы претендуете на должность администратора в приличной конторе, а не эникейщика по-быстрому клепающего сервера то извольте соблюдать правила. RFC не просто так пишут. Не правы и те кто отшивает по hello и те чьи кривые сервера правильно это hello сказать не могут. Почитав логи почтовика сразу видно в какой конторе какой ламер работает. И не надо тут орать что реверс у прова не выбить и это все они, а я хороший. В RFC четко сказано "The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client." поэтому если ваш сервак имеет статический IP, то извольте настроить его ТАК что бы он отвечал hello соответственно реверсу этого IP, либо отвечал самим ip адресом если адрес динамический, а иначе это не smtp сервер - а так... порождение вашей криворукости. Если нет возможности выбить "обратку" держите сервера у тех кто это может обеспечить. Сейчас практически любой платный хостинг в довесок к сайту дает бесплатно почту, чаще всего нормально настроенную. Тогда можно будет со спокойной совестью заявить что я сделал все что возможно чтобы отправлять легитимную почту и спокойно обсирать тех кто режет по helo за то что уже они нарушают RFC какими бы мотивами это не было вызвано. Но это уже означает что им эта почта просто не нужна.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Demar (??) on 22-Апр-05, 20:02
	Дело, видимо, не в чьей-то криворукости, узколобости, any'кейности и т.п. Вопрос в том - какие задачи ставятся перед тем или иным администратором(и кем ставятся). Если кого-то ни разу на денежку не сажали за входящий офигенный почтовый трафик, значит ему просто повезло. В этом деле никакой spamassassin не спасет (конечно, если на почтовом сервере не 100 полумертвых ящиков). С другой стороны, администраторы почтовых серверов больших сетей, где клиент платит денежку и хочет(вынужден) сам разбираться с почтой, могут смело попивать пиво и говорить о RFC, о массовых расстрелах или просто помогать детям закрыть popup-окна. Как правило, именно такие сети попадают в черные списки первыми и, честно говоря, я мало представляю себе как с этим бороться(взять тот же СТРИМ - уже тама). Отшивание по hello у нас вынужденная мера. Но за год с момента введения правил фильтрации  случаи отшивания "правильной" почты были единичны. А у нас работают журналисты, редакторы и т.п. которым нужна постоянная связь с регионами, с буржуями. Будь иначе - меня давно уволили ли. С черными листами чуть сложнее - взять тот же СТРИМ. Он никогда не вылезет из черных списков. Тут приходится использовать собственные списки позволяющие пустить клиента до проверки в черных листах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Аноним on 22-Апр-05, 23:01

># greylist рулит :) >удостоверится в существовании E-Mail адреса отправителя Применение этих методов - плохое решение. Они действительно иногда эффективны, но лишь потому, что используются относительно редко, и спамерам просто не охота связываться с этими "исключениями". Понятно, что обход серых списков осуществить очень просто. Что же касается проверки реальности адреса отправителя, то представтьте, что было бы если бы все её у себя ввели: господа чесные спамеры использовали бы реальные адреса. Так что, те кто используют эти методы, на мой взгляд, не честно играют. Про статью, что сказать... Похвально стремление автора изучать sendmail. А что будут жертвы, так на ошибках учатся. А вот не новая статейка, вдруг кто не читал: http://www.armory.com/~spcecdt/spamware/ Почему бы, например, не использовать критерии из обсуждаемой статьи не для того, чтобы почту отвергнуть сразу, а заставить подождать побольше? Исключительно безвредно и где-то даже эффективно, сам проверял-с

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 23-Апр-05, 10:38
	>Исключительно безвредно и где-то даже эффективно, сам проверял-с pre greeting delay эффективен только при маленьких объемах почты, для больших сайтов это DOS устроенная самому себе - во время пиков спамерской активности мы мгновенно упремся в лимит одновременных сессий.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Аноним on 23-Апр-05, 15:27
	>pre greeting delay эффективен только при маленьких объемах почты >для больших сайтов это DOS устроенная самому себе Не любой ли расход ресурсов, с которым не справляется оборудование - DOS cамому себе? Пусть "Большим сайтам" будет всегда достаточно своих ресурсов, и пусть не бурут, если им не хватает, из ресурсов тех, кого они обслуживают.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 23-Апр-05, 16:04
	>>pre greeting delay эффективен только при маленьких объемах почты >>для больших сайтов это DOS устроенная самому себе >Не любой ли расход ресурсов, с которым не справляется оборудование - DOS >cамому себе? Пусть "Большим сайтам" будет всегда достаточно своих ресурсов, и >пусть не бурут, если им не хватает, из ресурсов тех, кого >они обслуживают. Одно дело когда вас DOS'ят или действительно не хватает мощей железа, а другое когда вы роете яму для себя самостоятельно... Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zack on 23-Апр-05, 19:34
	> Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено? Exim, CommuniGatePro
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zack on 23-Апр-05, 19:37
	Хех, было бы только памяти достаточно. :) Гигабайт скажем. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 23-Апр-05, 19:42
	>Хех, было бы только памяти достаточно. :) Гигабайт скажем. :) Опять врете, память для MTA не критична
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 23-Апр-05, 19:41
	>> Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено? > >Exim, CommuniGatePro Врете
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от _DVS_ on 25-Апр-05, 14:32
	>>Исключительно безвредно и где-то даже эффективно, сам проверял-с >pre greeting delay эффективен только при маленьких объемах почты, для больших сайтов >это DOS устроенная самому себе - во время пиков спамерской активности >мы мгновенно упремся в лимит одновременных сессий. Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от unk (ok) on 25-Апр-05, 14:38
	>Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий? Поясняю - Никак. Протираем глаза и читаем "pre-greeting" с "greylisting" это не имеет ничего общего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от _DVS_ on 25-Апр-05, 15:02
	>>Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий? >Поясняю - Никак. >Протираем глаза и читаем "pre-greeting" с "greylisting" это не имеет ничего общего. > Сори. Осмотрелся.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "OpenNews: Блокирование спама на этапе соединения в sendmail"

Сообщение от Zulu on 24-Апр-05, 15:46

1) То что автор пионер, видно по приводимым конфигам. 2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не пробъется и стало быть никто о проблемах не скажет. В приличном месте таке не катит. Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP, на каждом их которых 10 имен. Но автор об этом не слышал. Отбой по проверке существования отправителя не катит, ибо например Яху тебя за такой номер в момент заблокирует, и все -- вешайся. Но автор об этом тоже не знает... В общем обсуждать нечего -- очередное творение уровня админа конторы из 10 человек. -- ZULU-UANIC, Почтовый поток  ~200 000 принятых писем в сутки, ~80 000 почтовых пользователей, ~10 отбитых писем в секунду в штатном режиме.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nazarov Dmitriy on 24-Апр-05, 16:01
	>1) То что автор пионер, видно по приводимым конфигам. >2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не >пробъется и стало быть никто о проблемах не скажет. В приличном >месте таке не катит. Ну может не отбой, а Service Unevailable. >Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP, >на каждом их которых 10 имен. Но автор об этом не >слышал. Позвольте поинтересоваться, а зачем на одном ИП 10 имен? >Отбой по проверке существования отправителя не катит, ибо например Яху тебя за >такой номер в момент заблокирует, и все -- вешайся. Но автор >об этом тоже не знает... А может как раз Яху и не прав. > >В общем обсуждать нечего -- очередное творение уровня админа конторы из 10 >человек. > >-- >ZULU-UANIC, >Почтовый поток  ~200 000 принятых писем в сутки, ~80 000 почтовых >пользователей, ~10 отбитых писем в секунду в штатном режиме.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от Nikola (??) on 25-Апр-05, 10:26
	>1) То что автор пионер, видно по приводимым конфигам. >2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не >пробъется и стало быть никто о проблемах не скажет. В приличном >месте таке не катит. >Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP, >на каждом их которых 10 имен. Но автор об этом не >слышал. >Отбой по проверке существования отправителя не катит, ибо например Яху тебя за >такой номер в момент заблокирует, и все -- вешайся. Но автор >об этом тоже не знает... > >В общем обсуждать нечего -- очередное творение уровня админа конторы из 10 >человек. > >-- >ZULU-UANIC, >Почтовый поток  ~200 000 принятых писем в сутки, ~80 000 почтовых >пользователей, ~10 отбитых писем в секунду в штатном режиме. Ну уж тогда поделись с нами о великий и ужасный ZULU секретами своего необъятного мастерства.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от Zulu on 25-Апр-05, 23:36
	>>1) То что автор пионер, видно по приводимым конфигам. >>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не >>пробъется и стало быть никто о проблемах не скажет. В приличном >>месте таке не катит. >>Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP, >>на каждом их которых 10 имен. Но автор об этом не >>слышал. >>Отбой по проверке существования отправителя не катит, ибо например Яху тебя за >>такой номер в момент заблокирует, и все -- вешайся. Но автор >>об этом тоже не знает... >> >>В общем обсуждать нечего -- очередное творение уровня админа конторы из 10 >>человек. >> >>-- >>ZULU-UANIC, >>Почтовый поток  ~200 000 принятых писем в сутки, ~80 000 почтовых >>пользователей, ~10 отбитых писем в секунду в штатном режиме. > > >Ну уж тогда поделись с нами о великий и ужасный ZULU секретами >своего необъятного мастерства. Парень... Возможно это ты автор и я тебя обидел выше -- тогда прости. Но подумай о том, что я написал выше. Не катят советы из статьи для применения в широких масштабах. Пользователи съедят.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от _DVS_ on 26-Апр-05, 13:37
	>>>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не >>>пробъется и стало быть никто о проблемах не скажет. В приличном >>>месте таке не катит. Следуя этой логике надо признать, что структура sendmail.cf разработана пионерами. Ведь если хост забанен в access.db, то на postmaster ему никакими судьбами не пробиться. И с DNSBL тоже самое, проверка происходит в Basic_check_relay на этапе соединения, т.е. еще до того как известен получатель.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от adsh (??) on 26-Апр-05, 18:39
	>Следуя этой логике надо признать, что структура sendmail.cf разработана пионерами. Ведь если >хост забанен в access.db, то на postmaster ему никакими судьбами не >пробиться. И с DNSBL тоже самое, проверка происходит в Basic_check_relay на >этапе соединения, т.е. еще до того как известен получатель. Man sendmail.mc /FEATURE(`delay_checks').
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "Блокирование спама на этапе соединения в sendmail"

Сообщение от adsh (??) on 24-Апр-05, 22:07

Существуют капитальные и систематизированные разработки в этой области от Виктора Устугова. Все, кто с пеной у рта кричат против вряд ли видели их в глаза. Очень небольшая их часть была включена в один из дистрибутивов линукс. Степень проверки каждого параметра и различные исключения там прописываются в настройках. Поскольку автор не склонен светить их в инете - ссылку не привожу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от demon (??) on 25-Апр-05, 01:26
	Так и нахрена он такой умный нужен, если не хочет показывать свое творение? Жаба душит? И нахрена вы тут рекламируете то, что показыать не стремитесь? Я бы с удовольствием почитал умного человека, который может дать действительно полезный совет по больбе со спамом, а не пионЭров коих нынче на опеннете развелось как собак нерезаных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от adsh (??) on 25-Апр-05, 02:43
	>Так и нахрена он такой умный нужен, если не хочет показывать свое >творение? Жаба душит? И нахрена вы тут рекламируете то, что показыать >не стремитесь? Вот то, что сделано публично: http://rpm.pbone.net/index.php3/stat/4/idpl/1799678/com/send... См. /usr/share/sendmail-cf/README.corvax.rus >Я бы с удовольствием почитал умного человека, который может дать действительно полезный >совет по больбе со спамом, а не пионЭров коих нынче на >опеннете развелось как собак нерезаных. Все когда то были "пионЭрами". Вы - в том числе...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

53. "OpenNews: Блокирование спама на этапе соединения в sendmail"

Сообщение от adsh (??) on 25-Апр-05, 02:57

Есть ещё хак, где можно выставлять проверку реверс DNS поюзерно (хочу принимать спам / не хочу принимать спам :-) ): http://www.cs.niu.edu/~rickert/cf/hack/require_rdns.m4 Ну - и ещё кое что: http://www.cs.niu.edu/~rickert/cf/

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от Максим (??) on 25-Апр-05, 14:22
	Я думаю, что наш форум читают не только праведные админы, но и програмеры спама, которым очень интересна наша дискуссия. А что касается фильтрации по HELO, то у меня примерно 90 проц. фильтруется по HELO моим-же доменом, моим IP, cablemodem и тд. http://www.opennet.ru/tips/info/813.shtml
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

87. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Zaltic (ok) on 11-Дек-06, 15:51

попробовал такую схему возник вопрос возможно ли вначале анализировать access а потом уже проверять соответствие PTR А? а то получается что access потом только просматривается

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

88. "OpenNews: Блокирование спама на этапе соединения в sendmail"

Сообщение от Russian on 17-Янв-08, 18:26

>Dmitry Zubov описал (http://dz.dn.ua/spam/antispam.html) достаточно жесткую схему фильтрации спама на почтовом сервере >работающем под управлением sendmail (FreeBSD). > > >Схема предусматривает блокировку хостов без обратной зоны или  несовпадении "PTR" и >"A" записей, подключение проверки в DNSBL системах, обратную проверку существования адреса >через milter-sender. Я у себя попробовал то что написано в статье буквально вчера, мне очень понравилось. Весь спам отрезало как и не было (раньше не менее 1000 писем в день), нормальные письма вроде доходят. Но похоже  что-то  и резануло сгоряча из того, что должно проходить (типа 3453.houston.hp.com) . В связи с этим вопрос, как реализовать то что пишет автор: " в самом начале SLocal_check_relay вставить для них обход всех проверок."..?? Простите, если вопрос покажется для кого-то глупым, но документация у Sendmail очень тяжелая...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "OpenNews: Блокирование спама на этапе соединения в sendmail"
	Сообщение от Jnis on 31-Мрт-08, 02:49
	>[оверквотинг удален] > >Я у себя попробовал то что написано в статье буквально вчера, мне >очень понравилось. Весь спам отрезало как и не было (раньше не >менее 1000 писем в день), нормальные письма вроде доходят. Но похоже > что-то  и резануло сгоряча из того, что должно проходить >(типа 3453.houston.hp.com) . В связи с этим вопрос, как реализовать то >что пишет автор: >" в самом начале SLocal_check_relay вставить для них обход всех проверок."..?? >Простите, если вопрос покажется для кого-то глупым, но документация у Sendmail очень >тяжелая... SLocal_check_relay R$*                     $: < $&{client_addr} > R<IP клиента>        $@OK
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

89. "Блокирование спама на этапе соединения в sendmail"

Сообщение от Jnis on 31-Мрт-08, 02:44

SLocal_check_relay R$*        $: < $&{client_addr} > R<IP клиента>    $@OK

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Russian on 10-Апр-08, 17:59
	>SLocal_check_relay >R$*        $: < $&{client_addr} > >R<IP клиента>    $@OK Адрес клиента вписывать вместо "<IP клиента>" и все ? А "{client_addr}" так и оставялем?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "Блокирование спама на этапе соединения в sendmail"
	Сообщение от Janis on 02-Авг-08, 00:55
	Именно так.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]