Today my mail server (patched 8.13.6) went and stopped delivering mail
for some of my toy domains.
This mail server is MX for those domains (receiving only though) and
delivers with catchall entries in virtusertable:

@toydomain.com some@internal.domain

Error is something like:

Running /var/spool/mqueue/l3NEpam09907 (sequence 1 of 5)
<some@toydomain.com>... toydomain.com: Name server timeout
<some@toydomain.com>... Transient parse error -- message queued for
future delivery

while something like
echo test | sendmail -v -d8.20 test@toydomain.com

shows a series of lookups for toydomain.com (AAAA A then MX), all
failing since that server does use an internal (private) dns server with
a configuration which doesn't get any data for that specific domain
(because not configured internally and no recursion to public name
servers allowed).
However this didn't ever stop sendmail from using the address
some@internal.domain specified in virtusertable, until now.

I couldn't find anything changed in any sendmail or bind configuration.
Is this normal behaviour, lookup for the MX of the destination domain
(and fail if no A or MX records found) even when it will be changed by
virtusertable anyway ?
In other words, did it work by chance before but shouldn't have had
(because the lookups before virtusertable expansions are normal and
records must be present) or should it still work now (and how can I find
what is wrong ?

In article <YY4Xh.16060$uJ5.284726@twister2.libero.it> HH
<already@enough.spam.thank.you> writes:
>Today my mail server (patched 8.13.6) went and stopped delivering mail
>for some of my toy domains.
>This mail server is MX for those domains (receiving only though) and
>delivers with catchall entries in virtusertable:
>
>@toydomain.com some@internal.domain
>
>Error is something like:
>
>Running /var/spool/mqueue/l3NEpam09907 (sequence 1 of 5)
><some@toydomain.com>... toydomain.com: Name server timeout
><some@toydomain.com>... Transient parse error -- message queued for
>future delivery
>
>while something like
>echo test | sendmail -v -d8.20 test@toydomain.com
>
>shows a series of lookups for toydomain.com (AAAA A then MX), all
>failing since that server does use an internal (private) dns server with
>a configuration which doesn't get any data for that specific domain
>(because not configured internally and no recursion to public name
>servers allowed).
>However this didn't ever stop sendmail from using the address
>some@internal.domain specified in virtusertable, until now.
>
>I couldn't find anything changed in any sendmail or bind configuration.
>Is this normal behaviour, lookup for the MX of the destination domain

Yes, it's part of "canonification" - e.g. sendmail doesn't (and
shouldn't) have internal knowledge about what toplevel domains exist,
and tries to deal with the possibility that toydomain.com is actually
shorthand for toydomain.com.example.net.

>(and fail if no A or MX records found)

It doesn't *fail*, the message is queued for a later retry. However this
wouldn't happen if DNS said "that domain doesn't exist" (NXDOMAIN), it's
due to a temporary type of failure - your DNS returned SERVFAIL or timed
out. Probably due to neither being able to reach external servers nor an
internal "fake" root server. NXDOMAIN means that canonification failed,
but sendmail will proceed with normal processing - however in some cases
that processing will be different due to the lack of canonification.

> even when it will be changed by virtusertable anyway ?

Yes, the virtusertable lookup happens later - it's important that
canonification happens before any routing decisions, e.g. to continue
the above hypothetical example, it wouldn't find your virtusertable
entry for toydomain.com.example.net otherwise.

>In other words, did it work by chance before but shouldn't have had
>(because the lookups before virtusertable expansions are normal and
>records must be present) or should it still work now (and how can I find
>what is wrong ?

"It depends", see above - canonification can also be satisfied by
/etc/hosts entries, btw. You can turn off canonification altogether or
partially via FEATURE(`nocanonify'), see cf/README, and you can declare
that toydomain.com should be considered already canonical by putting

LOCAL_CONFIG
CP toydomain.com

in your .mc file.

--Per Hedeland
per@hedeland.org