Recipe 5.2 Sending Error Messages from the mailertable

Problem

You have been asked to configure sendmail to reject mail bound for certain hosts and domains with an error.

Solution

Create mailertable entries using the domain names as the key to which mail will not be delivered and using the error messages as the return value that should be returned when the mail is rejected. Process that file with makemap to build a hash database.

Create a sendmail configuration that includes the mailertable feature. The following lines add the mailertable to a sendmail configuration:

 dnl Add support for the mailertable FEATURE(`mailertable') 

Build and install sendmail.cf , and then restart sendmail, as described in Recipe 1.8.

Discussion

The error mailer is built into the sendmail binary. The error mailer returns an error message to the sender of the mail message. Like other mailers, the error mailer can be specified in the mailer field of a mailertable entry. When it is, the host field of the entry contains the error message, the SMTP response code, and the Delivery Status Notification (DSN) code. The syntax of a mailertable entry for the error mailer is:

   key  error:D.S.N:code message   

where key is a full or partial domain name , error is the name of the mailer, D . S . N is an enhanced status code defined as three dot separated numeric fields or an SMTP error code keyword, ^[2] code is a numeric SMTP response code, and message is the text message returned to the sender. D . S . N values must comply with the specifications of RFC 1893, Enhanced Mail System Status Codes . D specifies success or failure; S identifies the error category; and N provides additional detail. The RFC calls these three values class , subject, and detail and defines them as follows :

^[2] See Table 5-1 for a list of SMTP error code keywords.

class

Provides a broad classification of the status. Three values are defined for class in the RFC: 2 means success, 4 means temporary failure, and 5 means permanent failure.

subject

Classifies the error messages as relating to one of eight categories:

0 (Undefined)

The specific category cannot be determined.

1 (Addressing)

A problem was encountered with the address.

2 (Mailbox)

A problem was encountered with the delivery mailbox.

3 (Mail system)

The destination mail delivery system is having a problem.

4 (Network)

The network infrastructure is having a problem.

5 (Protocol)

A protocol problem was encountered.

6 (Content)

The message content caused a translation error.

7 (Security)

A security problem was reported .

detail

Provides the details of the specific error. The detail value is only meaningful in the context of the subject code. For example, x.1.1 means a bad destination user address, and x.1.2 means a bad destination host address, while x.2.1 means the mailbox is disabled, and x.2.2 means the mailbox is full. See RFC 1893 for the list of detail codes.

Let's examine a sample mailertable entry:

 oldname.ora.com   error:5.7.1:550 oldname.ora.com is out of service 

Testing this entry with sendmail -bv shows that the mailertable is operational and that the entry works, but it does not make clear the role of the SMTP code or the DSN code:

 #  sendmail -bv [e-mail]  [e-mail]... oldname.ora.com is out of service 

In fact, the -bv test in this case does not show all of the values in the mail delivery triple. Instead, you see the same messages that anyone sending mail to oldname.ora.com would see. To see the full mail delivery triple for the error mailer, run sendmail with the -bt option and use the /parse command:

 #  sendmail -bt  ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> >  /parse [e-mail]  Cracked address = $g Parsing envelope recipient address canonify           input: richard @ oldname . ora . com Canonify2          input: richard < @ oldname . ora . com > Canonify2        returns: richard < @ oldname . ora . com > canonify         returns: richard < @ oldname . ora . com > parse              input: richard < @ oldname . ora . com > Parse0             input: richard < @ oldname . ora . com > Parse0           returns: richard < @ oldname . ora . com > Parse1             input: richard < @ oldname . ora . com > MailerToTriple     input: < error : 5 . 7 . 1 : 550 oldname . ora . com is out of  service > richard < @ oldname . ora . com > MailerToTriple   returns: $# error $@ 5 . 7 . 1 $: 550 oldname . ora . com is out of  service Parse1           returns: $# error $@ 5 . 7 . 1 $: 550 oldname . ora . com is out of  service parse            returns: $# error $@ 5 . 7 . 1 $: 550 oldname . ora . com is out of  service [e-mail]... oldname.ora.com is out of service mailer *error*, host 5.7.1, user 550 oldname.ora.com is out of service >  /quit  

The /parse command shows that the SMTP code or the DSN code is used as the host value in the mail delivery triple, and the error message appears as the user value. When the DSN code is used as the host value, the SMTP code appears as the first string of the user value. The effect of all of this is best seen in the SMTP protocol interactions. A simple telnet test shows the real impact of this mailer table entry:

 #  telnet localhost smtp  Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 chef ESMTP Sendmail 8.12.9; Mon, 4 Nov 2002 18:32:51 -0500  HELO chef.wrotethebook.com  250 chef.wrotethebook.com Hello localhost.localdomain [127.0.0.1], pleased to meet  you  MAIL From:<[e-mail]>  250 2.1.0 [e-mail]... Sender ok  RCPT To:<[e-mail]>  550 5.7.1 [e-mail]... oldname.ora.com is out of service  QUIT  221 2.0.0 chef.wrotethebook.com closing connection Connection closed by foreign host. 

The RCPT To : command contains a recipient address that matches the key in the oldname.ora.com mailertable entry. Notice the SMTP response to this recipient address. Like all SMTP responses, it starts with a response code. The code is 550, which is the value we defined in the mailertable entry. The next field in the SMTP response is the DSN code ”again, it is the value we defined in the mailertable . This is followed by the recipient address and the error message we defined in the mailer table. Clearly, the mailertable entry for oldname.ora.com controlled all aspects of this response.

I recommend using the DSN value on all mailertable entries for the error mailer because doing so places you in control of all aspects of the error response.

See Also

Recipe 5.1, Recipe 5.3, and Recipe 5.4 describe additional mailertable features. The sendmail book covers the mailertable in Section 4.8.24 and the error mailer in Section 20.4.4.