После одиннадцати месяцев разработки представлен (http://permalink.gmane.org/gmane.mail.postfix.announce/146) релиз новой стабильной ветки почтового сервера Postfix (http://www.postfix.org) - 2.11.0. Postfix является одним из редких проектов, сочетающих одновременно высокую безопасность, надёжность и производительность, чего удалось добиться благодаря продуманной архитектуре (http://www.postfix.org/OVERVIEW.html) и достаточно жесткой политике оформления кода и аудита патчей. Одновременно с выходом новой ветки, объявлено о прекращении поддержки ветки Postfix 2.7, выпущенной (http://www.opennet.ru/opennews/art.shtml?num=25575) в начале 2010 года.Из особенностей (ftp://ftp.porcupine.org/mirrors/postfix-release/official/pos... новой ветки можно отметить:
- Поддержка верификации серверных сертификатов TLS с использованием DANE (http://ru.wikipedia.org/wiki/DANE) (DNS-based Authentication of Named Entities) без привлечения инфраструктуры открытых ключей (PKI (http://ru.wikipedia.org/wiki/%D0%98%D0%B... Public Key Infrastructure), т.е. без оценки валидности на основе заверения удостоверяющим центром. При использовании DANE для подтверждения достоверности сервера применяется метод непосредственной передачи публичного ключа или сертификата сервера через DNS с проверкой подлинности переданных данных при помощи DNSSEC. Основной проблемой PKI является большое разрастание доверительной сети, в которой любой удостоверяющий центр может выписать валидный сертификат для любого домена, что подрывает всю систему при компрометации хотябы одного удостоверяющего центра. В случае DANE за подтверждение сертификатов отвечает непосредственно владелец доменной зоны, права которого подтверждаются владельцем родительского домена более низкого уровня.
- Поддержка постоянного хранения локальных баз данных в формате LMDB, развиваемом проектом OpenLDAP. Поддерживается LMDB 0.9.11 и более новые выпуски. В отличие от других форматов хранения БД (например, btree, hash, dbm, cdb, sdbm ) при использовании LMDB обеспечена возможность одновременной записи в базу из нескольких процессов, таких как postscreen. Ранее поддержка совместной записи из параллельно выполняемых процессов могла быть реализована только при помощи memcached.
- Добавлена опция postscreen_dnsbl_whitelist_threshold, позволяющая клиентам пропустить тесты postscreen (выполняет роль легковесного межсетевого экрана, предназначенного для первичного блокирования соединений от рассылающих спам зомби-машин) в зависимости от результатов проверки по белому списку через DNSBL. Применение postscreen_dnsbl_whitelist_threshold позволяет избавиться от заметных задержек в доставке почты от заведомо валидных почтовых систем, в которых повторные запросы не отправляются с одного и того же IP (задержка возникает из-за теста с использованием повторного реконнекта), например, так поступает Google.
- В директиве recipient_delimiter теперь возможно указание нескольких символов-разделителей, например, можно одновременно использовать как разделители "+" и "-".
- В master.cf реализованы расширенные операции запроса и обновления при доступе к атрибутам сервисов в формате ключ/значение. Например, для выключения помещения в chroot всех сервисов можно использовать "postconf -F '*/*/chroot = n'", а для добавления значения параметра сразу для нескольких серивисов - "postconf -P smtp/inet/name = value". Указанная возможность позволяет разработчикам автоматизированных инструментов организовать управление почтовым сервером без разбора файлов конфигурации.
URL: http://permalink.gmane.org/gmane.mail.postfix.announce/146
Новость: http://www.opennet.ru/opennews/art.shtml?num=38868
Хоть один проект настоящие крутые фичи внедряет, а не безумные перделки.
exim под нагрузкой не прогибается
Как и postfix. Зато у последнего конфиг адекватный.
Дистро-специфичные извращения никакого отношения к экзиму не имеют. Блок параметров, блок ацлей, блок роутеров, блок транспортов - все. Чистенько, аккуратненько, прямолинейно и очевидно. Ну а что в комплекте с нескучными обойчиками часто идет винегрет из мелко покрошеных инклудов - то печаль линуксоидов, а не экзима.
еще бы в формате yaml
Упасите Святые Небеса!!
Нормальный конфиг у Постфикса.
И, ИМХО, Постфикс все-таки более гибок в настройке, чем Эксим
> Нормальный конфиг у Постфикса.Да. Для тех, кто не осилил экзим.
Это для них "Добавлена опция postscreen_dnsbl_whitelist_threshold, позволяющая" не патчить Си-код для и не встраивать язык программирования в конфиг.
> И, ИМХО, Постфикс все-таки более гибок в настройке, чем Эксим
Нет.
> Да. Для тех, кто не осилил экзим.
> Это для них "Добавлена опция postscreen_dnsbl_whitelist_threshold, позволяющая" не патчить Си-код для и не встраивать язык программирования в конфиг.Да. Конфиг - это не код. Все правильно сделали.
> exim под нагрузкой не прогибаетсяЕсли б ещё не remote root раз в несколько лет... :-(
>> exim под нагрузкой не прогибается
> Если б ещё не remote root раз в несколько лет... :-(ну,, последний "root" был только для любителей настраивать всё к чему руки дотянулись следуя партийному инструктажу с сайта лисяры.
>> Если б ещё не remote root раз в несколько лет... :-(
> ну,, последний "root" был только для любителей настраивать всё к чему руки
> дотянулись следуя партийному инструктажу с сайта лисяры.И да, oldstable был ниуязвим! За неимением. DKIM-а, не exim-f, если кто не понял.
Но да, лисярщикам -- наше с кисточкой за фиксинг нашего нового oldstable-а.
>> exim под нагрузкой не прогибается
> Если б ещё не remote root раз в несколько лет... :-(Насколько помню один из недавних рутов был специфичен только для debian
>> Если б ещё не remote root раз в несколько лет... :-(
> Насколько помню один из недавних рутов был специфичен только для debianНапомни, https://security-tracker.debian.org/tracker/source-package/e... который?
-
Если про use_shell, то там remote shell, но не root был. И Debian распространял бырявый кусок конфига с давкотовского wiki.
И все-таки хочеться _штатной_ проверки spf, желательно включаемой и выключаемой возможности проверки соответствия значения helo.
А так же возможности включить проверки соответствия значения helo и dns-имени по ip адресу с которого пришло письмо.
а вообще smtp - такой древний костыль, который обрастает другими мини-костылями, а мини-костыли своими микро-костылями, что просто вах.
smtp сохраняет свой изначальный SHIT - отправку и получения почты без авторизации.
Существует куча restrictions, которые не дают 100% гарантии того, что вам не придет спам.
Потому что там идет проверка _наличия_ helo и максимум - соответствия FQDN.
Но простейший баш-скрипт позволит отправить письмо (от имени mail.ru, потому что у этих и прочих ***дарастов очень лояльные spf) и получить жертве, при условии что у вас провайдер выдает ip с записью в обратной зоне dns.
а таких сейчас не мало.
Итого - основой всех проблем является не почтовые сервера, а сам протокол smtp.
Проблему спама можно было бы решить давно (не знаю как именно, но знаю что можно), переделкой стандартов SMTP, но видимо наличие спама - кому-то выгодно.
Да что я говорю - просто обязательная проверка spf и жесткие ограничения на стороне ВСЕХ почтовых серверов по spf - и все, спама не было бы вообще.
Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его к валидным spf - дело пяти мину.
К слову у моего postfix разрешения в spf для одного ip и для всего остального - жесткий минус, так что МНОЙ уже никто не сможет представиться.
> И все-таки хочеться _штатной_ проверки spf+1, но только чтобы настраивалась гибко. Не, я конечно сделал у себя блокировку не только fail, но и softfail, и даже neutral блокирую для определённых доменов... А для некоторых доменов даже по отсутствию spf-записи блокировку сделал, но для всего этого пришлось нехило накостылить в стандартном перловом скрипте.
Кстати, по моей статистике на данный момент уже около 45% доменов имеют spf-записи, так что его проверка даёт ощутимый эффект. Вот данные, полученые из логов постфикса с предварительной группировкой по доменам (правда, сюда не попало то, что отсеялось по RBL и другим проверкам, которые срабатывают раньше):
276 fail
558 neutral
3822 none
1466 pass
185 permerror
632 softfail
106 temperror
> +1, но только чтобы настраивалась гибко. Не, я конечно сделал у себя
> блокировку не только fail, но и softfail, и даже neutral блокирую
> для определённых доменов... А для некоторых доменов даже по отсутствию spf-записи
> блокировку сделал, но для всего этого пришлось нехило накостылить в стандартном
> перловом скрипте.Круто, молодец что осилил перл, а я вот не стал разбираться, перл не умею вообще.
> Да что я говорю - просто обязательная проверка spf и жесткие ограничения
> на стороне ВСЕХ почтовых серверов по spf - и все, спама
> не было бы вообще.ололо ...
вы забыли про еще одно не мене слабое звено smtp - долбануто-рукажопый легион юзерастов
один сломаный ящик на авторизацию отправки - и вуаля - спам с легальным spf )) да и спамботом вроде никто не запрещал им себе ставить ))
SPF вообще ни разу не панацея и, более того, может быть даже наоборот.
Умные спамеры давно это поняли и делают в своих SPF записях что-то вроде
"v=spf1 +IP1/8 +IP2/8 ... ~all"
А можно и /1 сделать
Пускай делают, все домены с такими SPF-записями сразу отправляются лесом. Почтовые админы тоже не вчера родились.
Это понятно. Непонятен энтузиазм товарища насчёт SPF.
Тогда б уж DKIM + ADSP пиарил... ;-)
> Это понятно. Непонятен энтузиазм товарища насчёт SPF.
> Тогда б уж DKIM + ADSP пиарил... ;-)Так ведь нормальная эффективная технология, вот и вселяет энтузиазм.
А чем DKIM лучше? Распространён слабо, для антиспама подходит только в сочетании с ADSP, который вообще почти не встречается в реальной жизни. И даже с ADSP остаётся уязвимость вида "отправили одно спам-письмо самим себе и затем рассылаем подписанные копии откуда хотим".
DKIM хорошо приспособлен только для подтверждения факта прохода через конкретный почтовик, чтобы нельзя было подделать письмо от Васи и сказать что это он его тебе отправил с гмыла.
Вот тем и лучше, что подтверждает происхождение письма и его достоверность за счет DKIM, а также поведение принимающих его серверов следуя политике прописанной в ADSP.
Но, опять же, не панацея.
> Вот тем и лучше, что подтверждает происхождение письма и его достоверность за
> счет DKIM,Прекрасно, только при чём тут антиспам?
> а также поведение принимающих его серверов следуя политике прописанной
> в ADSP.Хорошая попытка, но спамеры со своих доменов всё ещё могут отправлять спам через ботнеты. Если в SPF есть возможность блокировать записи вида +ip4:5.0.0.0/8, то в DKIM+ADSP зацепиться незачто.
> Но, опять же, не панацея.
> Хорошая попытка, но спамеры со своих доменов всё ещё могут отправлять спам
> через ботнеты. Если в SPF есть возможность блокировать записи вида +ip4:5.0.0.0/8,
> то в DKIM+ADSP зацепиться незачто.Но только со своих адресов, что уже намного приятнее, не так ли?
Опять же, повторюсь, что радикального решения на сегодня, к сожалению, нет.
> Но только со своих адресов, что уже намного приятнее, не так ли?Чего? Как это у вас DKIM позволяет проверять - со своего IP отправлено письмо или не со своего? Может я чего-то не знаю и за последние годы в нём появилась такая возможность? Поподробнее не расскажете со ссылочками?
> Чего? Как это у вас DKIM позволяет проверять - со своего IP
> отправлено письмо или не со своего?...адресов e-mail, конечно. А их может подписывать только свой сервер.
Но, как вы верно заметили, ниже, это обходится.
> "отправили одно спам-письмо самим себе и затем рассылаем подписанные копии откуда хотим"Вот это недопонял...
>> "отправили одно спам-письмо самим себе и затем рассылаем подписанные копии откуда хотим"
> Вот это недопонял...Заводим ящик на гмейл, отправляем с него нужное письмо самим себе. Затем берём это письмо со всеми заголовками и рассылаем через ботнеты. Конверт SMTP-протокола не обязан совпадать с заголовками From и To в самом письме, так что все почтовые сервера будут думать, что это письмо отправил сам гмейл. Конечно, это при условии отсутствия проверки (или отсутствия) SPF-записи.
Ага, уловил.
> Конечно, это при условии отсутствия проверки (или отсутствия) SPF-записи.Вот именно.
Что вот именно? Вывод-то какой? - Правильно, для антиспама нужен SPF, а DKIM+ADSP для этого совсем не годятся.
> Что вот именно? Вывод-то какой? - Правильно, для антиспама нужен SPF, а
> DKIM+ADSP для этого совсем не годятся.Так вот почему ты стал айтишником - у тебя логика бинарная :).
О том, что ADSP и SFP лучше всего применять вместе в бинарной логике ИЛИ не уладывается :)
О том, что это только 1 из парамтров весового коэффициента марштутизации почты в антиспам-фильтре опеннетовскин аналитгам судя по всему понять не дано.
Чухча не читатель? Не сочтите за труд подняться к сообщению #43 и посмотреть с чего начался разговор. Заодно и всю ветку прочесть не помешало бы, прежде чем влезать в разговор со своими "прозрениями".И не объясните ли, в каких случаях ADSP может дать дополнительную информацию для блокировки спама при условии наличия SPF?
> И не объясните ли, в каких случаях ADSP может дать дополнительную информацию
> для блокировки спама при условии наличия SPF?Например, получение письма с домена well known DKIM signer а-ля gmail.com без подписи.
При их ~all в SPF это реальная ситуация.
Если речь идёт про well known, то информации из SPF вполне достаточно - DKIM совсем не нужен. У меня, например, все softfail блокируются наравне с fail по умолчанию. А вот для neutral уже да, только вручную прописанные домены блокируются.
Жестоко вы. Я на softfail баллов накидываю только.
> Жестоко вы. Я на softfail баллов накидываю только.Проблем пока небыло. А если возникнут, то занести домен в исключения не проблема.
Неправильно.
Сам по-себе SPF проблему не решает, а может и новые создавать.
SPF + DKIM/ADSP в совокупности значительно лучше, но тоже не панацея.
Вы не привели ни одного примера, где DKIM+ADSP имел бы какое-то преимущество перед SPF для борьбы со спамом (или оказывал бы ему какую-то помощь в этом). Единственная его польза является в доказательственности при расследованиях, как я уже писал выше.
> Вы не привели ни одного примера, где DKIM+ADSP имел бы какое-то преимущество
> перед SPFСм. выше случай с well know DKIM signers
>> Вы не привели ни одного примера, где DKIM+ADSP имел бы какое-то преимущество
>> перед SPF
> См. выше случай с well know DKIM signersКак я и ответил на то сообщение - SPF для этого более чем достаточен. Так что я всё ещё жду реальных примеров, а не надуманных.
>>> Вы не привели ни одного примера, где DKIM+ADSP имел бы какое-то преимущество
>>> перед SPF
>> См. выше случай с well know DKIM signers
> Как я и ответил на то сообщение - SPF для этого более
> чем достаточен. Так что я всё ещё жду реальных примеров, а
> не надуманных.Это реальный пример, который лично я использую при разборе входящей почты в конфиге, кстати говоря, Exim.
SPF недостаточно, ввиду того что может быть выставлена нейтральная политика.
> Это реальный пример, который лично я использую при разборе входящей почты в
> конфиге, кстати говоря, Exim.Это понятно, что можно и молотком саморезы забивать - это дело вкуса.
> SPF недостаточно, ввиду того что может быть выставлена нейтральная политика.
Видимо, вы опять не допоняли о чём я говорил: не важно какая дефолтная политика у домена, мы всегда можем её заменить на какую хотим для well known domains. Именно так я поступаю для некоторых доменов, у которых прописано ?all (выше уже упоминал).
Например - получаем письмо якобы от гмейла -> проверяем SPF, если результат отличен от pass или softfail - даём reject. Преимущества перед вашим методом: 1) можно посылать спамеров ещё на этапе SMTP-сессии, не затрачиваясь на трафик и прочие ресурсы; 2) отсутствует уязвимость "отправили одно спам-письмо самим себе и затем рассылаем подписанные копии откуда хотим".
Так что как ни посмотри, а не дотягивает DKIM до SPF в качестве антиспама.
> И все-таки хочеться _штатной_ проверки spf, желательно включаемой и выключаемой возможности
> проверки соответствия значения helo.
> А так же возможности включить проверки соответствия значения helo и dns-имени по
> ip адресу с которого пришло письмо.это и многое другое уже давно есть в exim из коробки ;)
> а вообще smtp - такой древний костыль, который обрастает другими мини-костылями, а
> мини-костыли своими микро-костылями, что просто вах.
> smtp сохраняет свой изначальный SHIT - отправку и получения почты без авторизации.как вы себе представляете отправку почту с авторизацией на незнакомый домен?
> Существует куча restrictions, которые не дают 100% гарантии того, что вам не
> придет спам.100% дают только в морге, фильтрация спама это не задача МТА как такового.
> Потому что там идет проверка _наличия_ helo и максимум - соответствия FQDN.
> Но простейший баш-скрипт позволит отправить письмо (от имени mail.ru, потому что у
> этих и прочих ***дарастов очень лояльные spf) и получить жертве, при
> условии что у вас провайдер выдает ip с записью в обратной
> зоне dns.
> а таких сейчас не мало.а зачем принимать решение только по одному критерию - наличие/отсутствию spf записи?
> Итого - основой всех проблем является не почтовые сервера, а сам протокол
> smtp.как вы ловко приплели spf к smtp, даже не знаю что и сказать
> Проблему спама можно было бы решить давно (не знаю как именно, но
> знаю что можно), переделкой стандартов SMTPне поспоришь! Вам надо идти в политику, они тоже не знаю что надо сделать, чтобы ситуация в стране изменилась к лучшему, но яро нас уверяют что они будут прикладывать к этому все свои силы и что это возможно :)
> но видимо наличие спама - кому-то выгодно.
как и наличие наркотиков, оружия и т.п.
> Да что я говорю - просто обязательная проверка spf и жесткие ограничения
> на стороне ВСЕХ почтовых серверов по spf - и все, спама
> не было бы вообще.блажен кто не ведает
> Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его
> к валидным spf - дело пяти мину.и что дальше? Приехали вы в другую страну, в крупную организацию и хотите отправить почту от имени mail.ru, а 25/587 порт в мир закрыты, только внутренний корпоративный smtp релей. По вашей логике все идут лесом в таком случае.
> К слову у моего postfix разрешения в spf для одного ip и
> для всего остального - жесткий минус, так что МНОЙ уже никто
> не сможет представиться.Я смогу представиться и отправить на сервер, который не делает проверки SFP или как минимум не принимает решение только на основании одной лишь SFP записи
>> Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его
>> к валидным spf - дело пяти мину.
> и что дальше? Приехали вы в другую страну, в крупную организацию и
> хотите отправить почту от имени mail.ru, а 25/587 порт в мир
> закрыты, только внутренний корпоративный smtp релей. По вашей логике все идут
> лесом в таком случае.Зайдёт через браузер и отправит. А за открытый релей вообще надо по рукам давать, ибо первый же вирус в локалке вполне заслуженно занесёт этот релей во всевозможные чёрные списки.
>>> Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его
>>> к валидным spf - дело пяти мину.
>> и что дальше? Приехали вы в другую страну, в крупную организацию и
>> хотите отправить почту от имени mail.ru, а 25/587 порт в мир
>> закрыты, только внутренний корпоративный smtp релей. По вашей логике все идут
>> лесом в таком случае.
> Зайдёт через браузер и отправит.очень удобно? веб тоже может быть зафильтрован :D
> А за открытый релей вообще надо по рукам давать, ибо первый же вирус в локалке вполне заслуженно занесёт этот релей во всевозможные чёрные списки.
а никто не сказал что он открытый, он с аутентификацией и что дальше?
Ну вот прямо всё вам закрыли, а от почтового релея аккаунт дали... Это что за организация такая и что вы там делали, стесняюсь спросить?
> как вы себе представляете отправку почту с авторизацией на незнакомый домен?А у вас авторизованные пользователи только локально почту отправляют? :-D
>> как вы себе представляете отправку почту с авторизацией на незнакомый домен?
> А у вас авторизованные пользователи только локально почту отправляют? :-Dаутентификацию от авторизации отличаем?
> аутентификацию от авторизации отличаем?Ну так объясните разницу, гениальный вы наш.
>> аутентификацию от авторизации отличаем?
> Ну так объясните разницу, гениальный вы наш.у вас гугл забанили?
Ну т.е. blah-blah-blah
> это и многое другое уже давно есть в exim из коробки ;)Уточню - возможность взять значение helo, затем ip с которого пришло письмо, затем этот ip преобразовать в доменное имя и сравнить это имя со значением в helo ?
> как вы себе представляете отправку почту с авторизацией на незнакомый домен?
Ну если представлять, то примерно так - после получения письма, ваш почтовик должен обратиться к отправителю и спросить "ты мне сейчас посылал письмо вот с таким id ?"
и тот должен ответить "да" или "нет".> 100% дают только в морге, фильтрация спама это не задача МТА как
> такового.Конечно, а я про что :) ?
> а зачем принимать решение только по одному критерию - наличие/отсутствию spf записи?
Не только но и в том числе, может я не четко выразился, у меня проверка spf стоит одной из последних.
> как вы ловко приплели spf к smtp, даже не знаю что и
> сказатьБыло бы не плохо если проверка spf была бы штатной, невыключаемой фишкой smtp, так же как и запрос MAIL FROM. А указание spf записи - такой же обязательной штукой, как и указание доменного имени для почтовика.
> не поспоришь! Вам надо идти в политику, они тоже не знаю что
Тоже так думаю, не важно что я говорю, важно КАК я это говорю.
Шутка, шутка.
>> Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его
>> к валидным spf - дело пяти мину.
> и что дальше? Приехали вы в другую страну, в крупную организацию и
> хотите отправить почту от имени mail.ru, а 25/587 порт в мир
> закрыты, только внутренний корпоративный smtp релей. По вашей логике все идут
> лесом в таком случае.Зачем в корпоративной сети слать почту от имени mail.ru ?
> Я смогу представиться и отправить на сервер, который не делает проверки SFP
Вот, и чья проблема в этом случае? что у вас будет спам от имени моего сервера :) ?
>> это и многое другое уже давно есть в exim из коробки ;)
> Уточню - возможность взять значение helo, затем ip с которого пришло письмо,
> затем этот ip преобразовать в доменное имя и сравнить это имя
> со значением в helo ?да. Собственно в exim все такие фишки ограничены только извращенностью вашей фантазии ;)
>> как вы себе представляете отправку почту с авторизацией на незнакомый домен?
> Ну если представлять, то примерно так - после получения письма, ваш почтовик
> должен обратиться к отправителю и спросить "ты мне сейчас посылал письмо
> вот с таким id ?"
> и тот должен ответить "да" или "нет".а вы думаете отправитель (спамер) укажет реальный сервер? А если сервер будет фейковый то он вам на все запросы будет отвечать - да, это моя отправила это письмо, так что принимай смело
>> 100% дают только в морге, фильтрация спама это не задача МТА как
>> такового.
> Конечно, а я про что :) ?ну хоть в чем то мы согласны :)
>> а зачем принимать решение только по одному критерию - наличие/отсутствию spf записи?
> Не только но и в том числе, может я не четко выразился,
> у меня проверка spf стоит одной из последних.и это правильно. В exim за такие штуки просто накидываю балы. А решение уже принимается по сумме балов
>> как вы ловко приплели spf к smtp, даже не знаю что и
>> сказать
> Было бы не плохо если проверка spf была бы штатной, невыключаемой фишкой
> smtp, так же как и запрос MAIL FROM. А указание spf
> записи - такой же обязательной штукой, как и указание доменного имени
> для почтовика.в любом случае SPF не панацея, ибо нельзя задавать жесткую политику, особенно всяким ISP и т.п.
>[оверквотинг удален]
> Тоже так думаю, не важно что я говорю, важно КАК я это
> говорю.
> Шутка, шутка.
>>> Если у какого-нить mail.ru появился новый ip для smtp-релея то добавить его
>>> к валидным spf - дело пяти мину.
>> и что дальше? Приехали вы в другую страну, в крупную организацию и
>> хотите отправить почту от имени mail.ru, а 25/587 порт в мир
>> закрыты, только внутренний корпоративный smtp релей. По вашей логике все идут
>> лесом в таком случае.
> Зачем в корпоративной сети слать почту от имени mail.ru ?ну вот надо клиенту, mail.ru просто для примера, пусть будет example.net :)
>> Я смогу представиться и отправить на сервер, который не делает проверки SFP
> Вот, и чья проблема в этом случае? что у вас будет спам
> от имени моего сервера :) ?как правило в таких случаях есть куча других не стыковок - типа ptr, ВТЫИД и т.п. Плюс не забываем, есть еще spamassassin и т.п. системы, которые собственно и разрабатывались для этой цели. MTA не должен заниматься фильтрацией спама в полном смысле этого слова, он лишь должен производить первичный отбор заведомо "плохих" клиентов, имхо
Гуру, объясните, пожалуйста, что это за тест с использованием повторного реконнекта?
> Гуру, объясните, пожалуйста, что это за тест с использованием повторного реконнекта?Это специальная *удобная* опция для ускорения хождения на костылях!
***грейлистинг (или это как-то по-другому называется) с _не_приёмом_ соединения с первой попытки с конкр.ip клиента, а только со второго -- решает больщую часть бот-нет спамеров, но может задерживить прием с исходящих (гугль), у которых _несколько_ [одновременно/попеременно] шлющих наружу ip.
дык есть список исключений greylist-а, забил туда всех известных "неадекватов" и всё пашет.
хотя на сегодняшний день спамеры тоже умные пошли, грэйлистинг умеют, не раз в логах видел, приходится особо надоедливых по домену банить, хотя это тоже им пох, домены нонче дёшевы, а amavisd/spamassasin не всё режут (ессно пока спам в "базы" не попадёт)
>с _не_приёмом_ соединения с первой попытки с конкр.ipУже представил как какая-то фирма лишилась выгодного контракта, потому что письмо с контрактом попало в грейлистинг.
> Уже представил как какая-то фирма лишилась выгодного контракта, потому что письмо с контрактом попало в грейлистинг.Метод основан на том, что практически любой нормальный почтовик спокойно отнесется к отлупу и повторит попытку (в отличие от самп-бота, который просто перейдет к следующему хосту).
Если фирма наняла убунтоадмина за полставки, и он, бездумно следуя нагугленному мануалу от такого же убунтоадмина, взял и отключил retry, это уже проблема конкретной фирмы. Нефиг экономить на спич^Wадминах.
>>с _не_приёмом_ соединения с первой попытки с конкр.ip
> Уже представил как какая-то фирма лишилась выгодного контракта, потому что письмо с
> контрактом попало в грейлистинг.Прочитайте RFC и как себя должен вести "нормальный" MTA в таких случаях ;)
>>>с _не_приёмом_ соединения с первой попытки с конкр.ip
>> Уже представил как какая-то фирма лишилась выгодного контракта, потому что письмо с
>> контрактом попало в грейлистинг.
> Прочитайте RFC и как себя должен вести "нормальный" MTA в таких случаях ;)Да, он же спамер! Он документации не читает. //Хотя может и бот.
>>с _не_приёмом_ соединения с первой попытки с конкр.ip
> Уже представил как какая-то фирма лишилась выгодного контракта, потому что письмо с
> контрактом попало в грейлистинг.А вот грейлистинг, как и все пилюли, нельзя применять бездумно. Специфику организации учитывать надо.
Там где задержки нежелательны я использовал policyd 1.8X, там есть очень классная штука, спаммтраппинг, по-моему. Смысл таков: в Инете "свечу" нужные мне ящики. Потихоньку на эти ящики начинает валить спам, адреса отправителей заносятся в блэклист.
Может случится так, что из сети контрагентов валил спам и попал в блэклист, а потом не прошло валидное письмо, но это уже их проблемы :-).
>Там где задержки нежелательныТам, где нежелательны задержки, не надо использовать электронную почту, потому что SMTP не гарантирует сроки доставки и никогда не собирался их гарантировать, ибо "best effort". То, что он обычно good, не означает каких-либо гарантий.
>> Гуру, объясните, пожалуйста, что это за тест с использованием повторного реконнекта?
> Это специальная *удобная* опция для ускорения хождения на костылях!
> ***грейлистинг (или это как-то по-другому называется) с _не_приёмом_ соединения с первой
> попытки с конкр.ip клиента, а только со второго -- решает больщую
> часть бот-нет спамеров, но может задерживить прием с исходящих (гугль), у
> которых _несколько_ [одновременно/попеременно] шлющих наружу ip.при грамотной настройке не будет никаких задержек, просто не надо грейлистить всех подряд без разбора ;)
>>> Гуру, объясните, пожалуйста, что это за тест с использованием повторного реконнекта?
>> Это специальная *удобная* опция для ускорения хождения на костылях!
>> ***грейлистинг (или это как-то по-другому называется) с _не_приёмом_ соединения с первой
>> попытки с конкр.ip клиента, а только со второго -- решает больщую
>> часть бот-нет спамеров, но может задерживить прием с исходящих (гугль), у
>> которых _несколько_ [одновременно/попеременно] шлющих наружу ip.
> при грамотной настройке не будет никаких задержек, просто не надо грейлистить всех
> подряд без разбора ;)Все равно будут.Проверено опытом. Вы все домены всех контрагентов в белый список не внесете.
>>>> Гуру, объясните, пожалуйста, что это за тест с использованием повторного реконнекта?
>>> Это специальная *удобная* опция для ускорения хождения на костылях!
>>> ***грейлистинг (или это как-то по-другому называется) с _не_приёмом_ соединения с первой
>>> попытки с конкр.ip клиента, а только со второго -- решает больщую
>>> часть бот-нет спамеров, но может задерживить прием с исходящих (гугль), у
>>> которых _несколько_ [одновременно/попеременно] шлющих наружу ip.
>> при грамотной настройке не будет никаких задержек, просто не надо грейлистить всех
>> подряд без разбора ;)
> Все равно будут.Проверено опытом. Вы все домены всех контрагентов в белый
> список не внесете.ну разве что единичные случаи ;)
У меня была одна проблема с грейлистингом, почтовый сервер посольство Англии не повторял отправку. Шеф из за этого сильно злой был =)
Пришлось "хорошо" настроенный почтовик Английского посольства, добавлять в белый список.
А ведь Англия жэ...
Как так!
> У меня была одна проблема с грейлистингом, почтовый сервер посольство Англии не
> повторял отправку. Шеф из за этого сильно злой был =)
> Пришлось "хорошо" настроенный почтовик Английского посольства, добавлять в белый список.
> А ведь Англия жэ...
> Как так!а что, по вашему в Англии/США/Германии/etc... нет криворуких админов? ;)
>> У меня была одна проблема с грейлистингом, почтовый сервер посольство Англии не
>> повторял отправку. Шеф из за этого сильно злой был =)
>> Пришлось "хорошо" настроенный почтовик Английского посольства, добавлять в белый список.
>> А ведь Англия жэ...
>> Как так!
> а что, по вашему в Англии/США/Германии/etc... нет криворуких админов? ;)Было высокое мнение о Англии, но теперь точно уверен что криворукие админы есть везде :(, и даже там.
> Как так!Тупые, сэр.
exim более гибкий MTA, адекватно его лучше использловать на шлюзах.А вот для связки с dovecot, postfix подходит лучше, так конфиги по синтаксису схожи.
> exim более гибкий MTA, адекватно его лучше использловать на шлюзах.
> А вот для связки с dovecot, postfix подходит лучше, так конфиги по
> синтаксису схожи.Зато у вас неров лич^W хардкодед задержка в очереди :)
П.С гибкий примерно как опенбсд :)))
> exim более гибкий MTA, адекватно его лучше использловать на шлюзах.Напуркуа на шлюзе гибкость?!?!?
На шлюзе должна стоять железка которая мрёт только с дэйтаценром расплавренном ядрЁнной бомбой. -> postfix и ничего другого!> А вот для связки с dovecot, postfix подходит лучше, так конфиги по синтаксису схожи.
А вот внутри часто просят него нить странного. Тут можно и есим, то что он чибче я и не спорю.
IMNHO.
postfix forever.
по синтаксу конфига exim-a можно пару докторских защитить, осилить не вопрос, но забивать себе моск этим извратом неохота.
То что можно сделать используя макросы exim, для postfix придеться скрипт писать и подключать его.
> по синтаксу конфига exim-a можно пару докторских защититьДа бросьте. У экзима тривиальнейший синтаксис конфига. То-есть, реально простейший возможный. Но вот то, что отдельные умельцы злоупотребляют инклудами и городят иерархию включений мелких файликов в десять этажей, да еще и скриптуют совершенно статичные вещи - это проблемы совсем не экзима.
> И, ИМХО, Постфикс все-таки более гибок в настройке, чем Эксимв каком месте? postfix прямолинейный как бревно, поэтому и проще в освоении. Но гибкости к сожалению у него нет.
Для блондинок постфикса с головой
Согласен, все кто минусует и пишит посты "postfix forever", вы сначала попробуйте сам exim, просмотрите MAN и сами поймете насколько это гибкий и удобный MTA. Я думаю многие, кто переходили на exim сначала использовали postfix и я в том числе.Если представить, так:
- sendmail(очень гибкий, но сложный в настройке)
- postfix(средней гибкости, но прост в настройке), то- exim (очень гибкий и немного сложнее в настройке, чем postfix), т.е. он находится где-то между ними.
> Если представить, так:А если по количеству remote root, то посредине или лидирует?
> А если по количеству remote root, то посредине или лидирует?У вас какая-то психологическая травма на этой почве? В каждой теме об экзиме непременно найдутся ваши заезженые пять копеек.
>> А если по количеству remote root, то посредине или лидирует?
> У вас какая-то психологическая травма на этой почве?Дыркозатыкательская.
А вот Вы пугаете такими вопросами.
>>Проблему спама можно было бы решить давно (не знаю как именно, но знаю что >можно)Посмеялся от души!