Derek Simkowiak wrote:
> [Somebody please correct me if I'm wrong, as I have not yet tested
> this hypothesis...]
>
> What I have learned is that, yes, there are a large number of
> built-in "drivers" (i.e., routers, transports, or authenticators). Those
> built-in drivers do not need to be defined in the config file because they
> are built-in.
These are like drivers for IDE/SCSI/Network.
> When you define your own "driver" (router, transport, or
I'm not sure if the term driver is right here, maybe "driver instance"
would be more correct, but on exim-users we mostly use the specific
terms router, transport and authenticator.
> authenticator) you are basically customizing one of the built-in drivers
> by using non-default config file options.
Yep.
> In the common case, when a message comes in, it starts at the
> first router in the config file, and then goes through them one-by-one
> until it matches the preconditions for that router (Section 3.9). Once
> the preconditions are met, it falls into that router, and then (commonly)
> would go to a transport. It may also be redirected to another router,
> etc. -- see Section 3.8 for the full story. For incoming mail, the
> message eventually winds up at a transport.
And it could be redirected to another address, this will restart the
whole router-process with the new address, unless you defined
redirect_router.
> The transport is what would move it from the Exim queue to the
> enduser's mailbox file, or maybe a pipe to procmail. The 'smtp' transport
> would relay the message on to a different host (I think).
Yep, basicly correct.
> This system is very easy to understand. I was at first confused
> because (a) I didn't realize there were a series of built-in drivers, and
> (b) because I could find no list of built-in drivers. What I did not
> realize is that the drivers are listed as chapters of the manual... that
> is, Chapter 15 is the "accept router" (all routers are drivers), Chapter
> 26 is the "autoreply transport" (all transports are drivers), etc.
>
> I would have kept on track if Section 3.7 would have said
>
> "There are a large number of built-in drivers (routers, transports, and
> authenticators) in Exim. You build your own drivers by specifying which
> built-in driver you want to use with the 'driver = ' option, and
> customizing that with the particular config options for that driver.
Well, this is not really correct, you just USE the driver for your
driver instance.
> The drivers are listed as chapter titles of this manual."
>
> Of course that's completely obvious now (DOH!), but reading
> through it for the first time this was not obvious. The HTML is set up
> such that you cannot see the titles of subsequent chapters at the time you
> are reading a particular chapter. (And when I'm already stuck at Chapter
> 3, looking ahead ten or twenty chapters is the last thing I want to
> confuse myself with.)
Reading the docs more than one time doesn't hurt, believe me ;)
>>I presume it redirects or tells the router to redirect.
>
>
> Yes. It tells it to use the built-in 'redirect' router, see
> Chapter 21.
>
>
>>where does it redirect from and to?
>>what tells it where to redirect to?
>
>
> See Chapter 21, I'm just a n00b (as they say on Counter-Strike).
>
>
>>I am sure this is pretty basic stuff but the router syntax is just not
>>very intuitive to me.
>
>
> Assuming my interpretation is correct, this is both easy and
> powerful. I'm starting to feel about Exim the way I feel about Python...!
> :)
It is, that's why we use it :)
The router-concept of exim allows great flexibility, if you want to see
something real sick, have a look at
http://mail.tmtowtdi.de/exim/exim4.qmail
the qmail_* routers are the interesting ones, if you know qmails
forward-file concept you maybe see what it does ;)
ciao
