slightly OT sendmail question

[Will Yardley]

I've been having some random problems with sendmail 8.12 beta that are
somewhat DNS related and have had no response from the sendmail newsgroup.
Is sendmail 8.12 more picky about DNS stuff than earlier versions (ie 8.11)?
I'm getting 'domain does not resolve' errors when i can clearly resolve
something on the machine itself.  There are usually DNS errors of one type or
another, but an A record and an MX record can be found generally (both
through at least one of the sites' nameservers (often _one_ is timing out)
and from the main nameserver in /etc/resolv.conf.  is sendmail now picky
about whether or not a repsonse is authoritative? does it query the
authoritative server directly for _any_ records?

turning off 'canonify' seems to help in some cases, but not always.

here's another error:
<address at removed>: Connected to 209.85.245.5 but sender was rejected.
Remote host said: 451 4.1.8 <forbar at 2xtreme.net>... Domain of sender address
forbar at 2xtreme.net does not resolve 

i can resolve 2xtreme.net through both nameservers directly, although both
respond non-authoritatively.

since we're having this problem with a lot of domains, I'm not quite sure
what to do - is this a bug or a feature of sendmail? sending to the same
domains works fine from my home machine (sendmail 8.11).  i will downgrade if
i have to, but i'd prefer not to.

here's some more information (the original message)

----- Forwarded message from will yardley <sendmail at hq.newdream.net> -----
We're running this verion of sendmail:
Debian Sendmail 8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1
(the debian woody package).

I'm getting a lot of errors like this in the mail queue:
f693os3v003543     7708    2708186+Jul  8 20:50 <address-removed>
                 (host map: lookup (prodigy.net.mx): deferred)

The nameservers in /etc/resolv.conf can find an mx record for most of
these hosts, as can sendmail. In most / all cases, it seems as if
_one_ of the authoritative nameservers for the domain that's being
sent to is timing out.  However one or two other nameservers are still
responding.  Force running the queue selectively results in the same
error (the first message to a particular domain takes a while, spits
out an error, and the rest scroll by).

Here's the results of testing one such address (I've replaced the
actual login name with 'removed' but the domain name is the correct
one in case that helps with testing:

# sendmail -v -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /parse removed at prodigy.net.mx
Cracked address = $g
Parsing envelope recipient address
canonify           input: removed @ prodigy . net . mx
Canonify2          input: removed < @ prodigy . net . mx >
removed at prodigy.net.mx... prodigy.net.mx: Name server timeout
Canonify2        returns: removed < @ prodigy . net . mx >
canonify         returns: removed < @ prodigy . net . mx >
parse              input: removed < @ prodigy . net . mx >
Parse0             input: removed < @ prodigy . net . mx >
Parse0           returns: removed < @ prodigy . net . mx >
ParseLocal         input: removed < @ prodigy . net . mx >
ParseLocal       returns: removed < @ prodigy . net . mx >
Parse1             input: removed < @ prodigy . net . mx >
MailerToTriple     input: < > removed < @ prodigy . net . mx >
MailerToTriple   returns: removed < @ prodigy . net . mx >
Parse1           returns: $# esmtp $@ prodigy . net . mx $: removed <
@ prodigy .
 net . mx >
parse            returns: $# esmtp $@ prodigy . net . mx $: removed <
@ prodigy .
 net . mx >
2                  input: removed < @ prodigy . net . mx >
2                returns: removed < @ prodigy . net . mx >
EnvToSMTP          input: removed < @ prodigy . net . mx >
PseudoToReal       input: removed < @ prodigy . net . mx >
PseudoToReal     returns: removed < @ prodigy . net . mx >
MasqSMTP           input: removed < @ prodigy . net . mx >
MasqSMTP         returns: removed < @ prodigy . net . mx >
EnvToSMTP        returns: removed < @ prodigy . net . mx >
final              input: removed < @ prodigy . net . mx >
final            returns: removed @ prodigy . net . mx
removed at prodigy.net.mx... Transient parse error -- message queued for
future deli
very
mailer esmtp, host prodigy.net.mx, user removed at prodigy.net.mx
> /mx prodigy.net.mx
getmxrr(prodigy.net.mx) returns 1 value(s):
        smtp.prodigy.net.mx.
>
I can resolve the hostname as well:
(from the same machine:
% dig prodigy.net.mx
<snip>
;; ANSWER SECTION:
prodigy.net.mx.         1m20s IN A      148.235.168.60

I was able to run the queue by adding (temporarily)
FEATURE(nocanonify) - however I have the distinct feeling that's
probably not a good idea longterm from reading the description of this
feature on the sendmail site.  Any response would be appreciated. 
Please cc me on response as I don't have access to a newsgroup server
at the moment.

Sendmail config file follows:
divert(0)
VERSIONID(`@(#)sendmail.mc      8.7 (Linux) 3/5/96')
OSTYPE(debian)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(`nouucp', `nospecial')dnl
FEATURE(redirect)dnl
FEATURE(local_procmail)

define(`confMAILER_NAME', `DREAM-DAEMON')dnl


MAILER(local)dnl
MAILER(smtp)dnl

## Custom configurations below (will be preserved)
# custom params
define(`confPRIVACY_FLAGS', `goaway,restrictmailq,restrictqrun')dnl

FEATURE(virtusertable)

FEATURE(access_db)
define(`confDONT_PROBE_INTERFACES',`True')

# rbl
FEATURE(`dnsbl',`blackholes.mail-abuse.org')
# relay entire domain
FEATURE(`relay_entire_domain')
# authenticated smtp
TRUST_AUTH_MECH(`PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `PLAIN LOGIN')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Port=25, Name=MSA, M=E')dnl
# set max daemon children
define(`confMAX_DAEMON_CHILDREN',`200')dnl
# _don't_ look at .forward files!
define(`confFORWARD_PATH',`')dnl



----- End forwarded message -----