2.7 Pitfalls

• Before replacing your current sendmail with a new version, be sure that the queue is empty. The new version might not be able to properly process old (or different) style queued files.^[13] After running the new sendmail for the first time, look in the queue directory for filenames that start with an uppercase Q, which can indicate a problem. See Section 11.5 for a description of why these files appear and what to do about them.

  ^[13] V8 sendmail can read old queue files but might be unable to read some vendor queue files. If this is a problem, you might 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 might fail when you first try to run it. If the failure is difficult to diagnose, you might need to run the old version while you fix the new version. But beware that the old version will probably not be able to read the queue files created by the new version.

• Some operating systems allow disks to be mounted such that set-user-id 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 (Mail eXchanger) 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 (NAMED_BIND). Also note that a misconfigured service-switch file can also prevent proper MX lookups (ServiceSwitchFile).