Представлен (http://undeadly.org/cgi?action=article&sid=20140305164835) выпуск почтового сервера OpenSMTPD 5.4.2 (http://www.opensmtpd.org/), развиваемого под эгидой проекта OpenBSD и нацеленного на создание простой и безопасной замены Sendmail. Сервер поддерживает большую часть требований RFC 5321 (https://tools.ietf.org/html/rfc5321) и реализует ряд используемых повсеместно расширений протокола, в том числе предоставляет поддержку аутентификацию пользователей (SMTP AUTH), SSL/TLS шифрование трафика, реализация блокирования спама по "серым спискам" через интеграцию со spamd (http://www.openbsd.org/cgi-bin/man.cgi?query=spamd). Для пользователей систем, отличных от OpenBSD, развивается переносимая версия (http://www.opensmtpd.org/portable.html) OpenSMTPD.
В новой версии представлена поддержка TLS-расширения SNI (Server Name Indication), которое позволяет обеспечить доступ через шифрованное соединение к виртуальным хостам на одном IP. Реализована начальная поддержка механизма уведомления о доставке DSN (Delivery Status Notification) и расширенных кодов статуса (Enhanced Status Codes). Добавлен вывод статуса процессов через команду "smtpctl show status". Продолжается развитие экспериментальных бэкендов для хранения таблиц в Redis,
SQLite, LDAP, PostgreSQL и SOCKETMAP.URL: http://undeadly.org/cgi?action=article&sid=20140305164835
Новость: http://www.opennet.me/opennews/art.shtml?num=39256
заменил им sendmail в openbsd, поскольку мне не нужен ни первый, ни второй. :)
конфиги - впечатляют. :)
Конфиги действительно впечатляют.
По сравнению с этим получеловечеким недоязыком sendmail.cf прост и понятен как 5 копеек.
Если тебе даже такой шедевр простоты и логичности не осилить ... иди в ассенизатору ужо.
Смотрите сами, как по мне даже жена осилит:
http://www.opensmtpd.org/smtpd.conf.5.html
Обманчивая у них простота. Нерегулярный он уж очень.
О!Спец по sendmail.cf!
Как мне настроить мой штатный системный vi, чтобы я видел, где табуляция, а где -- пробелы?
Ведь в sendmail.cf они же несут разную семантическую нагрузку, не так ли?
Несут, табы разделяют LHS, RHS и комменты, пробелы внутри каждой из этих частей - по желанию вставляются для лучшей читабельности.
А зачем их видеть, и так же очевидно где должно быть одно а где другое.
R $+ @ foo.com $1 @ bar.com user@foo.com -> user@bar.com
Каким тут образом можно спутать одно с другим? Если визуально разделение частей недостаточно, табов можно вставлять сколько надо. И на другие строки переносить тоже, только начинать строку с таба и пробела соответственно, или с нескольких.
>Маленькая Серая Мышка... да ладно - мыши столько не живут :)
Конфиг сендмыла читать без боли в анусе могут только 40-летние дядьки, так что хоть розовым поняшей назовись - спалишься :)
>>Маленькая Серая Мышка
> ... да ладно - мыши столько не живут :)Он[о] _мёртвая маленькая зверушка. Undead.
Да нет, есть достаточно молодые люди, имеющие собственное мнение и не желающие бежать в толпе, какой бы модной она не была.А sendmail.cf читать легко и просто если уяснить для себя что это слегка упрощенный РЕФАЛ.
> Спец по sendmail.cf!
> Как мне настроить мой штатный системный vi,Там не vim что ли?
> чтобы я видел, где табуляция, а где -- пробелы?
http://www.opennet.me/openforum/vsluhforumID3/94481.html#158 ?
+ google://vi visible tabs ??
> Там не vim что ли?Когда-то за редактирование системных конфигов vim-ом (а не vi) били по рукам линейкой, больно.
Брееехлооо :)
Ну хорошо, не очень больно.
> Когда-то за редактирование системных конфигов vim-ом (а не vi) били по рукам
> линейкой, больно.не знаю. вот кабысдохи от vim-lite наблюдал, да.
Как-то больше на велосипед похоже. Есть куча почтовиков с уже заявленными возможностями, а у SMTPD поддержка sql и ldap бэкендов еще только в планах.
>Как-то больше на велосипед похоже. Есть куча почтовиков с уже заявленными возможностями, а у SMTPD поддержка sql и ldap бэкендов еще только в планах.У OpenSMTPd конфиг гораздо нагляднее, чем у Postfix и Exim. У Postfix ACL'и не гибкие, "дубовые", а наличие Milter лишь усложняет понимание работы ACL'ей. У Exim ACL'и излишне сложны даже тогда, когда нужно сделать что-то простое. OpenSMTPd - это тот проект, который может показать, что сложное может быть простым.
В том что проще и нягляднее _для чтения_ - соглашусь полностью.
А вот если на нём писать - тут как бы не наоборот. Не вполне понятно будет ли такая или эдакая конструкция, чуть сложней самой примитивной, работать и, в некоторых случаях, как именно. А в случае настройки почтового сервера хотелось бы как раз максимальной предсказуемости, пусть и за счет элегантности и краткости.
>Как-то больше на велосипед похоже.Ты цели проекта читал? Это НЕ планировалось для установки на гигантские мэйл хабы. Это чтобы твой серверок мог отправить статус или алёрт какой админу. Ну чуть больше.
Для отсылания инфы админу достаточно ssmtp :)
А для надежного отсылания?
А для SMS?
Лучше бы сразу другой протокол пилили, несовместимый с дырявым SMTP.
В каком именно месте вы обнаружили дырявость протокола SMTP?
В принципе доверия отправителю.
DKIM, SPF же есть.
dkim и spf это хорошо, но толку от них немного. закручиваем гайки -- остаёмся без части корреспонденции, а так как оставаться без корреспонденции хуже чем получать лишнего -- гайки не закручиваются и ничего не меняется. dkim и spf могут выступать как подспорье для антиспам-решения, но целиком только лишь ими решать проблему спама сложно.
>закручиваем гайки -- остаёмся без части корреспонденцииНикоим образом SPF и DKIM не оставят вас без части корреспонденции, эти протоколы лишь подтверждают валидность отправителя, то есть вопрос доверия отправителю с помощью этого решается.
>>закручиваем гайки -- остаёмся без части корреспонденции
> Никоим образом SPF и DKIM не оставят вас без части корреспонденции, эти
> протоколы лишь подтверждают валидность отправителя, то есть вопрос доверия отправителю
> с помощью этого решается.SPF и DKIM может настроить любой спамер. Валидность подтверждена, а доверия по прежнему нет. Спам - он как DDoS-атаки - не устраним в принципе. Любой отправитель может послать письмо любому получателю. Любой IP-узел может послать IP-пакет любому IP-узлу. Замена протокола SMTP ничего не даст.
> SPF и DKIM может настроить любой спамер.НО есть ньюанс. Впрочем тебе вероятно его понять не дано.
> dkim и spf это хорошо, но толку от них немного. закручиваем гайки
> -- остаёмся без части корреспонденции, а так как оставаться без корреспонденции
> хуже чем получать лишнего -- гайки не закручиваются и ничего не
> меняется. dkim и spf могут выступать как подспорье для антиспам-решения, но
> целиком только лишь ими решать проблему спама сложно.Не надо закручивать гайки. Надо создавать на основе наличия PTR/SPF/DKIM/чужих блеклистов "репутацию" письма, и при хреновой репутации - ронять в спамбокс, а при нормальной - впускать в инбокс. Все, кто этому правилу не следует (а особенно клинические идиоты, блочащие наотрез по чужим спискам) - обречены на потерю части корреспонденции. С беспощадно банящими бесплатниками типа мыльцару песня другая - там нахаляву и уксус сладкий, и кто ими пользуется - позволить себе роскошь не получить часть почты вполне могут, просто в силу малой важности почтового обмена.
> Надо создавать на основе наличия PTR/SPF/DKIM/чужих блеклистов
> "репутацию" письма, и при хреновой репутации - ронять в спамбокс, а
> при нормальной - впускать в инбокс.Спасибо Капитан!
>Все, кто этому правилу не следует (а особенно клинические идиоты,
> блочащие наотрез по чужим спискам) - обречены на потерю части корреспонденции.А все кто следует всегда заняты - подкручивают веса чтобы зааджастить очередной плюк :)
Счастья нет Кэп, покой нам только снится :)> позволить себе роскошь не получить часть почты вполне могут,
> просто в силу малой важности почтового обмена.Это у дураков \ салабонов. У взрослых дяденек партнеры от которых почту нельзя терять сидят себе в WL-ях. А ви таки не знали?
> В принципе доверия отправителю.О, Вы тоже паспорт предъявляете когда письмо в почтовый ящик бросаете!?!?!?
> О, Вы тоже паспорт предъявляете когда письмо в почтовый ящик бросаете!?!?!?Почтовому ящику? Оригинально.
>> О, Вы тоже паспорт предъявляете когда письмо в почтовый ящик бросаете!?!?!?
> Почтовому ящику? Оригинально.Да, но только если у него есть IP-шник ;)
Оригинально, но немного страшновато :(
раз уже взялись за что-то настолько архаичное, как почта, могли бы хоть его производительным сделать. я говорю про мультитредовость. а так игрушка какая-то...
> раз уже взялись за что-то настолько архаичное, как почта, могли бы хоть
> его производительным сделать. я говорю про мультитредовость. а так игрушка какая-то...Вам-таки решительно недостает производительности почтового сервера на никсах? Или вы, страшно сказать, Аутглюк используете? Или ОС у Вас - винда?
В иных случаях мультитредовость как бы и ни к чему на почтовом сервере. Исключение, конечно - от 300 писем в секунду постоянно...
300 в секунду - где-то миллион в час... это штатная нагрузка для небольшой соц.сети. никсы всегда славились тем, что как раз такие нагрузки они могут выдерживать.
А разве в соц. сети используются не web-решения, а именно почтовый сервер, в более стандартном понимании этого слова? Web-решение отличается, на мой взгляд, возможностью горизонтального масштабирования в том числе и (веб)почты и не требует одиночного мощного почтового сервера, позволяя иметь взамен несколько маломощных...
В моем понимании, мощный почтовик - это решение, рассчитанное на ~300 писем в секунду постоянно, с пиками до 500-600, и средним размером письма порядка 50 Kb при максимальном 20 Mb. Причем никсы (postfix, в частности) это вполне тянут, не требуя топового железа и мультитреда.
Другое дело, что при среднем размере письма в 5Mb все резко ухудшается... Но тут, боюсь, и мультитред не поможет - только масштабирование...
> А разве в соц. сети используются не web-решения, а именно почтовый сервер,
> в более стандартном понимании этого слова?Имхо, нет, т.к. есть чисто SMTP функционал, который в вебчасти нет смысла реализовывать. Например, почтовые очереди или callback verification. Опять же демон на C будет заметно быстрее.
> возможностью горизонтального масштабирования в том числе и (веб)почты и не требует
> одиночного мощного почтового сервера, позволяя иметь взамен несколько маломощных...Т.е. почтовик не может использовать все имеющиеся ядра CPU и упирается в тактовую частоту одного из них, поэтому мы поставим рядом несколько серверов, которые будут частично простаивать?
> В моем понимании, мощный почтовик - это решение, рассчитанное на ~300 писем
> в секунду постоянно, с пиками до 500-600, и средним размером письма
> порядка 50 Kb при максимальном 20 Mb. Причем никсы (postfix, в
> частности) это вполне тянут, не требуя топового железа и мультитреда.Что топовое, а что среднее железо? Да, современные серверы даже средние дают хорошие результаты с postfix, но разве это повод теперь писать программы, как в эпоху одноядерных CPU? Работать-то всеравно будет неэффективно. А никсы всегда справлялись с высокой нагрузкой благодаря эффективности.
Если ты можешь поставить несколько серверов с MTA и сбалансировать нагрузку между ними, то что мешает поднять несколько инстансов MTA по числу ядер на одном сервере и точно так же сбалансировать нагрузку?
> раз уже взялись за что-то настолько архаичное, как почта, могли бы хоть
> его производительным сделать. я говорю про мультитредовость. а так игрушка какая-то...Исторически сложилась такая ситуация, что к почтовым серверам предъявляются высокие требования в аспекте безопасности и надёжности, а не производительности. Многопоточность - это небезопасное решение, т.к. один клиент, эксплуатирующий дыру в сервере, может его уронить или рассылать через него спам. Согласитесь, когда можно нанести ущерб третьей стороне, к безопасности нельзя относиться столь беспечно.
Другое дело - эти ваши веб-серверы, где третьей стороны кроме клиента и сервера нет, а в случае неполадки клиент просто запросит ту же страницу повторно. Однако я всё равно предпочитаю использовать многопроцессный php-fpm вместо mod_php в многопоточном Apache. Так безопаснее и надёжнее будет.
Тут видимо господин хороший, который писал про "могли бы мультитредовость", не отличает многопроцессность от многопоточности. Это вам не винда, где на запуск копии процесса оверхед такой, что можно сразу стреляться.
//это если я конечно не протупил, и оно действительно не в один процесс все жует. тогда тег "ненужно" к статье будет достаточно актуальным////оффтопично// Ну а mod_php в многопоточном апаче - это и вообще путь истинный для истинных божественных ветров.
> Тут видимо господин хороший, который писал про "могли бы мультитредовость", не отличает
> многопроцессность от многопоточности. Это вам не винда, где на запуск копии
> процесса оверхед такой, что можно сразу стреляться.
> //это если я конечно не протупил, и оно действительно не в один
> процесс все жует. тогда тег "ненужно" к статье будет достаточно актуальным//
> //оффтопично// Ну а mod_php в многопоточном апаче - это и вообще путь
> истинный для истинных божественных ветров.Это я тот хороший господин. Я не знаю, протупил ты или нет, но могу сказать, что на обработку SMTP там один процесс с полингом.
> Это я тот хороший господин. Я не знаю, протупил ты или нет,
> но могу сказать, что на обработку SMTP там один процесс с
> полингом.Ну поллинг поллингу тоже рознь. FSM-модель у нгинха тоже как бы подразумевает один мастер-процесс на CPU.
Еще какая рознь.
"The Intel DPDK implements a low overhead run-to-completion model for fast data plane performance and accesses devices via polling to eliminate the performance overhead of interrupt processing."
> Еще какая рознь.
> "The Intel DPDK implements a low overhead run-to-completion model for fast data
> plane performance and accesses devices via polling to eliminate the performance
> overhead of interrupt processing."Я почитал по ссылке, но не сказать, что уловил мысль. Т.е. ты хочешь сказать, что вот Intel предлагает фреймворк, который позволяет писать приложения с очень эффективным поллингом? Что такое data plane?
> Я почитал по ссылке, но не сказать, что уловил мысль. Т.е. ты
> хочешь сказать, что вот Intel предлагает фреймворк, который позволяет писать приложения
> с очень эффективным поллингом?Да.
>Что такое data plane?
Тот который не control plane.
http://networkstatic.net/the-control-plane-data-plane-and-fo.../
>> Это я тот хороший господин. Я не знаю, протупил ты или нет,
>> но могу сказать, что на обработку SMTP там один процесс с
>> полингом.
> Ну поллинг поллингу тоже рознь. FSM-модель у нгинха тоже как бы подразумевает
> один мастер-процесс на CPU.Хорошо, пусть так, но потом-то реквест распределяется по куче воркеров, а в случае с opensmtpd, postfix, sendmail... только один, условно говоря, qmgr процесс.
Это выше ваш собеседник неверно выразился. Мастер-процесс один, воркеров принято плодить по одному на ядро CPU.