So why would sendmail use IP over MX?

And so it goes that I spent most of the morning investigating  a pesky mail delivery problem which sort of goes as follows:

Running sendmail-8.13.8-8.1.el5_7 on CentOS5, with virtusertable and virtuser-domains. We (ourown.it) are handling mail for the domain customer.it:

  # dig ANY customer.it
   ...
  ;; ANSWER SECTION:
  customer.it.            9136    IN      NS      ns02.provider.com.
  customer.it.            9136    IN      NS      ns01.provider.com.
  customer.it.            31610   IN      MX      20 rigel.ourown.it.
  customer.it.            31610   IN      MX      10 alpha.ourown.it.
  customer.it.            3535    IN      A       10.213.221.92
  
  ;; AUTHORITY SECTION:
  customer.it.            9136    IN      NS      ns01.provider.com.
  customer.it.            9136    IN      NS      ns02.provider.com.
  
  ;; ADDITIONAL SECTION:
  ns01.provider.com.      3535    IN      A       10.227.46.9
  ns02.provider.com.      3535    IN      A       10.175.38.200
  alpha.ourown.it.                86400   IN      A       10.111.444.5
  rigel.ourown.it.                86400   IN      A       10.111.444.10

Customer.it is in virtuser-domains (so it *SHOULD* be recognized as local) but NOT in local-host-names (for long winded reasons I would rather avoid using local-host-names for this ). My expectation is that email should get to the highest MX (alpha) and be delivered there. What actually happens is that email sent to customer.it is queued up on alpha (even when it is sent form alpha itself) and delivery is attempted at the HOST customer.it (where no mail server is listed). This is what I see:

  #sendmail  -d17.99 -q -v -qRevit                                                 Running /var/spool/mqueue/r3C89pgp020280 (sequence 1 of 2)                     
  hostsignature(customer.it.)                                                    
  mxrand(rigel.ourown.it) = 148
  hostsignature(): getmxrr() returned 1, mxhosts[0]=customer.it.                   hostsignature(customer.it.) = evi... Deferred: Connection timed out with customer.it.

customer.it.                                                                    ... Connecting to customer.it. via esmtp...                                                                                   

MXs are correctly found:

  # echo "/mx customer.it" | sendmail -bt -d8.20
  
  ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
  Enter  

  > getmxrr(customer.it, droplocalhost=0)
  found localhost (alpha.ourown.it) in MX list, pref=10
  getmxrr(customer.it) returns 2 value(s):
          alpha.ourown.it.
          rigel.ourown.it.

I have many other domains thusly configured and working the crucial difference being that the IP for the domain is either not set or points to alpha.ourown.it. Address test outlines a difference:

  # sendmail -bt -d8.20
  ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
  Enter  

  > 0 aguy@customer.it
  parse              input: aguy @ customer . it
  Parse0             input: aguy @ customer . it
  Parse0           returns: aguy @ customer . it
  ParseLocal         input: aguy @ customer . it
  ParseLocal       returns: aguy @ customer . it
  Parse1             input: aguy @ customer . it
  Parse1           returns: $# local $: aguy @ customer . it
  parse            returns: $# local $: aguy @ customer . it
  
  
  > 0 alf@ourown.it
  parse              input: alf @ ourown . it
  Parse0             input: alf @ ourown . it
  Parse0           returns: alf @ ourown . it
  ParseLocal         input: alf @ ourown . it
  ParseLocal       returns: alf @ ourown . it
  Parse1             input: alf @ ourown . it
  Parse1           returns: $# local $: alf @ ourown . it
  parse            returns: $# local $: alf @ ourown . it

But its meaning is lost on me.

And then it struck me: the addresses that were being queued did not locally exist (it was someguy@customer.it rather than aguy@customer.it).

What happens is that sendmail, upon realizing that local delivery is not possible for the address at hand, "helpfully" tries the IP address as last resort. If that bugs you, as it bugs me, insert the line:

@customer.it               error:nouser 550 No such user here

in virtusertable, after all other customer.it records.