18.7 Pitfalls

• Before replacing your current sendmail with a new version, be sure that the queue is empty. The new version may not be able to properly process old (or different) style queued files. [10] After running the new sendmail for the first time, look in the queue directory for filenames that start with an uppercase Q. See Section 23.3, "A Bogus qf File (V8 only): Qf" for a description of why these files appear and what to do about them.

  [10] V8 sendmail can read old queue files but may be unable to read some vendor queue files. If this is a problem, you may have to run the old and new versions in parallel (with separate queue directories) until the old queue has been emptied.

• If you change the location of the queue to a different disk, be sure that disk is mounted (in /etc/rc) before the sendmail daemon is started. If sendmail starts first, there is a risk that messages will be queued in the mount point before the disk is mounted. This will result in mysteriously vanishing mail.

• Always save the old sendmail and configuration file. The new version may work fine for a while, then suddenly fail. If the failure is difficult to diagnose, you may need to run the old version while you fix the new version. But beware that the old version may not be able to read the queue files created by the new version.

• Some operating systems allow disks to be mounted such that suid permissions are disallowed. If you relocate sendmail, avoid locating it on such a disk.

• Don't be mistaken in the belief that nis will correctly give you MX for hosts. If, after compiling and installing sendmail, you find that you cannot send mail to hosts using MX records, you should recompile with NAMED_BIND defined (see Section 18.8.23, NAMED-BIND). Also note that a misconfigured service-switch file can also prevent proper MX lookups (see Section 34.8.61, ServiceSwitchFile).