Re: [exim] "unseen" not working correctly?

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] "unseen" not working correctly?
Robert Kehl wrote:
> Hello!
>
> I have two routers in a row that serve the purpose of forking a copy of
> a mail to one system while delivering the very same mail to another
> system, too. I need this for testing a system without affecting the real
> mail flow.
>
> The routers are simple manualroute routers with fixed destinations. The
> only option set is 'same_domain_copy_routing' to speed up things: the
> system is the main entry point to a mid-volume enterprise system and I
> do not rely on the local part at all. They get fed mails based on
> decision earlier routers take, so no decision is needed on these two -
> we know what we got. These are the routers in question:
>
> external_copy:
>    driver = manualroute
>    condition = yes
>    transport = external_smtp
>    route_data = 192.168.1.20
>    same_domain_copy_routing
>    unseen = yes

>
> external:
>    driver = manualroute
>    transport = external_smtp
>    route_data = 192.168.1.1
>    same_domain_copy_routing

>
> This is the transport both use:
>
> external_smtp:
>    driver = smtp
>    interface = 192.168.1.100
>    tls_certificate = /some/file
>    tls_privatekey = /some/otherfile
>    no_tls_tempfail_tryclear
>    hosts_randomize = true

>
> The problem I encounter is: The first router gets a mail with, say, 13
> recipients to process, whereas the second router only gets fed 7
> recipients afterwards. I understood the 'unseen' option as follows: The
> second router should get a 100% copy of the mail the first one got. I.
> e., no matter wether the first router is successful in delivering or
> not, the addresses are in every case given to the second router. Am I
> wrong in that point?
>
> If I am wrong, how could I implement forking away a copy of each email
> to a different host? I guess a shqdow_transport is not what I need?
>
> I'm running a self-compiled exim 4.71 on a minimized Debian Lenny
> system. Compile options are available, for sure.
>
> Any help would be greatly appreciated.
>
> With highest regards,
>
> Robert Kehl
>


'At least for testing'..... and perhaps for production.

A) Move towards finer granularity:

Duplicate the transport, give the new one a new name, change routers so
that each router calls its 'own' transport - even if they are identical
in all BUT 'name'.

Rationale:

- Reduce chance that the *transport* is making decisions (duplicates?)

- Your logs can now show precisely which router AND transport tiggered.



B) Move toward closer standardization:

- add a 'condition = <something>' to the second router.

(or remove the 'condition = yes' from the first. If that is what it
really says...)

IOW - do something realistic and germane with a conditional.

Conditionals are what give routers a sense of touch, taste, and smell..

;-)

That may not resolve the problem. But it should make it self-identify.

Bill