Gilles Chehade, один из разработчиков OpenBSD, импортировал (http://undeadly.org/cgi?action=article&sid=20081112084647) в базовый CVS-репозиторий проекта новый SMTP-сервер. Причиной создание новой программы послужило желание создать простой и безопасный SMTP-сервер, распространяемый под открытой лицензией. Gilles в течение 5 лет использовал Postfix, но испытывал дискомфорт из-за невозможности включить его в состав базовой системы OpenBSD, связанной с лицензионными ограничениями. Postfix распространяется под лицензией IBM Public License (ftp://ftp.porcupine.org/mirrors/postfix-release/LICENSE), отличающейся более жесткими требованиями по возврату изменений в основную ветку разработки.
Sendmail, включенный в состав OpenBSD, не выдерживает критики, как с точки зрения безопасности, так и с точки зрения удобства настройки. В итоге, намучившись с sendmail, Gilles Chehade распечатал rfc2821 и за пару часов, в порыве вдохновения, написал каркас простейшего SMTP сервера. Через некоторое вре...URL: http://undeadly.org/cgi?action=article&sid=20081112084647
Новость: http://www.opennet.me/opennews/art.shtml?num=18900
Почему не захотели развивать qmail - он ведь теперь под public domain ?
смысла нет - он сам без патчей на крайне начальном уровне развития. проще написать свой.
На мой взгляд, у qmail офигенная идея и хорошая (с оговорками) реализация. Но реализация отстала лет на 10 от реальности, в этом основная проблема.
Во-первых, public domain не есть лицензия. Во-вторых, вы не найдёте qmail даже в портах OpenBSD - разработчики последней разругались с разработчиком первого. Впрочем, это не мешает некоторым из них использовать qmail на своих серверах. :)
вот это здорово!
indeed, будем ждать включения в базовую сборку
>indeed, будем ждать включения в базовую сборкуcd /usr/src/usr.sbin/smtpd && make obj && make && sudo make install
читайте ниже свой собственный пост
>читайте ниже свой собственный постДля самых умных: наличие кода в CVS не означает, что этот код включается в релиз ОС. А выше я привёл команду, которая позволит не ждать включения сборки smtpd в релиз ОС.
Сколько пройдет времени пока станет стабильным ?
>Сколько пройдет времени пока станет стабильным ?Думаю, релиза следует ждать в 4.6 (через год то есть) - разработчики OpenBSD не отличаются привычкой выкладывать невылизанный код в релизах. :)
Протокол для обмена файлами на прикладном уровне и локально, и по сети должен быть один. Такой протокол давно уже есть: 9P и его модификации. Все, что понавалено в /etc/services, - просто блаж, отсебятина, мусор
а вам имя файла services ничего не говорит ? Помоему он указывает только на предоставляемые сервисы, а если быть точнее то порт на которм крутиться сервис, а не протокол. Более того именее файла services не гарантирует вам что вы на том же самом порту найдете тот-же сервис.
Более того на сегодняшний день везде и всюду используется практически один и тот же протокол для всех нужд, за редким исключением. Кажется он IP называется. ::))
Вы не могли-бы небольшой обзор протокола представить (в виде ссылки, например), я совсем не в курсе, большинство читателей, думаю, тоже.
>Вы не могли-бы небольшой обзор протокола представить (в виде ссылки, например), я
>совсем не в курсе, большинство читателей, думаю, тоже.http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ARC...
>Протокол для обмена файлами на прикладном уровне и локально, и по сети
>должен быть один. Такой протокол давно уже есть: 9P и его
>модификации. Все, что понавалено в /etc/services, - просто блаж, отсебятина, мусорА автомобили тоже должны быть все одинаковые? Скажем, "Газелями"?
> Протокол для обмена файламиА разве письма - это файлы?С фига ли?Письма являются файлами только в одной из инкарнаций, но строго говоря это внутреннее дело софта как оно там сохранит энное письмо.А если скажем 300 писем в одной БД лежат - тогда они что?А если письмо без сливания в файл отфутболено прямо из оперативки дальще - тогда как?А может еще IM сообщения к файлам приравнять заодно?Маньяк, безудержно бредящий P9 которому насрать на практику... =)
P.S. кстати в результате обмениваться файлами по супер-дупер протоколу придется исключительно с самим собой.Гуано с названием SMTP давно пора похоронить, хотя-бы за 5-10% КПД (90-95% спама - это жестко...) но его все таскают.Потому как обратная совместимость.Хотя этот протокол и очень настойчиво просится на свалку истории стараниями спамеров.
А что - если ты видишь письмо как /home/User239/mail/Inbox/Letter_from_telka - то оно ну просто ну никак! физически не может быть записью в db или областью памяти?
Винтузятнег!
>Винтузятнег!Сами такие.Что (с точки зрения теории, как этот Andr любит делать) мешает сложить 100 писем в одну БД?Или вообще не складывая ни в какие файлы отфутболить?Иррелевантно к операционке - оперативка и базы данных есть в любой системе и никто в принципе не обязан представлять письмо как какой-то конкретный файл.Если вашего куцего мозга не хватило на осознание данного факта - мои соболезнования.Можете и дальше считать письма файлами а меня виндузятником - мне то что?
> Можете и дальше считать письма файламиможете дальше считать /dev/ttyS0 файлами, мне то что ? :)))
аргументация в этой ветви бесподобна
>можете дальше считать /dev/ttyS0 файлами, мне то что ? :)))Это вполне себе файл, хоть и несколько специфичный.Если его конкретная инкарнация.А вот если скажем некий (абстрактный) сервак (в теории, как у Andr-а) получит от юзера письмо и сбагрит его в БД или и вовсе перешлет дальше забуферив в оперативке и вообще не сохраняя как файл и не вывешивая это в ФС в каком либо виде - то чего?Письмо само по себе файлом не является.Равно как и какой-либо набор данных просто посланый по сети.Его можно в качестве одного из представлений представить как файл.Но это далеко не единственное и не всегда наилучшее представление.Если хранить письма в ФС пофайлово - тут и slack, и фрагментация, и скорость работы здорово зависит от ФС и прочая.А по вашей логике пинги - это тоже файлы.Потому что в одном из представлений можно сбагривать каждый посланный мной icmp пакет в файл - тогда можно забубенить структуру типа /home/user/data/packets/ipv4/icmp/<type>/<date>/<time>/<src-ip>_<dst-ip>.cap :).Все, вуаля, пинги - это файлы.Поэтому согласно Andr'у заодно надо отменить нафиг и утилиту ping.А пинги передавать как файлы.Хренле... =)
Кстати еще прикол.А как вам Serial over IP?Ну допустим у нас утиля читает\пишет ttyS0 и гоняет данные между компортом и TCP конекцией (а один хрен, потоки данных).По вашему, данные которые летают в этой TCP конекции - непременно должны рассматриваться как именно файлы?А какого? :)
>аргументация в этой ветви бесподобна
Да уж.Видимо, мозг у большей части посетителей в пятницу вечером стабильно в оффлайне =)
>>можете дальше считать /dev/ttyS0 файлами, мне то что ? :)))
>
>Это вполне себе файл, хоть и несколько специфичный.вы не поняли иронии.
для меня файл - это то, что представлено в виде файлового дескриптора в ядре.
нет файлового дескриптора - это не файл. :)> (в теории, как у Andr-а)
андр излишне богат на теории, я его сообщения вообще не читаю - берегу мозг. и вам советую.
>Кстати еще прикол.А как вам Serial over IP?
кстати, прикол в том, что это было одна из первых моих задач: http://tibbo.com/vspdl.php
>Да уж.Видимо, мозг у большей части посетителей в пятницу вечером стабильно в
>оффлайне =)не знаю. я не пью. мне это противно. :(
что касается темы дискусии - вот когда он сделает чтобы там все работало, тогда и будет что обсуждать.
а так и я могу выложить свои сорцы и сказать: вот вам заготовка, давайте, фигачьте мне в нее все остальное кроме моей int main(). и тестеров побольше, побольше. потому что проект многообещающий.
>нет файлового дескриптора - это не файл. :)Тут тоже можно придумать много веселостей с такой формулировкой.Скажем файлы в архивах при этом - не файлы?Хотя до некоторой степени ведь так оно и есть :)
>андр излишне богат на теории, я его сообщения вообще не читаю -
Он иногда выдает и нечто интересное.Но часто - или откровенную дурь или изобретает то что до него изобрели давным давно а его осенило.
>берегу мозг. и вам советую.
Мне мозг трудно вынести =)
>кстати, прикол в том, что это было одна из первых моих задач:
>http://tibbo.com/vspdl.phpО как.Только это кажись "реверсная" задача - обучить софт работающий по компорту работать по TCP\IP?Я скорее говорил о работе по TCP\IP с физическим компортом (или виртуальным компортом типа любого usb2serial).При этом драйвер виртуального порта по идее не нужен - программе достаточно читать данные из сокета и порта и гонять их туда-сюда между ними.
В любом случае - респекты.>не знаю. я не пью. мне это противно. :(
Я тоже - мне мой мозг нравится работающим.
>main(). и тестеров побольше, побольше. потому что проект многообещающий.
Улыбнуло :D
>>не знаю. я не пью. мне это противно. :(
>Я тоже - мне мой мозг нравится работающим.дайте вашу руку! сколько войн было в России, три революции, 2 гражданских, несколько мировых...
>>>не знаю. я не пью. мне это противно. :(
>>Я тоже - мне мой мозг нравится работающим.
>
>дайте вашу руку! сколько войн было в России, три революции, 2 гражданских,
>несколько мировых...Кстати, да, плюс адын. Open-source против алкоголя? :)
Таки да, за отсутствием в России хорошего алкоголя... а вкус портить тем, что есть - нельзя:)
>Таки да, за отсутствием в России хорошего алкоголя... а вкус портить тем,
>что есть - нельзя:)Ммм... А у меня другая мотивация. Фармакология рассматривает спирт этиловый как классическое средство для наркоза (что совершенно верно). Имхо, человеку и так мало времени отводится, чтобы его ещё на нахождение в наркозе (преднаркозном возбуждении, постнаркозной депрессии) тратить. Я поработаю лучше. Или отдохну. С ясным, необараневшим мозгом.
> Кстати, да, плюс адын. Open-source против алкоголя? :)замутим флеш-моб на opennet по этому поводу? :)
скажем, на каждый дурацкий коммент писать:
"а я не пью, мне это противно" :)
> для меня файл - это то, что представлено в виде файлового дескриптора в ядреТ.е. на выключенной машине (где ядро не запущено) файлов нет?
Кстати, файловый дескриптор бывает только у открытого файла.
Вы знаете, смысл в его словах все таки есть.
Файлы может быть на выключенной машине и есть, но значение их можно рассматривать только в рамках увеличения энтропии.
Иначе говоря файл как таковой, как сущность полезна нам только на загруженной системе.
Это же касается и - "открытый закрытый файл".Ио есть если с фалом проводится работа - полезная работа именно с сущностью файла (а не скажем хранение, копирование) он всегда будет иметь дескриптор. Как и ttyS0
>[оверквотинг удален]
>БД лежат - тогда они что?А если письмо без сливания в
>файл отфутболено прямо из оперативки дальще - тогда как?А может еще
>IM сообщения к файлам приравнять заодно?Маньяк, безудержно бредящий P9 которому насрать
>на практику... =)
>
>P.S. кстати в результате обмениваться файлами по супер-дупер протоколу придется исключительно с
>самим собой.Гуано с названием SMTP давно пора похоронить, хотя-бы за 5-10%
>КПД (90-95% спама - это жестко...) но его все таскают.Потому как
>обратная совместимость.Хотя этот протокол и очень настойчиво просится на свалку истории
>стараниями спамеров.Хм. Даже в голову не пришло, что речь шла про SMTP, по инерции от коммента выше думал, что речь идёт о взаимодействии процессов smtpd... :-D В таком случае полностью присоединяюсь к вашим замечаниям :))
>инерции от коммента выше думал, что речь идёт о взаимодействии процессов
>smtpd... :-DМне кажется что Andr будучи истинным академиком (при том в хучшей форме - ему главное чтобы красиво в теории а что будет на практике глубоко пофиг) предложил передавать всю почту как именно файлы через упомянутый им протокол.Или я не вкурил в его полет мысли (у меня все-таки не настолько извращенное мышление :D).
>>инерции от коммента выше думал, что речь идёт о взаимодействии процессов
>>smtpd... :-D
>
>Мне кажется что Andr будучи истинным академиком (при том в хучшей форме
>- ему главное чтобы красиво в теории а что будет на
>практике глубоко пофиг) предложил передавать всю почту как именно файлы через
>упомянутый им протокол.Или я не вкурил в его полет мысли (у
>меня все-таки не настолько извращенное мышление :D).Вот-вот, уж на что меня давно кличут извращенцем, но чего-то в изложенной идее кто-то из нас явно не понимает. Хотя то, что Plan9 всё ещё живой, ещё позволяет надеяться, что и оттуда выйдет что-то ценное...
> Гуано с названием SMTP давно пора похоронить, хотя-бы за 5-10% КПД (90-95% спама - это жестко...)Рассмотрим функциональность, которую бизнес получает от SMTP. Фирма публикует адрес для связи, и любой желающий может послать на этот адрес запрос. Но любой протокол, позволяющий опубликовать адрес для того, чтобы по нему мог законнектиться любой желающий, немедленно создаст возможность спама. ICQ избавилась от спама благодаря ограничению входящих коннектов списком друзей, и не может заменить SMTP; а отказ от такого ограничения приведёт к спаму в ICQ.
В настоящее время единственный реальный путь снизить количество спама - это заставить провайдеров перестать быть лояльными к ботнетам. IMHO, это надо делать на законодательном уровне, начав с включение в провайдерскую лицензию запрета открывать SMTP:25 тем юзерам, которые не просили явно открыть им этот сервис. Нормальные юзеры ничего не потеряют, а ботнеты вмиг накроются.
Далее надо будет закрыть SMTP:25 на пограничных роутерах для тех стран, правительства которых не приняли подобного закона; можно сделать исключения для заведомо благонадёжных серверов. Можно закрывать SMTP:25 не всей стране, а только провайдерам, которые не присоединились к соглашению о борьбе со спамботами.
>> Гуано с названием SMTP давно пора похоронить, хотя-бы за 5-10% КПД (90-95% спама - это жестко...)
>
>Рассмотрим функциональность, которую бизнес получает от SMTP. Фирма публикует адрес для связи,
>и любой желающий может послать на этот адрес запрос. Но любой
>протокол, позволяющий опубликовать адрес для того, чтобы по нему мог законнектиться
>любой желающий, немедленно создаст возможность спама. ICQ избавилась от спама благодаря
>ограничению входящих коннектов списком друзей, и не может заменить SMTP; а
>отказ от такого ограничения приведёт к спаму в ICQ.
>rfc 2505 определяет возможность отказа в обслуживании для сетей, доменов.
Отсюда неявно следует что раз есть возможность, политика приёма почты может быть реализована и по сценарию accept whitelist -> deny all.>В настоящее время единственный реальный путь снизить количество спама - это заставить
>провайдеров перестать быть лояльными к ботнетам. IMHO, это надо делать на
>законодательном уровне, начав с включение в провайдерскую лицензию запрета открывать SMTP:25
>тем юзерам, которые не просили явно открыть им этот сервис. Нормальные
>юзеры ничего не потеряют, а ботнеты вмиг накроются.
>Вряд ли это возможно. Ботнеты строятся и из незащищённых хостов пользователей,пользователи не действуют со злым умыслом, могут быть некомпетентны в этом вопросе.
>Далее надо будет закрыть SMTP:25 на пограничных роутерах для тех стран, правительства
>которых не приняли подобного закона; можно сделать исключения для заведомо благонадёжных
>серверов. Можно закрывать SMTP:25 не всей стране, а только провайдерам, которые
>не присоединились к соглашению о борьбе со спамботами.Совсем круто.
IMHO достаточно уже придумано.
Допустим провайдер предосталяет свой smtp сервис как гарантирующий релей, естественно прописав в договоре условия использования, стоимость, и решает вопросы при недоставке клиентских сообщений.
Конечный mail hub не гарантирует приёма сообщений любого адресата.Есть другое мнение - отправить письмо стоит денег (пусть небольших), как на почте.
Массовые рассылки станут дорогим удовольствием.
>Вряд ли это возможно. Ботнеты строятся и из незащищённых хостов пользователей,пользователи не
>действуют со злым умыслом, могут быть некомпетентны в этом вопросе.Более того - весь этот гениальный трах на который будет спущено полно бабла приведет к простой схеме: бот будет выдирать настройки прововского smtp из почтовика и юзать его.Думаете, спамерам принципиально через какой сервак спамить?Если юзер может послать сообщение - это может и спамер от его лица, сделав те же самые действия.Какие проблемы то?
...
>В настоящее время единственный реальный путь снизить количество спама - это заставить
>провайдеров перестать быть лояльными к ботнетам. IMHO, это надо делать на
>законодательном уровне, начав с включение в провайдерскую лицензию запрета открывать SMTP:25
>тем юзерам, которые не просили явно открыть им этот сервис. Нормальные
>юзеры ничего не потеряют, а ботнеты вмиг накроются....
Пока провайдеры получают бабло за трафик, они на это не пойдут. Чем плотнее забит канал тем больше прибыль. А чем он забит - неважно.
Ситуация меняется прямо на противоположную при тотальном использовании безлимитки. И тут уже провайдеров не нужно ни о чем просить. Сами урезают всё что только можно. Вспомните скандалы с обиженными пользователями пиринговых сетей, который один из американских провайдеров перекрыл кислород.
>провайдеров не нужно ни о чем просить. Сами урезают всё что
>только можно. Вспомните скандалы с обиженными пользователями пиринговых сетей, который один
>из американских провайдеров перекрыл кислород.Но это скандал. А цивилизовано провайдер может тарифицировать smtp трафик на безлимитке отдельно через договор.
Простой пользователь заплатит копейки.
На пользователя с закладками на компьютере подействует счёт, он обратиться за разъяснениями и помощью.
Кому нравится - пусть платят, от них принимать не обязаны.
>Кому нравится - пусть платят, от них принимать не обязаны.А вы не думали что в условиях конкуренции геморройный и жадный провайдер просто будет послан нафиг?И кстати спамеров в последнюю очередь колебет сколько заплатит юзер а то что юзеры будут пинаться в судах с провайдерами за предоставление услуг которые никто не просил - опять же, спамеры посмеются да будут считать бабло.А вы там пинайтесь как хотите - не их проблемы.
>отказ от такого ограничения приведёт к спаму в ICQ.Уже придумано миллион методов испортить спамерам жизнь.Как то капчи, вопрос-ответы и т.п. на уровне протокола для проверки что с той стороны провода писал письмо не робот.А свобода общения чтобы без них - только после одобрения реципиентом что он и далее хочет с вами общаться по типу контакт-листа. Вот тогда спамеры всосут (простите, или вы робот или уж вы умеете отвечать на вопросы). Как ни крутите но если можно срать без подтверждения реципиентам - будут срать, без подтверждения реципиентами, соответственно.А то что SMTP делался без учета абузивного использования хрен знает когда и не предоставляет внятных возможностей это забороть хотя его уже густо утыкали костылями - так это хороший повод его закопать и перекроить с нуля.Сделав его простым для серверов, компактным для тех у кого трафф (например зачем хреначить ююки по 8-битным каналам?) и крайне неудобным для спамеров.
>В настоящее время единственный реальный путь снизить количество спама - это заставить
>провайдеров перестать быть лояльными к ботнетам.Любите бороться с ветряными мельницами?Боритесь!Но мой прогноз такой: толку с этого будет ноль целых, хрен десятых.Спамерам НАСРАТЬ что случится с протроянеными клиентами.Будут ли их отключать.Или что там еще.
>IMHO, это надо делать на законодательном уровне,
Ничего умнее мы конечно не придумали.Дефективность протокола мы скомпенсируем законами.Это шедеврально, да.Лучше тогда просто ввести расстрел без суда и следствия для спамеров - так намного эффективнее будет имхо.
>начав с включение в провайдерскую лицензию запрета открывать SMTP:25
>тем юзерам, которые не просили явно открыть им этот сервис. Нормальные
>юзеры ничего не потеряют, а ботнеты вмиг накроются.Ага, только вот если провайдер - урод, я буду сосать с их спамодавками или глючными антивирями гробящими мои легитимные сообщения.Это уже проходили, спасибо.Идите нафиг с вашим вырезанием гланд через попу автогеном.Это всего лишь очередной костыль с которым к тому же можно хлебнуть горя по полной, особенно с провайдером у которого хреновые админы.
>Далее надо будет закрыть SMTP:25 на пограничных роутерах для тех стран, правительства
>которых не приняли подобного закона;Для тупых намекаю: цифра 25 ничем таким не хуже любой другой.А то что протокол дефективный - ну знаете ли, может логично бороться не с следствием а с причиной? :)
Как вы думаете вообще - кому будет нужна почта которая не ходит и которую крайне геморройно использовать?Правильно - если сделать вот так - оно вмиг подохнет и тут же нарисуется проприетарное гогно которое эту проблему дескать для энтерпрайзов кульно решает.Потому что энтерпрайзам надо работать.А не разруливать выкрутасы красноглазых дрочеров с резками портов вон той стране.Понимаете, бизнес не может себе позволить роскоши не иметь дело вон с той страной только потому что там дескать спамеры.Так что вы с таким начинанием нагреете сугубо сами себя.>можно сделать исключения для заведомо благонадёжных
>серверов.Это которые ФСБ взяло под свое крылышко?Благодарю покорно, идите ка вы лесом с такими затеями.
>Можно закрывать SMTP:25 не всей стране, а только провайдерам, которые
>не присоединились к соглашению о борьбе со спамботами.Я все-таки предлагаю просто расстреливать спамеров.И тех кто заказывает рассылки.На порядок эффективнее и намного менее геморройно технически.
>Ничего умнее мы конечно не придумали.Дефективность протокола мы скомпенсируем законами.Насчёт дефективности хотябы:
1) Протокол прост.
2) Протокол разработан с возможности доставки сообщения из среды, которой доверяет отправитель, сразу в среду, которой доверяет получатель.
Этим пользуются спамеры, но разрабатывали умные люди, они не , по моему мнению, не смогли предложить простой концепции конверта, защищающего от прочтения на узлах пересылки.Вы имеете что либо предложить на том же уровне сложности? Лично я нет.
>Насчёт дефективности хотябы:
>1) Протокол прост.Это смотря с какой стороны посмотреть.В минимальной реализации - да.А если густо обвешать костылями типа спамодавов, блэклистов, вспомнить про всякие multipart\mixed сообщения, UU-кодирование и base-кодирование и густой набор связанных RFC, правил и прочая... - это просто кусок гуано обвешаный до посинения костылями чтобы хоть как-то могло работать в современных реалиях.При том половина костылей - откровенное легаси а протоколы из выводка SMTP и POP3 тупо не соответствует современным реалиям.
Что?Вы хотите отправить или получить 10 мегов фоток да не дай боже еще и по жпрс или диалапу?А вот хрен вам - докачка не поддерживается.А файлы еще и распухнут на треть за счет uu-кодирования или mime кодирования чтобы подсластить вам жизню.Ну а то что вы отлупили письмо - вовсе не гарантия того что его доставят.В лучшем случае через несколько дней (всего-то) вам приедет характерный квиток от софта с промежуточного релея о том что он дескать обломался при доставке почты.В хучшем - будете гадать на кофейной гуще, дошло сообщение или нет.Какой офигительный протокол, ага... :)
>2) Протокол разработан с возможности доставки сообщения из среды, которой доверяет отправитель,
>сразу в среду, которой доверяет получатель.Проблема только одна - с академической точки зрения все зашибись а на практике - 90% всей корреспонденции в итоге спам.Сферические кони в вакууме - рулят!
>Этим пользуются спамеры, но разрабатывали умные люди, они не , по моему
>мнению, не смогли предложить простой концепции конверта, защищающего от прочтения на
>узлах пересылки.По моему мнению - эти люди просто не думали о возможности того что их протокол может быть использован не только так как они задумали.Хорошо спроектированный протокол должен быть более-менее абузоустойчивым.Конечно хорошо верить что все люди - белые и пушистые.Но вы ведь врядли пойдете в неблагополучный район демонстративно понабив в карманы пачки денег и обвешавшись по уши золотом, правда?Потому что обычно соображалка подскажет что это - чревато.Ну вот соображалка разработчика протокола должна подсказывать оному что не все люди идеальные и их протокол будет использоваться по разному.Да, когда разрабатывали SMTP об этом не думали.Но тогда нафиг за такой дефективный и не соответствующий реалиям протокол хвататься с таким упорством?Закопать и задизайнить заново - проведя работу над ошибками...
>Вы имеете что либо предложить на том же уровне сложности? Лично я
>нет.Одно дело - иметь что предложить а другое убедить всех что им надо именно это.Пока почему-то все упорно цепляются за древнее говно.Вот такой жестокой некрофилии с элементами садо-мазо (а как еще назвать когда протокол гоняет более 90% спама а обладатели серверов согласны эту бесполезную работу оплачивать из своего кармана) я чесслово не понимаю.
>[оверквотинг удален]
>БД лежат - тогда они что?А если письмо без сливания в
>файл отфутболено прямо из оперативки дальще - тогда как?А может еще
>IM сообщения к файлам приравнять заодно?Маньяк, безудержно бредящий P9 которому насрать
>на практику... =)
>
>P.S. кстати в результате обмениваться файлами по супер-дупер протоколу придется исключительно с
>самим собой.Гуано с названием SMTP давно пора похоронить, хотя-бы за 5-10%
>КПД (90-95% спама - это жестко...) но его все таскают.Потому как
>обратная совместимость.Хотя этот протокол и очень настойчиво просится на свалку истории
>стараниями спамеров.Это спаммеры просятся на свалку истории стараниями мериканского ФБР:
http://www.lenta.ru/news/2008/11/13/mccolo/
>Это спаммеры просятся на свалку истории стараниями мериканского ФБР:Это называется пир во время чумы?Вот когда и если SMTP перестанет гонять 90% спама и 10% полезной почты - заявы про спам и историю будут чем-то чем попыткой прикрыть дефекты старикана и бахвальством.Но мне кажется что раньше подохнет SMTP поскольку это как с комарами - теоретически перебить всех комаров на Земле - можно.А практически - ну попробуйте, ага.Ключевая фраза в этой ссылке:
"Но вскоре количество спама в интернете вернулось на прежний уровень."
И так будет.ФБР может хоть в лепешку расшибиться.И кроме того - я посмотрю что они будут делать когда хацкеров-срацкеров это задолбает и они сделают истинно децентрализованные системы по типу P2P где накрывать центры управления тупо невозможно - за их отсутствием.Учтя что они до этого уже почти дотумкали... ну да, они еще не придумали как надежно организовать управление по P2P принципу без центров управления.Но на самом деле - все просто и они однажды додумаются до того как это сделать.
В концепции Unix, DOS, Windows и большинства современных операционок "файл" рассматривается как "неструктурированный набор байтов". Но большинство данных структурировано на уровне протокола: например, в письме есть заголовок (состоящий из многих полей вида "имя_поля: значение" или "имя_поля: параметр=значение", возможны варианты) и есть компоненты (текст письма в PlainText, текст письма в HTML, аттачи). Так что для почты (и для большинства др.задач) протокол обмена файлами не годится.Это похоже на то, что IP не годится для обмена данными - над ним надо надстраивать TCP или UDP, а сверху ещё что-то.
PS: Универсального протокола быть не может, т.к. у разных задач разные требования к протоколу. Например, одни задачи ждут от протокола экономности трафика, другие - богатства встроенных в протокол функций.
>> и за пару часов, в порыве вдохновения,
>> написал каркас простейшего SMTP сервера.
>А вот без этого выеб...на ну никак нельзя было пропиариться!Ну вообще за пару часов написать SMTP сервер ... - впечатляет.
>>> и за пару часов, в порыве вдохновения,
>>> написал каркас простейшего SMTP сервера.
>>А вот без этого выеб...на ну никак нельзя было пропиариться!
>
>Ну вообще за пару часов написать SMTP сервер ... - впечатляет.друг, ты читаешь?! :-)) "за пару часов написал Каркас Простейшего SMTP сервера".
хотите я за 5 минут напишу каркас простейшего смтп сервера?
я уверен, остальные смогут быстрее :)
главное, сокет открыть
>хотите я за 5 минут напишу каркас простейшего смтп сервера?
>я уверен, остальные смогут быстрее :)
>главное, сокет открытьДа ладно... fork(), open(), exit(), и всё закроет ОС :)))
>>хотите я за 5 минут напишу каркас простейшего смтп сервера?
>>я уверен, остальные смогут быстрее :)
>>главное, сокет открыть
>
>Да ладно... fork(), open(), exit(), и всё закроет ОС :)))гыгы. главное - вовремя прервать. сегфолтом там или еще чем-нибудь правильным :)
>>>хотите я за 5 минут напишу каркас простейшего смтп сервера?
>>>я уверен, остальные смогут быстрее :)
>>>главное, сокет открыть
>>
>>Да ладно... fork(), open(), exit(), и всё закроет ОС :)))
>
>гыгы. главное - вовремя прервать. сегфолтом там или еще чем-нибудь правильным :)Да ладно. Вылетит по лимитам, удалённый сервер обломится и перепошлёт :))))
>хотите я за 5 минут напишу каркас простейшего смтп сервера?
>я уверен, остальные смогут быстрее :)
>главное, сокет открытьИ куда глядели мои глаза - я чётко несколько раз прочёл "закрыть"... :))))) Поэтому и ответил "странно" :)
>>> и за пару часов, в порыве вдохновения,
>>> написал каркас простейшего SMTP сервера.
>>А вот без этого выеб...на ну никак нельзя было пропиариться!
>
>Ну вообще за пару часов написать SMTP сервер ... - впечатляет.Ключевое слово "Каркас" ;)
>>Ну вообще за пару часов написать SMTP сервер ... - впечатляет.
>Ключевое слово "Каркас" ;)Да, ладно. Ключевые слова не впечатляют. :)))
>>> и за пару часов, в порыве вдохновения,
>>> написал каркас простейшего SMTP сервера.
>>А вот без этого выеб...на ну никак нельзя было пропиариться!
>
>Ну вообще за пару часов написать SMTP сервер ... - впечатляет.пара часов - это промежуток от 4 до 6 часов :)
а вообще, простейший SMTP сервер где-то столько и пишется. Доводилось :)
>>> и за пару часов, в порыве вдохновения,
>>> написал каркас простейшего SMTP сервера.
>>А вот без этого выеб...на ну никак нельзя было пропиариться!
>
>Ну вообще за пару часов написать SMTP сервер ... - впечатляет.в стиле shut up and code -)
Во молодцы. Эти ребята не ищут простых путей!Ну что, можно принимать ставки, что со временем это будет самый безопасный сервер?
Или не вытянут они?С другой стороны, а чем им exim не нравится? Вроде бы с безопасностью там все нормально. Или тоже лицензия напрягает?
Ч-ч-ч! Тихо! Спугнёте! С зарождающимися супербезопасными проектами осторожнее надо -- не знают про иксим, не надо их раздражать... Они и так еле пережили знакомство с сендмылом и почтфиксом -- уже Каркасы писать бросились. $) Что же будет, когда такие впечатлительные и креативные ребята почитают RFC про SMTP?! Ж-] А уж, когда им расскажут про спам. :-O
>Ч-ч-ч! Тихо! Спугнёте! С зарождающимися супербезопасными проектами осторожнее надо -- не знают
>про иксим, не надо их раздражать... Они и так еле пережили
>знакомство с сендмылом и почтфиксом -- уже Каркасы писать бросились. $)
>Что же будет, когда такие впечатлительные и креативные ребята почитают RFC
>про SMTP?! Ж-] А уж, когда им расскажут про спам. :-OВы собрались рассказывать про спам разработчикам системы, где spamd идёт в базовой поставке?
Насчёт Exim проблема действительно в лицензии, разработчикам OpenBSD он, насколько помню, нравится.
>Насчёт Exim проблема действительно в лицензии, разработчикам OpenBSD он, насколько помню, нравится.Ну вот, пойми их.То фаны орут что бсдшники не гордые по части лицензий, то вдруг такие слова как гром посреди ясного неба на черепушки фанатиков :)
>>Насчёт Exim проблема действительно в лицензии, разработчикам OpenBSD он, насколько помню, нравится.
>
>Ну вот, пойми их.То фаны орут что бсдшники не гордые по части
>лицензий, то вдруг такие слова как гром посреди ясного неба на
>черепушки фанатиков :)Фаны - это фаны. Тут "от любви до ненависти"... Леннона жалко.
А насчёт "не гордые" - тут вопрос включения в состав базовой системы. Конкретно OpenBSD систематически избавляется от несовместимого с BSD-лицензией кода и не приемлет (более) добавление оного в состав базовой системы.
На серверах у нас сейчас бегают фряха и exim, и все вполне довольны.
В топку exim. Хуже exima'а в настройке - только sendmail.
>В топку exim. Хуже exima'а в настройке - только sendmail.Вообще-то за одну только поддержку Perl разработчикам Exim можно памятник ставить. Для простых задач конфиг тоже сложным не будет, ну а сложные конфигурации у Exim разбирать не в пример проще sendmail, да и некоторых других почтовиков.
Сам иди в топку, грамотей хренов
>Сам иди в топку, грамотей хреновСударь желает выступить в защиту exim'а? Чем же, по вашему, он лучше, чем sendmail или postfix? Кроме поддержки perl'а, пожалуйста - об этом уже писали выше.
>>Сам иди в топку, грамотей хренов
>
>Сударь желает выступить в защиту exim'а? Чем же, по вашему, он лучше,
>чем sendmail или postfix? Кроме поддержки perl'а, пожалуйста - об этом
>уже писали выше.По сравнению с Postfix он неплох на сильно замудрённых конфигурациях (когда есть полный набор, начиная образчиками индийского кода, от которого не убежать, и кончая "гениальными" клиентами с шелл-доступом). Postfix я на несложных задачах люблю, так как поднимается он чуть проще, но это "чуть" - не слишком принципиально. Ну а на рабочей станции практически всегда сгодится то, что идёт в базовой поставке. Sendmail сейчас достаточно хорошо вылизан с точки зрения безопасности и надёжности.
exim -- мощнейший smtp-сервер вообще. Его конфиг -- даже без перла -- это язык программирования с набором библиотек для доступа к данным.Когда я работал психиатром в маленькой психиатрической больнице^W^W^W^W^W обрабатывал по 300 000 только принятых писем в сутки -- я не нашел разумной альтернативы экзиму.
Конечно для Poupkeen personal server это оверхед, да
Язык sendmail.cf был (и остается) Тьюринг-полным задолго до появления других MTA. А сейчас еще и libmilter есть.
>Язык sendmail.cf был (и остается) Тьюринг-полным задолго до появления других MTA. А
>сейчас еще и libmilter есть.Вот только люди почему-то пишут всё больше не на ассемблере, а на PHP. С чего бы?
>Вот только люди почему-то пишут всё больше не на ассемблере, а на
>PHP. С чего бы?Странно, но мне нравится и ассемблер (для задач где он хорош) и PHP - для более других задач (генерить веб-страничку на ассемблере - проще застрелиться :D).Лично мне приятно в PHP то что синтаксис напоминает си - можно не греть голову изучением особо, если си знаешь - PHP как-то сам собой изучается как похожий на него.Аналогично кстати и еще некоторые языки :)
>>Вот только люди почему-то пишут всё больше не на ассемблере, а на
>>PHP. С чего бы?
>
>Странно, но мне нравится и ассемблер (для задач где он хорош) и
>PHP - для более других задач (генерить веб-страничку на ассемблере -
>проще застрелиться :D).Лично мне приятно в PHP то что синтаксис напоминает
>си - можно не греть голову изучением особо, если си знаешь
>- PHP как-то сам собой изучается как похожий на него.Аналогично кстати
>и еще некоторые языки :)Как язык вообще, PHP мне тоже нравится. В частности, реализация массивов/хешей очень удобная, ИМХО. Но реализация - гммм...
А насчёт C - мне в далёком детстве отец-инженер так и говорил: "будешь знать C/C++ - будешь понимать и всё остальное". Хорошо, что я его тогда послушал:).
А ассемблер тоже нужен, никто не спорит. Тут вопрос именно в том, что свобода, предоставляемая ассемблером, далеко не так важна, как удобство высокоуровневых языков. :)
>"будешь знать C/C++ - будешь понимать и всё остальное".Да уж.Хотя некоторые языки ну очень не похожи :)
>А ассемблер тоже нужен, никто не спорит. Тут вопрос именно в том,
>что свобода, предоставляемая ассемблером, далеко не так важна, как удобство высокоуровневых
>языков. :)А это смотря что и как делать.Каждый инструмент хорош для своего дела.Например видел пример программы на Java для работы поверх блютусного компорта с девайсом.Я, конечно, извиняюсь, но это - вырезание гланд через зад автогеном.Особенно если посмотреть список issues данной программы и общую ее уродливость.Жава-драйвер компорта для этой байды с компортом дескать у нас работает криво - сначала в компорт кто-то что-то должен послать, тогда, дескать, оно заработает - а до тех пор дескать, фигу вам!Круто.Мне нравится такое ограничение - компорт начинает работать только когда туда кто-то с другой стороны что-то послал.А до тех пор - сосите дескать.А если не изгаляться и писать такие программы на сях\сях++ - данные ужОсы забудутся как страшный сон.Итого - автор сэкономил немного времени на гуе зато отхватил немеряно проблем на основном функционале своего кошмарика.И заодно для запуска мааааленькой программы на пару сотен кил надо качать допуркуа мегабайтов рантайма и поднасрать ...цать мегов всем этим в системный каталог(ну спасибо что не полгига как в новых дотнетах).Вспоминается Ералаш про часы с телевизором и чемоданы с батарейками для оных - такая же дебильная и непрактичная конструкция на выходе получается - отличные часы и 2 огромных чемодана внагрузку к ним чтобы они работали =)
>Вспоминается Ералаш про часы с телевизором и
>чемоданы с батарейками для оных - такая же дебильная и непрактичная
>конструкция на выходе получается - отличные часы и 2 огромных чемодана
>внагрузку к ним чтобы они работали =)Да-да-да :)))
Хотя в качестве шутки чего только люди не пишут...
>Язык sendmail.cf был (и остается) Тьюринг-полнымBrainfuck насколько я помню этому критерию тоже соответствует :D.Это еще не значит что на нем легко и удобно писать программы ;)
>>Язык sendmail.cf был (и остается) Тьюринг-полным
>
>Brainfuck насколько я помню этому критерию тоже соответствует :D.Это еще не значит
>что на нем легко и удобно писать программы ;)Ну так и конфиги шлимылу давно уже пишут не напрямую в sendmail.cf, а с m4, получается довольно коротко.
>Язык sendmail.cf был (и остается) Тьюринг-полным задолго до появления других MTA. А
>сейчас еще и libmilter есть.Вот когда ты научишь эту машину Тьюринга хотя бы нормальному взаимодействию между тем что в sendmail.cf и тем что в мильтеровых фильтрах, а эти фильтры как-то взаимодействовать между собой - можно будет всё это вспоминать. А текущее убожище которое уже 20 лет не хотят нормально писать - заслуживает свалки.
>Ну что, можно принимать ставки, что со временем это будет самый безопасный
>сервер?Самый безопасный сервер - это который не подключен к сети.Его по определению нельзя сломать, проабузить, заDoS'ить, ... ;)
>Самый безопасный сервер - это который не подключен к сети.Его по определению
>нельзя сломать, проабузить, заDoS'ить, ... ;)Вы путаете со сферическим сервером в вакууме... ^_^
>>Ну что, можно принимать ставки, что со временем это будет самый безопасный
>>сервер?
>
>Самый безопасный сервер - это который не подключен к сети.Его по определению
>нельзя сломать, проабузить, заDoS'ить, ... ;)Можно. Электричество-то он кушает, вот вам и DoS. :)
>>Самый безопасный сервер - это который не подключен к сети.Его по определению
>>нельзя сломать, проабузить, заDoS'ить, ... ;)
>Можно. Электричество-то он кушает, вот вам и DoS. :)""не подключен к сети""!! Ж-P
>>>Самый безопасный сервер - это который не подключен к сети.Его по определению
>>>нельзя сломать, проабузить, заDoS'ить, ... ;)
>>Можно. Электричество-то он кушает, вот вам и DoS. :)
>
>""не подключен к сети""!! Ж-PЕсли к электрической, то он, видимо, и не работает вовсе. Ну или что там у него ещё источником энергии? Солнце + аккумуляторы? Производим компактный атомный взрыв, и, если сервер ещё после него живой, то батареек у него точно не хватит пережить всю ту пыль, что поднимется...
postfix наше все!!!
функционал постфикса нужен только на почтовых серверах, а простой smtp сервер в базовой поставке - это то что надо
надо его срочно в freebsd :) задолбало из портов postfix ставить
На самом деле с 2005г Claus Aßmann с нуля разрабатывает почтовый сервер под такой же лицензией, что и sendmail. Называется MeTA1. Полностью модульный MTA, есть в нем все! И обширная документация в том числе
Ну я, конечно, понимаю, что фамилию не выбирают, но, гм...
А чем Вам не угодила фамилия Асман?
>А чем Вам не угодила фамилия Асман?Теперь, когда ее написали через "шарф-эс" - ничем. Фамилия как фамилия.
>На самом деле с 2005г Claus Aßmann с нуля разрабатывает почтовый сервер
>под такой же лицензией, что и sendmail. Называется MeTA1.MeTA1 использует statethreads, который распространяется под MPL/GPL.
>под такой же лицензией, что и sendmail.sendmail распространяется под GPL. Вы не знали? Или постеснялись?
Или пропустили выше про "лицензия бла-бла-бла не устраивает бла-бла-бла для включения в базовую систему [OpenBSD] бла-бла-бла yнастойчиво избавляться бла-бла-бла то пусть меня покарает Рука"?
>>под такой же лицензией, что и sendmail.
>
>sendmail распространяется под GPL. Вы не знали? Или постеснялись?А мужики-то не знают...
http://sendmail.cybermirror.org/LICENSE
Не BSD, но и отнюдь не GPL.
>Или пропустили выше про "лицензия бла-бла-бла не устраивает бла-бла-бла для включения в
>базовую систему [OpenBSD] бла-бла-бла yнастойчиво избавляться бла-бла-бла то пусть меня покарает
>Рука"?Вообще-то, я упомянул, что речь идёт о текущем моменте. Кому надо, те знают, что в составе сборок (Open)BSD есть GPL-ный код - так же как и в дистрах Linux есть BSD-licensed код. И также не раз уже говорилось, что *BSD потихоньку избавляются от кода с не BSD-like лицензиями. Но если хотите снова завести сказку про белого бычка - пожалуйста, кто мешает:).
>>распространяется под GPL. Вы не знали? Или постеснялись?Я соврамши. Прошу прощения. :( То был не тот и не sendmail - промахнулся, когда проверял.
>А мужики-то не знают...
>http://sendmail.cybermirror.org/LICENSE
Нравится - пусть работают. Лицензионные заморочки тоже можно понять. Ну хочется им сделать абсолютно свободный продукт, а gpl это не позволяет. Что ещё делать? Приходится переписывать...
>Нравится - пусть работают. Лицензионные заморочки тоже можно понять. Ну хочется им
>сделать абсолютно свободный продукт, а gpl это не позволяет. Что ещё
>делать? Приходится переписывать...Бывают, кстати, не только лицензионные заморочки. libtool сейчас переписывают не от хорошей жизни, например.
Я уже давно все это сам понаписал. Их пока дождешься... ;) Взял qmail и все это и много другого понаваял. Получилась довольно мощная штука. Сейчас нехотя обслуживает больше 70 000 юзеров и их число каждый день растет на несколько сотен.
Спамеры?
Ну ясен пень, колесо то оно всяко интересно изобретать.
>Я уже давно все это сам понаписал. Их пока дождешься... ;) Взял
>qmail и все это и много другого понаваял. Получилась довольно мощная
>штука. Сейчас нехотя обслуживает больше 70 000 юзеров и их число
>каждый день растет на несколько сотен.дай пять, чувак. :) я тоже свою реализацию qmail хочу вывести на поток :)
с ума сойти, велосипеда развиваються круче машин
Вы когда-нибудь юзали smtp-демоны в условиях нахгрузки? Ну скажем 10-20 млн писем в день, да еще и с замороченными правилами. Что бы вы посоветовыли?* qmail? Да он абсолютно дубовый. И он вгоняет в ступор машину огромным числом fork-ов.
* postfix? Да, он умеет kqueue/epoll, да и в остальном вполне ничего. Но реализовать в нем замороченные правила крайне проблематично.
* exim? Функциональный конфиг. Встроенным perl-ом можно реализовать, все остальное. Но с производительностью там не все так гладко. В exim очень много кривого кода, оставшегося от предыдущих версий. Достаточно оценить количество глобальных переменных. поэтому проблемы производительности решить не так уж и легко.
* sendmail? С должным терпением от него можно добиться многого. Но тут о m4-макросах речи быть не может. А ковырять в голом виде конфиги сендмыла - занятие не для слабонервных.Так что, если опенки напишут производительный smtpd с хорошим конфигом, да еще и с хорошим кодом, то низкий поклон им и большое человеческое спасибо.
>Вы когда-нибудь юзали smtp-демоны в условиях нахгрузки? Ну скажем 10-20 млн писем
>в день, да еще и с замороченными правилами. Что бы вы
>посоветовыли?
>
>* exim? Функциональный конфиг. Встроенным perl-ом можно реализовать, все остальное. Но с
>производительностью там не все так гладко. В exim очень много кривого
>кода, оставшегося от предыдущих версий. Достаточно оценить количество глобальных переменных. поэтому
>проблемы производительности решить не так уж и легко.У нас бегает exim на FreeBSD. Жалоб на него не было вообще, окромя одной ситуации, обусловленной следующими факторами:
1. клиента ломают и от его имени начинают жёстко спамить, вследствие чего обратно на машину валится куча отлупов;
2. для доставки почты используется формат Maildir++, имеющий поддержку квотирования при помощи файлика maildirsize.Трабла в том, что maildirsize надо периодически пересоздавать - и при большом количестве уже имеющейся почты эта операция достаточно много ресурсов отжирает. А у exim'а каждый процесс, доставляющий почту, не лочит это дело и пытается пересоздать файл самостоятельно... Всё бы ничего, но кое-какой софт, также используемый на серверах, благополучно этот файлик систематически шлёпает. Где он это делает, искали (и вообще диагностику проводили) дооооолго...
... Так вот, за исключением этой траблы, ни одного нарекания - при наличии нескольких сотен клиентов с самым разнымм количеством виртуальных ящиков (от одного до примерно сотни) у каждого на одной машине. Ну и самих машин не один десяток...
>[оверквотинг удален]
>>кода, оставшегося от предыдущих версий. Достаточно оценить количество глобальных переменных. поэтому
>>проблемы производительности решить не так уж и легко.
>
>У нас бегает exim на FreeBSD. Жалоб на него не было вообще,
>окромя одной ситуации, обусловленной следующими факторами:
>
>1. клиента ломают и от его имени начинают жёстко спамить, вследствие чего
>обратно на машину валится куча отлупов;
>2. для доставки почты используется формат Maildir++, имеющий поддержку квотирования при помощи
>файлика maildirsize.Как в exim задавать код ответа скажем на deny в acl? Как в acl_smtp_connect принудительно ответить 554 с последующими 503 без разрыва соединения скажем по policy reason?
PS он гибок в настройках, но отчасти дубовый по RFC.
В новости написано разработчики вооружились RFC и решили писать классный сервер.
RFC запрещает разрывать соединение с клиентом кроме shut down сервера и quit клиента.
Если уменя максимум 1000 соединений и скажем 5 peer host. Через минуту на них всех будут висеть спамеры и почта пойдет на MX 20.
Я это к тому что надо стандарты развивать, а потом реализации писать.
> Если у меня максимум 1000 соединений и скажем 5 peer host.А зачем так жестоко?
Кроме того, как ты собираешься определять, от кого принимать соединения, а с кем порвать?
>А зачем так жестоко?
>
>Кроме того, как ты собираешься определять, от кого принимать соединения, а с
>кем порвать?Я примерно знаю интенсивность легальной входящей почты и подключений спамеров.
Это видно из логов. В минуту единицы входящих сообщений и сотни подключений с хостов, которые я заведомо (regexp или blacklist) знаю присылают только спам.Если я выставлю параметры мягче, вопрос только во времени запонения пула соединений.
Таймауты между командами всё равно достаточны велики.
Разрывать соединения (как сейчас и сделано), не рекомендуется.
Принимать сообщения, гонять их через спам фильтр, генерить отскоки накладно (трафик не безлимитный, нагрузка на сервер).А вообще - ответ по существу - при нашей интенсивности входящей почты, нам больше не надо, даже этого много.
PS. Домен давно используется, а организация небольшая. Спама очень много.
>Как в exim задавать код ответа скажем на deny в acl? Как
>в acl_smtp_connect принудительно ответить 554 с последующими 503 без разрыва соединения
>скажем по policy reason?
>
>PS он гибок в настройках, но отчасти дубовый по RFC.1. message (хотя где это нужно, пример?)
2. в acl_smtp_connect еще нет "далога" в сесии SMTP - отвечать не кудаPS RTFM
>2. в acl_smtp_connect еще нет "далога" в сесии SMTP - отвечать не
>кудаГде тогда управлять после connect до приглашения.
>>2. в acl_smtp_connect еще нет "далога" в сесии SMTP - отвечать не
>>куда
>Где тогда управлять после connect до приглашения.Если правильно понимаю, то у меня до acl_smtp_helo (самой команды helo smtp сесии)
ожидание 40 секунд, если хост далапный в соотв. проверке rbl (которая в acl_smtp_connect)Для "обычной" smtp сесии, есть
acl_smtp_connect
acl_smtp_helo
acl_smtp_mail
acl_smtp_rcpt
acl_smtp_predata
acl_smtp_data
acl_smtp_quithttp://www.exim.org/exim-html-current/doc/html/spec_html/ind...
>>>2. в acl_smtp_connect еще нет "далога" в сесии SMTP - отвечать не
>>>куда
>>Где тогда управлять после connect до приглашения.
>
>Если правильно понимаю, то у меня до acl_smtp_helo (самой команды helo smtp
>сесии)
>ожидание 40 секунд, если хост далапный в соотв. проверке rbl (которая в
>acl_smtp_connect)Интересное решение, а что это даёт?
PS Мне скоро заменять relay на exim, настройки тоже надо менять, так что не из праздности.
* Началась работа по реализации поддержки авторизации ( SMTP AUTH ).Им, оказывается, ещё пилить и пилить ...
Этих же smtp-серверов - как грязи. Но открытые бздуны никогда простых путей не ищут ...
Абсолютно точно так же начиналось и с PF. Думаю этим "велосипедом" утрут нос еще.
Ну в своё время выкинули ипфилтер и пф написали, с этой фигнёй будет скорее всего тоже самое.
>Ну в своё время выкинули ипфилтер и пф написали, с этой фигнёй
>будет скорее всего тоже самое.pf гораздо лучше чем ipfilter
А для обычных серверов sendmail/postfix избыточен
>А для обычных серверов sendmail/postfix избыточенПочему избыточен? На "обычных" серверах (это каких? сферических в вакууме?) хорошо работают и sendmail, и postfix с настройками по умолчанию, каши не просят.
> Почему избыточен? На "обычных" серверах (это каких? сферических в вакууме?) хорошо работают и sendmail, и postfix с настройками по умолчанию, каши не просят.Угу. Причем на 95% этих серверов почта не уходит далее /var/mail/ или /dev/null.