Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 149
Проблема в том, что вы описали сферического коня в вакууме. В рунете слишком много мелких хостингов с криво (дефолтно) настроенными почтовыми сервисами. Поэтому эти сервера, или создают возможность рассылки (точнее доставки) спама пользователям, или определяются «правильными» серверами как спамные.
Если бы во всей сети все было настроено правильно, то таких проблем в большинстве своем, можно было бы избежать.
Если бы во всей сети все было настроено правильно, то таких проблем в большинстве своем, можно было бы избежать.
Поэтому в своих скриптах я отправляю рассылки через смтп с авторизацией, а не через дефолтный сендмэйл сервера.
а Вас не берёт злость, что из-за того, что у большинства всё криво настроено, приходится и самому делать всё неправильно? )
Проблема в том, что так или иначе любая из представленных опций у кого-то включена на почтовом сервере. А значит при любом раскладе письма с кривых хостингов до кого-то не доходят. Не вижу причин принимать их у себя.
По собственным наблюдениям по поводу PTR: когда я забыл её прописать, 20% от меня перестали доходить. А это чуть ли ни самое жёсткое ограничение из представленных.
По собственным наблюдениям по поводу PTR: когда я забыл её прописать, 20% от меня перестали доходить. А это чуть ли ни самое жёсткое ограничение из представленных.
Не видите проблем? Когда вас на ковер позовет генеральный, и скажет а чего у нас проблема в почтовом сообщение с XYZ компани. Вы начнете ему втирать про ну у них не правильно настроен почтовый сервер… Думаю он вас пошлет в XYZ, ему нужно чтобы почта работала без «сбоев» c клиентами. Да, это всё блядский ынторпризе.
кстати, такие вопросы получалось довольно успешно решать отправкой письма или звонком технарям. люди охотно общаются если аргументация убедительная и вы фактически приносите им решение на блюдечке.
А ещё этот генеральный захочет на почту пароль 12345, и вы ему тоже не сможете отказать… Если действовать по шаблону, вами описанному.
Можно аргументировать генеральному, что снижение строгости фильтрации писем зановесит спамом сервер и он вообще работать не сможет… Совсем… Генеральные очень быстро смягчаются, когда им ещё худшую альтернативу поставишь.
Можно аргументировать генеральному, что снижение строгости фильтрации писем зановесит спамом сервер и он вообще работать не сможет… Совсем… Генеральные очень быстро смягчаются, когда им ещё худшую альтернативу поставишь.
это ИХ проблемы. spf уже лет пять и никто толком не настроил у себя. пока не будут резать — люди не пошевелятся
Еще есть довольно полезная техника, когда сервер ждет некоторое время при приеме почты, для слабо нагруженных хостов бывает довольно удобно.
это и есть грейлистинг
При такой настройке обычно достаточно 3-4 звонков от важных клиентов, которые не могут прислать письмо, потому что «у них отправляющий сервер плохо настроен» или письмо от вашего CEO не доходит до адресата, потому что SPF отрезал сервера «черной ягоды»… И все сразу становится на свои места. Покупаются дорогие фильтры и настраиваются DNSBL…
Это я к тому, что 1 false positive может вам стоить куда дороже, чем тысяча пропущенных спам-писем.
Это я к тому, что 1 false positive может вам стоить куда дороже, чем тысяча пропущенных спам-писем.
Да, крики начальства:
«Почта — наш основной инструмент для работы, а я не могу получить письмо от нашего клиента! Что это такое?! Разберись!».
А потом смотришь, письмо, конечно, в спаме и причем за дело, но сути дела это не меняет.
Спама много — проблема, несколько писем в месяц режется не тех — еще большая проблема.
«Почта — наш основной инструмент для работы, а я не могу получить письмо от нашего клиента! Что это такое?! Разберись!».
А потом смотришь, письмо, конечно, в спаме и причем за дело, но сути дела это не меняет.
Спама много — проблема, несколько писем в месяц режется не тех — еще большая проблема.
Я себе сильно упростил жизнь отдав почту в гугл. Хотя тоже бывают косяки, но реже. И спам режется хорошо.
Я после всего этого тоже переехал на гугл.
Но косяки остались, реже конечно, но все равно пару раз в месяц что-то не доходит.
Но косяки остались, реже конечно, но все равно пару раз в месяц что-то не доходит.
У Google тоже часто бывают false positives. Примеры, которые стоили мне денег или нервов:
— ответы службы поддержки Yota
— DHL tracking number
— уведомления хостинга о непрошедшем платеже из-за истечения срока действия карты
— ответы службы поддержки Yota
— DHL tracking number
— уведомления хостинга о непрошедшем платеже из-за истечения срока действия карты
это не письма попадают туда за дело, а фильтры слишком строгие. письмо от клиента не может быть спамом по умолчанию, а в крупных компаниях часто все основные коммуникации идут именно через почту и потеряное письмо просто недоупстимо.
Вы не правы, если на тысячу нормальных пропущенных писем приходится все лишь пара, которую фильтр срезал, говорит лишь о том, что письмо действительно очень похоже на спам по нескольким параметрам. И дело тут далеко не фильтре, а раз в письме. Просто приходится таких отправителей добавлять в белый список, благо такие случаи единичны.
ну да, а потом писать инцидент репорт и составлять RCA для клиента на тему того почему его запрос не обработали вовремя/корректно.
Мы с вами говорим про разные ситуации, в вашем случае это более критично, т.к. у вас, судя по всему, большое количество новых обращений от клиентов, а в моей фирме переписка, в основном, ведется с уже устоявшимися клиентами и партнерами.
В переписке с устоявшимися клиентами можно обойтись и без спам-фильтра.
>> И дело тут далеко не фильтре, а раз в письме.
Дело как раз в фильтре.
Задача фильтра — не столько отбрасывать спам, как принимать нужное. Не принял нужное письмо — не справился с задачей.
>> И дело тут далеко не фильтре, а раз в письме.
Дело как раз в фильтре.
Задача фильтра — не столько отбрасывать спам, как принимать нужное. Не принял нужное письмо — не справился с задачей.
Ни один спамфильтр не может принять всё. Либо фильтрация спама — либо уверенность в том, что ничего не пропустили. Хотя можно не отбрасывать и складывать в папочку Спам. Это более гуманно, да, но сути не меняет — ложные срабатывания всегда будут.
Конечно не может :)
Я собственно о другом говорю. Мне не ясна логика «фильтр молодец, а письма плохие». Фильтр — это не такая штука, которую надо кормить исключительно полированной корреспонденцией, а инструмент с вполне конкретными задачами.
Тем более часто компании держат почту не на гмэйле, а на частных серверах/хостингах, где настройки могут очень розниться.
Я собственно о другом говорю. Мне не ясна логика «фильтр молодец, а письма плохие». Фильтр — это не такая штука, которую надо кормить исключительно полированной корреспонденцией, а инструмент с вполне конкретными задачами.
Тем более часто компании держат почту не на гмэйле, а на частных серверах/хостингах, где настройки могут очень розниться.
Ну у меня несколько другая логика: при любой ошибке в настройке почтового сервера достаточно большой процент хостов перестанет получать почту от такого сервера. Не вижу причин принимать её у себя — лучше отдетектить проблему и сообщить её администратору сервера, чтобы он исправил.
интересно сравнить со своим первым опытом.
при запуске нового почтового сервера сделал достаточно мягкие ограничения. потом понемногу их усиливал. клиентов, попавших в категорию спама добавлял в белые списки. фактически все криво настроенные, но нужные рассылки оказались там.
политику фильтрации выбрал такую что письма, похожие на спам помечаются как спам, но не удаляются. а большинство спамеров — примерно 90% всего трафика — обламываются на грейлистинге. в итоге нет истеричных жалоб пользователей «мне не пришло письмо», но иногда бывает более мягкое «почему-то мой адресат — спамер».
при запуске нового почтового сервера сделал достаточно мягкие ограничения. потом понемногу их усиливал. клиентов, попавших в категорию спама добавлял в белые списки. фактически все криво настроенные, но нужные рассылки оказались там.
политику фильтрации выбрал такую что письма, похожие на спам помечаются как спам, но не удаляются. а большинство спамеров — примерно 90% всего трафика — обламываются на грейлистинге. в итоге нет истеричных жалоб пользователей «мне не пришло письмо», но иногда бывает более мягкое «почему-то мой адресат — спамер».
Да, не позволяйте на себя кричать начальству. Предложите ему вариантом решения проблемы уволить вас, если он вас считает некомпетентным, отработайте положенных две недели и уходите со спокойной душой. Если начальник так спокойно вас отпустит, значит он полный дебил. А ещё нового админа найти за две недели, вменяемого очень сложно. А ещё, вряд ли он разберётся во всём хозяйстве быстрей чем за два месяца. И после вот такого вот урока, я вас уверяю, с вами будут разговаривать по другому. А ещё, скорей всего, вас попросят вернуться обратно, потому что работа встала.
В сети потому так много спама, что кто-то «разбирается» с проблемой — лишь бы не уволили…
Последнее время набирают обороты закрытые почтовые сети. Как вы думаете почему?..
В сети потому так много спама, что кто-то «разбирается» с проблемой — лишь бы не уволили…
Последнее время набирают обороты закрытые почтовые сети. Как вы думаете почему?..
Вероятность того, что важное письмо придёт с хоста с ненастроенным DNS гораздо ниже, чем вероятность ложного срабатывания DNSBL и контекстного фильтра, ну вот ей-Богу. За полгода только одно (!) письмо видел на всю организацию. Плюс никто не мешает добавить хост, на котором администратор кретин, в вайтлист.
«EHLO timeout = 20» или как там в посфиксе, уже не помню, решает проблему со спамом на 80%
Спамер заинтересован разослать максимальное количество писем за минимальное время и ждать по 20 секунд не будет. Как показывает статистика — рвет сессию на 8-15 секунде. Такое поведение характерно для спам-скриптов и разных утилит заточенных под рассылку спама.
По крайней мере у меня такой метод зарубил 87% спама относительно того объема, который был до введения таймаутов. Естественно более 25-30 сек. ставить не следует, иначе нормальные почтовики подумают, что «Удаленный хост не доступен»
Спамер заинтересован разослать максимальное количество писем за минимальное время и ждать по 20 секунд не будет. Как показывает статистика — рвет сессию на 8-15 секунде. Такое поведение характерно для спам-скриптов и разных утилит заточенных под рассылку спама.
По крайней мере у меня такой метод зарубил 87% спама относительно того объема, который был до введения таймаутов. Естественно более 25-30 сек. ставить не следует, иначе нормальные почтовики подумают, что «Удаленный хост не доступен»
Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
# Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.Нет. Более мягкое ограничение reject_unknown_reverse_client_hostname требует у клиента наличия любого PTR для его IP адреса, более строгое ограничение reject_unknown_client_hostname требует, чтобы IP клиента ресолвился в любое доменное имя, и это доменное имя ресолвилось в IP клиента. Ограничения на «то же имя хоста» нет. Пример проверки клиента: 10.11.1.1 → example.com; example.com → 10.11.1.1; 10.11.1.1 = 10.11.1.1.
[reject_unknown_client_hostname] требует, чтобы IP, с которого совершается соединение, резолвился в имя из HELO, а имя из HELO резолвилось в свою очередь обратно в искомый IP. То есть фактически эта опция требует, чтобы сервер представлялся именно тем именем, под которым он известен в интернете (прописан в DNS).
# HELO заголовок должен в точности совпадать с именем сервера из A и соответствующей PTR записи.Ничего он такого не требует и не должен, см. выше. Имя может быть любым, с HELO не сравнивается. Единственное ограничение на HELO — имя должно иметь любую A или MX запись (reject_unknown_helo_hostname).
Можно спокойно иметь MX mail.example.com, представляться в HELO как sender.example.com, и иметь PTR example.com.
smtpd_reject_unlisted_recipient = yesЭтот параметр установлен по умолчанию, про него можно не писать.
Либо запрещающей опцией, имеющей тот же эффект:Ещё чего. Здесь, видимо, имелось в виду reject_unlisted_recipient.
reject_unlisted_sender
[reject_unauth_destination] превращает Postfix из почтового релея (то есть сервера пересылки) в конечный пункт назначения писем, поэтому используется не часто (т.к. обычно исходящие SMTP серверы совпадают со входящими, а значит вашим пользователям нужна будет возможность посылать через SMTP сервер письма наружу для адресатов, находящихся вне обслуживаемых постфиксом доменов).Ну да, опция, установленная по умолчанию в настройке smtpd_recipient_restrictions, «используется не часто». Чтобы разрешить отсылку писем на чужие адреса, используется либо опция доверенного IP клиента (permit_mynetworks), либо авторизация паролем (permit_sasl_authenticated). Опция же smtpd_recipient_restrictions никуда не убирается, поскольку иначе вы разрешите рассылать через ваш сервер всем (open-relay).
Если включить все ограничения, то письма от почтовых клиентов и крупных почтовых сервисов будут приходить без проблем. Но с различными уведомлениями сайтов, платёжных систем, банков, регистраторов доменов и т.п. начнутся проблемы, поскольку чаще всего их ПО не соответствует стандартам, почтовые сервера и DNS настроены не во всём верно.
Например: многие сервисы используют обратный адрес вида no-reply@example.com, которого не существует. Или добавляют случайный id в обратный адрес: client-62961@example.com. Или неверно кодируют кириллицу в поле From. Откройте любое «Это автоматическое уведомление...» и посмотрите сами.
Одно из решений — включить эти проверки синтаксиса вместе с DNSBL, SPF, DKIM и т.п. в систему, которая выдаёт разные баллы за каждое условие, и в зависимости от результирующей суммы перемещает письмо в соответствующую IMAP папку (Входящие / Подозрительно / Спам) или, при превышении порога, удаляет с уведомлением отправителя.
Не рекомендую использовать проверку обратного адреса (reject_unverified_sender). Достаточно много подводных камней. Самое простое — dead lock. Если два сервера будут с этой опцией, то как они смогут обмениваться почтой?
Вообще стоит почитать www.postfix.org/ADDRESS_VERIFICATION_README.html и особенно раздел Limitations of address verification.
Статья похожа на обзор базовых возможностей, так что проверка обратного адреса тут точно лишняя. На практике поймаете несколько плохо диагностируемых проблем.
Вообще стоит почитать www.postfix.org/ADDRESS_VERIFICATION_README.html и особенно раздел Limitations of address verification.
Статья похожа на обзор базовых возможностей, так что проверка обратного адреса тут точно лишняя. На практике поймаете несколько плохо диагностируемых проблем.
Вот тут я поддержу, очень «не кошерная» опция, учитывая что автор топика описал технику «грейлистинга». При проверки отправителя постфикс наткнувшись на отлуп впадёт в легкий ступор.
Ну от dead lock стоит защита же.
На текущем моём сервере не стоит проверка PTR, но стоит обратный запрос. Почему? Потому что торговая фирма и все важные письма приходят от клиентов, у которых хотелось бы видеть обратный адрес.
На текущем моём сервере не стоит проверка PTR, но стоит обратный запрос. Почему? Потому что торговая фирма и все важные письма приходят от клиентов, у которых хотелось бы видеть обратный адрес.
Защита от dead lock реализована так — всегда принимать на адрес double-bounce@$myorigin. А если поменять address_verify_sender на что-нибудь своё?
Я к тому, что использование этой опции требует изучения подводных камней, а не просто включения. А то получается медвежья услуга.
Если бы статья была «проверка обратного адреса — плюсы и минусы». И в итоге вы показали бы, что для вас плюсов больше, чем минусов… Тогда бы я с вами согласился.
Я к тому, что использование этой опции требует изучения подводных камней, а не просто включения. А то получается медвежья услуга.
Если бы статья была «проверка обратного адреса — плюсы и минусы». И в итоге вы показали бы, что для вас плюсов больше, чем минусов… Тогда бы я с вами согласился.
Для одной средней компании (сотрудников на 150-200) настраивал почтовый сервер, также сопровождаю его дальше.
И вы представить не можете, сколько почты не доходит из-за несоответствия dns->ip ip->dns.
Бывает, так, чтоб письмо пришло мне приходиться опускать все спам защиты и по мониторингу лога ожидать, когда письмо свалится. заново поднимая защиту.
Соглашусь с Vanav, надо вводить систему баллов, и оценивать сумму.
т.к. то что я выше описал получало бы -1 бал, всё остальное у них верно. а порог вхождения -2 балла например от максимума, Тогда все эти письма шли дальше
И вы представить не можете, сколько почты не доходит из-за несоответствия dns->ip ip->dns.
Бывает, так, чтоб письмо пришло мне приходиться опускать все спам защиты и по мониторингу лога ожидать, когда письмо свалится. заново поднимая защиту.
Соглашусь с Vanav, надо вводить систему баллов, и оценивать сумму.
т.к. то что я выше описал получало бы -1 бал, всё остальное у них верно. а порог вхождения -2 балла например от максимума, Тогда все эти письма шли дальше
Я лично в текущий момент этой опцией не пользуюсь, однако по моим наблюдениям PTR проверяют процентов 20 хостов, поэтому присоединиться к ним — милое дело, хотя всё конечно на усмотрение админа.
Используйте spamassassin, что мешает? Там все эти правила есть уже, только нужно чуток поправить кол-во очков для этих правил.
Использую qmail+spamdyke. Spamdyke даёт Greylisting, rDNS, RBL…
Поток спама сократился на до мизера…
Поток спама сократился на до мизера…
RFC1123 позволяет MAILER DAEMONу писать ответы с пустым from адресом. Что будет с такими письмами при вашей настройке?
Отлупятся. Практически все хосты отлупляют некорректный MAIL FROM, так что на эту тему можно даже не париться.
нет нет. Пустой mail from это корректный. А вот хосты, которые его банят — они как раз и есть — некорректные.
Сказать простыми словами — вы подставляете своих пользователей. Они могут просто не узнать, что их письмо застряло.
Сказать простыми словами — вы подставляете своих пользователей. Они могут просто не узнать, что их письмо застряло.
И какой баран в современном мире посылает письма с пустым MAIL FROM? Я не знаю ни одного почтового сервера, который так делает. Однако как я уже писал, совершенно очевидно, что большинство хостов не принимает письма с пустым адресом отправителя.
Request for Comments (RFC) какбы одобряют использование «письма с пустым MAIL FROM» для DSN…
А сервера, увы, отсеивают подобные письма. Причём ЕМНИП даже некоторые крупные почтовые хостинги так делают. И как быть?
… вам решать, следовать ли рекомендациям :)
вопрос фильтрации спама много шире, чем просто пристальное внимание к «HELO, MAIL FROM и RCPT TO»…
вопрос фильтрации спама много шире, чем просто пристальное внимание к «HELO, MAIL FROM и RCPT TO»…
Конечно много шире. Просто начинать надо с пристального внимания)))
А про пропуск писем с пустым mail from первый раз вообще слышу — все всегда рекомендуют блокировать некорректных отправителей, даже оф. документация Postfix это подразумевает.
А про пропуск писем с пустым mail from первый раз вообще слышу — все всегда рекомендуют блокировать некорректных отправителей, даже оф. документация Postfix это подразумевает.
вгляните на RFC 1891 «SMTP Service Extension for Delivery Status Notifications» и RFC 821 «Simple Mail Transfer Protocol»…
я бы, например, не рекомендовал использовать Greylisting в принципе и значение HELO, как аргумент для отказа соединения… но это мое мнение…
я бы, например, не рекомендовал использовать Greylisting в принципе и значение HELO, как аргумент для отказа соединения… но это мое мнение…
Сам не занимался администрированием почты, но всегда было интересно, может ли прижиться метод с автоматической высылкой капчи подозрительному на спам отправителю («если вы хотите, чтобы ваше письмо дошло, ответьте на это письмо и включите в ответ цифры с картинки»)? Ну, понятно, совсем подозрительные письма фильтровать молча, а вот промежуточные с такой проверкой.
reject_non_fqdn_helo_hostname — я бы это убрал, как показывает практика, многие администраторы почтовых серверов игнорируют соглашение об FQDN, к тому же в RFC описана передача hello в формате FQDN как should, а не must! Самый яркий пример в моей практике — Альфа-Банк. Во время сесси проверка делалась по 3м разным доменам — в hello один, в DNS другой, а в адресе отправителя третий — и ни один не был в формате FQDN.
Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны)
… кто вам сказал такую глупость?
Outlook
… что Outlook? :)
Outlook представляется не FQDN, а именем узла. То есть вместо comp1.dom.local посылает просто comp1.
… я, как понял, речь идет о взаимодействии почтовых серверов по протоколу SMTP и, собственно, фильтрации этих взаимодействий… дак, при чем здесь Outlook? он, минуя промежуточные узлы, самостоятельно подключается к почтовым обменникам получателей?
Протокол SMTP не различает серверы и клиенты. Вам приходит запрос с некоего IP — вы его обрабатываете. А узнать, кто сидит на той стороне, сервер или же клиент, нельзя. MS во всех своих инфраструктурных продуктах посылает не FQDN. Поэтому использование Postfix с настройкой reject_non_fqdn_helo_hostname в сетях MS затруднительно. У себя я решил проблему просто — выкинул всё от MS, что имеет отношение к отправке почты через SMTP.
MS во всех своих инфраструктурных продуктах посылает не FQDN.
… очередной вздор. что посылать — на совести администратора
О! Как, где это настроить?? Даже не слышал, чтобы это можно было изменить((
где именно? Exchange — свойства коннекторов отправки…
И это повлияет на клиентские приложения Outlook? А если у меня нету Exchange в домене?))) Что Exchange общается с другими серверами в интернете через FQDN — это я знаю. Я же говорю про внутреннюю доменную инфраструктуру.
… что-то, вы все в кучу сплели… при чем здесь «клиентские приложения Outlook»? здоровая практика — это авторизация клиентов на сервере, а уж для для авторизованных совсем другие правила…
… и зачем вам «внутреннюю доменную инфраструктуру» подвергать фильтрации?
я перестал вас понимать…
… и зачем вам «внутреннюю доменную инфраструктуру» подвергать фильтрации?
я перестал вас понимать…
Так. Есть сервер — Postfix. Есть клиент — Outlook. Клиент хочет передать письмо через сервер и не может. Почему? Потому что сразу после HELO запроса к серверу получает отлуп.
дык, не нужно всех в одну корзину складывать… я в Postfix не силен, и почтовый сервер у нас не один, но, в вашем случае сделал бы или так:
один интерфейс почтового сервера для внутренних клиентов без фильтрации, другой интерфейс для внешних, ессно с фильтрацией.
или вариант с одним интерфейсом но с использованием отличного от 25 порта для внешних подключений, перенаправление на «отличный» порт на совести шлюза…
както так…
один интерфейс почтового сервера для внутренних клиентов без фильтрации, другой интерфейс для внешних, ессно с фильтрацией.
или вариант с одним интерфейсом но с использованием отличного от 25 порта для внешних подключений, перенаправление на «отличный» порт на совести шлюза…
както так…
… дело в том, что некоторые «недоклиенты» не умеют порт, отличный от 25 (я не про полноценные почтовые клиенты, а про ПО, использующее почтовый сервер для отсылки системных уведомлений)…
… у нас, например, клиенты вообще не используют SMTP для почтовых коммуникаций, только Outlook с RPC
… но на пограничном почтовом сервере используется стандартный 25 порт для внутренних коммуникаций и другой порт для внешних, а Интернет-шлюз слушает стандартный порт и перенаправляет на другой порт…
… у нас, например, клиенты вообще не используют SMTP для почтовых коммуникаций, только Outlook с RPC
… но на пограничном почтовом сервере используется стандартный 25 порт для внутренних коммуникаций и другой порт для внешних, а Интернет-шлюз слушает стандартный порт и перенаправляет на другой порт…
все просто: если IP клиента заранее известен — в mynetworks, неизвестен — через sasl.
читаем документацию, вписываем в smtpd_helo_restrictions перед reject-ами и живем счастливо
читаем документацию, вписываем в smtpd_helo_restrictions перед reject-ами и живем счастливо
Сервер мой, да, но проблема в том, что SMTP аутентификация проходит уже после проверки HELO запроса. Поэтому при правильной настройке почтового сервера организации Outlook не сможет с ним взаимодействовать. Это конечно проблема решаемая с помощью костылей, но она увы присутствует.
Случай не надуманный, а реальный)) Я когда первый раз пытался сконнектить Postfix и Outlook был несказанно удивлён такому поведению последнего.
Случай не надуманный, а реальный)) Я когда первый раз пытался сконнектить Postfix и Outlook был несказанно удивлён такому поведению последнего.
> Outlook представляется не FQDN, а именем узла.
Давайте не будем путать MTA и MUA. Почтовые сервера обязаны (MUST в терминологии RFC) использовать FQDN. Exchange, который посылает не-FQDN — это некорректно настроенный Exchange. Почтовые клиенты могут посылать и не-FQDN, и вовсе IP-литералы.
> SMTP аутентификация проходит уже после проверки HELO запроса.
В более-менее свежих версиях Postfix все проверки выполняются после получения RCPT. Отвечает за это опция smtpd_delay_reject, которая включена по-умолчанию. Поэтому проблема вполне решаема:
smtpd_delay_reject = yes
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_non_fqdn_hostname
Давайте не будем путать MTA и MUA. Почтовые сервера обязаны (MUST в терминологии RFC) использовать FQDN. Exchange, который посылает не-FQDN — это некорректно настроенный Exchange. Почтовые клиенты могут посылать и не-FQDN, и вовсе IP-литералы.
> SMTP аутентификация проходит уже после проверки HELO запроса.
В более-менее свежих версиях Postfix все проверки выполняются после получения RCPT. Отвечает за это опция smtpd_delay_reject, которая включена по-умолчанию. Поэтому проблема вполне решаема:
smtpd_delay_reject = yes
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_non_fqdn_hostname
это не так, внимательно читайте
www.postfix.org/postconf.5.html#smtpd_helo_restrictions
и
www.postfix.org/postconf.5.html#smtpd_client_restrictions
www.postfix.org/postconf.5.html#smtpd_helo_restrictions
и
www.postfix.org/postconf.5.html#smtpd_client_restrictions
хорошая статья, много правильной теории,
но может ли кто-нибудь из сообщества покидать ссылок по практике настройки таких же параметров для IIS?
но может ли кто-нибудь из сообщества покидать ссылок по практике настройки таких же параметров для IIS?
Поставьте ASSP, настройте за неделю-другую, и будет вам счастье… ну и конечно DK, DKIM, SPF не помешает…
У меня на Маке в Mail — жизнь без спама.
Да-да, и без писем, и аккаунт вообще не настроен.
При чем клиент к почтовому серверу?
При чем клиент к почтовому серверу?
Можно было без сарказма.
Мы тут спам обсуждаем, вот я и высказал свое мнение, что на стороне клиента можно отлично фильтровать спам, не зависимо от того, какой сервер.
Мы тут спам обсуждаем, вот я и высказал свое мнение, что на стороне клиента можно отлично фильтровать спам, не зависимо от того, какой сервер.
ТС показал нам пример идеально-правильной настройки почтовика в сферическом вакууме. В реальной жизни из-за строгих проверок dns важные письма будут улетать в /dev/null, а грейлистинг доставит много удовольствия руководству. Пусть лучше часть спама просачивается в почтовые ящики пользователей, чем иметь геморой из-за неполученного письма из банка.
Грейлистинг — чуть ли не единственное из всего описанного, что должно быть включено без вариантов. Первый раз начальник подождёт 15 минут, не развалиться. Зато поток спама, а соответственно нагрузка на сервер, снизится в разы, скорей даже на порядки. А вероятность потерять при этом нужное письмо нулевая (почти).
Когда он подождет в десятый раз, то вы будете искать новую работу :)
Грейлистинг — это на любителя… Тяжело объясняться с клиентами, почему, важную корреспонденцию надо ждать полчаса, а то, может и не дойдет… :) Не надо так безапелляционно заявлять необходимость…
Тут уже писали, что руководству будет не приятны потери писем контрагентов, из-за того, что у тех не достаточно правильно настроен DNS?
Грейлистинг конечно штука интересная, но часто бывает что большие почтовые службы (например google), каждый раз пытаются доставить одно и то же письмо с разных smtp-серверов. И получается каждый раз такое письмо натыкается на грейлистинг и так и не доходит.
Я у себя сделал так — если в домене отправителя указаны записи SPF, то письма минуют грейлистинг. Если же не указаны, то срабатывает грейлистинг, а в причине ошибки указывается просьба настроить SPF для пропуска этой проверки.
Я у себя сделал так — если в домене отправителя указаны записи SPF, то письма минуют грейлистинг. Если же не указаны, то срабатывает грейлистинг, а в причине ошибки указывается просьба настроить SPF для пропуска этой проверки.
Текст интересный, более-менее полезный, хотя антиспам решения надежнее. Одно но.
За получасовой грейлистинг надо «расстреливать». Не более получаса, офигеть. И все в бизнесе сидят и ждут когда же почтовый сервер таки соизволит принять письмо. Дальше я еще могу много скрипеть про то что технологии для пользы людям, а не наоборот, но суть такова что за такой грейлистинг нужно «расстреливать».
За получасовой грейлистинг надо «расстреливать». Не более получаса, офигеть. И все в бизнесе сидят и ждут когда же почтовый сервер таки соизволит принять письмо. Дальше я еще могу много скрипеть про то что технологии для пользы людям, а не наоборот, но суть такова что за такой грейлистинг нужно «расстреливать».
… владельцев серверов с неправильным таймаутом повторной отправки, да))
Да мне все равно как руководителю, как у партнеров настроены сервера. Это деньги, мои деньги, зарплата сотрудников, в том числе и администратора. И недопустимо, чтобы если с нашей стороны мы могли сделать что-то чтобы письмо пришло, то мы этого не сделали. В том числе такие вот правила, когда первый раз по умолчанию от ворот поворот.
Время задержки целиком и полностью зависит от сервера отправителя. Оно никак не настраивается на сервере получателя. Кстати, в RFC5321 прописан именно интервал в 30 минут. Правда, с небольшой оговоркой, которой пользуются все более-менее приличные MTA.
Да нет, как раз таки настраивается на сервере получателя.
… что настраивается? настравивается интервал, в течение которого отправителю, будет временно отказано…
а вот интервал, спустя который, отправитель повторно попытается выполнить доставку «целиком и полностью зависит от сервера отправителя», и оно по умолчанию 30 минут.
а вот интервал, спустя который, отправитель повторно попытается выполнить доставку «целиком и полностью зависит от сервера отправителя», и оно по умолчанию 30 минут.
The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.
Настраивается, принять письмо сразу или по… думать над этим.
Перечитайте принцип действия greylisting'а и подумайте над этим.
Mentor mode off
Read mode on
Read mode on
На exim-e проверка HELO происходит у меня так:
check_helo:
accept hosts = +relay_from_hosts
accept condition = ${if eq {$interface_port}{587}{yes}{no}}
deny message = "ERR. Blacklisted HELO/EHLO received $sender_host_address (1)"
hosts = !+relay_from_hosts
condition = ${lookup{$sender_helo_name}nwildlsearch{/etc/exim4/blacklist_helo}{1}{0}}
deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (2)"
hosts = !+relay_from_hosts
condition = ${if match{$sender_helo_name}{\N^\d+$\N}{yes}{no}}
deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (3)"
hosts = !+relay_from_hosts
condition = ${if match{$sender_address}{\N^\s+$\N}{yes}{no}}
deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (4)"
hosts = !+relay_from_hosts
condition = ${if match{$sender_helo_name}{\N^\[?\d+\.\d+\.\d+\.\d+\]?$\N}{yes}{no}}
deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (5)"
condition = ${if match{$sender_helo_name} {\N\.\N}{no}{yes}}
hosts = !+relay_from_hosts
deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (6)"
condition = ${if eq{$sender_helo_name}{$interface_address}{yes}{no}}
deny message = "ERR. HELO/EHLO required by SMTP RFC IP $sender_host_address (7)"
condition = ${if eq{$sender_helo_name}{}{yes}{no}}
!senders = :
accept
Ну а где же регулярки для проверки EHLO записей?
/^mail\.example\.com$/ Reject That's my hostname, use your own
/^127\.0\.0\.1$/ Reject That's my IP address, use your own
/^[127\.0\.0\.1]$/ Reject That's my IP address, use your own
/^[0-9.]+$/ Reject Your client not RFC 2821 compilant
/([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}/ 553 SPAM-raw-ip-in-helo
/(^|[0-9.-])([axv]dsl|isadsl|as|bgp|dynamicIP|broadband|cable|[ck]lient|dhcp|dial|dialin|dialup|dialer|dip|dsl|dslam|dup|dyn|dynamic|host|ip|isdn|modem|nas|node|pool|ppp|pppo[ae]|sirius.*ukrtel.*|user|users|vpn)[0-9.-]/i 553 SPAM_DYNAMIC-in-helo
/([0-9]*-){3}[0-9]*(\..*){2,}/i 553 SPAM-ip-add-rr-ess_networks-in-helo
/([0-9]*\.){4}(.*\.){3,}.*/i 553 SPAM-ip-add-rr-ess_networks-in-helo
/^mail\.example\.com$/ Reject That's my hostname, use your own
/^127\.0\.0\.1$/ Reject That's my IP address, use your own
/^[127\.0\.0\.1]$/ Reject That's my IP address, use your own
/^[0-9.]+$/ Reject Your client not RFC 2821 compilant
/([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}/ 553 SPAM-raw-ip-in-helo
/(^|[0-9.-])([axv]dsl|isadsl|as|bgp|dynamicIP|broadband|cable|[ck]lient|dhcp|dial|dialin|dialup|dialer|dip|dsl|dslam|dup|dyn|dynamic|host|ip|isdn|modem|nas|node|pool|ppp|pppo[ae]|sirius.*ukrtel.*|user|users|vpn)[0-9.-]/i 553 SPAM_DYNAMIC-in-helo
/([0-9]*-){3}[0-9]*(\..*){2,}/i 553 SPAM-ip-add-rr-ess_networks-in-helo
/([0-9]*\.){4}(.*\.){3,}.*/i 553 SPAM-ip-add-rr-ess_networks-in-helo
reject_unverified_sender — говорите используете, а вы не подумали о том что я могу использовать ваш сервер чтобы DOSить другой?
SPF записи должны быть не только для домена, но и для HELO записи.
SPF записи должны быть не только для домена, но и для HELO записи.
Я вообще удивился количеству дыр, когда впервые познакомился с почтовыми протоколами и серверами. Сразу стало понятно, откуда столько спама.
Считаю, что все перечисленные опции должны быть жёстким стандартом и включены по умолчанию. Это как борьба с IE6. Пользователи должны требовать от своих админов поддержку правильных стандартов передачи почты.
Спасибо за тему.
Успехов.
Считаю, что все перечисленные опции должны быть жёстким стандартом и включены по умолчанию. Это как борьба с IE6. Пользователи должны требовать от своих админов поддержку правильных стандартов передачи почты.
Спасибо за тему.
Успехов.
Есть еще неплохой доклад от schors об особенностях организации почтового сервера: vimeo.com/7876353
Считаю, что не принимать письмо нельзя. Админ просто не вправе решать нужно это письмо получателю или нет. Единственно допустимый вариант это на основании комплекса оценок предполагать, что письмо, возможно является спамом и класть его в специальную папочку пользователю.
SPF — не панацея, и его применение далеко не всегда возможно. Банальный пример: вы настроили свой антиспам на обработку SPF для входящего потока почты. Ок. Представим себе, что ваш контрагент имеет ящик где-нибудь на бесплатном и популярном почтовом хостинге, например mail.ru. При этом администраторы mail.ru создали для своего домена SPF запись. Разумеется в блок адресов включены только адреса серверов mail.ru. А тот самый контрагент пользуется местной локальной сетью и 25 порт у них закрыт для всех, кроме внутреннего почтового сервера этой самой локальной сети. И от их провайдера рекоммендация: отправляйте почту через наш почтовый релей. И что в итоге? А вот что: SPF отфильтрует это письмо поскольку IP адрес почтового сервера отправителя не попадает в блок, описанный в SPF.
По-моему, абсолютно бесполезная статья.
SPF вообще нельзя использовать для отсеивания спама, слишком уж много мейл-хостеров пишут туда ~all. Для чего SPF можно реально использовать, причем очень хорошо — так это для уменьшения числа false positives, если SPF-проверка пройдена, значит — не спам. Правда, в этом случае еще желательно сверять адрес в MAIL FROM: и в заголовке From: самого письма. Последние полгода, например, в сети hotmail есть активный ботнет, рассылающий письма с корректным MAIL FROM:, проходящем SPF-проверку, и совершенно другим From.
SPF вообще нельзя использовать для отсеивания спама, слишком уж много мейл-хостеров пишут туда ~all. Для чего SPF можно реально использовать, причем очень хорошо — так это для уменьшения числа false positives, если SPF-проверка пройдена, значит — не спам. Правда, в этом случае еще желательно сверять адрес в MAIL FROM: и в заголовке From: самого письма. Последние полгода, например, в сети hotmail есть активный ботнет, рассылающий письма с корректным MAIL FROM:, проходящем SPF-проверку, и совершенно другим From.
Что касается RBL, их надо использовать. Только не как однозначный определитель спама, а как это делается в spamassasin — попадание в каждый из них дает сколько-то очков, так же как и неверный SPF, отсутствующий rDNS, неверный rDNS. Кстати, не принимая письма с неверным rDNS, вы на практике также отрезаете кучу легитимной почты.
Лично я использую в spamassasin комбинацию SPF (причем fail ценится не слишком высоко, зато pass почти сразу делает письмо не-спамом), RBL и несколько эвристик самого spamassasin. При этом письма, набравшие выше Х баллов, идут в отдельный спам-ящик, а письма, набравшие от Y до X баллов, доходят в обычный ящик с пометкой SPAM в заголовке. Если туда вдруг попадает обычное письмо — это повод внимательно посмотреть, по каким правилам оно набрало высокий вес и подправить их.
Лично я использую в spamassasin комбинацию SPF (причем fail ценится не слишком высоко, зато pass почти сразу делает письмо не-спамом), RBL и несколько эвристик самого spamassasin. При этом письма, набравшие выше Х баллов, идут в отдельный спам-ящик, а письма, набравшие от Y до X баллов, доходят в обычный ящик с пометкой SPAM в заголовке. Если туда вдруг попадает обычное письмо — это повод внимательно посмотреть, по каким правилам оно набрало высокий вес и подправить их.
аффтар дилетант и рассуждает имея в виду почтовик принимающий 100 писем в сутки, включая спам.
Если подумать о 100 писем в секунду то расклад совершенно другой:
1. RBL всегда кроме белых списков (dnswl.org) и строгого SPF
2. geo-maping — CN, KR, IN в отдельный restriction class со всякими строгими helo_restrictions и _concurrency и _connection_count и _rate_ лимитами
3. graylisting только для клиентов с отсутствующей PTR
Со spamassassin тоже не вcё прекрасно — на Opteron Quad с 4 гигами памяти можно обрабатывать одновременно не более 70 писем со средней скоростью 0.3 письма в секунду.
Если подумать о 100 писем в секунду то расклад совершенно другой:
1. RBL всегда кроме белых списков (dnswl.org) и строгого SPF
2. geo-maping — CN, KR, IN в отдельный restriction class со всякими строгими helo_restrictions и _concurrency и _connection_count и _rate_ лимитами
3. graylisting только для клиентов с отсутствующей PTR
Со spamassassin тоже не вcё прекрасно — на Opteron Quad с 4 гигами памяти можно обрабатывать одновременно не более 70 писем со средней скоростью 0.3 письма в секунду.
статья содержательная, но много спорных моментов. Я пару лет админил почтовый сервер с сотнями клиентов и не во всём согласен с автором.
DNSBL — чрезвычайно эффективный метод борьбы со спамом. Я лично поставил проверку на 3-4 блэклистах и лишился многих проблем. Ложные срабатывания при этом были раза 2-3 за 2 года, но их можно запросто решить добавлением клиента в белый список.
Кстати, существуют специальные блэклисты, куда провайдеры могут добровольно добавить список своих домосетей. Моя проверка показала, что многие крупнейшие украинские провайдеры домосетей ими пользуются. Собственно, я тоже свою добавил.
SPF — хорошая технология, но её недостатком есть то, что она требует использования всеми участниками почтового обмена. Сейчас же очень мало кто в своих доменах настраивает SPF.
А самым эффективным барьером от спама оказалась железка от ЦИСКО, IronPort. Мы брали её на тест. Вот это действительно была качественная защита.
Кстати, судя по статье автор не знает, что каждый почтовый сервер по стандарту обязан принимать любое письмо, отправителем или получателем которого есть postmaster@
DNSBL — чрезвычайно эффективный метод борьбы со спамом. Я лично поставил проверку на 3-4 блэклистах и лишился многих проблем. Ложные срабатывания при этом были раза 2-3 за 2 года, но их можно запросто решить добавлением клиента в белый список.
Кстати, существуют специальные блэклисты, куда провайдеры могут добровольно добавить список своих домосетей. Моя проверка показала, что многие крупнейшие украинские провайдеры домосетей ими пользуются. Собственно, я тоже свою добавил.
SPF — хорошая технология, но её недостатком есть то, что она требует использования всеми участниками почтового обмена. Сейчас же очень мало кто в своих доменах настраивает SPF.
А самым эффективным барьером от спама оказалась железка от ЦИСКО, IronPort. Мы брали её на тест. Вот это действительно была качественная защита.
Кстати, судя по статье автор не знает, что каждый почтовый сервер по стандарту обязан принимать любое письмо, отправителем или получателем которого есть postmaster@
pbl.spamhaus.org очень полезен
www.opennet.ru/opennews/art.shtml?num=27693 Моя позиция по поводу DNSBL совершенно жёсткая: максимум, для чего их можно применять — это только для накидывания лишних 5-10% к рейтингу спама для письма, если вы конечно используете фильтр, который оценивает спам по совокупности критериев. В чистом виде DNSBL не должны применяться никогда и ни при каких условиях.
Не упомянули о том факте (да, я прочитал все комментарии), что, в отличие от помещения письма в папку Спам, при отказе в приеме легитимный отправитель получит отлуп и сразу же вам перезвонит :)
Что же касается рассылок и уведомлений, терять их, конечно, неприятно, но, как правило, не столь критично, как при общении с живыми людьми.
Что же касается рассылок и уведомлений, терять их, конечно, неприятно, но, как правило, не столь критично, как при общении с живыми людьми.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неприступный почтовый сервер, или жизнь без спама