Cannot send to anyone hosted by messagelabs

[Brian]

Every time we try to send to any domain hosted by messagelabs we have
trouble. The first mx record for some reason does not get used and it
goes to the seconday mx record, which slowly dies with a 421 message
deferred error (actually I don not think they have any servers working
behind some secondary MX records).

We have no issues sending to anyone else, whatsoever. GWIA is 6.5.6 sp 4.

Thanks for anyone who can help!

Brian

[Brian]

No takers? If I can send to everywhere else except domains hosted by
messagelabs how safely can I assume it is their problem?

Thanks!

Brian

[Massimo Rosen]

Hi,

Post by Brian
No takers?

Well, some technical detail would possibly help getting more attention.
How about some significant part of your GWIA logs for that matter? Set
to verbose please. <g>

CU,

[Brian]

Sorry about lack of detail. Here is the repeating theme. For whatever
reason we are not connecting to the primary mx, but get attached to the
secondary mx record which does not seem to be connected to anything.


06-15-07 06:58:59 35 DMN: MSG 162325 Sending file:
KSSPTCNWGWD11/DATA:DOMAINWPGATEGWIAsendp67238b2.038
06-15-07 06:59:00 35 DMN: MSG 162325 Connected to
cluster3a.eu.messagelabs.com
06-15-07 06:59:00 35 DMN: MSG 162325 Send Failure: 421 Service Temporarily
Unavailable


The only thing I can get from this is that they are not RFC compliant if
there is nothing behind their secondary mx record, but I am not absolutely
sure that it is not our issue either.

Thanks!

Brian

[Chris]

Brian,

Did you ever get this resolved? I've got the same exact thing going on
right now, only mine is getting rejected from cluster2 and not cluster3.

Not being a MessageLabs customer, any call that I've placed to them has
gone exactly no where.

[Karim C Kronfli]

Post by Chris
Brian,
Did you ever get this resolved? I've got the same exact thing going on
right now, only mine is getting rejected from cluster2 and not cluster3.
Not being a MessageLabs customer, any call that I've placed to them has
gone exactly no where.

I'm having exactly the same problem, I am hoping to initiate a packet
scan to see exactly what's going on

Further to this I have taken a packet scan and found that the gwia ONLY
initiates a connection with the secondary MX.

I know I am on GW7.0.3 but it is a similar problem.

My network design is.

GWIA = 7.0.3 on NW 6.5.5
DNS Server on Win2K Latest patches
Firewall = BM 3.8 sp5 on NW 6.5.7

I can telnet to port 25 on the secondary MX from the gwia server with most
of the time, it fails on the primary MX.(Grr)

I can telnet from a windows workstation or server without issues.

I can telnet from a linux box without issues.

I am beginning to lose the will to live :-(

Karim

[karimk]

Hi Guys, I don't know if you are still having this issue but it looks
like we have solved.

We had to open an incident with Novell.

We got a very new build of GW 7.0.3 with a newer GWIA apparently this
changes the way DNS lookups occur.

We upgraded our Primary Domain and GWIA (Which sits on the same server)
and hey presto mail starts going to messagelabs!

[BSWOODS35]

Guys,

This turns out to be a scheme by messgelabs. If you used cached DNS
information that is too stale, you will always go to the secondary MX
record they publish, the so called honeypot.

To get around it I configured my DNS to have a very short TTL , like 15
seconds or so.

They have a very tight window on when DNS information is accurate. If
you are not pretty much constantly updating your DNS you run the risk of
defer till death. Just make the TTL in DNS a very small number.

Brian
MCNE

[Massimo Rosen]

Hi,

DNS TTL is not a GW setting. It's an OS / DNS server setting. Consult
your NOS docs.

Actually, before trying to dive into this, to me this whole explanation
sounds extremely suspicious and unlikely. The TTL of a DNS record is
specified by the owner of the record (here: Mesagelabs). Every remotely
serious DNS server has to adhere to the setting that is specified in the
original record, and isn't something that should or even can be changed
on ones own DNS server.

CU,

[Karim C Kronfli]

Thanks for all your replies guys.

In order to solve it we built a linux DNS server just for our GWIA to use
and dropped its caching time to absolute minimum. That solved the issue.

Karim