W B Hacker wrote:
> Jakob Hirsch wrote:
>> Dr. Tilo Levante, 2010-06-15 15:58:
>>
>>> we have the following log entry about the backup MX:
>>>
>>> 450 4.1.0 Don't use the Backup MX 'relay.rzone.de' while the Primary MX
>>> is available - please send your mail to ...
>>>
>>> Does exim use the Backup MX if the primary MX is available? Can I
>>> configure exim to prefer the primary MX?
>> Can you post the rcpt domain of the message?
>> rzone.de is the German ISP Strato, but I don't know any domains hosted
>> there that have relay.rzone.de listed as a MX.
>> Usually they only have this 10 mailin.rzone.de.
>>
>>
>> Funny thing is, just two days ago a message from Strato's outbound
>> relays was blocked on my mailserver because it connected to the second
>> MX without trying the first one before...
>>
>
> There appear to be propagation issues.
>
> Dig from USA, IAD area and from Hong Kong do not return the same records (or
> necessarily *any* records).
Directly checking the four listed primary nameservers ...
>
> There is no MX RR for relay.rzone.de Exim appears to have found it by its A RR.
>
> rzone.de lists as its *only* MX portal.webgods.de
>
> portal.webgods.de does not respond to a ping, but does to telnet smtp.
>
> rzone.de - despite published RR's, does not necessarily even resolve, so cannot
> be pinged or tenet'ed to (from HKG or IAD).
>
> relay.rzone.de responds to both ping and telnet smtp. Also http - though only to
> a placeholder page.
Well it *did* - with a rediract to an under construction page on
http://relay.zone.de (xone, not rzone).
Whatever was on
http://relay.rzone.de is no longer responding.
The
http://relay.zone.de page is still up.
>
> Looks to me to be that something is 'in transition'. Perhaps several somethings.
>
> Either way, not really an Exim issue at all.
>
> Might be simply hunger.
>
> Bill
>
BTW - traceroute to the nameservers completes only on ns3 and ns4, not on ns1 or ns2
... hard to analyze a moving target.....
Bill