Re: [exim] exim expert needed

トップ ページ
このメッセージを削除
このメッセージに返信
著者: W B Hacker
日付:  
To: exim users
題目: Re: [exim] exim expert needed
evi nemeth wrote:
*snip*

>
> i am having trouble wrapping my head around the exim config language and
> recognizing what is a language keyword or option name and what is a
> configured variable name. havent yet found a good explanation of the config
> language in the docs.
>


A prerequisite is understanding the smtp 'phases', next that the 'acl's' operate
during a single session, more or less in 'real time', and end with rejecting
ELSE handing-off a message to the queue, with or without added headers and
values in 'acl_m' variables.

The routers and transports are then operated off the queue contents, anywhere
from 'immediately after' to 'q' time later - hence the differences in 'language'
and what things they can and cannot see and do.

As to the acl 'language':

Exim was not written in Forth - but it could have been.

An acl and its logical flow is a vanilla 'case of' Forth word, and dead-easy for
a Forth coder to grok.

But it takes nearly an hour to learn enough Forth from a cold start to grok a
case structure, so I'll not push that route.

;-)

Among the best ways to learn?

- First: Use the debug toolset. No need to actually move any mail, as it can
tell you in selectably gruesome detail all the thing it WOULD do under a given
configuration when fed a sample message - and that includes hand-off to, for
example ClamAV or SA.

- Next: Enable 'ip_literals', set up two instances of Exim, both with
'log_selector = +all', either on two boxes on a crossover-cable or inside a LAN,
ELSE two Exim instances on ONE box, using different ~/configure files, and with
each bound to a different aliased-up IP on one NIC. No cable needed if on one
box - we'll just bounce in and out of the stack.

Put the IP's into /etc/hosts, and simulated 'live' traffic can go in and out of
the stack or over a roll-cable or local switch without ever having to disturb
the outside world, and with no risk of zombot penetration - which you can also
simulate.

When finally ready to go 'live' the smart admin sits on an ssh terminal with
something like:

tail -f -n 200 /var/log/exim/mainlog

And not just for an hour...

;-)

When satisfied that all is well, don't forget to back-down the 'log_selector =
+all' to something less hungry for disk space. And do come back and spot-check
frequently, even on a server that has been up for 2 or more years w/o reboot.

Any service as potentially easily abused as an MTA should be subject to plenty
of configuration testing before being opened-up to the world at large, and given
frequent monitoring thereafter.

Running an MTA is not to be done carelessly. Think of it as a public restaurant.

Quite welcome when kept clean and serving wholesome food.

But if you allow it to become dirty and spread disease, the mentors of those
who've been poisoned will hunt you down and lynch you in a New York minute...

;-)

Bill