PrivacyOptions
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,... 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:
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
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 businessprior to V8.7 502 Sorry, we do not allow this operation
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?
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
EAN: 2147483647
Pages: 1174