PrivacyOptions

Increase privacy of the daemon

V8.1 and later

The PrivacyOptions option is used primarily as a way to force other sites to adhere to SMTP conventions, but can also be used to improve security.

The forms of the PrivacyOptions option are as follows:

O PrivacyOptions=what,...               configuration file (V8.7 and later) 
-OPrivacyOptions=what,...               command line (V8.7 and later) 
define(`confPRIVACY_FLAGS',``what,...'')    mc configuration (V8.7 and later) 
Opwhat,...                              configuration file (deprecated) 
-opwhat,...                             command line (deprecated)

Multiple what arguments are allowed but they must be separated from one another by commas^[49] (there can be arbitrary spaces around the commas). For example:

^[49] When the argument to an m4 define command contains one or more commas, that argument should be enclosed in double half-quotes.

define(`confPRIVACY_FLAGS',``authwarnings, needmailhelo'')

If this option is entirely omitted or if no what arguments are listed, the option defaults to public. The default for the mc configuration technique is authwarnings. The possible what arguments are listed in Table 24-23, and are described in more details in the sections that follow.

Table 24-23. PrivacyOptions option keywords
Keyword	§	Meaning
authwarnings	See this section	Enable `X-Authentication-Warning:` headers
goaway	See this section	Much checking for privacy and security
needexpnhelo	See this section	Require HELO before EXPN
needmailhelo	See this section	Require HELO before MAIL FROM:
needvrfyhelo	See this section	Require HELO before VRFY
nobodyreturn	See this section	Prevent RETURN=FULL from returning the body (V8.10 and later)
noetrn	See this section	Disallow all SMTP ETRN commands
noexpn	See this section	Disallow all SMTP EXPN commands
noreceipts	See this section	Prevent SUCCESS return receipts
noverb	See this section	Disallow all SMTP VERB commands
novrfy	See this section	Disallow all SMTP VRFY commands
public	See this section	No extra checking for privacy or security
restrictexpand	See this section	Restrict who can use `-bv` (V8.12 and later)
restrictmailq	See this section	Restrict who can run mailq(1)
restrictqrun	See this section	Restrict who can processes the queues

If what is other than one of the keywords listed in the table, sendmail prints the following message and ignores the unknown word:

readcf: Op line: unknown_word unrecognized

Note that sendmail checks for non-root use of the -C (-C) and -oQ (QueueDirectory) command-line switches and dangerous uses of the -f (-f) command-line switch when the command line is read but does not issue warnings until after the configuration file is read. That way, the configuration file determines how X-Authentication-Warning: headers will be issued.

The PrivacyOptions option is safe. If specified from the command line, it does not cause sendmail to relinquish its special privileges. Because it is really a mask, specifications in the configuration file or on the command line can only make it more restrictive.

PrivacyOptions=authwarnings

Setting authwarnings causes sendmail to insert special headers into the mail message that advise the recipient of reasons to suspect that the message might not be authentic. The general form of this special header is shown here. The possible reasons are listed in Chapter 25, in X-Authentication-Warning:.

X-Authentication-Warning: ourhost:  reason

PrivacyOptions=goaway

This is a shorthand way to set authwarnings, noexpn, novrfy, noverb, needmailhelo, needexpnhelo, needvrfyhelo, and nobodyreturn.

PrivacyOptions=nobodyreturn

Ordinarily, the body of the original message in a bounced message will be returned with the bounce. Also, if the DSN extension RET (-R) indicates that the original body should be returned, it will. For example:

MAIL From:<address> RET=FULL

Beginning with V8.10, you set this privacy flag to make it your policy to never return the original body in a bounce, and to suppress the honoring of RET=FULL.

PrivacyOptions=noetrn

The ETRN (Section 11.8.2.6) ESMTP extension allows sites that connect to your sendmail daemon to force the daemon to process the queue on demand. For sites that support dial-up hosts' mail, this is a useful and valuable feature. For sites that prefer to process the queue only when they want to, this feature might not be desirable. To disable the ETRN feature, just define this privacy flag. By disabling it, you cause the following ESMTP reply to be sent when the ETRN command is attempted:

502 5.7.0 Sorry, we do not allow this operation

Note that you can use the check_etrn rule set (check_etrn) to allow some sites to use ETRN, while disallowing other sites.^[50]

^[50] The check_etrn rule set can do much more than this too.

PrivacyOptions=needexpnhelo

The SMTP EXPN command causes sendmail to "expand" a local address and print the result. If the address is an alias, it shows all the addresses that result from the alias expansion. If the address is local, it shows the result of aliasing through a user's ~/.forward file. If needexpnhelo is specified, sendmail requires that the requesting site first introduce itself with an SMTP HELO or EHLO command. If the requesting site has not done so, sendmail responds with the following message rather than providing the requested expansion information:

503 5.0.0 I demand that you introduce yourself first

PrivacyOptions=needmailhelo

The SMTP protocol specifies that the sending site should issue the HELO or EHLO command to identify itself before specifying the name of the sender with the MAIL FROM: command. By listing needmailhelo with the PrivacyOptions option, you cause the following error to be returned to the sending site in this situation:

503 5.0.0 Polite people say HELO first

If needmailhelo is not specified but authwarnings is specified, the following header is added to the message describing the problem:

X-Authentication-Warning: ourself: Host they didn't use HELO protocol

PrivacyOptions=needvrfyhelo

The SMTP VRFY command causes sendmail to verify that an address is that of a local user or local alias. Unlike EXPN, VRFY does not cause mailing-list contents, the result of aliasing, or the contents of ~/.forward files to be displayed. If needvrfyhelo is specified, sendmail requires that the requesting site first introduce itself with an SMTP HELO or EHLO command. If the requesting site has not done so, sendmail responds with the same message as for needexpnhelo, rather than providing the requested verification information.

PrivacyOptions=noexpn

Setting noexpn causes sendmail to disallow all SMTP EXPN commands. In place of information, sendmail sends the following reply to the requesting host:

502 That's none of your business         prior to V8.7
502 Sorry, we do not allow this operation    beginning with V8.7

Setting noexpn also causes sendmail to reject all SMTP VERB commands:

502 5.0.0 Verbose unavailable

Other sendmail programs might send VERB if the delivery agent making the connection has the F=I flag set (see F=I (uppercase i)).

Note that you can use the check_expn rule set (check_vrfy and check_expn) to allow some sites to use EXPN, while disallowing other sites.^[51]

^[51] The check_expn rule set can do much more than this too.

PrivacyOptions=noreceipts

Setting noreceipts causes pre-V8.7 sendmail to silently skip the processing of all Return-Receipt-To: headers (see Return-Receipt-To:). Beginning with V8.7 sendmail, notification of successful delivery is governed by the NOTIFY keyword (see RFC1891) to the ESMTP RCPT TO: command:

RCPT To:<address> NOTIFY=SUCCESS

Setting noreceipts causes V8.7 and later sendmail to silently skip all such requests for notification of successful delivery.

Note that this also causes the ESMTP DSN feature to not be advertised in the EHLO response. But, because that feature is very valuable, we recommend you not specify noreceipts.

PrivacyOptions=noverb

The VERB (F=I (uppercase i)) ESMTP command places sendmail into verbose mode when processing an inbound session. This can be useful for debugging a connection, but it also opens the possibility that unwanted information will be disclosed to outsiders. If you see this as a risk, you can disable VERB by defining this privacy option. With it defined, an attempt to use the VERB command will result in the following rejection:

502 5.7.0 Verbose unavailable

PrivacyOptions=novrfy

Setting novrfy causes sendmail to disallow all SMTP VRFY commands. In place of verification, sendmail sends the following reply to the requesting host:

252 Who's to say?                                               V8.6
252 Cannot VRFY user; try RCPT to attempt delivery (or try finger)  V8.7 and later

Note that you can use the check_vrfy rule set (check_vrfy and check_expn) to allow some sites to use VRFY, while disallowing other sites.^[52]

^[52] The check_vrfy rule set can do much more than this too.

PrivacyOptions=public

The default for the non-mc version of the PrivacyOptions option is public. This means that there is no extra checking for valid SMTP syntax and no checking for the security matters.

PrivacyOptions=restrictexpand (V8.12 and later)

The -bv command-line switch causes sendmail to verify the list of recipients. For security reasons, you might want to prevent users from using this command-line switch because it could allow them to read ~/.forward files, :include: files, and aliases that can contain privileged information.

Beginning with V8.12, this restrictexpand keyword causes sendmail to drop special privileges when the -bv switch is specified by a user who is neither root, nor the trusted user specified in the TrustedUser option. This protects information by denying them from reading ~/.forward files, :include: files, and private aliases (aliases found in aliases files that are not ordinarily readable). This restrictexpand keyword also prevents the -v command-line switch from being used. See -bv for additional information.

PrivacyOptions=restrictmailq

Ordinarily, only a subset of users can examine the mail queue's contents by using the mailq(1) command (see Section 11.6). To further limit who can examine a queue's contents, specify restrictmailq. If restricted, sendmail allows only users who are in the same group as the group ownership of the queue directory to examine the queue's contents. This allows the queue directory to be protected (e.g., mode 0750), yet selected users will be able to see its contents. Alternatively, if sendmail is run as set-user-id root (not the default), this allows the queue directory to be fully protected with mode 0700, yet still allow selected users to see its contents.

PrivacyOptions=restrictqrun

Ordinarily, anyone can process the queue with the -q switch (see Section 11.8.1). To limit queue processing to root, or to the owner of the queue directory, specify restrictqrun. If queue processing is restricted, any nonprivileged user who attempts to process the queue will get this message:

You do not have permission to process the queue

Table 24-23. PrivacyOptions option keywords