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.

The strange world of SELinux and webmin

I am willing to share a few more sysdamin pains today, for the BDSM oriented people who enjoy suffering.

I am testing webmin on a CentOS 6.3 machine today. Purpose: creating a restricted web-paneled environmente where a basically skilled admin can add users, mailboxes, aliases and so on  without hosing the system or opening mile-wide holes into it. It does look doable so far except....

I want mail delivery done in Maildir-style folders under the user homedir. Procmail is the perfect tool for this, given the following /etc/procmailrc:

LOGFILE=/var/log/proc_log
DEFAULT=$HOME/mail/

(Hint: the trainling slash does the trick).

Enters webmin, breakage begins.  A webmin-added user, balf, cannot have mail properly delivered, while a adduser-added user alf, can. Ostensible reason being that, in the first instance, procmail is incapable of creating the mail/ directory. The logfile trace is self-explanatory as usual:

procmail: Unable to treat as directory "/home/balf/mail"
procmail: Locking "/home/balf/mail.lock"
procmail: Error while writing to "/home/balf/_D3D.N35ZRB.localhost.localdo"
procmail: Lock failure on "/home/balf/mail.lock"
procmail: Assigning "LASTFOLDER=/home/balf/mail/"
procmail: Opening "/home/balf/mail/"
procmail: Error while writing to "/home/balf/mail"
procmail: Assigning "LASTFOLDER=/var/spool/mail/balf"
procmail: Opening "/var/spool/mail/balf"
procmail: Acquiring kernel-lock

Uh? Google brings no joy other than the usual check permissions and stuff. Which I did. The gut instinct reaction (manually creating the mail directory) just pushes the problem deeper. Some work succeds in making the users exactly the same (same permissions, on home dirs, same group, same passwd and shadow entries, same files in the home dir. So it must be something with permissions, which means....SELinux. Which I usually turn off - but forgot on this time. 'ls -Z' verifies that the homedirs of the users have indeed different context:

 # ls -Z drwx------. alf mailusers unconfined_u:object_r:user_home_dir_t:s0 alf drwx------. balf mailusers unconfined_u:object_r:home_root_t:s0 balf

So, at this point you turn off SELinux, and all is well (put SELINUX=disabled in /etc/sysconfig/selinux).