[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Читать /var/mail/*



On 2008.08.25 at 12:19:39 +0100, Mikhail Ramendik wrote:

> 
>    On 25/08/2008, Victor Wagner <[1]vitus@wagner.pp.ru> wrote:
> 
>      On 2008.08.25 at 11:55:23 +0100, Mikhail Ramendik wrote:
>      >
>      >    Мне нужен простой бекап без какой-либо фильтрации. Я упорно не
>      Тогда это isync, а не fetchmail.
> 
> 
> 
>    К сожалению, сообщают, что у гугля IMAP иногда отваливается. А бекап
>    хочется сделать простым, _надёжным_, и запускаемым по крону раз в 5-10

Вот если он запускается по крону раз в 5-10 минут и ИНОГДА отваливается
(то есть сейчас отвалился, а через 10 минут отработал), то это для
практических целей - вполне достаточная надежность.

>    минут. Чтобы уж если связь отвалилась или гугль упал - у меня была
>    копия всей моей почты.

Ну копии той почты, которая пришла на гугль ПОСЛЕ того, как связь
отвалилась - у тебя все равно не будет. А которая до последнего удачного
sync - будет.


>    Из /var/mail/root я хочу только _читать_ локальную почту на рута.

А удалять кто будет? Ну не нужны тебе отчеты от cron двухлетней
давности, уже прочитанные.  

>    Впрочем, её-то как раз можно и в другое место - но если это просто
>    делается.

Вот именно что В ДРУГОЕ место. 

> 
>      >    Благо "пяти вопросов" не хватает - настройка всё же требуется.
>      Странно. Мне во многих случаях хватает. Тебе - не хватает.
> 
> 
>    Мне надо два доступных ящика. Один с локальной почтой для рута. Другой

Внимание! Если эти два ящика нужны ТЕБЕ, то они и должны принадлежать
тому юзеру, от которого работаешь ты. 

В случае почты имеет смысл сводить входящую почту в один поток, а потом
разводить отдельно на несколько потоков. Так даже целые виртуальные
домены организуют - у провайдера все валится в один ящик, с
прописыванием SMTP-шного recipient-а в какой-нибудь заголовок вроде
X-Envelope-To, а после забирания фетчмейлом всего этого потока оно по
этому заголовку локально разбрасывается по ящикам (разных
пользователей).

В данном случае у тебя другая задача - собрать и направить к тебе почту
тебе и почту руту (через aliases),  а потом разобрать и сложить в разные
ТВОИ ящики (например procmail-ом).


>    Мне также надо, чтобы система никогда не пыталась ничего отправить
>    наружу.

Ну ты ж иногда и писать будешь. Письма написанные тобой внешним
адресатам система должна отправлять наружу. Причем лучше чтобы это была
именно система, а не GUI-шный почтовый клиент.

Тому есть несколько причин:

1. Допустим случился перерыв в связи. Если у тебя стоит MTA, то клиент
письмо ему отдал и готов к продолжению работы. Ты можешь его вообще
закрыть, разлогиниться и пустить на компьютер жену - под её логином. А
MTA будет упорно, с прописанным ему в конфиге интервалом, пока связь не
восстановится и письмо таки не отправится.

2. MTA гораздо лучше умеют всякие сложные случае аутентификации с другим
MTA, чем клиенты.  Я вот вяло подумываю над подъемом полноценного MTA на
Nokia N800. Чтобы по сертификатам у моего сервера авторизовывался.


>    Я так и не понял, как это настроить "пятью вопросами". Ибо при пяти
>    вопросах ящик=юзер, и как создать лишнего юзера чтобы он ни в коем

Это неправда, что ящик равно юзер. Юзер - это юзер. Некто, от имени
которого запускаются процессы (в частности, почтовые клиенты).  
Просто раскидывание по ящикам почты
для юзера - это уже не дело MTA, это дело MDA. (mail delivery agent).
В комплект MTA как правило, входит какой-нибудь простенький (а иногда и
продвинутый) MDA, но никто не мешает использовать более другой, с
требуемой степенью продвинутости. Тем более что тебе нужны явно не два
ящика. Ты как минимум эту рассылку читаешь. То есть уже для неё третий
ящик нужен.

Хотя вообще mda это уже ближе к imap серверу, чем к MTA, потому что
MDA кладет письма в ту самую структуру ящиков, из которой её потом
раздает imap. Так что если ты используешь imap-сервер с какой-нибудь
нестандартной системой хранения, например в базе данных, то тебе
потребуется mda, который умеет работать с этой структурой.



Reply to: