Re: lug-bg: Sendmail

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

Delian Krustev wrote:

> Аиде сега да обясниш. Щом не съм разбрал да попитам.
> Първо, за какви обявявания на адрес и порт говориш ?
> Второ, що е то удостоверителен механизъм, и какво общо имат маршрутизаторите с него ?
>
> Thank You
>  
Усещам аз, че Google още не се е популяризирал някъде:) и че на хората 
не им се чете документация.
Да се върнем първо на оригиналният въпрос, а той беше как да се накара 
Sendmail като клиент да използва определен IP адрес, а не винаги да 
излиза от адресът, който лежи в един сегмент с този на шлюза за сървъра. 
Беше малко не на място да ме цитираш в един твой предишен постинг 
относно макроса DAEMON_OPTIONS, защото той бе дадена за пълнота за да се 
ориентира питащият (ето какво си написал ти):
=============================================================

On Wednesday 14 April 2004 11:28, Vesselin Kolev wrote:


> > DAEMON_OPTIONS(`Port=smtp,Addr=IP_address, Name=MTA')dnl
>  
Има и друг вариант, без да пипаш конфига на сендмаила. При стартиране
(ако е по sid) адваш правила в iptables/netfilter с помощта на -m owner
(може по sid, може и по uid, зависи как го рънваш) match-ваш, и маркираш.
Впоследствие:

ip ru add from ... fwmark ... lookup ...

и в съответната таблица му задаваш да излиза с което ip искаш ..

=============================================================

Не искам да те обидя, но нямаш доста основни познания. Макросът 
DAEMON_OPTIONS се използва от демона за приемане на входящи сесии.  
Темата, която обсъждахме ние касаеше макросът CLIENT_OPTIONS и именно 
той касе изходящите сесии. Първо ред обяснения, които може би ще са ти 
нужни. По принцип Sendmail може да е многолик, когато се използва за 
клиент. Причината се крие в различните (два на брой) протоколи за 
удостоверяване, които той може да използва, а и не само в тях. 
Особеността идва от едни вътрешномакросни флагове, които се именоват (в 
единствено число) като "Modifier". Тези флагове касаят примерно 
подаването на име при HELO и EHLO и т.н. Така и така стана дума за EHLO 
и HELO, ето точно един пример с тях. Възможно е да направиш следното 
нещо. Обявяваш макросът CLIENT_OPTIONS, употребяваш Modifier и му слагаш 
флаг "h", т.е. да се получи нещо от рода на "M=h" и това значи, че при 
действието си като клиент Sendmail ще се представи пред сървъра, с който 
комуникира с хост името, което е асоциирано към адреса, от който той 
комуникира (упоменат в макроса CLIENT_OPTIONS). Как ще постигнеш това 
чрез маршрутизация (както ти пишеш) като това е механизъм касаещ 
протокола SMTP? Чрез флаг "E" може да се изисква да се използва STARTTLS 
и т.н. Любопитно ми е как чрез предложената от теб схема ще успееш да 
накараш Sendmail при действието си като клиент да използва STARTTLS при 
изходяща сесия от един от асоциираните към него IP адреси и как ще го 
накараш да не използва STARTTLS при използването на друг IP адрес?
Та сега на въпроса ти за маршрутизаторите и удостоверителните механизми. 
Sendmail може да избира (примерно чрез LDAP маршрутизация) 
направленията, в които той ще работи като клиент и адмнистратора може да 
дефинира в кои направления може да се използва или не удостоверяване 
(схема mail hub най-вече). Ако ти направиш изборът на изходящо 
направление (изходящ IP адрес) чрез външна за Sendmail процедура, ти 
прецакваш цялата тази избирателност по направления. Пример. Друг сървър, 
на който ти предаваш електронна поща като клиент е свързан с твоя в един 
сегмент (т.е. той ти е link съсед) и ти имаш IP адрес в този сегмент и 
този сегмент е различен от този, в който се намира шлюза. Ти си избраш 
по подразбиране изходящата поща да използва STARTTLS. Но за какъв дявол 
ти е STARTTLS към link съседа ти, който се намира в същия сегмент и 
потока от/към него не минава през Интернет? По принцип STARTTLS схемата 
товари и е оправдана само, ако се прави пренос в несигурна среда. Да не 
говорим, че пък може да искаш към Интернет да се използва STARTTLS, а 
към съседа да се използва SMTP-AUTH. Как ще познаеш кога какво се иска 
чрез маркиране на пакетите?
Друг пример. Имаш няколко Sendmail демона в chroot и всеки обслужва 
заявки идващи към отделен IP адрес, но използват един единствен адрес 
при работата си като клиенти. Как ще познаеш кой демон кой е (обикновено 
те използват един потребител, например mail за собственик на процесите).
След това, цялата ти схема с маркиране може да работи ако имаш поне два 
шлюза и дефинираш отделни маршрутизиращи таблици за всеки един от тях и 
твоя Sendmail в даден момент е или само клиент или само сървър от гледна 
точка на сесиите. Представи си каква каша ще стане, ако Sendmail 
едновременно вземе да приема и изпраща. Жална ти майка. И какво, в 
рамките на една сесия приема пакети на един IP адрес и излъчва от друг. 
Единственият изход е да си сигурен, че този дето иницира сесията (когато 
твоя Sendmail работи като сървър) не изпъчва от порт 25 и да правиш 
някакви сложни премаркирания в зависимост от порта на излъчвателя и да 
следиш всеки пакет и да товариш машината с глупости. Ама няма как да си 
сигурен в това (да не говорим, че доста сървъри за поща, когато работят 
като клиенти излъчват от порт 25 за да минат през разни "заграждения"). 
Следеното на тези неща може да стане само на ниво SMTP протокол. Но ако 
е така, защо са ти тези абсурдни външни маршрутизации?
 Весо



============================================================================
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
============================================================================