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

OpenNews: Блокирование спама на этапе соединения в sendmail, opennews (??), 22-Апр-05, (0) [смотреть все] Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации На одном и, Андрей (??), 10:21 , 22-Апр-05, (1) Уважаемый Вы как давно делали такую фильтрацию В курсе ли Вы что Yandex, etc не, Аноним (2), 10:28 , 22-Апр-05, (2) Стрелял, а затем добивал бы прикладом тех,кто у себя это настроить не может Нен, Zerg (??), 10:41 , 22-Апр-05, (3)   // dig ns catalysis ru dig caty catalysis ru dig -x 193 124 35 68Что здесь неправил, Андрей (??), 12:01 , 22-Апр-05, (9)   // Неправильно, то что в RFC 2 821 нет _четкого_ описания что является main hostna, unk (ok), 13:11 , 22-Апр-05, (13)   // Полностью согласен Однако вопрос в том как резать Можно проверять валидность пр, Merry Monk (?), 09:47 , 25-Апр-05, (59)   Тут есть одно большое, но - это замечательно работает на не больших релеях, а тя, unk (ok), 10:00 , 25-Апр-05, (60)   Максимальное число открытых соединений - настраиваемый параметр По большому сче, Merry Monk (?), 10:41 , 25-Апр-05, (62)   У меня и так четыре frontend a на MX вы предлагаете мне поставить еще 4 Дело в с, unk (ok), 10:51 , 25-Апр-05, (63)   Основное преимущество метода - возможность отсеять большое количество спама с га, Merry Monk (?), 11:21 , 25-Апр-05, (64)   так у вас возможны точно те же проблемы, что и у меня, только вероятность их воз, unk (ok), 11:31 , 25-Апр-05, (65)   Пока что легче для спамеров оказывается не обходить задержки, а терять небольшой, Merry Monk (?), 11:41 , 25-Апр-05, (66)   Боюсь нам с вами от этого легче не будет - число зомбированных сетей растет как , unk (ok), 12:02 , 25-Апр-05, (67)   Предлагаю на этом закончить дискуссию, налить по кружечке пива и выпить за кончи, Merry Monk (?), 12:05 , 25-Апр-05, (68)   За это и водки можно , unk (ok), 12:09 , 25-Апр-05, (69)   Тогда придется закуску искать, а мне сегодня обед не привезли Пойду найду в спа, Merry Monk (?), 12:12 , 25-Апр-05, (70)   И вам не попадались отсылающие скрипты с небольшим таймаутом или MTA админ котор, uldus (ok), 13:37 , 25-Апр-05, (73)   Если админ по незнанию, а тем более по злому умыслу балуется таймаутами, согласи, Merry Monk (?), 14:08 , 25-Апр-05, (76)   to unk А какими вы методами пользуетесь против спама , Agp (??), 13:05 , 25-Апр-05, (71)   reject клиента и MX NS домена из MAIL по мягким RBL, greylisting встречная п, unk (ok), 13:25 , 25-Апр-05, (72)   антиспам после DATA - какой , Agp (??), 13:55 , 25-Апр-05, (74)   spamassassin без Байеса человек пишущий под него правила, unk (ok), 14:03 , 25-Апр-05, (75)   А когда машина была MX-ом, в IN MX что стояло ns catalysis ru или caty catalysi, Nazarov Dmitriy (?), 03:09 , 24-Апр-05, (36)   // Какая разница, как был прописан MX, когда проблемы с эмитером Из-за любителей , unk (ok), 10:10 , 24-Апр-05, (37)   Я нормально спросил Хамить необязательно У вас там caty catalysis ru описан как, Nazarov Dmitriy (?), 15:31 , 24-Апр-05, (38)   Где вы хоть каплю грубости увидели Не у меня, но не суть Ваши высказывания вер, unk (ok), 16:45 , 24-Апр-05, (41)   Сорри, среагировал на любителей резать все подряд Он отправлял почту со своего, Nazarov Dmitriy (?), 17:20 , 24-Апр-05, (42)   Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr и getho, unk (ok), 18:12 , 24-Апр-05, (43)   Только не обижайтесь ---Удаленный хост получает соединение на 25 порт и получает, Nazarov Dmitriy (?), 18:37 , 24-Апр-05, (44)   Простите, но это не алгоритм, а бред вашего воображения объяснять почему не буд, unk (ok), 19:04 , 24-Апр-05, (45)   Взаимно , Nazarov Dmitriy (?), 19:08 , 24-Апр-05, (46)   Вы понимаете, что этот алгаритм режет все почтовики класса mail ru , unk (ok), 19:10 , 24-Апр-05, (47)   Прекрасно Вот чего я не понимаю, так это почему почтовики класса mail ru или наз, Nazarov Dmitriy (?), 20:01 , 24-Апр-05, (48)   Вы ничего не понимаете, дело не в free, и не в их объемах, не в SPF и авторизаци, unk (ok), 20:41 , 24-Апр-05, (49)   Вот теперь смотрите 1 у меня есть 2 домена catalysis ru и catalysis nsk su, за к, Андрей (??), 07:49 , 25-Апр-05, (55)   У вас та же проблема, что и у предыдущего господина Почему вы так упорно хотите, unk (ok), 08:58 , 25-Апр-05, (56)   Я этого не хочу Просто конкретно в моей ситуации, этого хватило бы Но даже в, Андрей (??), 09:20 , 25-Апр-05, (57)   Если не хотите, и понимаете, то зачем пишете, да еще называете единственно прав, unk (ok), 09:34 , 25-Апр-05, (58)   nsk su - устаревшая зонаПоэтому выход такой Оставляешь адреса только xxx catalys, Осторожный (?), 11:26 , 04-Июл-05, (86)   Дмитрий, во-первых, хамящий анонимус к моему Институту отношения не имееет, и со, Андрей (??), 06:19 , 25-Апр-05, (54)   вот если бы статью опубликовали типа Блокирование спама на этапе создания письм, Аноним (2), 10:45 , 22-Апр-05, (4) greylist рулит , dubanoze (??), 10:50 , 22-Апр-05, (5) // Надо - дошлешь через часок , Банзай (??), 21:41 , 23-Апр-05, (31) Если бы один процент получателей спама один раз в день звонил бы по одному из сп, Dmitry U. Karpov (?), 10:51 , 22-Апр-05, (6) // то он умер бы с голоду - не хватило бы веремени на еду , Банзай (??), 21:46 , 23-Апр-05, (32) Ув Dmitry U Karpov, если каждому звонить ты попадёшь на ещё одни бабки, плюс и, Nikola (??), 10:57 , 22-Апр-05, (7) // Я делаю один звонок в день ну, три, если хочется поругаться Звонок местный п, Dmitry U. Karoiv (?), 22:37 , 25-Апр-05, (81) // Отучаемся говорить за всю сеть Вот именно Буду я каждому дерьму из Питера в Мос, Alex_SPb (?), 17:58 , 26-Апр-05, (84) To Zerg---Так и до геноцида недалеко Типа, расстреливать всех с карими глазами,, DAV (?), 11:58 , 22-Апр-05, (8) Отбрасывать на основе отсутствия обрятной зоны - неправильно Мы обратную зону и, orm (??), 12:39 , 22-Апр-05, (10) // Вы знаете, если отключить вирус спам фильтры, то нагрузка на сервера упадет в ра, unk (ok), 13:14 , 22-Апр-05, (15) Это супер Святопевздевевский Узел Электрической Связи Модемы на пе, Банзай (??), 21:54 , 23-Апр-05, (33) Блокирование на этапе соединения - правильная вещь, но пользоваться ею надо с ум, demon (??), 13:03 , 22-Апр-05, (11) // Абсолютно согласен Не понимаю админов, которые пихают все подряд списки без разб, orm (??), 14:13 , 22-Апр-05, (17) Конечно не должны если пользователь платит за траффик Но обычно почему то о, Zerg (??), 13:11 , 22-Апр-05, (12) // ИМХО ОСНОВНAЯ ПРОБЛЕМА это то, что держатели некоторых черных список уроды , Zerg (??), 13:12 , 22-Апр-05, (14) Zerg, ты не прав Нельзя по несовпадению ДНС-информации отшибать , Kazan (?), 13:33 , 22-Апр-05, (16) // Похоже, автор держит маленький почтовый сервер для себя одного в своей полностью, illi (?), 14:40 , 22-Апр-05, (18) // грубовато сказано если не сказать по хамски по крайней мере мне так показал, Zerg (??), 17:29 , 22-Апр-05, (19) // ИМХО обязательно надо использовать черные списки , проверка реверса, milter-se, Zerg (??), 17:39 , 22-Апр-05, (20) Если вы претендуете на должность администратора в приличной конторе, а не эникей, Ghost (??), 18:01 , 22-Апр-05, (21) Дело, видимо, не в чьей-то криворукости, узколобости, any кейности и т п Вопр, Demar (??), 20:02 , 22-Апр-05, (22) Применение этих методов - плохое решение Они действительно иногда эффективны, но, Аноним (2), 23:01 , 22-Апр-05, (23) // pre greeting delay эффективен только при маленьких объемах почты, для больших са, unk (ok), 10:38 , 23-Апр-05, (24) // Не любой ли расход ресурсов, с которым не справляется оборудование - DOS cамому , Аноним (2), 15:27 , 23-Апр-05, (25) // Одно дело когда вас DOS ят или действительно не хватает мощей железа, а другое к, unk (ok), 16:04 , 23-Апр-05, (26) Exim, CommuniGatePro, Zack (?), 19:34 , 23-Апр-05, (27) Хех, было бы только памяти достаточно Гигабайт скажем , Zack (?), 19:37 , 23-Апр-05, (28) Опять врете, память для MTA не критична, unk (ok), 19:42 , 23-Апр-05, (30) Врете, unk (ok), 19:41 , 23-Апр-05, (29) Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сесс, _DVS_ (?), 14:32 , 25-Апр-05, (78) // Поясняю - Никак Протираем глаза и читаем pre-greeting с greylisting это не и, unk (ok), 14:38 , 25-Апр-05, (79) Сори Осмотрелся , _DVS_ (?), 15:02 , 25-Апр-05, (80) 1 То что автор пионер, видно по приводимым конфигам 2 Отбой на этапе соединен, Zulu (?), 15:46 , 24-Апр-05, (39) // Ну может не отбой, а Service Unevailable Позвольте поинтересоваться, а зачем на , Nazarov Dmitriy (?), 16:01 , 24-Апр-05, (40) Ну уж тогда поделись с нами о великий и ужасный ZULU секретами своего необъятног, Nikola (??), 10:26 , 25-Апр-05, (61) // Парень Возможно это ты автор и я тебя обидел выше -- тогда прости Но подумай, Zulu (?), 23:36 , 25-Апр-05, (82) // Следуя этой логике надо признать, что структура sendmail cf разработана пионерам, _DVS_ (?), 13:37 , 26-Апр-05, (83) Man sendmail mc FEATURE delay_checks , adsh (??), 18:39 , 26-Апр-05, (85) Существуют капитальные и систематизированные разработки в этой области от Виктор, adsh (??), 22:07 , 24-Апр-05, (50) // Так и нахрена он такой умный нужен, если не хочет показывать свое творение Жаба, demon (??), 01:26 , 25-Апр-05, (51) // Вот то, что сделано публично http rpm pbone net index php3 stat 4 idpl 1799678, adsh (??), 02:43 , 25-Апр-05, (52) Есть ещё хак, где можно выставлять проверку реверс DNS поюзерно хочу принимать , adsh (??), 02:57 , 25-Апр-05, (53) // Я думаю, что наш форум читают не только праведные админы, но и програмеры спама,, Максим (??), 14:22 , 25-Апр-05, (77) попробовал такую схемувозник вопросвозможно ли вначале анализировать access а по, Zaltic (ok), 15:51 , 11-Дек-06, (87) Я у себя попробовал то что написано в статье буквально вчера, мне очень понравил, Russian (?), 18:26 , 17-Янв-08, (88) // gt оверквотинг удален SLocal_check_relay R clien, Jnis (?), 02:49 , 31-Мрт-08, (90) SLocal_check_relay R client_addr R IP клиента OK, Jnis (?), 02:44 , 31-Мрт-08, (89) // Адрес клиента вписывать вместо IP клиента и все А client_addr так и ос, Russian (?), 17:59 , 10-Апр-08, (91) // Именно так , Janis (?), 00:55 , 02-Авг-08, (92) 1,2,3,4,5,6,7,8,10,11,12,16,23,39,50,53,87,88,89

Сообщения

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

3. "Блокирование спама на этапе соединения в sendmail"	+/–
Сообщение от Zerg (??), 22-Апр-05, 10:41
>Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации!!! Стрелял, а затем добивал бы прикладом тех, кто у себя это настроить не может. Ненавижу! ИМХО: политика отлупа на стадии соединения, наиболее верная ... Главное при этом соблюдать осторожность при выборе "черных списков". Всякие там спам-ассасины - штука конечно полезна, но на бабки ты уже попал ... Письмо, то сервак получил. А когда этих писем 20-30 тысяч ...
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	36. "Блокирование спама на этапе соединения в sendmail"	+/–
	Сообщение от Nazarov Dmitriy (?), 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
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

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

	38. "Блокирование спама на этапе соединения в sendmail"	+/–
	Сообщение от Nazarov Dmitriy (?), 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), 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 (?), 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), 24-Апр-05, 18:12
	>Вот тут и проблема. >Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не >прошел элементарную проверку. Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr() и gethostbyname()
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Блокирование спама на этапе соединения в sendmail"	+/–
	Сообщение от Nazarov Dmitriy (?), 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), 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 (?), 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), 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 (?), 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), 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, пинки от начальства, плевки коллег, вылетаете с работы, занавес.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	55. "Блокирование спама на этапе соединения в sendmail"	+/–
	Сообщение от Андрей (??), 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, с которого идет коннект, в этом списке. Если есть принимаем письмо, если нет, отбриваем. Все бы ничего, да только шаг В никто не выполняет :( Берут первый попавшийся адрес и считают что это единствено возможный вариант.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

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

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

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

	86. "Блокирование спама на этапе соединения в sendmail"	+/–
	Сообщение от Осторожный (?), 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 Делал переезд с одного домена в другой В СПЕШНОМ ПОРЯДКЕ Можно сказать в соседнем институте кстати :) И ничего - все живы
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема