How to Check Mail Aliases
To verify aliases and to confirm that mail can or cannot be delivered to a specified recipient, follow these instructions.
Display the aliases and identify that the final address is deliverable or not deliverable.
% /usr/lib/sendmail -v -bv recipient |
recipient | Specify a recipient's alias. |
The following is an example of the output.
% /usr/lib/sendmail -v -bv sandy sandy... aliased to ssmith ssmith... aliased to sandy@phoenix sandy@phoenix... deliverable: mailer esmtp, host phoenix, user sandy@phoenix.example.com % |
Avoid loops and inconsistent databases when both local and domain-wide aliases are used. Be especially careful when you move a user from one system to another to avoid the creation of alias loops.
How to Test the sendmail Rule Sets
To check the input and returns of the sendmail rule sets, follow these instructions.
Change to address test mode.
# /usr/lib/sendmail -bt
Test a mail address.
Provide the following numbers and address at the last prompt (>).
> 3,0 mail_address
mail_address
Use the mail address that you are testing.
End the session.
Press Control-d.
The following is an example of the output.
% /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 sandy@phoenix
canonify input: sandy @ phoenix
Canonify2 input: sandy < @ phoenix >
Canonify2 returns: sandy < @ phoenix . example . com . >
canonify returns: sandy < @ phoenix . example . com . >
parse input: sandy < @ phoenix . example . com . >
Parse0 input: sandy < @ phoenix . example . com . >
Parse0 returns: sandy < @ phoenix . example . com . >
ParseLocal input: sandy < @ phoenix . example . com . >
ParseLocal returns: sandy < @ phoenix . example . com . >
Parse1 input: sandy < @ phoenix . example . com . >
MailerToTriple input: < mailhost . phoenix . example . com >
sandy < @ phoenix . example . com . >
MailerToTriple returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
Parse1 returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
parse returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
|
How to Verify Connections to Other Systems
The mconnect program opens a connection to a mail server on a host that you specify and enables you to test that connection. The program runs interactively, so you can issue various diagnostic commands. See the mconnect(1) man page for a complete description. The following example verifies that mail to the user name sandy is deliverable.
% mconnect phoenix connecting to host phoenix (172.31.255.255), port 25 connection open 220 phoenix.example.com ESMTP Sendmail 8.12.0+Sun/8.12.0; Sun, 4 Sep 2001 3:52:56 -0700(PDT) expn sandy 250 2.1.5 <sandy@phoenix.example.com> quit |
If you cannot use mconnect to connect to an SMTP port, check these conditions.
Is the system load too high?
Is the sendmail daemon running?
Does the system have the appropriate /etc/mail/sendmail.cf file?
Is port 25 (the port that sendmail uses) active?
Logging Error Messages
Your mail services logs most error messages by using the syslogd program. By default, the syslogd program sends these messages to a system that is called loghost, which is specified in the /etc/hosts file. You can define loghost to hold all logs for an entire NIS domain. If no loghost is specified, error messages from syslogd are not reported.
The /etc/syslog.conf file controls where the syslogd program forwards messages. You can change the default configuration by editing the /etc/syslog.conf file. You must restart the syslog daemon for any changes to become active. To gather information about mail, you can add the following selections to the file.
mail.alert - Messages about conditions that should be fixed now
mail.crit - Critical messages
mail.warning - Warning messages
mail.notice - Messages that are not errors, but might need attention
mail.info - Informational messages
mail.debug - Debugging messages
The following entry in the /etc/syslog.conf file sends a copy of all critical, informational, and debug messages to /var/log/syslog.
mail.crit;mail.info;mail.debug /var/log/syslog |
Each line in the system log contains a timestamp, the name of the system that generated the line, and a message. The syslog file can log a large amount of information.
The log is arranged in a succession of levels. At the lowest level, only unusual occurrences are logged. At the highest level, even the most mundane and uninteresting events are recorded. As a convention, log levels under 10 are considered "useful." Log levels higher than 10 are usually used for debugging. See the "Customizing System Message Logging" in System Administration Guide: Advanced Administration for information about loghost and the syslogd program.