Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
грейлистинг тоже хороший способ потерять письмо от клиента с кривым почтовым сервером.
Угу, а блоклисты — это верный путь потерять письмо от клиента с совершенно прямым почтовым сервером. Об этом я тоже написал.
верный — не верный, его все равно будут использовать, и администратор будет отгребать проблемы в любом случае.
Моё дело предупредить, что столь пафосно разрекламированные блоклисты создают порой огромные проблемы тем, кто их применяет. Точнее организациям, в которых они применяются, администратор-то всегда может убедить глупое руководство, что это проблемы с другой стороны, ведь такие солидные конторы как spamhaus не могут ошибаться.
кстати если уж говорить о «серьезной торговой организации» для массовых рассылок есть специальные сервисы аля www.mailchimp.com
грейлистинг вещь интересная и, действительно, убирает практически весь мусор.
вот только после 2ух месяцев были проблемы с получением почты от ряда компаний.
ну криво настроена у них почта! и писал, и ругался…
«а в чем проблема? на нас работает. это что-то у вас там»
вот только после 2ух месяцев были проблемы с получением почты от ряда компаний.
ну криво настроена у них почта! и писал, и ругался…
«а в чем проблема? на нас работает. это что-то у вас там»
кричать «блоклисты — это дилетантство» можно только пока объем входящей почты не превышает 100 писем в день
Примерно 1000-2000 в день на организацию, включён правда грейлистинг. Спама почти нет. Тем более к статье это не имеет никакого отношения. Цель статьи показать, что использовать блоклисты ни в коем случае нельзя, потому что они совершенно непарясь отсеивают почту с полностью благонадёжных хостов, чему в интернетах полно подтверждений. Как вы будете строить защиту от спама — это уже ваши проблемы, как системного администратора. Блоклисты — это таки да, классическое дилетанство. Попытка легко решить комплексную проблему, которая не имеет простого решения. И из-за вашей лени страдают администраторы других почтовых серверов, которые ни в чём не виноваты.
расскажи это spamhaus — вот они посмеются
ты ведь наверняка никогда не видел 100 соединений в секунду на почтовый сервер? Или у тебя есть решение «комплексной проблемы» для такого случая? Hint: грейлистинг не спасает
ты ведь наверняка никогда не видел 100 соединений в секунду на почтовый сервер? Или у тебя есть решение «комплексной проблемы» для такого случая? Hint: грейлистинг не спасает
Я про Фому, ты про Ерёму. Совершенно не важно, сколько соединений в секунду, хоть мильон. Это ваши проблемы, как вы будете их фильтровать. Разговор не об организации эффективной защиты от спама, а о блоклистах, и почему их ни в коем случае нельзя использовать для целей фильтрации.
если кто-то заявляет что «блоклисты — это дилетантство» он должен предложить достойную альтернативу. Если таковая не обозначана — заявитель сам дилетант.
С чего вдруг? Альтернатива — не использовать блоклисты. Вам, если вы системный администратор, деньги платят за то, чтобы вы делали как лучше, а не как проще. Мне что, убеждая наркомана отказываться от наркотиков, тоже предложите альтернативу подыскать, чтобы так же классно штырило? Я в отличие от вас не оправдываю использование убогих вредных технологий своей ленью сделать всё правильно.
это юношеский максимализм. Каждый может кричать — «это говно, то говно». Не можешь предложить альтернативы — сиди и молчи.
Кстати с наркоманами так и поступают — ищут для них альтернативу.
Кстати с наркоманами так и поступают — ищут для них альтернативу.
Это не юношеский максимализм, это скорей активная жизненная позиция, направленная против ущербных технологий, тормозящих прогресс и развитие или просто нарушающих нормальную работу. Если можно сделать как лучше, надо делать как лучше. Я никогда не буду поддерживать всякий отстой вроде спам листов, ибо они разрушают все принципы открытых стандартизированных коммуникаций. Я открыто высказываю своё презрение и большое φ всем тем, кто в угоду своей лени способствует развитию ущербных технологий, таких как блоклисты. Образно выражаясь вы готовы пройти по говну, но быстро, а я лучше обойду, но по чистой дороге.
Ага, а иметь своё мнение о еде могут только шеф-повара элитных ресторанов. (:
Хех, публичные блэклисты… Фигня это, а не проблема. Оттуда хоть вычиститься можно путём отправки запросов. Проблемы лично у меня возникали только с 3-мя (последствия вирусни в сетке и, как результата, рассылки спама через почтовик):
1. apews.org. Опции «отправить запрос на удаление из блэклиста» вообще не нашел. Так и валялся в блэклисте, пока сам apews в даун не упал. Сейчас не доступен.
2. uceprotect.net. Просят денег за срочную очистку. Если не платить, приходится около недельки ждать, пока вылезешь автоматически. Вообще, нормальный блэклист. Вменяемый.
3. nszones.com. Ну, эти просто мудаки (пруф — http://www.spamhaus.org/organization/statement.lasso?ref=8). Несмотря на то, что числимся до сих пор, благополучно забили на этот факт. Пофигу, учитывая специфику этого «блэклиста».
С остальных поудалялся в течение суток.
Но есть такой почтовый сервис как великий и могучий gmail. Не, я Гугл очень уважаю и более того, мой личный основной ящик именно там и находится, но возненавидел их тогда всей душой. Это стало настоящей проблемой.
Письма на гмыло тупо не доходили. Даже в спам не попадали. Просто приходил отлуп в виде «бла-бла-бла, айпи вашего почтового сервера заблокирован, вы нарушили правила почтовой рассылки, почитайте как надо [здесь линк на правила оформления писем]». Всё. С гмыла, однако, почта приходила исправно.
Ковыряние в инете по поводу решения проблемы дало следующие результаты:
— способов связаться с техподдержкой напрямую нет.
— на форуме гугла (да и прочих других) только ответы типа «gmail не использует блэклистов, оформляйте письма правильно ([опять тот же линк]) и в спам попадать ничего не будет». Указания по поводу того, что почта режется сразу на подходе к собственно получателю, тупо игнорировались — «бла-бла, гмэйл не использует блэклистов».
— справочная система у гугла гавно редкостное. Не, реально, всё настолько тупо, что я, столкнувшись с этим, поначалу даже урл перепроверял — туда ли я зашел. Я не мог поверить, что ответа на такой, казалось бы, типичный вопрос нет вообще. «бла-бла, проверьте связь», «бла-бла, оформляйте правильно», «бла-бла, это у вас отправка почты поломалась». Козлы, млять… Этот момент, по поводу хэлпа, кстати, не только гмыла касается. Как минимум адвордса тоже (намедни полчаса искал, хули у меня статистика по рекламе неправильно отображается, в итоге писал в саппорт с вообще левой темой «я не вижу своё объявление»).
Ругательства на их форуме, кстати, эффекта тоже никакого не дали.
Это продолжалось 2 или 3 месяца. Письма шли через специально заведенный аккаунт на гмыле. Ситуацию осложняло то, что некоторые адресаты перевели корпоративную почту именно на гмыло с сохранением своего домена, а оттого приходилось сразу получить отлуп от гугла, потом заходить на веб-морду джмэйла и отправлять опять. Юзера просто достали этим всем. Дело дошло до того, что появились мысли об увольнении нахрен. Но в один прекрасный день почта стала доходить. Что произошло, я не знаю. На ящик типа abuse@ourdomain.com или admin@ourdomain.com ничего от гугла не приходило.
Так вот, блэклисты штука нормальная. Но вот так тупить как гугл, наверное, таки не надо.
1. apews.org. Опции «отправить запрос на удаление из блэклиста» вообще не нашел. Так и валялся в блэклисте, пока сам apews в даун не упал. Сейчас не доступен.
2. uceprotect.net. Просят денег за срочную очистку. Если не платить, приходится около недельки ждать, пока вылезешь автоматически. Вообще, нормальный блэклист. Вменяемый.
3. nszones.com. Ну, эти просто мудаки (пруф — http://www.spamhaus.org/organization/statement.lasso?ref=8). Несмотря на то, что числимся до сих пор, благополучно забили на этот факт. Пофигу, учитывая специфику этого «блэклиста».
С остальных поудалялся в течение суток.
Но есть такой почтовый сервис как великий и могучий gmail. Не, я Гугл очень уважаю и более того, мой личный основной ящик именно там и находится, но возненавидел их тогда всей душой. Это стало настоящей проблемой.
Письма на гмыло тупо не доходили. Даже в спам не попадали. Просто приходил отлуп в виде «бла-бла-бла, айпи вашего почтового сервера заблокирован, вы нарушили правила почтовой рассылки, почитайте как надо [здесь линк на правила оформления писем]». Всё. С гмыла, однако, почта приходила исправно.
Ковыряние в инете по поводу решения проблемы дало следующие результаты:
— способов связаться с техподдержкой напрямую нет.
— на форуме гугла (да и прочих других) только ответы типа «gmail не использует блэклистов, оформляйте письма правильно ([опять тот же линк]) и в спам попадать ничего не будет». Указания по поводу того, что почта режется сразу на подходе к собственно получателю, тупо игнорировались — «бла-бла, гмэйл не использует блэклистов».
— справочная система у гугла гавно редкостное. Не, реально, всё настолько тупо, что я, столкнувшись с этим, поначалу даже урл перепроверял — туда ли я зашел. Я не мог поверить, что ответа на такой, казалось бы, типичный вопрос нет вообще. «бла-бла, проверьте связь», «бла-бла, оформляйте правильно», «бла-бла, это у вас отправка почты поломалась». Козлы, млять… Этот момент, по поводу хэлпа, кстати, не только гмыла касается. Как минимум адвордса тоже (намедни полчаса искал, хули у меня статистика по рекламе неправильно отображается, в итоге писал в саппорт с вообще левой темой «я не вижу своё объявление»).
Ругательства на их форуме, кстати, эффекта тоже никакого не дали.
Это продолжалось 2 или 3 месяца. Письма шли через специально заведенный аккаунт на гмыле. Ситуацию осложняло то, что некоторые адресаты перевели корпоративную почту именно на гмыло с сохранением своего домена, а оттого приходилось сразу получить отлуп от гугла, потом заходить на веб-морду джмэйла и отправлять опять. Юзера просто достали этим всем. Дело дошло до того, что появились мысли об увольнении нахрен. Но в один прекрасный день почта стала доходить. Что произошло, я не знаю. На ящик типа abuse@ourdomain.com или admin@ourdomain.com ничего от гугла не приходило.
Так вот, блэклисты штука нормальная. Но вот так тупить как гугл, наверное, таки не надо.
Не понял из сего рассказа, почему блоклисты — штука нормальная)) С проблемами с гмылом не сталкивался — ничего сказать не могу. С проблемами с приватными блоклистами сталкивался — благополучно забил на них большой болт и тупо посылаю администраторам, их использующим, корректное письмо о том, что они идиоты. Точнее не админам, а клиенту, который из-за админа не может от нас получить письмо. Поскольку специфика компании предполагает общение с серьёзными организациями, то когда возникают подобные проблемы в связи администраторам на той стороне частенько достаются большие втыки.
О том, почему иногда блоклисты это очень таки даже хорошо. Тут от ситуации зависит. У нас сервер режет спама порядка 2,5-3 тысяч писем в сутки (турагенство у нас, тут уж карма такая, по роду деятельности положено такой спам получать :) ). Так что публичные блэклисты очень даже выручают. Отлуп от спамассассина, и пусть идут лесом.
Попробуйте на досуге посчитать, скольких клиентов из-за публичных блоклистов вы потеряли))
Я лучше посчитаю, сколько клиентов наши менеджеры уберегли только тем, что вовремя отвечали на почту, а не чистили её от спама ))
Я всегда думал, что блоклисты — это такой легальный бизнес по шантажу организаций и провайдеров.
Ну да, а этот пост как-то это опровергает? См. статьи хотя бы на хабре по поводу блоклистов.
Уже год администрирую два почтовых сервера для массовых рассылок (сотни тысяч писем в неделю). Ни разу айпишники не попадали в спам листы (проверялось многочисленными чекерами). ЧЯДНТ?
Блоклистов только популярных существует с десяток, и в какой мы интересно попали и что нам теперь делать?С этой проблемой помогют справиться robtex.com и 2ip.ru. Сразу одним махом на большой пачке блеклистов проверяют.
А по теме — не соглашусь с вами. Да, есть левые блоклисты, есть устаревшие, но которые до сих пор у некоторых админов настроены и т.п. Но это не проблема блеклистов как таковых. Вы больной зуб предлагаете лечить гильотиной, что попахивает максимализмом. Да обидели вас. Но вы сами признаете факт массовых рассылок. Вам необходимо договориться с держателями блеклистов, чтобы не банили вас, раз уж рассылки — часть бизнеса. Или как говорили уже — отдать рассылки на аутсорс, профессионалы давно имеют договоренности с блеклист-админами.
Мне больше всего это понравилось — multirbl.valli.org/. Запрос шлется вида multirbl.valli.org/lookup/127.0.0.1.html (айпишник в адресе, само собой, надо другой подставлять).
Это, извините, идиотизм. Об этом писали выше — спамлисты — это чистой воды рэкет, а вы их ещё и оправдываете. Сама технология порочна от основания до макушки и в принципе не имеет права на существование. Да, она сильно упрощает жизнь за счёт того, что все закрывают глаза на её критически важные недостатки. Я грешным делом уважаю прозрачность и стандартизированность интернет-технологий и жутко ненавижу всё, что их ломает и нарушает.
Это, извините, не более чем ваше лично мнение оскорблённого и униженного админа (и таких же как вы). Вам уже по делу немало написали, а вы всё слюной брызжете и в гневе распаляетесь. Никакой порочности в блеклистах нет, этот колхоз — добровольное начинание обычных интернетчиков, чтобы избавиться от таких спамеров, как вы. Да-да. Вы же сами сказали, что списки ваши часто неактуальны, а это значит, что некоторая часть писем шла в существующие ящики, но не принадлежащие вашим клиентам. Следовательно, с точки зрения таких пользователей — это чистой воды СПАМ, на который они жалуются и шлют абузы. Справедливо. Послушайте тов. амарао, он вам дал наиболее дельные советы чуть ниже. Спокойнее надо быть, коллега. Вы просто не сумели приготовить рассылку должным образом, вот и получаете детскими граблями. Ваши вопли понятны, я сочувствую искренне, но выводы делаете неверные в запале ненависти.
Почему неверные? Адреса менеджерам пишут сами пользователи, за их правильность я отвечать увы ну никак не могу. В целом наши рассылки ну никаким боком не спам. Но всё равно вы упорно, как и амарао, уходите от обсуждения одной простой истины: RBL имею абсолютно ложные срабатывания, что делает их неприменимыми при фильтрации спама, поскольку потенциально может потеряться абсолютно любое письмо.
Почему неверные?Ну дык, цитирую вас же:
добрая четверть адресов в базе является некорректной
Не можете отвечать за актуальность — так вставьте unsubscribe в рассылку, вам же сказали. И человек, ошибочно получивший письмо, не абуз будет слать, а просто кликнет «отписаться». Продумывать-то нужно не только как «25 порт закрыть», но и с точки зрения юзера посмотреть на проблему. Правильных почтовых админов блеклисты не беспокоят.
В этом вы правы. Но вы снова и в очередной раз ушли от обсуждения основной проблемы и тезиса данной статьи. В своё оправдание могу сказать, что в свою подпись менеджеры добавляют контакты и ссылки для связи по вопросам подписки на новости. Правда это сделано в основном для того, чтобы люди подписывались на разные другие мероприятия, но и попросить удалить тоже можно при желании.
«контакты менеджеров» — это кусок г-на, извините, с точки зрения получившего левое письмо. А вот нормальный текст вида:
Вы получили это письмо, т.к являетесь клиентом бла-бла и подписались на получение бла-бла по e-mailгооорааздо понятнее и эффективнее.
Если вы не хотите получать подобных писем, нажмите на ссылку:
хттп://your.domain.com/unsubscribe
И кстати ещё, полагаться на колхоз в столь критически важных областях, как связь, это немного странно. Я вот лично при отсеивании писем полагаюсь только на чёткие стандарты и ни на что больше.
полагаться на колхоз в столь критически важных областях, как связь, это немного странно.Вы это расскажите, например таким ребятам, как АНО «ЦВКС «МСК-IX». В этом добровольном колхозе и гугль с яндексом участвуют. От колхозов может быть много пользы, главное знать, как доить. Даже от побочных продуктов (говна, простите) польза — отличное удобрение. )
Понимаете, в данном случае колхоз блоклистов — это неорганизованная толпа сервисов, которые по информации из неназываемых источников и по нераскрываемым алгоритмам имеют наглость без предъявления каких-либо доказательств утверждать о неюлагонадёжности отдельных хостов. Плюс иногда ещё и требовать денег за изменение своего решения. Это, как бы так сказать, абсурд + осознанная клевета.
я прекрасно понимаю ваше негодование по поводу таких вот нехороших блоклистов. В бытность мою эникеем-сисадмином, когда и почта была на моих плечах, я делал несколько иначе. Наличие/отсутствие айпи в блоклистах (двух или трех, хороших, проверенных) лишь добавляло пару очков к общей формуле принятия решения о принадлежности к СПАМу. Туда же шли «очки» за PTR, FQDN, результат проверки баесового фильтра, наличие определенных вложений и прочие параметры. Никакая из проверок не была решающей, а лишь некая сумма проверок, с коэффициентами «весов» у каждой проверки. Мои сервера тоже попадали в блоклисты (то вирус свеженький на ноуте босса, то еще хрен какой разошлет барахло), я негодовал, но потом просто настроил rate на передачу писем в сек. от юзера и на роутерах rate по pps от компов тоже стал контроллировать, автоматически блокируя аномальный трафик от потенциально зараженных машин. С месяц неторопливой отладки — и система стала работать как часы, никаких более попаданий в блоклисты я не знал.
Не, ну я естественно выкручусь и не буду попадать в блоклисты. Но разговор-то этот я инициировал по совершенно другой причине. Я выкручусь, закостылив свою сеть, а блоклисты останутся и их продолжат использовать нерадивые админы. Я категорически не согласен с самим фактом наличия блоклистов, поскольку они уродуют почтовый обмен, превращая его в недокументированную игру без правил. Мне такой расклад не нравится, поэтому я никогда не буду использовать блоклисты во-первых и стараюсь привлечь как можно больше внимания к проблеме во-вторых.
В вас бурлит идеализм, с максимализмом на пару. Вам бы в эпохк DARPANet и BBS-ок жить. Всяческие rbl, spf, domain-key, bayes heur, greylisting и прочие не от хорошей жизни родились. Суки-СПАМеры всех достали. Вот и пытаются трудяги-админы из 100% SMTP-трафика выжать те несчастные 9% полезной корреспонденции, оградив себя от фекальных потоков. Побочные эффекты неизбежны. Нужно просто с ними смириться и решать текущие задачи имеющимися средствами. В максималистических порывах можно дойти до лозунга «Разослал СПАМ — расстрелять на месте» и хвататься за ружьё. Источник-то проблемы вашей не в rbl, а в наличии СПАМеров. Не симптомы ведь нужно лечить, а болезнь?
Да вот в том-то и дело, что ваш подход тоже не верен. Нет и не может быть никаких побочных эффектов, это нонсенс признавать то, что система обеспечивает заведомо ложные срабатывания и продолжать пользоваться системой. Стандарты должны быть непротиворечивыми, а какое-либо взаимодействие вне стандартов — порицаемым. Это элементарно организуется в современном мире, достаточно ввести рейтинговую систему оценки спама и полагаться на спамлисты только в качестве дополнительного фактора или же вообще не использовать их при оценке рейтинга. Но нет, вместо этого горе-админы ставят прямую проверку адреса по спамлистам, закрывая глаза на очевидную нелепость и абсурдность такого подхода. В итоге имеем глобальную систему обмена почтой с совершенно непредсказуемым поведением, браво, спасибо всем, принимающим участие в этой комедии абсурда! И большинство с этим молча соглашается. Я — нет. Пора уже избавляться от велосипедов о квадратных колёсах, коими являются спамлисты, и обеспечивать хотя бы непротиворечивость обмена почтой. Тем паче что сделать это при современном уровне развития различных спамфильтров проще простого.
не существует никаких стандартов для обмена электронной корреспонденцией. Есть лишь несколько RFC.
Электронная почта — это один из инструментов, которые ваша компания добровольно выбрала в качестве способа решения ряда бизнес-задач. Именно вы (компания) — заинтересованное лицо, а не какой-то там «Дух Стандартов» или еще кто. тут, как говорится, всё «по понятиям», а не по букварю. Гугль, например, срать хотел на соответствие MX-ов PTR-ам, и всё тут. И под него подстраиваются те, кто не хочет терять письма от гугловских релеев. При этом отключи глобально на серверах проверку совпадения MX-PTR и получишь прибавку в 1328% СПАМа, т.к. вольётся армия зомби-релеев из домовых сетей.
Зато работа e-почтмейстеров не скучная, увлекательная и разнообразная ) Везде нужно искать позитив, тогда его и будешь находить. Будешь искать негатив — его и найдешь. Простой принцип.
Электронная почта — это один из инструментов, которые ваша компания добровольно выбрала в качестве способа решения ряда бизнес-задач. Именно вы (компания) — заинтересованное лицо, а не какой-то там «Дух Стандартов» или еще кто. тут, как говорится, всё «по понятиям», а не по букварю. Гугль, например, срать хотел на соответствие MX-ов PTR-ам, и всё тут. И под него подстраиваются те, кто не хочет терять письма от гугловских релеев. При этом отключи глобально на серверах проверку совпадения MX-PTR и получишь прибавку в 1328% СПАМа, т.к. вольётся армия зомби-релеев из домовых сетей.
Зато работа e-почтмейстеров не скучная, увлекательная и разнообразная ) Везде нужно искать позитив, тогда его и будешь находить. Будешь искать негатив — его и найдешь. Простой принцип.
А MX и не должны соответствовать PTR, с чего бы вдруг?))) PTR должен соответствовать A и наоборот. И только. И это даже не требование RFC на SMTP, это требование RFC на DNS. Иначе вы зарежете много ретрансляторов, серверов, которые только отправляют почту, и т.д. И гугл этому требованию вроде как соответствует, ни разу по крайней мере не ловил проблем с ним, хотя у меня включена проверка обратной записи. RFC — это как бы не стандарт, да. Но это договорённость строгого плана. В цифровом мире нельзя жить по понятиям, можно жить только по правилам.
MX — это такой специфическая CNAME, по сути. Без А-записи не существует сама по себе. Вот именно цепочка MX->A->PTR должна совпадать.
Не совпадает. И так все их MX-ы, проверьте сами.
И гугл этому требованию вроде как соответствует
~$ dig gmail.com MX +short | head -n 1
5 gmail-smtp-in.l.google.com.
~$ dig gmail.com MX +short | head -n 1
5 gmail-smtp-in.l.google.com.
~$ dig gmail-smtp-in.l.google.com. +short
74.125.77.27
~$ dig -x 74.125.77.27 +short
ew-in-f27.1e100.net.Не совпадает. И так все их MX-ы, проверьте сами.
черт, первая строка задублировалась, пока копипастил.
ну и заодно:
ну и заодно:
MX — это такойая специфическая CNAME
Вы забыли сделать ещё один шаг:
$ dig ew-in-f27.1e100.net +short
74.125.77.27
Запрос-то идёт сперва IP->A, потом полученную A обратно в IP, затем сверка исходного IP и полученного. Цель такого запроса — убедиться, что физический хост-отправитель корректно зарегистрирован в сети. При этом полученная А запись не должна иметь какое-либо отношение к обслуживаемому почтовому домену. И MX — тоже, поскольку единственное требование к MX записям — это ссылка на существующие А, а на какие- это не важно. Это распространённая практика делать MX записи ссылками на А записи домена, хотя серваки находятся в другом домене, таким образом получается ситуация как у гугла. Например, дефолтнейм почтового сервера для домена — это mail.domain.com. Короче, у гугла всё чётко в рамках общепринятых стандартов.
$ dig ew-in-f27.1e100.net +short
74.125.77.27
Запрос-то идёт сперва IP->A, потом полученную A обратно в IP, затем сверка исходного IP и полученного. Цель такого запроса — убедиться, что физический хост-отправитель корректно зарегистрирован в сети. При этом полученная А запись не должна иметь какое-либо отношение к обслуживаемому почтовому домену. И MX — тоже, поскольку единственное требование к MX записям — это ссылка на существующие А, а на какие- это не важно. Это распространённая практика делать MX записи ссылками на А записи домена, хотя серваки находятся в другом домене, таким образом получается ситуация как у гугла. Например, дефолтнейм почтового сервера для домена — это mail.domain.com. Короче, у гугла всё чётко в рамках общепринятых стандартов.
ок, раз уж вы попытались углубиться, то и я продолжу. Если быть совсем точным, PTR-запись должна совпадать с ответом SMTP-сервера на 25 порту. Согласны? Т.е. если сервер представился по SMTP как mx.domain.com с ip-адреса 1.2.3.4, то PTR-запись для 1.2.3.4 должна быть равна mx.domain.com.
Что ж, идем к гуглю:
А теперь следите за руками:
Вот такой вот мисматч. Вы бы лучше боролись на этом фронте, тут ложноположительных срабатываний в разы больше, чем от несчастных rbl.
Что ж, идем к гуглю:
$ telnet gmail-smtp-in.l.google.com. 25
Trying 74.125.77.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP u1si8812570eeh.32
А теперь следите за руками:
$ dig -x 74.125.77.27 +short
ew-in-f27.1e100.net.Вот такой вот мисматч. Вы бы лучше боролись на этом фронте, тут ложноположительных срабатываний в разы больше, чем от несчастных rbl.
Напомните номер RFC в котором говорилось о PTR записи, если я не ошибаюсь это был один из Best Current Practice(rfc2505?). А в стандарте нету слов о PTR. Там даже четко сказанно если мы захотим проверить EHLO/HELO и нам это не удасться сделать мы должны все равно принимать почту.
Не, ну это вообще чушь. HELO не должно совпадать ни с одним ответом от DNS, поскольку это совершенно несвязанные вещи. Для HELO должна существовать адресная запись, но при этом она совершенно не обязана совпадать с адресом сервера отправки. Потому как часто почтовый сервер находится за шлюзом, а в крупных органзициях шлюзов несколько, соответственно отправка писем с одного почтового сервера может происходить через разные шлюзы. Читайте RFC внимательней ;)
Не, ну это вообще чушь.Вот в этом-то и разница между теми, кто постоянно попадает в блеклисты и теми, кто блюдет правила хорошего тона:
HELO = FQDN сервера = MX домена = PTR Запись
Чтобы понять глубинный смысл данного заклинания, начинаем издалека, с чтения rfc1912. Далее rfc821 и вслед за ним rfc2821. Вместо строгих равенств можно расставить нестрогие, но тут уже не обижайтесь, если вырастет процент серверов, которые откажутся принимать
Правила хорошего тона перечислены в конце этой статьи. Других не существует, ибо иначе вы бы просто сделали невозможными большинство конфигураций корпоративных сетей. И у меня таки да, у меня есть лишний внешний IP, поэтому HELO совпадает с MX и совпадает с PTR. Я ж говорю, хост настроен на 100% корректно. Но это совершенно необязательно, важны только правила по ссылке, всё остальное — лишь ваши домыслы.
а как это связано с наличием внешнего ip?
Да и вообще, опыт показывает, что 100% корректно настроенный хост не попадает в блоклисты, уж поверьте, через наши релеи проходит около 40 тысяч легитимных писем в день. Если, конечно, этот хост не СПАМит. Третьего не дано.
Да и вообще, опыт показывает, что 100% корректно настроенный хост не попадает в блоклисты, уж поверьте, через наши релеи проходит около 40 тысяч легитимных писем в день. Если, конечно, этот хост не СПАМит. Третьего не дано.
Я вот вижу, что дано. А по поводу IP: представьте, что у вас есть домен vasya.com. Это имя ссылается на IP вашего шлюза, в PTR которого прописано это же имя. Всё пучком. Но vasya.com — нехороший почтовый домен, поэтому у вас есть ещё парочка — dima.com и lisa.com, в каждом есть mail.dima.com и mail.lisa.com, дабы нормально работали почтовые программы. Но шлюз-то у вас один и только один IP, значит оба mail. ссылаются на IP vasya.com. А в HELO вы тоже не запихнёте одновременно и mail.dima.com и mail.lisa.com, а сервер-то один. Вот и получается, что MX не соответствует A, HELO не соответствует MX, а PTR вообще резолвится в левый домен. Тем не менее совершенно корректная конфигурация.
вы явно путаете HELO и MAIL FROM. Домен из HELO ни разу не обязан совпасть с тем, что в MAIL FROM, т.е. грубо говоря, один почтовый релей может запросто рассылать почту от имени множества доменов. Нет никакой проблемы настроить HELO одинаково на всех серверах (в вашем примере mail.vasya.com.), хоть их там десяток за одним ip.
Да и вообще, странный постулат, что при одном шлюзе один ip. Спишем на неказистость примера. Да и вообще, зачем конторе с одним ip (очевидно, уровня SOHO) два и более релеев? Да даже один зачем? В общем, пример уж слишком искусственен, хотя из него мне стали ясны ваши представления. И на том спасибо.
Да и вообще, странный постулат, что при одном шлюзе один ip. Спишем на неказистость примера. Да и вообще, зачем конторе с одним ip (очевидно, уровня SOHO) два и более релеев? Да даже один зачем? В общем, пример уж слишком искусственен, хотя из него мне стали ясны ваши представления. И на том спасибо.
Не-не, я ничего не путаю)) MAIL FROM вообще не имеет никакого отношения ни к HELO, ни к A, ни к MX, ни к PTR, ни к DNS в целом. Но и HELO не имеет никакого отношения к хосту, с которого приходит письмо. HELO — это нечто MAIL FROM, но только для сервера. В теории по имени из HELO должно быть можно попасть на тот же сервер. И только. При этом запросы могут идти с совершенно другого. По поводу искусственности — все обслуживаемые мной почтовые домены имеют именно такую конфигурацию, кроме одного. Ибо интернет корпоративный нынче безумно дорог, лишние IP — тоже, а почту и сайт хочется иметь всем.
мелким конторам почту нужно отдавать на откуп гуглю/яндексу, а сайт — на шаред хостинг. И да будет щщастье, и да не будет админ порицаем понапрасну из-за коварных, скрытных и загадочных блоклистеров.
Нуу, по многочисленным причинам обычно это неприемлемо)))
Единственная вменяемая причина — невозможно самостоятельно забесплатно рассылать спаммассовые рассылки по клиентам. Придется платить спец. сервисам типа сабскрайб.ру )
Ну да как же. Причин вагон, начиная с нежелания руководства отдавать документы, представляющие корпоративную тайну, гуглу, заканчивая тем, что необходима интеграция почты с корпоративной сетью и корпоративной БД пользователей.
Все эти пафосные фразы несовместимы с конторой о 12 сотрудниках с одним айпи на все сервера ) А документы все равно клиентам бегают по голозадому SMTP. Вы же криптуете такие письма, да? Тогда никакой разницы нет. кто является релеем. А внутренние документы с «корпоративной тайной» )) можно передать, протянув руку ).
а вот проверка MX-PTR это зло, ибо не один гугл забил на это и при включении кроме 1328% спамеров туда же пойдут 60% ham-еров
Рассылка должна выполняться менеджером рассылок, а не «специальной программкой». У меня в одной из контор более 30 списков рассылки, с более чем 150к получателей. Около 30% исходящего трафика от нас — почтовый. И никаких ложных срабатываний на вменяемых RBL.
Причина? Разумеется, mailman. Который предоставляет -unsubscribe, который дописывает снизу сообщения инструкцию о том, как отписаться, который добавляет в заголовки письма указание на то, что это рассылка. Разумеется, это не спам и на спам не похоже. А если кто-то из ваших менеджеров делает рассылку из тандербёрда в режиме «поставлю всех в поле CC, а себя в поле „кому“», о и получается типичное спам-письмо с неверным получателем.
Используйте адекватные менеджеры рассылок и у вас не будет проблем с «похожестью на спам».
Ещё SFP чуток помогает, его наличие и правильность некоторые считают как отрицательный коэфицент к спамобойке.
Причина? Разумеется, mailman. Который предоставляет -unsubscribe, который дописывает снизу сообщения инструкцию о том, как отписаться, который добавляет в заголовки письма указание на то, что это рассылка. Разумеется, это не спам и на спам не похоже. А если кто-то из ваших менеджеров делает рассылку из тандербёрда в режиме «поставлю всех в поле CC, а себя в поле „кому“», о и получается типичное спам-письмо с неверным получателем.
Используйте адекватные менеджеры рассылок и у вас не будет проблем с «похожестью на спам».
Ещё SFP чуток помогает, его наличие и правильность некоторые считают как отрицательный коэфицент к спамобойке.
Ок, какое это имеет отношение к RBL? Я вам гарантирую, что 100% корреспонденции, уходящей с моего сервера, является абсолютно корректной. Ещё разок: лично вы готовы нести ответственность за срыв контракта, скажем, на пару миллионов рублей, из-за того, что у вас включена проверка RBL? С моей стороны никаких недоработок нет — абсолютно корректно настроенный сервер, который никогда не посылал никакого спама. У моих менеджеров уже были попытки впаять сисадминам некоторых контор лишение премии за то, что они срывали обмен корреспонденцией. И не безрезультатно, чему лично я очень рад. Мне звонят менеджеры и говорят, что у них срываются контракты. Я им говорю, что с моей стороны всё совершенно нормально и что из-за их писем нас снова добавили в спам листы. Или мне надо написать директиву по организации, согласно которой рассылать больше 5 писем в минуту со своего аккаунта запрещено из-за идиотизма некоторых администраторов принимающих серверов?? Пользуйтесь мол корпоративной рассылкой. Меня категорически не поймут.
Есть бесспорный факт — RBL обеспечивают ложное срабатывание для совершенно благонадёжных хостов. Есть очевидный вывод из этого факта — RBL не могут использоваться для фильтрации спама и ответственный администратор никогда не будет использовать RBL. Всё остальное — словоблудие. Конечно я выкручусь из ситуации и конкретно мой хост больше не будут добавлять в RBL. Но общей ситуации абсолютной неприемлемости применения RBL это не поменяет.
Есть бесспорный факт — RBL обеспечивают ложное срабатывание для совершенно благонадёжных хостов. Есть очевидный вывод из этого факта — RBL не могут использоваться для фильтрации спама и ответственный администратор никогда не будет использовать RBL. Всё остальное — словоблудие. Конечно я выкручусь из ситуации и конкретно мой хост больше не будут добавлять в RBL. Но общей ситуации абсолютной неприемлемости применения RBL это не поменяет.
Вы знаете, но у меня это ограничение на сервере прописано. Не более 6 одновременных адресатов письма (за вычетом внутренних адресов, разумеется). И у меня все менеджеры точно приучены к пользованию mailman'ом (самые умные сами управляют списком, самые тупые знают, что я сделаю и слать можно будет на betsloni@lists.slonivpodarok.ru, а дальше оно само разойдётся).
Вопрос с RBL с моей стороны решён очень просто — у всех, кому это важно, есть емейл без RBL и вообще без какой-либо фильтрации (у меня такие согласно RFC abuse, postmaster, hostmaster). Эти адреса никогда не появляются в исходящих письмах, потому мало засвечены. Обычная двусторонняя переписка идёт через обычный емейл с RBL, строгой проверкой наличия PTR, валидного FQDN в HELO и т.д. А если вдруг что не так — есть резервный емейл, который можно продиктовать.
Кстати, перед RBL у любого уважающего себя сервера должен быть RWL. Который большинство вопросов решает.
Вопрос с RBL с моей стороны решён очень просто — у всех, кому это важно, есть емейл без RBL и вообще без какой-либо фильтрации (у меня такие согласно RFC abuse, postmaster, hostmaster). Эти адреса никогда не появляются в исходящих письмах, потому мало засвечены. Обычная двусторонняя переписка идёт через обычный емейл с RBL, строгой проверкой наличия PTR, валидного FQDN в HELO и т.д. А если вдруг что не так — есть резервный емейл, который можно продиктовать.
Кстати, перед RBL у любого уважающего себя сервера должен быть RWL. Который большинство вопросов решает.
Круто. Пожалуйста ссылочку на RFC, регламентирующую максимальное количество писем в минуту, в студию. А так же ответ на вопрос готовы ли вы нести ответственность за срыв по вашей вине крупного коммерческого контракта.
Закостылить я могу всё, что угодно. И ограничение на отправку и пересылку по хитроумным маршрутам. Только проблема в том, что это всё мне абсолютно ненужно. Я всё делаю правильно и максимально согласуясь с общепринятыми стандартам обмена электронной корреспонденцией. Я не собираюсь ввязывать в теневые игры без правил, которые навязывают блоклисты, поскольку вся ответственность за срыв обмена сообщениями лежит полностью на принимающей стороне. Именно об этом весь пост: RBL гарантированно приводят к ложным срабатываниям даже для 100% благонадёжных хостов. Если вы это понимаете и вас это устраивает — пожалуйста, мне же просто хотелось предостеречь неопытных администраторов от совершения ошибок.
Закостылить я могу всё, что угодно. И ограничение на отправку и пересылку по хитроумным маршрутам. Только проблема в том, что это всё мне абсолютно ненужно. Я всё делаю правильно и максимально согласуясь с общепринятыми стандартам обмена электронной корреспонденцией. Я не собираюсь ввязывать в теневые игры без правил, которые навязывают блоклисты, поскольку вся ответственность за срыв обмена сообщениями лежит полностью на принимающей стороне. Именно об этом весь пост: RBL гарантированно приводят к ложным срабатываниям даже для 100% благонадёжных хостов. Если вы это понимаете и вас это устраивает — пожалуйста, мне же просто хотелось предостеречь неопытных администраторов от совершения ошибок.
про крупные контракты которые рвутся из за не дошедшего емаила это отличная отмаза, что бы ничего не делать… :) простите а вы за это отвечаете?:)
Хм, ну ничего не делать — это громко сказано. Проблема с массовой рассылкой от имени конкретного человека — это последняя нерешённая проблема почты)) Но таки да, меня лишали премии когда по моей вине не работал почтовый сервер в момент, когда он был нужен. И в общем насколько мне известно стараниями наших сердобольных менеджеров некоторым особенно умным админам по моему обоснованию невозможности обмена корреспонденцией также были впаяны санкции за срыв работы. Было три случая разборок с админами принимающей стороны, один из-за полного бардака в настройках сервака, а два из-за блоклистов.
Скажите, у вас нет проблемы спама? У меня была обратная проблема — примерно 2 недели не работали никакие фильтры (кроме reject unknown_recipient_domain) — контору просто физически завалило спамом — больше 300 тысяч писем ежедневно.
Далее. Утверждать, что сисадмин может гарантировать приём почты от любого почтового сервера в мире — явная ошибка, этого невозможно гарантировать (мало ли кому что не понравится).
И да, у меня на предыдущей работе остался файл с исключениями кривых китайских серверов, присылающих почту с динамических IP и кривыми HELO. Те самые миллионные контракты (кстати, без шуток).
Если лично вас решили премии — это ваши проблемы с начальством, не надо злобу на них вымещать на технологиях.
Лично у меня схема такая:
разрешить исключения получаетелей
разрешить исключения отправителей
отказать тем, у кого helo не ресолвится в IP
разрешить отправку своим сетям
отказать в приёме с нашими адресами поле FROM
отказать в приёме с посторонними адресами в поле TO
отказать в приёме от узлов с HELO без FQDN
отказать в приёме писем на несуществующие адреса
отказать ручному чёрному списку
принять почту от узлов, прошедших WBL
принять почту от узлов, у которых SFP настроен на ограниченное количество узлов и прошёл проверку
принять почту от узлов, чьи сертификаты TLS у меня в доверенных
отказать тем, кто в RBL.
принять.
В отлупе на RBL у меня написано «your IP X.X.X.X [FQDN] was rejected by RBL-NAME, you can contact mail administrator via postmaster@domain (non-filtered).»
ЧЯДНТ?
Далее. Утверждать, что сисадмин может гарантировать приём почты от любого почтового сервера в мире — явная ошибка, этого невозможно гарантировать (мало ли кому что не понравится).
И да, у меня на предыдущей работе остался файл с исключениями кривых китайских серверов, присылающих почту с динамических IP и кривыми HELO. Те самые миллионные контракты (кстати, без шуток).
Если лично вас решили премии — это ваши проблемы с начальством, не надо злобу на них вымещать на технологиях.
Лично у меня схема такая:
разрешить исключения получаетелей
разрешить исключения отправителей
отказать тем, у кого helo не ресолвится в IP
разрешить отправку своим сетям
отказать в приёме с нашими адресами поле FROM
отказать в приёме с посторонними адресами в поле TO
отказать в приёме от узлов с HELO без FQDN
отказать в приёме писем на несуществующие адреса
отказать ручному чёрному списку
принять почту от узлов, прошедших WBL
принять почту от узлов, у которых SFP настроен на ограниченное количество узлов и прошёл проверку
принять почту от узлов, чьи сертификаты TLS у меня в доверенных
отказать тем, кто в RBL.
принять.
В отлупе на RBL у меня написано «your IP X.X.X.X [FQDN] was rejected by RBL-NAME, you can contact mail administrator via postmaster@domain (non-filtered).»
ЧЯДНТ?
RBL тут лишний. У меня примерно такая же схема, вместо RBL стоит грейлистинг только. Вы можете спокойно не принять почту от нового для себя хоста (хотя может SPF спасти), я приму при любом раскладе если хост отправителя настроен корректно. Вы полагаетесь на мнение левых дяденек, которые неаргументированно и бездоказательно присваивают хостам статус спамерских, я же полагаюсь только на данные, которые сам могу проверить. Разница только в подходе, результат — практически идентичный (RBL не сильно эффективней грейлистинга). Именно об этом весь пост. Как бы вы назвали принятие решения о судьбе чего-то крайне важного на основе неаргументированного мнения левой организации, про работу которой вам ничего неизвестно и которая неоднократно замечена в совершении ошибок? Я кроме как дилетантством и некомпетентностью назвать это не могу.
Вообще говоря, я присматривался к отправке спама — и боты на виндах спам посылают дважды. Именно для прохода через грейлистинг.
А грейлистинг, как я уже написал, несовместим с некоторыми постфиксами — у вас могут быть проблемы с отправкой.
А грейлистинг, как я уже написал, несовместим с некоторыми постфиксами — у вас могут быть проблемы с отправкой.
С некоторыми. Старыми, как мир. И проблемы опять же будут не у меня, а у принимающей стороны. Но я с такими никогда не сталкивался. Зато вот с проблемами отправки из-за RBL сталкивался уже неединожды. Поэтому грейлистинг очевидно лучше RBL.
И таки да, его проходят некоторые спамботы. Это, правда, ничего не меняет. по совокупности всех критериев мой сервер пропускает буквально несколько спамписем в день. Что для обслуживаемой организации очень и очень хорошо. Раньше у них стоял Exchange, в котором единственной проверкой был запрос к спамхаусу. Спама было просто до черта.
И таки да, его проходят некоторые спамботы. Это, правда, ничего не меняет. по совокупности всех критериев мой сервер пропускает буквально несколько спамписем в день. Что для обслуживаемой организации очень и очень хорошо. Раньше у них стоял Exchange, в котором единственной проверкой был запрос к спамхаусу. Спама было просто до черта.
"
отказать тем, у кого helo не ресолвится в IP
разрешить отправку своим сетям
отказать в приёме с нашими адресами поле FROM
отказать в приёме с посторонними адресами в поле TO
отказать в приёме от узлов с HELO без FQDN
отказать в приёме писем на несуществующие адреса
" — неправильный порядок + дублирование
отказать тем, у кого helo не ресолвится в IP
разрешить отправку своим сетям
отказать в приёме с нашими адресами поле FROM
отказать в приёме с посторонними адресами в поле TO
отказать в приёме от узлов с HELO без FQDN
отказать в приёме писем на несуществующие адреса
" — неправильный порядок + дублирование
Почему и где?
«отказать тем, у кого helo не ресолвится в IP» == «отказать в приёме от узлов с HELO без FQDN»
«отказать тем, у кого helo не ресолвится в IP» перед «разрешить отправку своим сетям» блокирует windows в своих сетях
«отказать в приёме с посторонними адресами в поле TO» == «отказать в приёме писем на несуществующие адреса»
где «разрешить слать авторизованным клиентам»?
«принять почту от узлов, у которых SFP настроен на ограниченное количество узлов и прошёл проверку» думаю должно быть бесполезно по большей части ибо нет ничего проще чем добавить SPF к своему домену и слать спам с него
«отказать тем, у кого helo не ресолвится в IP» перед «разрешить отправку своим сетям» блокирует windows в своих сетях
«отказать в приёме с посторонними адресами в поле TO» == «отказать в приёме писем на несуществующие адреса»
где «разрешить слать авторизованным клиентам»?
«принять почту от узлов, у которых SFP настроен на ограниченное количество узлов и прошёл проверку» думаю должно быть бесполезно по большей части ибо нет ничего проще чем добавить SPF к своему домену и слать спам с него
>Причина? Разумеется, mailman.
>Используйте адекватные менеджеры рассылок
Какие, например?
>Используйте адекватные менеджеры рассылок
Какие, например?
Грейлистинг рулит — у меня связка qmail + spamdyke. Минимум спама…
грейлистинг не совместим с некоторыми постфиксами, у которых проверка существования отправителя.
qmail убожество — дизайн, патчи, логи.
Особенно убивает, это когда на каком-то почтовом сервере настроен блеклист с ПЛАТНЫМ делистингом, и вот хоть тресни, нужно туда что-нибудь отправить.
За несколько лет был лишь ОДИН случай, когда удаленная сторона пожаловалась на якобы несправедливую блокировку BL, причем менеджер позвонила сама и настаивала на немедленном разрешении проблемы.
После внесения в белый список эта самая сторона начала усиленную рассылку спама по всем известным ей адресам в компании и по просьбам сотрудников была отправлена в уже навечный бан.
После внесения в белый список эта самая сторона начала усиленную рассылку спама по всем известным ей адресам в компании и по просьбам сотрудников была отправлена в уже навечный бан.
Ну конечно, вам-то не звонят. Я тоже никому не звоню, когда меня блокируют, мне чё, делать нечего? Я просто удаляю себя из блоклистов и всё. Вот только я утверждаю, что в блоклисты попадают совершенно благонадёжные хосты. Чему, кстати, есть подтверждения даже на хабре, см. например топики про Агаву и spamhaus. Посему использования блоклистов неприемлемо.
А я всегда пишу. У меня даже типовой шаблончик есть. Потому что это проблема совместная.
Да нет в этом мире стопроцентно надежных методов. Каждый имеет какие-нибудь недостатки и связанные с ними риски. Даже при правильно настроенном сервере хотя бы раз в месяц имеем проблемы с получением писем от серверов, настроенных криворукими людьми.
Если ваш бизнес действительно зависит от получения одного письма, которое никогда и ни за что вам не продублируют, тогда конечно придется поотключать все, что только можно. Но мы, например, больше получаем от BL пользы, чем вреда.
Если ваш бизнес действительно зависит от получения одного письма, которое никогда и ни за что вам не продублируют, тогда конечно придется поотключать все, что только можно. Но мы, например, больше получаем от BL пользы, чем вреда.
Нет ничего совершенного. Но если ВЫ включили проверку RBL, то виноваты в срыве приёма корреспонденции исключительно ВЫ, а не отправитель, который случайно попал в RBL. Если допустим я включаю у себя грейлистинг, то виноват в срыве приёма почты оказывается админ отправляющей стороны, потому что он неправильно настроил сервер. Важен не сам факт наличия ложных срабатываний, важно что ВЫ, как администратор почтового сервера, берёте на себя полную ответственность за срыв почтового обмена, прекрасно осознавая, что при ваших настройках он неизбежен, чтобы отправляющая сторона не делала. Вот это — неправильно.
Ага. А если вы отказались принять «миллионный контракт» с хоста, у которого кривой HELO? (например, не являющийся FQDN, что-то вида myserver)?
Ведь это ваши действия и (патетичным голосом) исключительно вы виноваты в срыве приёма миллионного контракта из-за тупой придирки к никому не важному полю.
Ведь это ваши действия и (патетичным голосом) исключительно вы виноваты в срыве приёма миллионного контракта из-за тупой придирки к никому не важному полю.
Нет, виноват администратор отправляющего сервера. Я не полагаюсь на непроверенные данные левых контор вроде спамхауса, я смотрю только на то, что можно проверить самостоятельно. Если админ отправляющей стороны идиот — это его проблемы, а не мои. Разница только в подходе. У меня жёсткие правила, но я не использую непроверенных данных. Вы — используете, причём прекрасно осознавая, что они зачастую ложные.
А если письмо не придёт вовремя из-за ваших жёстких правил, хотя отправляющая сторона полностью выполняет RFC?
Хм, а как такое возможно? По поводу грейлистинга все мои пользователи предупреждены и поставлены перед выбором — либо он, либо спам. Кто захочет спам — я ему грейлистинг отключу)) Пока никто не захотел.
Ровно так же пользователи ставятся перед выборами с RBL.
Да. С точки зрения ваших пользователей ситуация аналогична. С точки зрения же взаимодействия почтовых серверов — нет. Вы ставите себя выше администратора отправляющих серверов без каких-либо причин и без аргументов. Это элементарный вопрос что такое хорошо, а что такое плохо.
Как это без агрументов? У меня чётко написано куда писать, если проблемы. У вас же просто требование «пробуй ещё раз» (и ни слова про тот же самый IP).
Обижаете. У меня тоже совершенно чётко написано, что отклонено про причине greylisted.
Собственно, к доказательству о грейлистинге: за последний четверг у меня было 603904 reject'а (в обе стороны при этом прошло около 17к писем).
grep reject mail.log.1|wc -l
603904
grep reject mail.log.1|grep "\([[:digit:]]\{1,4\}\.\)\{3\}[[:digit:]]\{1,3\}"|sort -u|wc -l
433241
Итого — реджектнуто около 200 тысяч адресов, которые пытались доставить спам за сутки ДВАЖДЫ.
grep reject mail.log.1|wc -l
603904
grep reject mail.log.1|grep "\([[:digit:]]\{1,4\}\.\)\{3\}[[:digit:]]\{1,3\}"|sort -u|wc -l
433241
Итого — реджектнуто около 200 тысяч адресов, которые пытались доставить спам за сутки ДВАЖДЫ.
пардон, не то спописастил, grep -o.
Да, таки расскажите, как вы боритесь со спамом. А то складывается ощущение, что все вокруг злодеи, а вы небожитель, которого спам не касается.
Даю установку: 200 емейлов из вашей конторы попали в целевую базу рассылки, идёт миллион попыток в день отправки спама. FQDN правильный, однако отправка идёт с адерсов вида 333-333-333-333-dynamic.mydsl.foo по этим адресам.
Как они будут отфильтровываться?
Даю установку: 200 емейлов из вашей конторы попали в целевую базу рассылки, идёт миллион попыток в день отправки спама. FQDN правильный, однако отправка идёт с адерсов вида 333-333-333-333-dynamic.mydsl.foo по этим адресам.
Как они будут отфильтровываться?
Одно неполученное сообщение — это не срыв почтового обмена. Это часть неизбежных издержек, связанных с неидеальностью нашего мира. А администратор, как вам уже говорили выше, не может гарантировать 100% доставки писем (строго говоря, на 100% никто и ничего гарантировать не может). Есть некий предел, за которым уже можно говорить о срыве обмена. Мы от этого предела далеки.
Ну вот представьте, ваш контрагент отправил вам условия контракта на 100500 миллионов и ждет, что в течение двух минут получит от вас ответ, то есть задержка в этом случае фактически равна отсутствию письма. Грейлистинг задержал письмо, контрагент-истеричка рыдает и не берет трубку. Это что, срыв почтового обмена, а админу уже можно рубить голову?
Ну вот представьте, ваш контрагент отправил вам условия контракта на 100500 миллионов и ждет, что в течение двух минут получит от вас ответ, то есть задержка в этом случае фактически равна отсутствию письма. Грейлистинг задержал письмо, контрагент-истеричка рыдает и не берет трубку. Это что, срыв почтового обмена, а админу уже можно рубить голову?
Я уже ответил не один раз. Вы полагаетесь на мнение левых чуваков, про которых доподлинно известно, что они ошибаются. Никто не может гарантировать 100% приёма всех нужных писем, но я могу хотя бы сказать критерии, по которым мой сервер отсеивает письма. Совершенно обычные критерии, которые согласуются с общепринятыми стандартами. Вы — не можете, потому что вы ничего не знаете про механизмы работы всяких спамхаусов. Это вот и есть классическое дилетантство.
Да бросьте вы. Достаточно внимательно посмотреть на логи почтового сервера, чтобы понять, что BL отбивают огромное количество спама. Да, мне не совсем известно, как работает конкретный сервис, но результат его работы меня устраивает.
Вы, например, тоже не знаете на 100%, как работает процессор вашего сервера, однако пользуетесь им, доверяя его производителю. Это что, тоже классическое дилетантство?
Вы, например, тоже не знаете на 100%, как работает процессор вашего сервера, однако пользуетесь им, доверяя его производителю. Это что, тоже классическое дилетантство?
Вас устраивает — меня нет. Это конечно в основном из-за того, что я нахожусь обычно с другой стороны от подобных вам и из-за таких вот идиотских сервисов, как спамхаус, не уходит почта от моих пользователей. Но в целом ситуацию это не меняет. У меня включён warn if reject на BL спамхауса самым последним правилом (после грейлистинга и всех других проверок). Я не вижу, чем бы мне помогло реальное включение RBL, спамхаус не отсеивает практически ничего из того, что прошло остальные проверки. И процессоры тут ни при чём. Вы доверяете мнению конторы, которая неоднократно замечена в откровенных ошибках. Интересно, что будет, если кто-то скажет вашему начальнику, что письмо не дошло из-за того, что системный администратор отсеивает письма на основе мнения совершенно левой конторы, которая с завидной регулярностью совершает ошибки?
Мои IP дважды были в блеклистах — и оба раза заслуженно. Один раз я забыл закрыть NAT для домашних диалап-пользователей (обычные ботнеты), второй раз «умный» менеджер решил поработать спам-ботом и собрал тематические емейлы с сайтов руками и сделал рассылку мимо mailman'а.
Проблема решалась в течение единиц часов, в худшем случае в течение трёх дней.
У спамхауса вполне описаны критерии разных списков. Если вы отправили письмо в spamtrap — это признак того, что вы отправляли спам. Не вы, так ваш сотрудник.
Проблема решалась в течение единиц часов, в худшем случае в течение трёх дней.
У спамхауса вполне описаны критерии разных списков. Если вы отправили письмо в spamtrap — это признак того, что вы отправляли спам. Не вы, так ваш сотрудник.
Если вы хотите кидаться словами «кто юзает RBL — тот ламер» (именно так я трактую ваши слова «дилетантство», то вот вам простенькая схема, в которой грейлистинг сосёт, а админ нервно чешет репу, объясняя директору где его бесценное письмо на миллионный контракт:
Предположим, у отправляющей стороны сервер находится за NAT'ом с пулом адресов для DNAT'а. Если отправляющая сторона будет каждый раз выходить через новый IP, то письмо не будет принято из-за грейлистинга, пока снова не попадётся тот же самый IP. С учётом размеров пула (допустим, 29 адресов) и переотправки в час письмо не придёт в течение полутора рабочих дней.
Прав ли отправляющий? Прав, RFC никаким образом не предписывают использовать один и тот же IP каждый раз. Прав ли принимающий? Не уверен, процедура «временного отказа в приёме с просьбой подойти с ТОГО ЖЕ САМОГО IP» не предусмотрена RFC.
Итого — обзываете ламерами, идиотизмом, однако сами тоже принимаете не всю соответствующую RFC корреспонденцию.
Вежливее и аккуратнее надо быть, особенно при обсуждении профессиональных вопросов.
Предположим, у отправляющей стороны сервер находится за NAT'ом с пулом адресов для DNAT'а. Если отправляющая сторона будет каждый раз выходить через новый IP, то письмо не будет принято из-за грейлистинга, пока снова не попадётся тот же самый IP. С учётом размеров пула (допустим, 29 адресов) и переотправки в час письмо не придёт в течение полутора рабочих дней.
Прав ли отправляющий? Прав, RFC никаким образом не предписывают использовать один и тот же IP каждый раз. Прав ли принимающий? Не уверен, процедура «временного отказа в приёме с просьбой подойти с ТОГО ЖЕ САМОГО IP» не предусмотрена RFC.
Итого — обзываете ламерами, идиотизмом, однако сами тоже принимаете не всю соответствующую RFC корреспонденцию.
Вежливее и аккуратнее надо быть, особенно при обсуждении профессиональных вопросов.
Не согласен. И вот почему: если вы внимательно посмотрите на свои логи, то увидите, что минимум 25% хостов используют грейлистинг. Это общепринятая практика, проблемы с которой, в отличие от RBL, зависят исключительно от отправляющей стороны. Отправка с разных IP одного и того же письма — это уже просто некомпетентность администратора, который видимо никогда не слышал про грейлистинг. В чём-то вы правы, это не регламентируется RFC, однако при использовании грейлистинга все участники находятся в одинаков положении и сама эта технология полностью прозрачна. При использовании RBL вы, как принимающая сторона, выдвигаете стороне отправляющей абсурдные условия, не предоставляя чёткого алгоритма их прохождения. Это просто подло. С точки зрения профессионального подхода это вопрос элементарной этики. Вы открыто обвиняете отправляющую сторону в рассылке спама на основе непроверенных данных левых контор — это разве нормально??
Ну видите, как вы вдруг заговорили. Внезапно, «это не по RFC, но общепринято». RBL ровно так же общеприняты и ровно так же укладываются в RFC с оговорками (мы отклоняем приём писем из-за подозрений в рассылке спама — ровно так же вы, из-за подозрений в отправке спама задерживаете всех новых клиентов).
Лично я один раз наблюдал, когда из-за грейлистинга вполне себе рабочая конфигурация с primary outgoing mailserver secondaries outgoing mail server не работала из-за того, что кто-то выдвигал идиотские требования «один и тот же IP каждый раз» (в той конфигурации был первичный сервер, который пробовал один раз и по неуспеху тут же перекладывал письмо на NFS-шару, откуда другие почтовые сервера пробовали переотправить письмо с минимальным приоритетом).
Почему из-за левой пятки правой ноги админа почта должна задерживаться? Более того, админу отправляющей стороны придётся каждый раз руками изучать проблему — а есть вероятность, что её даже поймать не удастся с первого раза, так как грейлистинг срабатывает только в первый раз. Итого: трудноуловимые глюки с периодическим неприёмом почты.
Грейлистинг не хуже и не лучше RBL, это одна из техник за пределами RFC для борьбы со спамом. Выходя за пределы RFC он становится на скользкий путь предположений «все так делают и вроде проблем нет». Но в случае проблемы виноват будет тот, кто вышел за пределы RFC, а не тот, кто сделал придуманной конфигурации «неудобно».
Лично я один раз наблюдал, когда из-за грейлистинга вполне себе рабочая конфигурация с primary outgoing mailserver secondaries outgoing mail server не работала из-за того, что кто-то выдвигал идиотские требования «один и тот же IP каждый раз» (в той конфигурации был первичный сервер, который пробовал один раз и по неуспеху тут же перекладывал письмо на NFS-шару, откуда другие почтовые сервера пробовали переотправить письмо с минимальным приоритетом).
Почему из-за левой пятки правой ноги админа почта должна задерживаться? Более того, админу отправляющей стороны придётся каждый раз руками изучать проблему — а есть вероятность, что её даже поймать не удастся с первого раза, так как грейлистинг срабатывает только в первый раз. Итого: трудноуловимые глюки с периодическим неприёмом почты.
Грейлистинг не хуже и не лучше RBL, это одна из техник за пределами RFC для борьбы со спамом. Выходя за пределы RFC он становится на скользкий путь предположений «все так делают и вроде проблем нет». Но в случае проблемы виноват будет тот, кто вышел за пределы RFC, а не тот, кто сделал придуманной конфигурации «неудобно».
С этим согласен. Но сути поста не меняет. Применять RBL категорически нельзя по причинам абсолютной непрозрачности данной технологии. Грейлистинг — это только как альтернатива, не лучшая, согласен, но хотя бы в случае использования грейлистинга вы объявляете простые правила, которым очень легко следовать. В случае RBL вы вообще ни во что не ставите других администраторов почты, по типу у меня всё работает, а на вас мне плевать, разбирайтесь со всякими спамхаусами. RBL и грейлистниг по своему отношению к процессу обмена почты диаметрально противоположные технологии, приводящие при этом к примерно одинаковому результату. RBL — это шаг от открытых стандартов в сторону субъективных закрытых технологий. Поддерживать это — абсурд. Вы в жизни не сможете привести мне конфигурацию сервера, которая бы гарантировала бы непопадание в спамлисты. Даже если накрутить абсурдных рестрикшенов, никто не помешает спамхаусу заблокировать всю подсеть провайдера, прецедентов была уже масса. Эта технология изначально порочна и в принципе неспособна обеспечивать необходимую прозрачность обмена почтой. Вот почему все так упорно пытаются не защищать RBL, отвечая на обвинения в их адрес, а уходить в сторону и искать какие-то проблемы лично у меня или у того же грейлистинга. Грейлистинг — это отдельный разговор, никакого отношения к RBL по сути не имеющий, я лишь предлагаю его как альтернативу, поскольку раз уж вам настолько плевать на других администраторв почты, что вы используете RBL, то уж использование грейлистинга не должно вызывать у вас каких-то неудобств.
Правила у вменяемых RBL вполне вменяемы. Попался в spamtraps? Сиди в RBL.
… кажется, я знаю, что вам не нравится. zen.spamhaus.org — это да, это зло. Ну так это вопрос в том, кто его юзает.
В моей конфигурации я вам назвал условие непопадания в RBL: SPF с ограниченным списком IP, прошедший проверку.
Что не так?
RBL применяется к лентяям.
… кажется, я знаю, что вам не нравится. zen.spamhaus.org — это да, это зло. Ну так это вопрос в том, кто его юзает.
В моей конфигурации я вам назвал условие непопадания в RBL: SPF с ограниченным списком IP, прошедший проверку.
Что не так?
RBL применяется к лентяям.
RBL применяется ко всем. Попасть в spamtraps элементарно и спам при этом рассылать совершенно необязательно.
В вашей — возможно. У меня SPF прописан (+mx ~all), к вам значит дойдёт. Но проблемы RBL это опять же не решает. От меня дойдёт, от другого админа, у которого настроено всё верно — нет. Хотя он в этом виноват не будет нисколько.
В вашей — возможно. У меня SPF прописан (+mx ~all), к вам значит дойдёт. Но проблемы RBL это опять же не решает. От меня дойдёт, от другого админа, у которого настроено всё верно — нет. Хотя он в этом виноват не будет нисколько.
То есть мы из глобального и абсолютного зла приходим к очень тонкому и осторожному выводу «неправильное применение RBL чревато проблемами с хождением почты».
Ну так мы можем то же самое сказать про любую другую технологию. «Неправильное применение почтового сервера чревато превращением в открытый релей», «неправильное применение паяльника чревато проблемами с дефекацией» и т.д.
Основное моё возмущение — в оголтелости утверждения и обвинения тех, кто пользуется RBL в непрофессионализме.
Ну так мы можем то же самое сказать про любую другую технологию. «Неправильное применение почтового сервера чревато превращением в открытый релей», «неправильное применение паяльника чревато проблемами с дефекацией» и т.д.
Основное моё возмущение — в оголтелости утверждения и обвинения тех, кто пользуется RBL в непрофессионализме.
Почему неправильное? В вашем случае любой хост имеет все шансы до вас недостучаться, причём не по его вине. SPF во многих случаях не поможет, даже если администратор её настроит. Простейший пример — переадресующий почтовый домен. Я совершенно не собираюсь отказываться от тезиса неприменимости RBL ни при каких условиях, кроме, разве что, начисления дополнительных очков в рейтинговой системе.
По поводу обвинения в непрофессионализме — я возможно погорячился, за мной вообще водится стремление к гиперболизации. Однако с другой стороны для меня лично то, что RBL не обеспечивают никакой прозрачности и не предоставляют никаких гарантий ни для отправляющей, ни для принимающей стороны, является вполне себе веским аргументом для того, чтобы поставить под сомнение квалификацию специалиста, их применяющего. Возможно не утверждать сразу, что он дилетант в целом, но как минимум утверждать, что использовать RBL — это непрофессионально. Я сам часто поступаю не так, как надо, а так, как проще, ибо стремление к совершенству не доводит ни до чего хорошего, обычно надо работать, а не идеалы строить. Но при этом используемые мной хаки не становятся проф. инструментами, равно как и RBL, кто бы их не использовал, всё равно остаются порочной непрофессиональной технологией.
По поводу обвинения в непрофессионализме — я возможно погорячился, за мной вообще водится стремление к гиперболизации. Однако с другой стороны для меня лично то, что RBL не обеспечивают никакой прозрачности и не предоставляют никаких гарантий ни для отправляющей, ни для принимающей стороны, является вполне себе веским аргументом для того, чтобы поставить под сомнение квалификацию специалиста, их применяющего. Возможно не утверждать сразу, что он дилетант в целом, но как минимум утверждать, что использовать RBL — это непрофессионально. Я сам часто поступаю не так, как надо, а так, как проще, ибо стремление к совершенству не доводит ни до чего хорошего, обычно надо работать, а не идеалы строить. Но при этом используемые мной хаки не становятся проф. инструментами, равно как и RBL, кто бы их не использовал, всё равно остаются порочной непрофессиональной технологией.
В корне не соглашусь с заголовком «Почему блоклисты — это дилетантство»
Это не верно. А верно то, что блеклисты являются хорошим дополнительным методом фильтрации спама.
Кто вам мешает правильно использовать блеклисты? Как это правильно? Ну например как делаю это я.
Схема следующая. Сообщение проходит определенные стадии проверки — HELO, соответствие DNS. Всего у меня штук восемь проверок. За каждую проверку начисляется определенное количество спам очков. Не соответствует HELO обратной зоне? Получи 30 очков. Нет обратной записи для хоста? Еще 30. Количество получателей более 4? Еще 20 очков. Ну и еще с пяток проверок.
Далее проверяем белые листы — это те домены куда наши юзера отправляли почту. Если есть в белых листах, то обнуляем спам очки.
Далее идут нелюбимые вами DNSBL. Если у письма нет очков, то проверка не осуществляется. Если больше 0, то идет в cbl.abuseat.org. Если есть совпадение, то начисляется 30 очков. Далее если у письма более 30 очков, то идет sbl-xbl.spamhaus.org. Если после второго DNSBL более 60 очков то идем проверяемся в третий — dul.dnsbl.sorbs.net. При этом письмо не блокируется при наличии домена в DNSBL, а лишь начисляются спам очки.
Далее выставляем задержку на принятие сообщения в зависимости от набранных очков. Некоторые отваливаются, так как не могут подождать пол минуты :) Далее проверяем тело письма — китайские символы, расширения файлов, вирусы, синтаксис заголовков. Тут можно либо рубить сообщения, либо опять таки начислять очки.
Перед маршрутизацией сообщений рубим тупых спамеров. Это те которые набрали большое количество очков (у меня более 70). Далее в процессе маршрутизации направляем письма со спамом на спец ящик (70-60 очков). По желанию сомнительные письма можно складывать в специальную папку в почтовом ящике юзера. Но это актуально при IMAP. Если письмо набрало менее 60 очков, то с большой долей вероятности это нормальное письмо. Хотя признаюсь иногда проскакивает и спам.
К чему это я так подробно описал процесс получения сообщения? Да к тому, чтобы показать как можно правильно использовать DNSBL — как прекрасное дополнительно средство фильтрации спама.
И да, в качестве MTA у меня exim.
Это не верно. А верно то, что блеклисты являются хорошим дополнительным методом фильтрации спама.
Кто вам мешает правильно использовать блеклисты? Как это правильно? Ну например как делаю это я.
Схема следующая. Сообщение проходит определенные стадии проверки — HELO, соответствие DNS. Всего у меня штук восемь проверок. За каждую проверку начисляется определенное количество спам очков. Не соответствует HELO обратной зоне? Получи 30 очков. Нет обратной записи для хоста? Еще 30. Количество получателей более 4? Еще 20 очков. Ну и еще с пяток проверок.
Далее проверяем белые листы — это те домены куда наши юзера отправляли почту. Если есть в белых листах, то обнуляем спам очки.
Далее идут нелюбимые вами DNSBL. Если у письма нет очков, то проверка не осуществляется. Если больше 0, то идет в cbl.abuseat.org. Если есть совпадение, то начисляется 30 очков. Далее если у письма более 30 очков, то идет sbl-xbl.spamhaus.org. Если после второго DNSBL более 60 очков то идем проверяемся в третий — dul.dnsbl.sorbs.net. При этом письмо не блокируется при наличии домена в DNSBL, а лишь начисляются спам очки.
Далее выставляем задержку на принятие сообщения в зависимости от набранных очков. Некоторые отваливаются, так как не могут подождать пол минуты :) Далее проверяем тело письма — китайские символы, расширения файлов, вирусы, синтаксис заголовков. Тут можно либо рубить сообщения, либо опять таки начислять очки.
Перед маршрутизацией сообщений рубим тупых спамеров. Это те которые набрали большое количество очков (у меня более 70). Далее в процессе маршрутизации направляем письма со спамом на спец ящик (70-60 очков). По желанию сомнительные письма можно складывать в специальную папку в почтовом ящике юзера. Но это актуально при IMAP. Если письмо набрало менее 60 очков, то с большой долей вероятности это нормальное письмо. Хотя признаюсь иногда проскакивает и спам.
К чему это я так подробно описал процесс получения сообщения? Да к тому, чтобы показать как можно правильно использовать DNSBL — как прекрасное дополнительно средство фильтрации спама.
И да, в качестве MTA у меня exim.
Ключевое слово — дополнительное. Ни в коем случае не основное средство фильтрации спама. Как дополнительное в рейтинговой системе — пожалуйста. Но полагаться только на RBL на любом этапе проверки письма ни в коем случае нельзя.
из заголовка и текста топика не сделаешь такой вывод. Рекомендую таки сбавить тон топика и заголовка. Типа «Давайте жить дружноиспользовать RBL правильно! А?» И аццкий, полезный топик, про начисление мультиисточникового рейтинга в процессе принятия решения о принадлежности письма к СПАМу. Вот это будет годная хабрастатья. Тем более, что в комментах вам уже столько накидали текста )
а там, глядишь, статья обретет популярность, разойдётся по интернетам и всё меньше будет тупых админов, которые банят по первому флажку от спамхауза.
Я лучше через пару месяцев напишу статью «Как правильно использовать RBL и как их использовать нельзя». Ну или мб кто другой напишет. Эта статья задумывалась с целью запугивания очевидными недостатками RBL, дабы народ призадумался о недопустимости их «чистого» использования. Не прокатило. Жалко конечно, но весьма прогнозируемо.
Не прогнозируемо. А очевидно до смешного. Любые безаппеляционные выкрики и безкомпромиссные лозунги просто обречены на штыки. Даже если верны на 101%. А сабжевые и на 93% не тянут. Тактика «террора», то бишь, запугивания, неэффективна без рычагов давления, т.е. заложников, как правило. Без рычагов эта тактика преаращается в обыкновенную истерику, коей любят пользоваться невоспитанные дети и избалованные дамы. У дам, кстати, какой-никакой, а рычаг есть )
Ну не знаю. Я привык общаться с людьми, которые адекватно воспринимают очевидные факты. В общем-то для меня, равно как и для всех, с кем я общаюсь по работе в реальной жизни, данная статья носит слишком мягкий характер. Хотя с вами согласен.
Проблема в том, что факт не очевиден. И доказать это почтенной публике вы не смогли. Да и сами засомневались.
Сравните два заголовка:
«Те, кто использует RBL — мудаки.»
и
«Те, кто ТАК использует RBL — мудаки.»
Всего одна деталь, а разница — колоссальна. Не задеты те, кто правильно готовит. Вас бы разцеловали и аццки поддержали бы все. Ну, те, кто не назвал бы К.О. ) Бытовая психология иосновы риторики, мать их так.
Сравните два заголовка:
«Те, кто использует RBL — мудаки.»
и
«Те, кто ТАК использует RBL — мудаки.»
Всего одна деталь, а разница — колоссальна. Не задеты те, кто правильно готовит. Вас бы разцеловали и аццки поддержали бы все. Ну, те, кто не назвал бы К.О. ) Бытовая психология иосновы риторики, мать их так.
Блоклистов только популярных существует с десяток, и в какой мы интересно попали и что нам теперь делать?
Пойти, например, сюда, вбить свой IP и увидеть, в какой именно. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему блоклисты — это дилетантство