Re: [exim] changing mailstores

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Phil Pennock
Fecha:  
A: paul.osborne
Cc: exim users, W B Hacker
Asunto: Re: [exim] changing mailstores
On 2012-10-05 at 10:58 +0100, paul.osborne@??? wrote:
> Hence my very specific questions related to what happens if I queue
> the email on the router and the routing data is updated.
>
> Does exim calculate the routing data and cache that information so
> when it retries a delivery it uses the cached data, or will say ah
> retry time is up and run the delivery back through the routers for the
> mail that is queued and so pick up the new routing data?


There are two different ways a deferred delivery can be done; one will
re-route, the other won't. Both depend on DB files in the db/
subdirectory of the spool directory ("exim -bP spool_directory").
Because of this duality, the specification is silent. I'll describe
matters as they stand now, although I don't think there are any
guarantees that this will hold in future releases. (Equally, there are
no plans I'm aware of to change, and you're doing the transition _now_).

A queue runner will look at the retry DB, find what still needs to be
sent and has reached a retry threshold time period, then run the routers
and delivery the mail. This does exactly what you want.

SEPARATELY, if a mail can't be delivered to a remote host, an entry is
created in a wait-<transport_name> DB. If a later connection to the
same host succeeds, and the transport lets more than one message be
delivered down one SMTP connection, then after the first message is
delivered, the later messages will be grabbed for delivery too. I don't
believe that routing is re-run in this case.

ALSO, if you do two-stage routing/delivery (queue_only, exim -qq, etc)
then the routing stage does the hints creation in the wait-<TN> DB so
that one connection can pump all the mails down it.

So, if you set connection_max_messages to 1 on the transports, and can
live with using one TCP connection per email, always, then you should be
okay.

If your volumes are such that you _need_ multiple mails in one
connection for the majority of mails, then things are more complicated.

-Phil