On 25/08/2008, Victor Wagner <[EMAIL PROTECTED]> wrote:
> Впрочем, её-то как раз можно и в другое место - но если это просто > > делается. > > Вот именно что В ДРУГОЕ место. Если это можно _просто_ сделать, я это сделаю. > > Мне надо два доступных ящика. Один с локальной почтой для рута. Другой > > Внимание! Если эти два ящика нужны ТЕБЕ, то они и должны принадлежать > тому юзеру, от которого работаешь ты. Если их можно _просто_ создать, я их создам. В случае почты имеет смысл сводить входящую почту в один поток, а потом > разводить отдельно на несколько потоков. Так даже целые виртуальные > домены организуют - у провайдера все валится в один ящик, с > прописыванием SMTP-шного recipient-а в какой-нибудь заголовок вроде > X-Envelope-To, а после забирания фетчмейлом всего этого потока оно по > этому заголовку локально разбрасывается по ящикам (разных > пользователей). Вот я и не понимаю, зачем мне сидеть, часами читать документацию и ставить несколько пакетов, вполне достаточных для создания виртуального домена - чтобы решить задачу на два ящика. Для чего мне столько сложных и мощных инструментов, если моя конкретная задача куда проще? В данном случае у тебя другая задача - собрать и направить к тебе почту > тебе и почту руту (через aliases), а потом разобрать и сложить в разные > ТВОИ ящики (например procmail-ом). Итак на несчастные два ящика мне предлагается настраивать четыре инструмента - fetchmail, MTA, MUA, procmail. Артиллерийская канонада сметает воробья. > Мне также надо, чтобы система никогда не пыталась ничего отправить > > наружу. > > Ну ты ж иногда и писать будешь. Письма написанные тобой внешним > адресатам система должна отправлять наружу. Причем лучше чтобы это была > именно система, а не GUI-шный почтовый клиент. Вот только я не всегда это буду делать с этой машины. И у меня нет никкаких гарантий, что в момент отправки письма эта машина работает и я с ней в одной сети. А сложных схем аутентификации не предполагается - та, что есть, успешно отрабатывается существующими GUI MUA. Я отнюдь не оспариваю важности и необходимости сложных юниксных инструментов для соответствующих задач. Просто не стоит, по-моему, ставить провайдерскую конфигурацию на юзерскую задачу. Наоборот, конечно, ещё хуже (Exchange... бррр!) > > Я так и не понял, как это настроить "пятью вопросами". Ибо при пяти > > вопросах ящик=юзер, и как создать лишнего юзера чтобы он ни в коем > > Это неправда, что ящик равно юзер. Юзер - это юзер. Некто, от имени > которого запускаются процессы (в частности, почтовые клиенты). > Просто раскидывание по ящикам почты > для юзера - это уже не дело MTA, это дело MDA. (mail delivery agent). А это ещё одна настройка, и кроме попросту возни - ещё один уровень риска при ошибках в ней. Артём утверждал, что я могу получить всю нужную конфигурацию (кроме самого fetchmail), просто ответив на пять вопросов. К сожалению, не вышло. В комплект MTA как правило, входит какой-нибудь простенький (а иногда и > продвинутый) MDA, но никто не мешает использовать более другой, с > требуемой степенью продвинутости. Тем более что тебе нужны явно не два > ящика. Ты как минимум эту рассылку читаешь. То есть уже для неё третий > ящик нужен. В данном случае нет, поскольку основное чтение у меня - с гугля, и поста там раскидывается гуглёвыми же фильтрами. Локальная копия - сугубо бекап. Он для чтения в экстренной ситуации или для поиска, который фолдеры как раз усложнят. (Например, я могу помнить, что ты мне что-то писал N месяцев назад - и не помнить, в какой рассылке). Вне особых ситуаций читаться там будет только почта для рута. Которую я решил настроить просто потому, что буду включать обновления по крону, и возможно придётся поднять систему на lenny (спутникового ТВ захотелось). Соответственно, придётся за обновлениями следить. Хотя вообще mda это уже ближе к imap серверу, чем к MTA, потому что > MDA кладет письма в ту самую структуру ящиков, из которой её потом > раздает imap. Так что если ты используешь imap-сервер с какой-нибудь > нестандартной системой хранения, например в базе данных, то тебе > потребуется mda, который умеет работать с этой структурой. На локальный IMAP сервер забит болт - не получится у меня 24h uptime систему собрать в ближайшее время. Хотел было, но облом - VIA EPIA/Eden оказались слишком дорогими. -- Yours, Mikhail Ramendik
