[mdk-re] Анатомия почты в Spring

[mdk-re] Анатомия почты в Spring

[Sergey Kuznetsov]

Уважаемое сообщество!

Железо, в основном, настроил. Теперь решил наконец перевести почту под
Linux.  Сейчас сижу, читаю документацию по Postfix'у и fetchmail'у. Но
не  оставляет  чувство,  что  я  все  же  не  понимаю,  как по замыслу
разработчиков  должна  строиться  почтовая  система  _в целом_. Пока в
голове  сложилась  такая  схема  (речь  идет  о  домашнем компьютере с
dialup-соединением):

Отправка  почты:
MUA  отдает  почту Postfix'у. Тот ждет соединения с провайдером, затем
по   команде  sendmail  -q  отправляет  ее  адресату  или  по  адресу,
прописанному в relayhost.

Получение почты:
Fetchmail  скачивает  почту  с почтового сервера по команде fetchmail,
если  есть предварительно созданный файл .fetchmailrc, или fetchmail с
параметрами,  если такого файла нет. Затем почта передается postfix'у,
который отдает ее MUA по запросу пользователя.

Если  вышеописанное  представление  правильно,  то  для  чего же нужен
postfix?  Если  бы  входящая  и  исходящая почта просто складывалась в
заранее   обусловленном   месте   и  подхватывалась  из  него  другими
программами,  не  то  же  ли  самое  бы  было?  Зачем  нужен  еще один
посредник?
Если я все понял неправильно, то как все обстоит на самом деле? (Речь
идет о построении почтовой системы В ЦЕЛОМ).

С уважением,
Сергей

Re: [mdk-re] Анатомия почты в Spring

[Roman S]

On Mon, 24 Sep 2001 22:55:08 +0400
Sergey Kuznetsov <skuznetsov@comail.ru> wrote:

> Если  вышеописанное  представление  правильно,  то  для  чего же нужен
> postfix?  Если  бы  входящая  и  исходящая почта просто складывалась в
> заранее   обусловленном   месте   и  подхватывалась  из  него  другими
> программами,  не  то  же  ли  самое  бы  было?  Зачем  нужен  еще один
> посредник?
> Если я все понял неправильно, то как все обстоит на самом деле? (Речь
> идет о построении почтовой системы В ЦЕЛОМ).
Почти правильно. В принципе можно fetchmail-у велеть отдавать письма напрямую через procmail, но:
1) Домашний кнопкопутер - несколько пользователей (скажем, жена поставла на отправку и забыла)
2) в Unix-ах система общается с пользователем посредством электронной почты 
Т.е. то, что выдают программы по расписанию (cron)
Или скажем, делаете любимую команду всех времён и народов:
echo rpm -ba cool_large_package.spec | batch - то что получится, вы получите по e-mail.
3) Этого "посредника" можно научить достаточно большому кол-ву гадостей, но если особо не учить, то много хлеба он не просит....

-- 
Rgds!
Roman Savelyev.

Re: [mdk-re] Анатомия почты в Spring

[Alex Savvin]

On Mon, 24 Sep 2001 22:55:08 +0400
Sergey Kuznetsov <skuznetsov@comail.ru> wrote:

> Отправка  почты:
> MUA  отдает  почту Postfix'у. Тот ждет соединения с провайдером, затем
> по   команде  sendmail  -q  отправляет  ее  адресату  или  по  адресу,
> прописанному в relayhost.
А так же без команды, автоматом в момент поступления письма в очередь.
Но это характерно больше для хостов с постоянным соединением.
> 
> Получение почты:
> Fetchmail  скачивает  почту  с почтового сервера по команде fetchmail,
> если  есть предварительно созданный файл .fetchmailrc, или fetchmail с
> параметрами,  если такого файла нет. Затем почта передается postfix'у,
> который отдает ее MUA по запросу пользователя.
Точнее, почта передается агенту локальной доставки (procmail), который 
кладет почту в системный почтовый ящик (/var/spool/mail/<user>). Затем
уже MUA забирает (по команде пользователя) почту из спула и кладет
ее в свою собственную базу (напр, ~/Mail/).
> 
> Если  вышеописанное  представление  правильно,  то  для  чего же нужен
> postfix?  Зачем  нужен  еще один  посредник?
> Если я все понял неправильно, то как все обстоит на самом деле? (Речь
> идет о построении почтовой системы В ЦЕЛОМ).

Идея примерно следующая:
Вам необходимо отправить почтовое сообщение пользователю (локальному 
или удаленному). Не забывайте, что процессы в Unix тоже, в некотором 
приближении, рассматриваются как пользователи. Если бы дело ограничивалось
людьми, то настроил пару-тройку MUA, куда ложить почту и все! Но нельзя настроить
массу программ, которые могут выдавать почту для, скажем, root'а и иже с ним.
Т.е. нужен механизм приема "случайных" сообщений, приходящих на стандартный
порт (для smtp - 25). Обмен сообщениями между процессами через порты - стандартная
"фича" Unix (и не только). В случае с удаленным пользователем - более показательный
пример. Он не знает, что вы написали ему письмо (он вообще Вас не знает :), поэтому
запускать fetchmail и смотреть почтовый ящик на Вашем компьютере он не будет 
(да и не сможет, пока не узнает свой логин и пароль :). Тут опять помогает postfix
(правильнее MTA). Он узнает IP адрес вашего адресата и обращается к запущенному
у него агенту MTA. Обмениваются приветами, и ваш передает письмо. Тот смотрит, 
является ли адрес адресата для него локальным - если да, то передает локальному
агенту для разборки и укладывания в соотв. локальный почт. ящик; если нет - смотрит, 
разрешено ли ему релеить это письмо на другой хост, и либо передает, либо дает
вашему MTA "отлуп", дескать relay запрещен.
Короче, таким образом письмо попадает в тот или иной локальный системный 
почтовый ящик. А вот тут может понадобится fetchmail. Если вы реальный
пользователь хоста, т.е. имеет доступ к его терминалу - запускайте MUA и читайте
почту, если же вы удаленный пользователь хоста (не случайный, а имеющий логин
и пароль), то вы можете либо читать почту online, либо перебросить ее на свою машину
и читать offline. Переброской занимается fetchmail. Обращается к POP-серверу удаленного
хоста, логинится и смотрит, есть ли для него почта в системном почтовом спуле, 
если да - забирает ее и передает локальному агент доставки - тот сам разберется, какое 
письмо в какой ящик кинуть, а может вообще в /dev/null (т.е. фильтрация).

Надеюсь, не сильно сумбурно получилось.

-- 
С уважением, 
                  Александр Саввин
----------------------------------
Email:	savvin@mail.ru
ICQ:    103069766		 
----------------------------------
      Powered by Linux Mandrake RE

[mdk-re] Re[2]: [mdk-re] Анатомия почты в Spring

[Sergey Kuznetsov]

>> Получение почты:
>> Fetchmail  скачивает  почту  с почтового сервера по команде fetchmail,
>> если  есть предварительно созданный файл .fetchmailrc, или fetchmail с
>> параметрами,  если такого файла нет. Затем почта передается postfix'у,
>> который отдает ее MUA по запросу пользователя.
> Точнее, почта передается агенту локальной доставки (procmail), который 
> кладет почту в системный почтовый ящик (/var/spool/mail/<user>). Затем
> уже MUA забирает (по команде пользователя) почту из спула и кладет
> ее в свою собственную базу (напр, ~/Mail/).
>> 

Ага...  Значит  procmail  тоже  в этой схеме ДОЛЖЕН БЫТЬ задействован.
Если  не  ошибаюсь,  он  проводит сортировку писем... ну да, рассовать
почту  по  локальным  ящикам  -  это,  собственно,  и  есть сортировка
(особенно  если  включить  правила,  по  которым  письма,  к  примеру,
удаляются).   А   есть  для  его  настройки  какая-нибудь  утиль  типа
fetchmailconf, или это можно ТОЛЬКО через файл конфигурации?

> Идея примерно следующая:
> Вам необходимо отправить почтовое сообщение пользователю
> (локальному 
> или удаленному). Не забывайте, что процессы в Unix тоже, в
> некотором 
> приближении, рассматриваются как пользователи. Если бы дело
> ограничивалось
> людьми, то настроил пару-тройку MUA, куда ложить почту и все!
> Но нельзя настроить
> массу программ, которые могут выдавать почту для, скажем,
> root'а и иже с ним.
> Т.е. нужен механизм приема "случайных" сообщений, приходящих
> на стандартный
> порт (для smtp - 25). Обмен сообщениями между процессами
> через порты - стандартная
> "фича" Unix (и не только). В случае с удаленным пользователем
> - более показательный
> пример. Он не знает, что вы написали ему письмо (он вообще
> Вас не знает :), поэтому
> запускать fetchmail и смотреть почтовый ящик на Вашем
> компьютере он не будет 
> (да и не сможет, пока не узнает свой логин и пароль :). Тут
> опять помогает postfix
> (правильнее MTA). Он узнает IP адрес вашего адресата и
> обращается к запущенному
> у него агенту MTA.

Так, попробуем въехать. Если мой адресат имеет постоянное подключение
к И-нету, то этот MTA запущен на _локальной_ машине, а если он такой
же dialup'щик, то он крутится на _почтовом сервере провайдера_. Так?

> Обмениваются приветами, и ваш передает
> письмо. Тот смотрит, 
> является ли адрес адресата для него локальным - если да, то
> передает локальному
> агенту для разборки и укладывания в соотв. локальный почт.
> ящик; если нет - смотрит, 
> разрешено ли ему релеить это письмо на другой хост, и либо
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Имеется в виду - на компьютер адресата?

> передает, либо дает
> вашему MTA "отлуп", дескать relay запрещен.
> Короче, таким образом письмо попадает в тот или иной
> локальный системный 
> почтовый ящик. А вот тут может понадобится fetchmail. Если вы
                                                             ^^^
Я или адресат моего письма?

> реальный
> пользователь хоста, т.е. имеет доступ к его терминалу -
> запускайте MUA и читайте
> почту, если же вы удаленный пользователь хоста (не случайный,
> а имеющий логин
> и пароль), то вы можете либо читать почту online, либо
> перебросить ее на свою машину
> и читать offline. Переброской занимается fetchmail.
> Обращается к POP-серверу удаленного
> хоста, логинится и смотрит, есть ли для него почта в
> системном почтовом спуле, 
> если да - забирает ее и передает локальному агент доставки -
> тот сам разберется, какое 
> письмо в какой ящик кинуть, а может вообще в /dev/null (т.е.
> фильтрация).
>
> Надеюсь, не сильно сумбурно получилось.

Да нет, вроде что-то в голове прояснилось. Спасибо! А что выступает в
роли MTA в оффтопике? Сама почтовая программа?

С уважением,
Сергей

Re: [mdk-re] Re[2]: [mdk-re] Анатомия почты в Spring

[Alex Savvin]

[-- Attachment #1: Type: text/plain, Size: 5144 bytes --]

On Tue, 25 Sep 2001 23:05:45 +0400
Sergey Kuznetsov <skuznetsov@comail.ru> wrote:

> > уже MUA забирает (по команде пользователя) почту из спула и кладет
> > ее в свою собственную базу (напр, ~/Mail/).
> Ага...  Значит  procmail  тоже  в этой схеме ДОЛЖЕН БЫТЬ задействован.
> Если  не  ошибаюсь,  он  проводит сортировку писем... ну да, рассовать
> почту  по  локальным  ящикам  -  это,  собственно,  и  есть сортировка
> (особенно  если  включить  правила,  по  которым  письма,  к  примеру,
> удаляются).   А   есть  для  его  настройки  какая-нибудь  утиль  типа
> fetchmailconf, или это можно ТОЛЬКО через файл конфигурации?
насколько я знаю, никакой "конфигурялки" для procmail'а нет. Ручками
через ~/procmailrc (man procmail)
     <skip>
> Так, попробуем въехать. Если мой адресат имеет постоянное подключение
> к И-нету, то этот MTA запущен на _локальной_ машине, а если он такой
> же dialup'щик, то он крутится на _почтовом сервере провайдера_. Так?

Как правило, да. Если у юзера нет выделеного доменного имени (т.е. он
просто пользователь user домена abc.net.ru), то вся почта приходит и 
хранится на почтовом сервере провайдера. Он же (юзер) получает
к ней доступ по POP3. Если у него есть доменное имя (напр. pupkin.abc.net.ru),
то, в принципе, он может получать почту по smtp. Просто в этом, втором
случае почта хранится у провайдера некоторое время, заданное в настройках
его smtp-сервера. Если smtp-сервер пользователя не появлялся в поле зрения
smtp-сервера провайдера в течение этого времени, то вся почта вернется
отправителям.
Вообще, вся работа smtp-сервера завязана на DNS. В DNS в
описании домена (напр. abc.net.ru) имеются записи MX, которые
указывают на почтовые серверы, которые могут принимать почту для
данного домена. Разумеется, эти серверы должны иметь постоянное
соединение (хотя можно и не иметь :). Так, отправитель (postfix или другой
SMTP-сервер), желающий отправить письмо по адресу vasya@pupkin.abc.net.ru,
обращается на DNS сервер и ищет МХ запись для pupkin.abc.net.ru. Она может быть,
а может и не быть. Допустим, что провайдер ничего не указал для этого клиента
(как правило :) или эта машина стоит в отделе организации, которой принадлежит
данный домент (abc.net.ru). Тогда сервер отправителя ищет mx запись для домена
предыдущего уровня (abc.net.ru). Их может быть несколько, т.е. почту для этого
домена можно отправлять на несколько _разных_ серверов. Одним из параметров
записи mx является приоритет (формат записи: [<domen>] MX <priority> <smtp-server address>)
Чем меньше номер - тем выше приоритет сервера. Пусть будет такая запись:
abc.net.ru.	mx	10 	mx.abc.net.ru.
		     mx     20      mx.cba.ten.ru
отправитель сначала пробует mx.abc.net.ru, если он недоступен, тогда mx.cba.net.ru.
Отправив почту на mx.cba, он считает свою работу выполненной. mx.cba, в свою 
очередь, тоже смотрит DNS, но видит, что перед ним остался только один
сервер - mx.abc. Если он не отвечает,  то mx.cba откладывает доставку на некоторое
время, потом повторяет. Так определенное количество раз. Если попытки не увенчались
успехом - он возвращает почту назад. Вот именно поэтому для хостов без постоянного
соединения нежелательно использование smtp протокола для _получения_ почты извне.
Лучше пусть она лежит у провайдера сколько угодно времени, а я потом вернусь из
отпуска и по POP3 скачаю. Кроме того, диалапщикам редко выделяют доменное имя, и
еще реже на них прописывают mx запись (и правильно, по приведенным выше причинам).


> 
> > Обмениваются приветами, и ваш передает
> > письмо. Тот смотрит, 
> > является ли адрес адресата для него локальным - если да, то
> > передает локальному
> > агенту для разборки и укладывания в соотв. локальный почт.
> > ящик; если нет - смотрит, 
> > разрешено ли ему релеить это письмо на другой хост, и либо
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Имеется в виду - на компьютер адресата?

                                                                                           <relay>                     <relay>
да:   petya@nosik.sender.ru -smtp-> mx.sender.ru -(dns:mx 50)-> some.mx.server.ru ->... 
                       <local domain>
        -(dns:mx 10)-> mx.abc.net.ru -> procmail -> local.mailbox -pop3-> vasya@abc.net.ru

> 
> > почтовый ящик. А вот тут может понадобится fetchmail. Если вы
>                                                              ^^^
> Я или адресат моего письма?

:-) если релей запрещен, то вам, если нет - адресату

> 
> Да нет, вроде что-то в голове прояснилось. Спасибо! А что выступает в
> роли MTA в оффтопике? Сама почтовая программа?
Если рассматривать Win 9x, Me, то, как правило, да. Функции MTA и MUA
объединены в одной программе (Bat, OE). Про агента локальной доставки
речи нет, т.к. нелокальная доставка не предусмотрена в проекте данной ОС.
Хотя существуют отдельные smtp- и pop-серверы сторонних производителей.
Но у нас в России их мало кто использует - ведь можно поставить NT
с того же диска ;-)

-- 
С уважением, 
                  Александр Саввин
----------------------------------
Email:	savvin@mail.ru
ICQ:    103069766		 
----------------------------------
      Powered by Linux Mandrake RE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[mdk-re] Re: Анатомия почты в Spring

[Mikhail Zabaluev]

Hello Sergey,

On Mon, Sep 24, 2001 at 10:55:08PM +0400, Sergey Kuznetsov wrote:
>
> Отправка  почты:
> MUA  отдает  почту Postfix'у. Тот ждет соединения с провайдером, затем
> по   команде  sendmail  -q  отправляет  ее  адресату  или  по  адресу,
> прописанному в relayhost.
> 
> Получение почты:
> Fetchmail  скачивает  почту  с почтового сервера по команде fetchmail,
> если  есть предварительно созданный файл .fetchmailrc, или fetchmail с
> параметрами,  если такого файла нет. Затем почта передается postfix'у,
> который отдает ее MUA по запросу пользователя.
> 
> Если  вышеописанное  представление  правильно,  то  для  чего же нужен
> postfix?  Если  бы  входящая  и  исходящая почта просто складывалась в
> заранее   обусловленном   месте   и  подхватывалась  из  него  другими
> программами,  не  то  же  ли  самое  бы  было?  Зачем  нужен  еще один
> посредник?

А зачем нужен адвокат, если все умеют читать и имеют доступ к
законодательным текстам? Postfix -- системный агент доставки, который
умеет обработать вверенную ему почту корректно, быстро и максимально
безопасно, или сообщить о возникших проблемах. Так что все другие
участники вечеринки могут отдавать ему сообщения и не тратить
собственный код на всю эту изумительную и тонкую работу.

> Если я все понял неправильно, то как все обстоит на самом деле? (Речь
> идет о построении почтовой системы В ЦЕЛОМ).

Все правильно.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
The worst is enemy of the bad.

[mdk-re] Re: [mdk-re] Re: Анатомия почты в Spring

[Sergey Kuznetsov]

>> Если  вышеописанное  представление  правильно,  то  для  чего же нужен
>> postfix?  Если  бы  входящая  и  исходящая почта просто складывалась в
>> заранее   обусловленном   месте   и  подхватывалась  из  него  другими
>> программами,  не  то  же  ли  самое  бы  было?  Зачем  нужен  еще один
>> посредник?
> 
> А зачем нужен адвокат, если все умеют читать и имеют доступ к
> законодательным текстам? Postfix -- системный агент доставки, который
> умеет обработать вверенную ему почту корректно, быстро и максимально
> безопасно, или сообщить о возникших проблемах. Так что все другие
> участники вечеринки могут отдавать ему сообщения и не тратить
> собственный код на всю эту изумительную и тонкую работу.

А  почтовый  сервер провайдера с этой задачей справиться не может? Или
postfix   умеет  выполнять  еще  что-то?  Правда,  я  еще  не  дочитал
документацию  до  конца...  А  как  же  обходится оффтопик - ведь там,
вроде, нет аналога postfix'у?

С уважением,
Сергей

[mdk-re] Re: Анатомия почты в Spring

[Mikhail Zabaluev]

Hello Sergey,

On Tue, Sep 25, 2001 at 11:12:55PM +0400, Sergey Kuznetsov wrote:
>
> 
> >> Если  вышеописанное  представление  правильно,  то  для  чего же нужен
> >> postfix?  Если  бы  входящая  и  исходящая почта просто складывалась в
> >> заранее   обусловленном   месте   и  подхватывалась  из  него  другими
> >> программами,  не  то  же  ли  самое  бы  было?  Зачем  нужен  еще один
> >> посредник?
> > 
> > А зачем нужен адвокат, если все умеют читать и имеют доступ к
> > законодательным текстам? Postfix -- системный агент доставки, который
> > умеет обработать вверенную ему почту корректно, быстро и максимально
> > безопасно, или сообщить о возникших проблемах. Так что все другие
> > участники вечеринки могут отдавать ему сообщения и не тратить
> > собственный код на всю эту изумительную и тонкую работу.
> 
> А  почтовый  сервер провайдера с этой задачей справиться не может? Или
> postfix   умеет  выполнять  еще  что-то?  Правда,  я  еще  не  дочитал
> документацию  до  конца...  А  как  же  обходится оффтопик - ведь там,
> вроде, нет аналога postfix'у?

Ну, в принципе, можно и как в Windows -- например, настроить
dial on demand, чтобы соединение устанавливалось каждый раз, когда вы
командуете клиенту отправить почту на провайдерский сервер. Но я этот
вариант отверг как менее удобный лично мне.

Вдобавок, как тут и везде уже было сказано, существуют процессы,
которые иногда не прочь передать вам привет с помощью локальной
почты. В Windows такой традиции нет, там даже сервисы общаются с
администратором с помощью всяких alert log'ов, а то и уродливых
message box'ов. Дежурный Админ в этой, с позволения сказать, культуре
прикован цепями к физическому монитору сервера, в то время как другой
админ, оперативник, носится между рабочими местами и выполняет текущие
задачи -- устанавливает ПО, меняет какую-нибудь одну настройку на
каждой машине и т.п.

Развивая тему удаленного доступа: в культуре Unix администратор скорее
подобен всемогущему и всеведущему богу. Присутствие во плоти требуется
от него редко; обо всем важном он может быть извещен по email, и для
управления сетью машин обычно достаточно удаленного терминала. Поэтому
администраторы Unix чаще обладают избыточным весом и повышенным
авторитетом.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org

Re: [mdk-re] Re: Анатомия почты в Spring

[cornet]

Mikhail Zabaluev wrote:
skip.

> Развивая тему удаленного доступа: в культуре Unix администратор скорее
> подобен всемогущему и всеведущему богу. Присутствие во плоти требуется
> от него редко; обо всем важном он может быть извещен по email, и для
> управления сетью машин обычно достаточно удаленного терминала. Поэтому
> администраторы Unix чаще обладают избыточным весом и повышенным
> авторитетом.

Это точно :-)) У меня частенько возникает ощущение, что я эдакий
паук в засаде, раскинувший свои невидимые сЕти по всей локальной
и не очень сетИ. Сижу на своем рабочем месте, за собственным
монтотом, и могу легко дотянуться везде где мне надо не слезая со
стула.
:-))

-- 
******** FIRE & STEEL ********