Often, but not always, sendmail defers sending messages to recipients
in the domain qnet.com. When it does this, it reports:

mailer=esmtp, pri=122123, relay=qnet.com., dsn=4.0.0, stat=Deferred:
Name server: qnet.com.: host name lookup failure

Hours later, when it finally works, it reports
relay=mailguard-600-a.qnet.com ,
which is the correct MX record for qnet.com whenever I look. When
sendmail uses relay=mailguard-600-a.qnet.com the first time the
message goes through the first time. It would seem that there is a
tempfail of the lookup of qnet's MX record occasionally. Is there
anyway to force sendmail always to relay messages to qnet.com
via mailguard-600-a.qnet.com? We send a lot of messages to
recipients in this domain (It's a rural area and qnet used to have a
monopoly.) and delays sometimes last seven hours.

random troll wrote:
> Often, but not always, sendmail defers sending messages to recipients
> in the domain qnet.com. When it does this, it reports:
>
> mailer=esmtp, pri=122123, relay=qnet.com., dsn=4.0.0, stat=Deferred:
> Name server: qnet.com.: host name lookup failure
>
> Hours later, when it finally works, it reports
> relay=mailguard-600-a.qnet.com ,
> which is the correct MX record for qnet.com whenever I look. When
> sendmail uses relay=mailguard-600-a.qnet.com the first time the
> message goes through the first time. It would seem that there is a
> tempfail of the lookup of qnet's MX record occasionally. Is there
> anyway to force sendmail always to relay messages to qnet.com
> via mailguard-600-a.qnet.com? We send a lot of messages to
> recipients in this domain (It's a rural area and qnet used to have a
> monopoly.) and delays sometimes last seven hours.

Use the mailertable feature.

You may also find that the resolution of the above record to name is
unreliable as well, requiring you to utilize a hosts file entry.

However, this is all evil.

Proper is to find out why this is happening, whose fault it is, and fix
it so that things work the way they were meant to.

jmaimon: 'Use the mailertable feature.'
I looked at that but was not sure how it worked.
Would I use:
qnet.com smtp:[mailguard-600-a.qnet.com]
?

jmaimon: 'You may also find that the resolution
of the above record to name is unreliable as well,
requiring you to utilize a hosts file entry.'
Wouldn't that affect all protocols?

jmaimon: 'Proper is to find out why this is happening,
whose fault it is, and fix it so that things work the way
they were meant to.'
What control have I over this? Doesn't qnet's DNS
return the MX record, meaning that they have to fix it?

random troll wrote:
> jmaimon: 'Use the mailertable feature.'
> I looked at that but was not sure how it worked.
> Would I use:
> qnet.com smtp:[mailguard-600-a.qnet.com]

cf/README

esmtp is probably a better idea than smtp

> ?
>
> jmaimon: 'You may also find that the resolution
> of the above record to name is unreliable as well,
> requiring you to utilize a hosts file entry.'
> Wouldn't that affect all protocols?
>
> jmaimon: 'Proper is to find out why this is happening,
> whose fault it is, and fix it so that things work the way
> they were meant to.'
> What control have I over this? Doesn't qnet's DNS
> return the MX record, meaning that they have to fix it?

there is a distance between "we dont get a response to our query for mx
record" and "they dont send an answer to our query"

jmaimon wrote: 'cf/README'
I read the README. I didn't have confidence
that I understood it completely.

jmaimon: 'there is a distance between "we dont
get a response to our query for mx record"
and "they dont send an answer to our query"'
I interpret this sentence to mean that qnet
may reply to our request for an MX record but
that it may take longer to arrive than sendmail
waits. I don't understand how to apply it to
our situation. Lengthen one of the resolver
timeouts?

random troll wrote:
> jmaimon wrote: 'cf/README'
> I read the README. I didn't have confidence
> that I understood it completely.

This will work

qnet.com esmtp:[mailguard-600-a.qnet.com.]

This may work better

qnet.com esmtp:[209.221.193.28]

Or this

qnet.com
esmtp:[mailguard-600-a.qnet.com.]:[209.221.193.28]

Or this

qnet.com
esmtp:qnet.com.:[mailguard-600-a.qnet.com.]:[209.221.193.28]


>
> jmaimon: 'there is a distance between "we dont
> get a response to our query for mx record"
> and "they dont send an answer to our query"'
> I interpret this sentence to mean that qnet
> may reply to our request for an MX record but
> that it may take longer to arrive than sendmail
> waits. I don't understand how to apply it to
> our situation. Lengthen one of the resolver
> timeouts?

You just want to check that it is indeed them not you. Having performed
some digs on the zone, I can well understand if they have problems
implementing DNS correctly, so lets assume the issue does indeed lie
with them and the mailertable is the best you can do.