As a mail transfer agent, or MTA, sendmail is intended to run as a daemon process, and not to interact directly with users. Sendmail is capable of delivering mail to a wide variety of hosts, located on different networks, and communicating with different protocols. To achieve this level of flexibility, sendmail uses the concept of "mail delivery agents". These mail delivery agents are defined within the sendmail configuration file
Each mail delivery agent is set up to handle delivery to certain types of destination, and the majority of the mail delivery agents call external programs to perform their functions. For mail that is to be delivered to a local user, the local delivery agent will be used, which will in turn call /bin/mail (or sometimes mail.local or procmail) for actual delivery. For mail destined for UUCP connected hosts, the UUCP delivery agent will be used, and this will in turn call uux for final delivery. Similarly, mail destined for hosts on DECNET or BITNET will use other delivery agents. For each type of host that sendmail is to deliver to, there must be a corresponding delivery agent.
The delivery agents that sendmail uses for Internet e-mail are the SMTP and ESMTP delivery agents, and these are worthy of particular note, as they do not reference external programs, but instead call upon the SMTP/ESMTP protocol support built into sendmail.
The delivery agents are defined within sendmail.cf, and the definitions look something like this:-
Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21/31, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=IPC $h
The mail delivery agents give sendmail the flexibility it needs to get mail to hosts with virtually any type of network connection, but they do not address the problem of mail routing; how does sendmail decide which delivery agent to use for a given piece of mail?
Although sendmail in capable of delivering mail to hosts on many different types of network due to the flexibility provided by the mail delivery agents, it can receive incoming mail only from a TCP/IP network, from a remote mailer that speaks SMTP/ESMTP. To understand how sendmail chooses a delivery agent, it is first necessary to understand how an SMTP mail transaction is structured. Returning to our previous example of a user at mail.linux.org sending mail to a user at microsoft.com, the mail transaction might look like this:-
220 mail1.microsoft.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2524.0) ready helo mail.linux.org 250 mail1.microsoft.com Hello linus@mail.linux.org [198.182.196.59], pleased to meet you mail from: <linus@mail.linux.org> 250 <linux@mail.linux.org>... Sender ok rcpt to: billg@microsoft.com> 250 <billg@microsoft.com>... Recipient ok data 354 Enter mail, end with "." on a line by itself Date: Mon, 04 Jan 1999 09:51:42 -0000 (GMT) From: Linus Torvalds <linus@mail.linux.org> To: Bill Gates <billg@microsoft.com> Subject: MTA's Bill, I notice you are using Microsoft Exchange for your mail. Hasn't anyone told you about the superiority of open source software for mission critical tasks like this? I suggest you switch to sendmail - it's cheaper too.... Linus. . 250 XAA08154 Message accepted for delivery quit 221 closing connection
The first 7 lines of the mail transaction tell the remote mailer who the sender and recipient are, and terminate with the "data" command. This information forms the SMTP envelope. In the data phase of the SMTP transaction, headers are transmitted first, then a blank line, then the body of the mail message, and finally a message will end with a . on a line alone. Sendmail uses the information in the SMTP envelope to determine how to deliver the message. The headers may be rewritten by sendmail, but they will not be used in mail routing decisions.
Sendmail parses the recipient address specified in the SMTP envelope through a series or rules. Rules are like regular expressions; each rule tests a pattern against an address, and if the pattern matches, the address is rewritten into a different form. By passing an address through a large enough block of rules, sendmail can make decisions about how to deal with a message. Each of these blocks of rules is called a ruleset, and an example ruleset in a sendmail.cf file might look like this:-
S3 # handle null input (translate to <@> special case) R$@ $@ <@> # strip group: syntax (not inside angle brackets!) and trailing semicolon R$* $: $1 <@> mark addresses R$* < $* > $* <@> $: $1 < $2 > $3 unmarkIt goes on, but you get the idea..... The sendmail configuration file has, in the past, been compared to such diverse things as modem noise and ciphertext, by various people.R@ $* <@> $: @ $1 unmark @host:... R$* :: $* <@> $: $1 :: $2 unmark node::addr R:include: $* <@> $: :include: $1 unmark :include:... R$* [ $* : $* ] <@> $: $1 [ $2 : $3 ] unmark IPv6 addrs R$* : $* [ $* ] $: $1 : $2 [ $3 ] <@> remark if leading colon R$* : $* <@> $: $2 strip colon if marked R$* <@> $: $1 unmark R$* ; $1 strip trailing semi R$* < $* ; > $1 < $2 > bogus bracketed semi
Sendmail employs a series of rulesets chained together for the purposes of analyzing mail.
These rulesets are related as shown:-
Sendmail uses these rulesets as follows:-