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
