During the delivery phase of a message, sendmail looks up the destination hostname with DNS and (possibly) redirects delivery to MX hosts, if present. One way (but not the best way) to suppress that MX lookup is to surround the destination hostname with square brackets. An unfortunate side effect of this technique is that the square brackets are included in the envelope of the message:

RCPT To:<user@[mail.us.edu]>

The F=0 flag is a better way to suppress MX lookups. For an example of one use for this flag, consider the nullclient feature from Section 19.6.20, FEATURE(nullclient).

FEATURE(`nullclient',`mail.us.edu')

Here, all mail will be forwarded to mail.us.edu; but because mail.us.edu is not surrounded by square brackets, its MX records will be looked up for delivery. This may not be desirable, because the hostname in the envelope will change depending on which MX record is selected. To suppress those MX lookups, we can surround the address with square brackets:

FEATURE(`nullclient',`[mail.us.edu]')

But this has the unfortunate side effect of adding the bracketed name [mail.us.edu] to the outgoing envelope. If, instead, the brackets are omitted and the F=0 flag is added, we achieve the same MX suppression effect and send out a legal envelope:

define(`SMTP_MAILER_FLAGS', `0')
FEATURE(`nullclient',`mail.us.edu')

A better way to achieve the same effect is to define a new delivery agent and use that with the nullclient feature:

FEATURE(`nullclient',`nomxsmtp:mail.us.edu')
LOCAL_CONFIG
Mnomxsmtp, P=[IPC], F=0mDFMuX, S=11/31, R=21, E=\r\n, L=990, T=DNS/RFC822/SMTP, A=IPC $h 
                      
                     note

This second approach is much better for the various ..._RELAY features.

The F=0 flag is suitable only for configurations like the nullclient. It can be extremely dangerous to use it with any other delivery agents, because it can cause necessary MX lookups to be skipped.

When sendmail is required to convert a message body into quoted-printable form as determined by the EightBitMode (8) option (see Section 34.8.22), it ordinarily converts only those characters that are required by RFC1521. Unfortunately, mail that is transmitted to some IBM machines (specifically those that speak EBCDIC instead of ASCII) can become garbled because of the way EBCDIC represents (or fails to represent) certain characters. Those characters are

! " # $ @ \ [  ] ^ ` { | } ~

When sending MIME mail to such sites, you should probably set the F=3 flag for any delivery agents that handle those sites. Setting this flag tells sendmail to encode those characters, in addition to those normally encoded, using quoted-printable.

Note that sendmail does this encoding only if 8-bit characters appear in the message. This flag solves one EBCDIC problem but should not be thought of as a general solution for all EBCDIC problems.

Prior to V8.7 sendmail, only the local delivery agent could cause rule set 5 to be called (see Section 29.7, "Rule Set 5"). Rule set 5 is called after aliasing and before forwarding, and can be used to select a new delivery agent. Beginning with V8.7, any delivery agent with the F=A flag set (see Section 30.8.12) can cause an address to be looked up in the aliases(5) file. Therefore any delivery agent that has the F=A and F=5 flag set will cause rule set 5 to be called as though the agent were the local delivery agent.

In configuration files prior to Version 6 (see Section 27.5, "The V Configuration Command") this flag is automatically set for the local delivery agent. Note that addresses that (perhaps artificially) begin with an @ character cause rule set 5 to be skipped (see Section 29.7).

Under old versions of sendmail, all lines of text output by sendmail (including the header and body of a message) automatically have the high bit cleared (zeroed) for every character. This behavior remains unchanged under V8 sendmail for configuration file versions 2 or less (see Section 27.5). But with version 3 and above configuration files, the message body is transmitted with the high bit intact by default. For those delivery agents that should not allow 8-bit data to be transmitted, you may use the F=7 flag to force the old behavior.

Beginning with V8.7, the F=7 flag can be used to suppress certain kinds of MIME conversions. For example, if the EightBitMode (8) option (see Section 34.8.22) is set to p (pass 8) and if the message contains 8-bit MIME data in its body, this F=7 flag will force sendmail to bounce the message with the following SMTP error, to put 5.6.3 (see RFC1893) in its DSN status, and to exit with EX_DATAERR:

554 Cannot send 8-bit data to 7-bit destination

Note that F=7 affects only the message body. Headers always have the high bit cleared.

Beginning with V8.7 sendmail, you can set the EightBitMode (8) option (see Section 34.8.22) to m (mimefy) to force all unlabeled 8-bit mail to be converted into MIME labeled mail.

You can suppress this conversion for particular delivery agents by specifying the F=8 flag. This form of suppression has the effect of setting the EightBitMode (8) option to p (pass 8) for an individual delivery agent.

The F=9 flag cause the MIME message body of a delivered message to be converted back from either quoted-printable or base64 into its original 8-bit form. The F=9 flag is effective only if sendmail was compiled with MIME7TO8 defined (see Section 18.8.21, MIME7TO8).

Conversion works only on single-part MIME messages. If the Content-Transfer-Encoding: header type is base64, conversion is done from base64 to 8-bit. Otherwise, if the Content-Transfer-Encoding: header type is quoted-printable, then conversion is done from quoted-printable to 8-bit. If the Content-Transfer-Encoding: header type is neither, no conversion is done. The conversion process can be watched with the -d43.3 debugging switch (see Section 37.5.151, -d43.3).

Prior to V8.7 sendmail, only the local delivery agent could recognize the :include: directive for creating mailing lists (see Section 25.2, ":include: Mailing Lists").

Beginning with V8.7, any delivery agent can be made to recognize the :include: directive by setting the F=: flag (or to ignore it by not setting the F=: flag). This flag allows you to design a local delivery agent without :include: support or local-type clones with :include: support. In configuration files prior to Version 6 (see Section 27.5) this flag is automatically set for the local delivery agent.

This flag is only legal for addresses contained in aliases(5) databases or ~/.forward files. Any :include: address in an SMTP dialog or on the command-line will be rejected.

Prior to V8.7 sendmail, only the local delivery agent could recognize the | character as a directive to pipe the mail message through a program. (See Section 24.2.3, "Delivery via Programs" and Section 25.7.4, "Piping Through Programs".)

Beginning with V8.7, any delivery agent can be made to accept the leading | character. If the F=| flag is present, the delivery agent will accept the leading | character and call the prog delivery agent to pipe the message through a program. If the flag is absent, this ability to pipe is prohibited. In general, the F=| flag should be present for the local and local-clone delivery agents but absent for all others. In configuration files prior to Version 6 (see Section 27.5) this flag is automatically set for the local delivery agent.

This flag is only legal for addresses contained in aliases(5) databases or ~/.forward files. Any |program address in a SMTP dialog or on the command-line will be rejected.

Prior to V8.7 sendmail, only the local delivery agent could recognize a leading / character as a directive to append the mail message to a file. (See Section 24.2.2 and Section 25.7.3, "Appending to Files".)

Beginning with V8.7, any delivery agent can be made to accept the leading / character. If the F=/ flag is present, the delivery agent will accept a leading / character and call the *file* delivery agent to append the mail message to a file. If the flag is absent, this ability to append is prohibited. In general, the F=/ flag should be present for the local and local-clone delivery agents but absent for all others. In configuration files prior to Version 6 (see Section 27.5), this flag is automatically set for the local delivery agent.

This flag is only legal for addresses contained in aliases(5) databases or ~/.forward files. Any /file address in an SMTP dialog or on the command-line will be rejected.

If V8.7 or above sendmail has been compiled with User Database support (see Section 33.5, "The User Database"), specifying this flag for a delivery agent causes the delivery agent to perform User Database lookups for each address it handles. For sender header and envelope addresses, a User Database mailname keyword is used to perform reverse aliasing. For recipient envelope addresses, a User Database maildrop keyword is used to perform additional forward aliasing. Note that any address with a leading @ character (in the $: part of the triple returned by rule set 0) causes User Database lookups to be skipped. Also note that the absence of an F=i flag (Section 30.8.24) suppresses User Database rewriting of the envelope sender.

If the F=@ flag is present, the delivery agent will try to use the User Database. If the F=@ flag is absent, all User Database lookups are skipped. In general, this flag should be present for the local and local-clone delivery agents but absent for all others. In configuration files prior to Version 6 (see Section 27.5) this flag is automatically set for the local delivery agent.

Most versions of sendmail run only basic SMTP (Simple Mail Transfer Protocol) defined in RFC821. In 1993 that service was extended by RFC1425 to become Extended SMTP (or ESMTP). Beginning with V8 sendmail, you can enable a delivery agent to use ESMTP by specifying the F=a flag. This causes sendmail to first try to use the extended form of the HELO command, called EHLO. If that fails to be acknowledged as okay, sendmail tries again with nonextended SMTP. If the initial inbound greeting includes a line containing the word ESMTP, the F=a flag is assumed.

Prior to V8.7 sendmail, only the local delivery agent could cause addresses to be looked up in the aliases(5) database (see Section 24.1.2, "Local Must Be Local"). Beginning with V8.7 sendmail, any delivery agent that has an F=A flag set will cause its $: address to be looked up on the left-hand side of the aliases(5) file.

For example, the F=A flag can be used to design a local-clone delivery agent that recognizes certain nonlocal addresses as local for aliasing purposes: [16]

[16] This example is somewhat contrived because the same thing can be done in a more versatile manner with the mailertable feature (see Section 19.6.14, FEATURE(mailertable)).

R$+ <@ FIRE.WALL>     $#firelocal $: [email protected]

This allows an alias file like the following to legally exist:

[email protected]:   [email protected]

As a safety net (and if the F=5 flag is also specified), any address that is not found in the aliases(5) database will be passed to rule set 5 (see Section 29.7), where another delivery agent can be selected.

In configuration files prior to Version 6 (see Section 27.5) the F=A flag is automatically set for the local delivery agent.

Some UNIX mailbox formats require a blank line at the end of one message and before the start of the next message. If your local version of /bin/mail does not assure one, you may use the F=b flag. If this flag is specified and if the message being sent to the delivery agent lacks a blank line at the end, sendmail adds one. This flag is also appropriate for use with the *file* delivery agent.

Ordinarily, sendmail tries to preserve all RFC822 comments in sender addresses (see Section 35.3.4, "Comments in the Header Field"). But beginning with V8.7, RFC822 comments can be be stripped by setting this F=c flag. (An RFC822 comment is one in parentheses or text outside angle brackets.) The sender address, always without a comment and stripped of angle brackets, is placed into $g (see Section 31.10.16, $g) and is used with the -f or -r arguments to A= (see Section 30.8.37). In assembling headers, the comment is ordinarily restored to $g; but if this F=c flag is set, the comment is left out.

The main use for this flag is to supply just the address to programs that cannot handle anything else. Another use might be to suppress disclosure of potentially proprietary information. By adding F=c to the smtp delivery agent, for example, you can cause sender headers that are defined with $g to go out without RFC822 comments:

From: George Washington (The Prez!) <[email protected]>     without F=c
From: [email protected]                                     with F=c

Note that this does no good at all if users send out mail with disclosing headers already present or if they give out information in signature lines.

The F=C flag causes sendmail to append an @domain extension to any recipient address that lacks one. The @domain that is added is copied from the envelope sender's address.

This F=C flag is not looked for in the delivery agent definition that was selected to send the message. Rather, it is looked for in the delivery agent that would be selected if the sender were the recipient (as in the case of bounced mail).

To illustrate, consider the following mail:

From: [email protected]
To: [email protected], alice

The recipient address alice lacks an @domain specification. The sendmail program processes the envelope sender address [email protected] to decide on a delivery agent definition that can be used if this mail needs to be returned. If that envelope sender's return mail delivery agent has the F=C flag set, then the @oursite.edu part of the envelope sender's address is appended to alice:

From: [email protected]
To: [email protected], [email protected]

The F=C flag is traditionally used for the smtp class of delivery agent that is supposed to always supply an @domain part for all addresses.

Note that the domain part of the envelope sender is used. In our example the envelope and header sender are the same.

Ordinarily, V8 sendmail forces envelope-sender route addresses [17] to be enclosed in angle brackets. But beginning with V8.7 sendmail, angle brackets can be omitted by specifying F=d.

[17] Also see the DontPruneRoutes option in Section 34.8.20, DontPruneRoutes (R) and how route addresses are handled in rules in Section 29.4.3, "Handling Routing Addresses".

Under some circumstances it is possible for these angle-bracketed addresses to be given to a shell, causing them to be wrongly viewed as IO redirection. This problem is most common with the UUCP delivery agents.

The F=D flag is used by sendmail.cf header commands to force the inclusion of date information:

H?D?Resent-Date: $a
H?D?Date: $a

The F=D flag has no special internal meaning to sendmail. It is a convention that is used only in the assorted Date: header (see Section 35.10.10, Date:) definitions. See Section 30.4.5 for a general description of this process.

The sendmail.cf HoldExpensive (c) option (see Section 34.8.29, HoldExpensive (c)) tells sendmail not to connect to expensive delivery agents. Instead, mail destined for those agents is queued for later delivery. This F=e flag marks a delivery agent as expensive.

For example, consider a site connected to the Internet over a dial-on-demand ISDN link that costs lots of money per minute. Such a site might want all the Internet mail to be queued and would arrange for that queue to be processed only once every other hour.

Under V8 sendmail, verbose output (watch delivery) cancels the effect of the F=e flag (suppresses queueing). [18] Verbose output is set with the -v command line switch (see Section 36.7.41, -v) or the Verbose (v) option (see Section 34.8.76).

[18] According to Eric Allman, "It's assumed that if you say you want to watch delivery, you really want to watch it."

All UNIX mail-reading programs, such as /usr/ucb/Mail, require that each mail message in a file of many mail messages be delimited from the others by a blank line, then a line that begins with the five characters "From ":

and thanks again. - bill                one message ends
                                         a blank line
From george Fri Apr  6 12:03:45 1996    next message starts

This means that any given mail message may have only one line in it that begins with the five characters "From ". To prevent such lines being improperly fed to such mail delivery agents, sendmail offers the F=E flag. This flag tells sendmail to insert a > character at the front of all but the first such lines found. Consider the following:

From [email protected] Mon Dec 27 13:00:03 1999

From now on, let's meet on Saturdays instead of Tuesdays
like we discussed.

If the F=E flag is specified for the delivery agent that delivers the above message, sendmail converts it to read

From [email protected] Mon Dec 30 13:00:03 1996

>From now on, let's meet on Saturdays instead of Tuesdays
like we discussed.

This F=E flag is rarely needed. Usually, the program specified by the local delivery agent definition handles From line conversions. This flag should be used only with delivery agents that handle final local delivery.

You may wish to consider omitting this flag from the prog definition. Omitting it allows a user the option of not transforming "From " lines, by specifying a program in his or her ~/.forward file.

If sendmail is run with a -f command-line argument (see Section 36.7.21, -f and -r) and if the F=f flag is specified, the A= for this delivery agent will have the two additional arguments -f and $g inserted between its argv[0] and argv[1]. For example, if sendmail is run as

/usr/lib/sendmail -f jim host!bill

and if the delivery agent for sending to host is defined as

Muucp, P=/bin/uux, F=fmsDFMhuU, S=13, R=23, A=uux - -r $h!rmail ($u)

then the f in F=fmsDFhuU causes the A= of

A=uux - -r $h@rmail ($u)

to be rewritten as

A=uux -f $g - -r $h@rmail ($u)

Here, $g is jim from the original command line (but rewritten to be a return address relative to the recipient). The original -f argument jim is first rewritten by rule sets 3, 1, and 4. The result of those rewrites is placed into $f. The $f macro is rewritten by rule sets 3, 1, S=, and 4, and the result is placed into $g. ($f and $g are described in Section 31.10.16.)

Note that the F=f and the F=r flags are very similar and easily confused.

The F=F flag is used by sendmail.cf header commands to force the inclusion of sender (From) information (see Section 30.4.5):

H?F?Resent-From: $q
H?F?From: $q

The F=F flag has no special internal meaning to sendmail. It is a convention that is used only in the assorted From: header (see Section 35.10.14, From:) definitions. See Section 30.4.5 for a general description of this process.

The special address <> is used as the envelope sender when sendmail bounces a mail message. This address is intended to prevent bounced messages from themselves bouncing. Unfortunately, not all configuration files properly handle this form of sender address. The stock SunOS configuration files prior to Solaris 2.3, for example, caused sendmail to enter an endless loop when processing <>. Also, some UUCP implementations get confused when they are executed with command line arguments of:

-f <>

As an interim measure, until all programs learn to correctly handle the <> address, you may use the F=g flag to suppress that address for selected delivery agents. If the F=g flag is set for a delivery agent, it uses the value of $g (see Section 31.10.16) in place of the <>, where $g contains $n (usually MAILER-DAEMON see Section 31.10.26, $n) with an @ and your domain name appended.

Some delivery agents, such as those that deal with files, require that the recipient's hostname be left as is. The hostname portion of the recipient's address is ordinarily converted to all lowercase before being tucked into $h. Specifying the F=h flag tells sendmail to not convert that address to lowercase. [19]

[19] This flag was added specifically to handle the UUCP host named Shasta at Stanford University.

The $h macro (see Section 31.10.17) is usually used with the A= equate of a delivery agent. For example

Muucp, P=/usr/bin/uux, F=msDFMhuU, A=uux - -r $h!rmail ($u)

Here, the h in F=msDFMhuU tells sendmail to leave the $h alone and not to convert the hostname in that defined macro to lowercase.

The F=@ flag (see Section 30.8.10) allows all addresses for a given delivery agent to be rewritten by the User Database (see Section 33.5). The F=i flag either suppresses that rewrite for the sender envelope (if absent) or allows that rewrite for the sender envelope (if present). For example, consider mail from the user jane:

MAIL from: jane          SMTP envelope sender
From: jane               header sender

Now assume that a User Database entry like the following exists:

jane:mailname       Jane.Doe

If the F=i flag is absent but the F=@ flag present, the envelope-sender address will remain unchanged, but the header-sender address will be rewritten by the User Database:

MAIL from: jane          SMTP envelope sender
From: Jane.Doe           header sender

But if the F=i and F=@ flags are both present, the envelope- and header-sender addresses will both be rewritten by the User Database:

MAIL from: Jane.Doe      SMTP envelope sender
From: Jane.Doe           header sender

No matter how the envelope-sender address is rewritten (with or without use of the User Database), the result is saved to the S line of the qf file (Section 23.9.14, S line).

The F=I flag tells the local sendmail to send the following VERB [20] SMTP command to the receiving sendmail:

[20] VERB is defined in RFC1700.

VERB				 ours sends
200 Verbose mode			 recipient replies

The VERB SMTP command causes the receiving sendmail to go into verbose mode and to set its deliver mode to interactive. This has the same effect as would occur if the receiving sendmail had been run with the command-line options -v and -odi set.

The F=I flag is intended as an aid in debugging a remote receiving site's sendmail. The VERB SMTP command causes that remote site to run in verbose mode. By temporarily adding the F=I flag to a delivery agent's definition and then running sendmail locally with the -v command-line argument, you can watch both the local and the remote's verbose output. Each line of the remote site's verbose output will be seen locally prefixed with a 050.

Note that if the PrivacyOptions (p) option on the remote site's sendmail is set to noexpn (see Section 34.8.47, PrivacyOptions (p)), that site's response to the VERB SMTP command will be this rejection:

502 Verbose unavailable

Also note that if the other side is not running sendmail, you may see other errors:

501 No argument given in VERB command.   PMDF V5.0
250 Ok                                   post.office v1.9.1 (but ignores its own Ok)

In both these cases, the request to the other machine to go into verbose mode has failed.

If sendmail was compiled with User Database support (see Section 18.8.54, USERDB) and if that database is being used (see Section 34.8.75, UserDatabaseSpec (U)), you may have sendmail rewrite header recipient addresses using that database. The F=j flag tells sendmail to look up recipient addresses in the User Database (using the mailname keyword). If an appropriate entry is found, it is used in place of the original address in the recipient headers. The process is the same as that described for the F=i flag, except that here it is for recipient headers.

When another host connects to the local host and that other host claims to have the same canonical name as the local host, it should be considered an error. In V8.6 sendmail, setting the CheckLoopBack variable in conf.c determined whether this error was detected. But beginning with V8.7 sendmail, this check is based on the delivery agent. If the F=k flag is absent, the check is done. If the F=k flag is set, the check is skipped.

The check is performed only for SMTP connections. The literal canonical name given in the connecting host's HELO line is compared to the canonical name for the local host. If they are the same, the following error is printed, and the connection is disallowed:

553 host config error: mail loops back to myself            V8.6
553 host config error: mail loops back to me (MX problem?)  V8.7

Here, host is the name of the offending host.

A problem can arise at sites that run two different invocations of sendmail (one for SMTP connections and another for command-line invocation, where each uses a different configuration file). In this instance, when the latter connects to the former, this error may occur. Such sites may find it necessary to set the F=k flag for the delivery agent that handles SMTP connections, usually Msmtp. With an m4 configuration the following command does just that:

define(`SMTP_MAILER_FLAGS',`k')dnl

Note that sendmail must recognize its local hostname among many possible names. See Section 32.5.8, $=w for a discussion of $=w and MX records.

The F=l flag tells sendmail that this delivery agent will be performing final delivery (usually on the local machine). This notification affects sendmail's behavior in three ways.

First, it enables the DSN notify on success mechanism. [21] That is, if the message were received via SMTP with the envelope

[21] This replaces the Return-Receipt-To: header line.

RCPT To: [email protected] NOTIFY=SUCCESS

then sendmail (upon final local delivery) sends back to the original sender an email message acknowledging receipt. This mechanism should be used sparingly.

Second, the F=l flag allows sendmail to ignore any host part of the triple returned by rule set 0. Ordinarily, the $@ operator must appear in the RHS for all delivery agents selected. If no host is selected by $@, sendmail prints this error and bounces the message

554 buildaddr: no host

But since the host is not always needed for final delivery, the presence of the F=l flag tells sendmail to silently ignore a missing host part.

Third, the F=l flag influences how undeliverable mail will be handled. When the ErrorMode (e) option (see Section 34.8.24, ErrorMode (e)) is q (quiet), such mail is usually reported in the sendmail program's exit(2) status (see Section 36.5, "sendmail's exit() Status"). With the F=l flag set, the undeliverable message will instead be appended to ~/dead.letter for a local sender or mailed back for a remote sender.

In general, the F=l flag should always be specified for the local, prog, and *file* delivery agents.

Note that the processing of a user's ~/.forward file is no longer tied to the local delivery agent, nor to this F=l flag. The ability to look in a user's ~/.forward file is now determined by the F=w flag.

Prior to V8.8 sendmail, this F=L flag caused sendmail to split output lines in the message body so that they did not exceed 990 characters and always caused sendmail to clear the most significant bit of the characters in those lines.

Beginning with V8.8 sendmail, F=L emulates this old behavior under certain conditions. F=L causes sendmail to assign L= a default value of 990, if it is missing one (see Section 30.4.6), and (if the configuration file level is 1 or less) to set the F=7 flag.

Whenever the sendmail program executes the program specified by the P= equate (see Section 30.4.9), that program is given its argv vector as specified by the A= equate (see Section 30.4.1). As the last step in building that argv, sendmail appends one or more recipient addresses.

The decision as to whether it appends one address or many is determined by the F=m flag. If this flag is not specified, the delivery agent is given only one recipient. Otherwise, if it is specified, the delivery agent may be given many recipients. In either case, if there are more recipients than the argv can accept, the delivery agent is rerun as many times as is necessary to handle them all.

Note that sendmail is able to distinguish only between failures involving one, many, or all of the recipients when it is delivering with SMTP. Otherwise, it judges delivery as successful if a zero exit(2) value is returned by a delivery agent. If the delivery agent fails to deliver to one of many recipients, it exits with a nonzero value, and because of that single failure, sendmail will presume that delivery to all recipients failed.

The F=M flag is used by sendmail.cf header commands to force the inclusion of message identification information. (see Section 30.4.5):

H?M?Resent-Message-ID: <$t.$i@$j>
H?M?Message-ID: <$t.$i@$j>

The F=M flag has no special internal meaning to sendmail. It is a convention that is used only in the assorted Message-ID: header (see Section 35.10.19, Message-ID:) definitions. See Section 30.4.5 for a general description of this process.

Note that the Message-ID: header definition should always be included in the sendmail.cf file because packages expect the presence of that header by many software packages.

The UNIX-style mailbox (a single file into which many mail messages are placed) requires that each message be separated from the others by a blank line followed by a line that begins with the five characters "From ":

and thanks again. - bill                   one message ends
                                            a blank line
From george Fri Apr  6 12:03:45 1990       next message starts

Ordinarily, sendmail adds a five-character "From " line to a message if there isn't one. The F=n flag prevents sendmail from doing this. It is intended for use when not dealing with a UNIX-style mailbox.

Note that if the F=U flag is specified (but not F=n), then the five-character "From " header line is created, and the words remote from $g are appended to that line. The F=n flag should always be specified for SMTP delivery agents. The five-character "From " line is not a valid RFC822 header (because it lacks a colon) and is not permitted.

Apart from SMTP, the use of the F=n flag is best determined on a case-by-case basis. Some delivery agents always generate a "From " line, so the F=n flag can be used to avoid duplication. Some delivery agents generate a "From " line only if there is not already one there, so the F=n flag is optional and perhaps best omitted. Some delivery agents never generate a "From " line, yet require one (such as the uux program); for these the F=n flag should always be omitted.

Under certain circumstances, before sendmail delivers to a file or through programs, it may assume the identity (uid and gid) of the controlling user (see Section 24.2.2 for a description of this process). Beginning with V8.7, the F=o flag changes this behavior. Specifying F=o flag causes sendmail to assume the identity of the recipient. Omitting the F=o flag causes sendmail to assume the identity of the controlling user where appropriate.

In version 5 and earlier configuration files (Section 27.5) this flag is automatically set for the prog and *file* delivery agents. Note that the U= equate (see Section 30.4.13), when specified, always overrides the controlling user.

The SMTP mail command normally uses the envelope address for the sender:

MAIL From:<[email protected]>

If the F=p flag is specified, sendmail instead sends a transformed version of that address. The transformation can take one of two forms, depending on the first character of the envelope address. If that address begins with an @ character, then an @, the local hostname and a comma are prepended to that address to create a legal return path:

<@hub:[email protected]>
  
becomes
  
<@ourhost,@hub:[email protected]>

If the envelope address for the sender does not start with an @ character, then an @, the local hostname, and a colon are prepended to that address:

<[email protected]> becomes <@ourhost:[email protected]>

See also the DontPruneRoutes option.

Note that these forms of address transformations are discouraged by RFC1123. For this reason the F=p flag is deprecated and may be removed from future versions of sendmail.

The F=P flag is used by sendmail.cf header commands to force the inclusion of return-path information:

H?P?Return-Path: <$g>

The F=P flag has no special internal meaning to sendmail. It is a convention that is used only in the assorted Return-Path: header (see Section 35.10.28, Return-Path:) definitions. See Section 30.4.5 for a general description of this process.

The sender's envelope address (the address that would be used to return mail if it were bounced, for example) is placed into $g for use in the Return-Path: header line. This is usually done during final delivery, although it can also be done for delivery agents that lack a clear envelope address. The form of the address in the $g macro (see Section 31.10.16) depends on the setting of the F=p flag. Note that this is normally the same as the address in the five character "From " line.

Prior to RFC1123 a successful reply to the SMTP VRFY command was always prefixed with a 250, meaning that sending to this address was likely to result in successful delivery:

VRFY user
250 [email protected] (Full Name)

Here, sendmail states (with the 250) that it interpreted the address as valid locally and that delivery or relaying to another site would be attempted.

RFC1123 now requires that shades of meaning be conveyed in that success code, so the correct prefix should be 252, which means that we will accept the address and attempt to relay it elsewhere.

If the F=q flag is set, sendmail returns the 250 prefix; otherwise, it returns the 252 prefix. It should be set only for delivery agents doing local delivery. For configuration files earlier than version 7, the F=q flag is automatically set for the local, prog, and *file* delivery agents.

If sendmail is run with a -f command-line argument, and if the F=r flag is specified, the A= for this delivery agent has the two additional arguments, -r and $g, inserted between its argv[0] and argv[1]. Consider a case in which sendmail is run as

/usr/lib/sendmail -f jim bill

If bill is a local user and the delivery agent for local is defined as

Mlocal, P=/bin/mail, F=rlsDFMmnP, S=10, R=20, A=mail -d $u

then the r in F=rlsDFmnP will cause the A= of

A=mail -d $u

to be rewritten as

A=mail -r $g -d $u

The $g is jim from the original command line (but rewritten to be a return address relative to the recipient). The original -f argument jim is first rewritten by rule sets 3, 1, and 4. The result of those rewrites is placed into $f (see Section 31.10.14, $f). The $f macro is rewritten by rule sets 3, 1, S=, and 4, and the result is placed into $g (see Section 31.10.16).

Note that the F=f and the F=r flags are very similar and easily confused.

The F=R flag causes sendmail to connect on a reserved (privileged) TCP port for additional security. Privileged Internet ports are those in the range 0 to 1023. Only root is allowed to connect to such ports. The sendmail program calls rresvport(3) to obtain a socket on its selected port. Note that this is done only when instantiating an outgoing connection. See Section 30.4.1.2, "$h and other arguments in A=[IPC]" for another way to set the outgoing port number.

This flag is suitable only for use with the [IPC] and [TCP] delivery agents. Note that sendmail is usually suid root when run as a daemon.

Some delivery agents don't correctly understand quotation marks in addresses, for example,

"dechost::user"@relay

For delivery agents that do not correctly understand them, the F=s flag causes sendmail to strip all quotation marks from the address before handing it to the delivery agent:

dechost::user@relay

The local delivery agent should always have the F=s flag specified. The prog delivery agent commonly has the F=s flag specified. The uucp delivery agent may or may not require that flag depending on the specifics of the program specified in the P= equate. The [IPC] and [TCP] delivery agents should never specify the F=s flag.

There are two major ways in which sendmail can be run: as an suid root process (that is, with the permissions of root no matter who runs it) or as an ordinary process run by an ordinary (nonprivileged) user (that is, with root privilege only if it is run by root). When sendmail is running with root privilege and when the F=S flag is specified for a delivery agent, sendmail always invokes that delivery agent as the effective user and effective group specified by the U= equate. [22] If the U= equate is unspecified or is specified as zero, it runs as root. In both instances, the real GID and UID remain that of the receiving user -that is, the F=S flag acts like the UNIX suid and sgid bits.

[22] Prior to V8.7 there was no U= equate, so F=S always ran as root.

If the F=S is not specified for the delivery agent, sendmail first checks to see whether there is a controlling user for the address. If there is one, sendmail becomes that user for delivery. If delivery is to a file and if the suid bit is set for that file, sendmail becomes the owner of the file. Similarly, if delivery is to a file and the sgid bit is set, sendmail sets its group identity to the group of the file. Finally, if the user or group part of the U= equate was missing or 0, sendmail assumes the identity of the DefaultUser (u) option (see Section 34.8.15). Otherwise, it assumes the identity of the U= equate.

The username portion of the recipient's address is ordinarily converted to lowercase before being tucked into $u. The $u is usually used with the A= equate of a delivery agent:

Mprog,  P=/bin/sh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u

Some delivery agents, such as the prog agent, execute programs. They require that the program (user) name be left as is (otherwise, the program name would not be found). Specifying the F=u flag tells sendmail to not convert that name to lowercase.

Beginning with V8.7 sendmail, the F=u flag also determines how some aliases are treated. If it is set, usernames are stored in the aliases database without conversion to lowercase. If it is clear, they are converted to lowercase.

Also if the F=u flag is set, looking up the owner part that follows the owner- in a mailing list is done in a case-sensitive manner. If the F=u flag is clear, the owner is converted to lowercase before being looked up.

In general, the F=u flag should be set in all delivery agent declarations, except the local delivery agent.

The F=U flag causes sendmail to prepend a five-character "From " line to the start of the headers if there is not already one there. Whether one was prepended or not, this flag also tells sendmail to add the words remote from host to the end of that line and also requires that $g be in the form host!....

The F=U flag is required when a neighbor UUCP site runs an old (or possibly SysV) version of the rmail program. The newer BSD versions of rmail do not require this flag.

The sendmail program uses the passwd(5) file to determine whether a local address corresponds to a local account. If it does, the home directory for the user is copied into $z (see Section 31.10.46). Then the full name of the user is extracted from the gecos field of the passwd(5) file and placed into $x (see Section 31.10.42, $x).

Beginning with V8.7 sendmail, the information in the passwd(5) file is looked up only if the F=w flag is set for the recipient's delivery agent. In general, it must be present (set) for the local and any local-clone delivery agents but should be absent for all other delivery agents. For configuration files less than 6 (see Section 27.5), the F=w flag is automatically set for the local delivery agent.

Omitting the F=w flag has several consequences:

• The recipient's home directory is not looked up, and all user-level forwarding is prevented. Note that this voids all forwarding, even if the user's home is defined as part of the ForwardPath (J) option (see Section 34.8.27, ForwardPath (J)).

• The user's full name is not looked up in the gecos field of the passwd(5) file.

• The uid and gid of the recipient become unavailable, so the identity of the controlling user cannot be set to that of the recipient.

Note that this flag should be considered mandatory for local and local clones. If you want to cancel forwarding, use the ForwardPath (J) option. Attempting to cancel forwarding by omitting the F=w flag can have unpredictable side effects that may cause mail to fail.

The F=x flag is used by sendmail.cf header commands to force the inclusion of the user's full name (see Section 30.4.5):

H?x?Full-Name: $x

The F=x flag has no special internal meaning to sendmail. It is a convention that is used only in the assorted Full-Name: header (see Section 35.10.15, Full-Name:) definitions. See Section 30.4.5 for a general description of this process.

Delivery agents that speak SMTP require that any line of the message that begins with a dot have that dot doubled. Delivery agents speak SMTP when the $u is missing from the A= equate. For example,

Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h

An example of a file that contains leading dots is a troff(1) source file:

.\" Show example
.Ps
Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h
.Ps

In the above, three lines begin with a leading dot. The F=X flag causes sendmail to transmit the above message as

..\" Show example
..Ps
Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h
..Pe

The extra leading dot is automatically restored to a single dot at the receiving end.

This F=X flag should be used only with delivery agents that speak SMTP. It should not be used with other delivery agents, because they will not know to strip the extra dots.