Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: Sendmail


  • Subject: Re: lug-bg: Sendmail
  • From: Delian Krustev <krustev@xxxxxxxxxxx>
  • Date: Fri, 16 Apr 2004 00:41:11 +0300

On Thursday 15 April 2004 21:33, Vesselin Kolev wrote:

> Не искам да те обидя, но нямаш доста основни познания. Макросът
> DAEMON_OPTIONS се използва от демона за приемане на входящи сесии.
> Темата, която обсъждахме ние касаеше макросът CLIENT_OPTIONS и именно
> той касе изходящите сесии.

Абсолютно си прав, за съжаление видях че съм оставил DAEMON_OPTIONS
вместо CLIENT_OPTIONS след като натиснах сенд ..

Що се отнася до _основните_ понятия, не съм ползвал нито CLIENT_OPTIONS,
нито DAEMON_OPTIONS. И да съм ги ползвал е било преди години, когато
все още работех с sendmail. От постинга ти, както и самите имена на
опциите говорят красноречиво кое за какво е .. Thank You че се хващаш
за глупости ..

> Първо ред обяснения, които може би ще са ти
> нужни. По принцип Sendmail може да е многолик, когато се използва за
> клиент. Причината се крие в различните (два на брой) протоколи за
> удостоверяване, които той може да използва, а и не само в тях.
> Особеността идва от едни вътрешномакросни флагове, които се именоват (в
> единствено число) като "Modifier". Тези флагове касаят примерно
> подаването на име при HELO и EHLO и т.н. Така и така стана дума за EHLO
> и HELO, ето точно един пример с тях. Възможно е да направиш следното
> нещо. Обявяваш макросът CLIENT_OPTIONS, употребяваш Modifier и му слагаш
> флаг "h", т.е. да се получи нещо от рода на "M=h" и това значи, че при
> действието си като клиент Sendmail ще се представи пред сървъра, с който
> комуникира с хост името, което е асоциирано към адреса, от който той
> комуникира (упоменат в макроса CLIENT_OPTIONS). Как ще постигнеш това
> чрез маршрутизация (както ти пишеш) като това е механизъм касаещ
> протокола SMTP?

Никак. Логично е че не си конфигваш хоста с които отговаряш/се представяш
с рутинг. Тук за справка погледни въпроса който беше зададен в оригиналния
пост.

> Чрез флаг "E" може да се изисква да се използва STARTTLS
> и т.н. Любопитно ми е как чрез предложената от теб схема ще успееш да
> накараш Sendmail при действието си като клиент да използва STARTTLS при
> изходяща сесия от един от асоциираните към него IP адреси и как ще го
> накараш да не използва STARTTLS при използването на друг IP адрес?

Отново offtopic. Човека не питаше това.

> Та сега на въпроса ти за маршрутизаторите и удостоверителните механизми.
> Sendmail може да избира (примерно чрез LDAP маршрутизация)
> направленията, в които той ще работи като клиент и адмнистратора може да
> дефинира в кои направления може да се използва или не удостоверяване
> (схема mail hub най-вече). Ако ти направиш изборът на изходящо
> направление (изходящ IP адрес) чрез външна за Sendmail процедура, ти
> прецакваш цялата тази избирателност по направления. Пример. Друг сървър,
> на който ти предаваш електронна поща като клиент е свързан с твоя в един
> сегмент (т.е. той ти е link съсед) и ти имаш IP адрес в този сегмент и
> този сегмент е различен от този, в който се намира шлюза. Ти си избраш
> по подразбиране изходящата поща да използва STARTTLS. Но за какъв дявол
> ти е STARTTLS към link съседа ти, който се намира в същия сегмент и
> потока от/към него не минава през Интернет? По принцип STARTTLS схемата
> товари и е оправдана само, ако се прави пренос в несигурна среда. Да не
> говорим, че пък може да искаш към Интернет да се използва STARTTLS, а
> към съседа да се използва SMTP-AUTH. Как ще познаеш кога какво се иска
> чрез маркиране на пакетите?

Аха. Тук казваш - има вариант в които ако sendmaila ти е конфигнат еди
как си, твоята схема няма да работи. Allright. Вярно е, има.

> Друг пример. Имаш няколко Sendmail демона в chroot и всеки обслужва
> заявки идващи към отделен IP адрес, но използват един единствен адрес
> при работата си като клиенти. Как ще познаеш кой демон кой е (обикновено
> те използват един потребител, например mail за собственик на процесите).

Гледаики от къде ? Ще ги позная по PID. Xe xe. Само да добавя, изпуснал
си частта за маркирането по SID, session identifier. Oще нещо, ако човека
беше тръгнал да прави това нямаше да задава тоя въпрос.

> След това, цялата ти схема с маркиране може да работи ако имаш поне два
> шлюза 

Абсолютно невярно. man ip.
ip ru add ..... src ....

> и дефинираш отделни маршрутизиращи таблици за всеки един от тях и
> твоя Sendmail в даден момент е или само клиент или само сървър от гледна
> точка на сесиите. 

Ще работи както ако е клиент така и ако е сървър. За това споменах в втория
постинг да си подсигури на кое ip му влиза пощата.

> Представи си каква каша ще стане, ако Sendmail
> едновременно вземе да приема и изпраща. Жална ти майка. И какво, в
> рамките на една сесия приема пакети на един IP адрес и излъчва от друг.
> Единственият изход е да си сигурен, че този дето иницира сесията (когато
> твоя Sendmail работи като сървър) не изпъчва от порт 25 и да правиш
> някакви сложни премаркирания в зависимост от порта на излъчвателя и да
> следиш всеки пакет и да товариш машината с глупости. Ама няма как да си
> сигурен в това (да не говорим, че доста сървъри за поща, когато работят
> като клиенти излъчват от порт 25 за да минат през разни "заграждения").

Напротив, имаш как да си сигурен. За това са тия DNS записи.

> Следеното на тези неща може да стане само на ниво SMTP протокол. Но ако
> е така, защо са ти тези абсурдни външни маршрутизации?

Защото е demon independent. Защото си го правил. Защото си сигурен че работи.
Защото не ти се рови по документацията на сендмаила. Защото предпочиташ да
свършиш работата бързо. Enough ?

Ето ти малко психология. Избиваш комплекси пич. Като се правиш на велик.
Обичаш да си мислиш че си по-умен от всички останали. Изкарваш другите
неподготвени за да си проличи колко си подготвен ти.

Не говоря за подробните ти постинги. Евала за тях. Говоря за безсмисленото
заяждане.

> Доста прибързано решение, което може да ти създаде ОГРОМНИ проблеми.
> Причината е, че в обявяванията за адрес и порт в общия случай може да
> има конкретизиран и удостоверителен механизъм (M=a, M=E, M=Ea и др.).

"удостоверителен" - думичката е аутентикация, не удостоверяване
"обявяванията за адрес и порт" - избор на адрес и порт

> Как ще разбере маршрутизатора ти за какъв вид удостоверяване иде реч е
> доста интересен въпрос.

Никак, не му е това работата.

Благораря за отделеното време да се конкретизираш. И пак още нещо. Считай
казаното от мен за градивна критика. Не съм имал на идея да те обиждам
и/или да подлагам на въпрос познанията ти в *nix. Такива очевидно имаш.

Поздрави,
Делян
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================


  • Във връзка с:

 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.