Re: [exim] multiple hosts in route_data

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] multiple hosts in route_data
bsd@??? wrote:

> W B Hacker wrote:
>
>>Tony Finch wrote:
>>
>>
>>>On Tue, 22 Aug 2006, bsd@??? wrote:
>>>
>>>
>>>
>>>>How can I configure that exim tries all hosts when the first fails?
>>>
>>>You can't. Your DNS and Exim configurations must be consistent.
>>>
>>>Tony.
>>
>>AFAIK, so long as they *are* consistent, Exim will inherently try all known mx
>>hosts in published mx priority order at initial delivery and at each retry
>>attempt until it finds one that accepts the traffic, ELSE fails to find *any*
>>such active.
>
> I don't want to use MX records.


Well.... given that that is what they are *for*, perhaps you don't want to use
smtp either?

> We set up a relay server for a customer.
> This relay is the only MX record for this domain.


You can give it more than one IP, and more than one mx record, BUT - that
presumes a highly reliable box....

> We have a manualroute
> router for this customer where route_data is set in a mysql db. Now the
> customer's DNS setup was broken and the host didn't resolve.


Exim should maybe read minds?

> Then exim
> denied all incoming mails for this domain with 451 temporary rejected.


What else could it have done?

> Now I search for a solution for this:
>
> - I'd like to add more than one server in route_data for the case that
> one of them fails. I tried that with : seperated entries but exim always
> only uses the first one.


Nature of the beast with that particular structure.
Uses first match found, looks no further.

>
> - I'd like that exim accepts the mail even when the server in route_data
> is not resolvable. I added host_find_failed = defer to the router but
> exim still rejects the mail with 451.
>
> Michael
>


You would need a fall-through and one or more similar subsequent routers with
valid alternative destination(s) (temporary storage, perhaps?).

You would also need to 'test' each potential route before committing to it.
AFAIK, such behaviour is not entirely inherent, but could no doubt be
constructed in any of several ways.

But why reinvent that wheel? When you cut your face shaving, you want to put the
band-aid on the wound, not on the bathroom mirror.

Far better to improve the reliability of the servers involved - and the DNS,
even if you have to run your own copy of it. A *BSD server should stay up until
intentionally rebooted or until the CPU or PS fan and HDD fail.

HTH,

Bill