|
|
|
|
|
|
|
|
HP-UX Mailing Services Administrator's Guide: HP-UX 11i v1 and HP-UX 11i v2 > Chapter 3 Sendmail 8.13.3
New Features in Sendmail 8.13.3 |
|
This chapter discusses the following new features in Sendmail 8.13.3: The following sections discuss the new features in detail. Sendmail 8.13.3 supports LDAP recursion based on the TYPEs given to attribute specifications in an LDAP map definition. This allows LDAP queries to return a new query, a DN, or an LDAP URL which will in turn be queried. LDAP recursion allows you to add TYPEs to the search attributes on an LDAP map specification. The syntax for LDAP recursion is as follows: -v ATTRIBUTE[:TYPE[:OBJECTCLASS[|OBJECTCLASS|...]]] Following are the various TYPEs available:
Any untyped attributes are considered NORMAL attributes. The optional OBJECTCLASS (| separated) list contains the objectClass values for which that attribute applies. If the list is given, the attribute named will only be used if the LDAP record being returned is a member of that object class. If these new value attribute TYPEs are used in an AliasFile option setting, it will need to be double quoted to prevent Sendmail from misparsing the colons. LDAP recursion attributes which do not ultimately point to an LDAP record are not considered as an error. Following is an example of LDAP recursion that uses all the four new TYPEs:
This definition specifies that:
When Sendmail prepares to connect to a remote host for transfer of mail, it first performs a series of checks to identify the remote host. Sendmail looks up the MX records and calls the res_search() BIND library routine to find all MX records for the host. If Sendmail does not find the MX records, it tries to deliver the message to a single original host, which is a central mail hub to which mail can be forwarded. If this fails, Sendmail attempts to deliver to the host listed with the FallbackMXHost option. Following is the format of the FallbackMXHost option: FallbackMXhost=fallbackhost The FallbackMXhost option works only if Sendmail can look up the host name of the recipient. If Sendmail does not find the host name, the FallbackMXhost is not useful. In such situations, Sendmail uses the FallBackSmartHost option. The FallBackSmartHost option specifies the name of a mail exchange (MX record) that Sendmail must use as a last resort when MX records are not available to identify the remote host. This option is given an artificially low priority so that Sendmail tries to connect to it only if all other connection attempts for the remote host have failed. Following is the format for the FallBackSmartHost option: FallBackSmartHost=hostname where, hostname specifies the canonical name to which the host will fallback. Mail message forwarded to that host name fails if hostname is an empty string or is the name of a nonexistent host. You can also use macros to represent the hostname. Sendmail expands these macros before connecting to the remote host. If the hostname that you specify for the FallBackSmartHost option exists in the $=w class, Sendmail silently ignores the hostname. The FallBackSmartHost option is also useful for unreliable FallbackMXhost servers. When the FallbackMXhost server goes down, Sendmail uses the FallBackSmartHost option and thus the flow of mail messages does not stop. You must be careful while using the FallBackSmartHost option because if you specify this option from the command line, Sendmail can relinquish its special privileges. Sendmail 8.13.3 contains a new socket map to query maps through TCP/IP sockets. The socket map uses a simple request or reply protocol over TCP or UNIX® domain sockets to query an external server, which can be a third party or a self-coded program. Neither the requests nor replies end with a carriage return (CR) or line feed (LF). Both the requests and replies are text based and encoded as net strings. A string "hello there" is represented as follows: 11:hello there The request consists of the database map name and the lookup key separated by a space character, specified as follows: <mapname> ‘ ’ <key> The server responds with the following status indicator and the result (if any): <status> ‘ ’ <result> The status indicator is one of the following upper case words:
In case of an error, that is, when the status is TEMP, TIMEOUT, or PERM, the result field contains an explanatory error message. Following are examples of the error messages in the result field:
The socket map uses the following syntax to specify the remote endpoint: Xname {, field=value }* where, name is the name of the filter and field=name pairs define attributes to the filter. Following are the different field types:
Sendmail checks only the first character of the field name for the field type. The field name is case sensitive. Following are different forms of socket specifications: S=inet:port@host S=inet6:port@host S=local:path The first two forms describe an IPv4 or IPv6 socket listening on a certain port at a given host or IP address. The last form describes a named socket on the file system at the given path. Following is an example of a socket map that specifies a remote endpoint: KmySocketMap socket inet:12345@127.0.0.1 If multiple socket maps define the same remote endpoint, they share a single connection to this endpoint. The dns map is an internal database map available to perform DNS lookups. You can use the following K configuration command to declare the dns map: Kdnslookup dns -Rlookup-type where dnslookup specifies the name of the map using DNS. The dns-type database map is primarily used for dnsbl and endnsbl features. You must always include the -R switch, which specifies the DNS resource record type to lookup, in the dns map declaration. Sendmail 8.13.3 supports the following types of resource records: A, AAAA, AFSDB, CNAME, MX, NS, PTR, SRV, and TXT. A map lookup returns only one record. For certain types of records, such as MX records, the return value can be a random element of the list due to randomizing in the DNS resolver. Table 3-1 “Supported DNS Queries” describes the different -R values in the dns database map. Table 3-1 Supported DNS Queries
To make the dns database-map more useful, you can also use the switches described in Table 3-2 “The dns Database-Map Type K Command Switches”. Table 3-2 The dns Database-Map Type K Command Switches
The Delivery By SMTP extension is a mechanism by which an SMTP client can request a server to deliver the message within a prescribed period of time, while transmitting a message to an SMTP server. A client that makes such a request also specifies message handling which must occur if the message cannot be delivered within the specified time period. The options can be either to return the message as an undeliverable message with no further processing or to issue a delayed delivery status notification (DSN). Following is the declaration for the Delivery By SMTP extension in the Sendmail 8.13.3 configuration file: #O DeliverByMin=0 A value of 0 (zero) indicates that the DeliverByMin option is disabled. Do not consider this extension as a vehicle for requesting “priority” processing. A receiving SMTP server can assign processing priority to a message transmitted with a Delivery By request. A Delivery By request serves to express the urgency of a message and to provide an additional degree of determinancy in its processing. The message can be withdrawn if it is not delivered within the specified period of time. A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered, for example within 30 minutes, a "delayed" DSN is generated but delivery attempts are nonetheless continued. In this case, senders are allowed to express a preference for when they would like to learn of delivery problems. In addition to the anti-spamming features provided by Sendmail 8.11.1, Sendmail 8.13.3 provides the following anti-spamming features:
The following sections discuss the anti-spamming features in detail. Starting with Sendmail 8.13.3, you can quarantine mail messages, which are otherwise known as envelopes. Queue files or envelopes are stored but not considered for delivery or display unless the “quarantine” state of the envelope is undone, or delivery or display of the quarantined items is requested. Quarantined messages are tagged using the name hf for the queue file instead of the name qf for the queue file, and by adding the quarantine reason to the queue file. When you run the following command, the quarantine reason is displayed in a new line prefixed with QUARANTINE: mailq -qQ where, the -qQ option specifies the quarantined queue items. Quarantined messages are not run on normal queue displays. They run unless specifically requested with the -qQ option. You can run and display restricted mail queues based on the quarantined reason using the -qQtext option if the quarantine reason contains the given text. Similarly, the -q!Qtext runs or displays quarantined items which do not have the given text in the quarantine reason. You can use the -qQ flag option to request the delivery or display of quarantined items. Additionally, you can quarantine or unquarantine messages already in the queue using the new -Q flag to Sendmail. For example, the following command quarantines the normal queue items matching the criteria specified by the -q[!][I|R|S|G][matchstring] option using the reason given in the -Q flag: sendmail -Qreason -q[!][I|R|S|G][matchstring] Similarly, you can use the following command to change the quarantine reason for the quarantined items matching the criteria specified by the -q[!][I|R|S|Q][matchstring] option using the reason given on the -Q flag: sendmail -qQ -Q[reason] -q[!][I|R|S|Q|G][matchstring] If you do not specify a reason, unquarantine the matching items and make them normal queue items. The -qQ flag informs Sendmail to operate on quarantined items instead of normal items. A new error code for the $#error $@ quarantine $: reason, can be used to quarantine message in check_* (except check_compat) and header check rulesets. The $: of the mailer triplet will be used for the quarantine reason. Beginning with Sendmail 8.13.3, you can use the Mail Filter (Milter) APIs to filter all inbound messages through an external filter program. Milter is designed to allow third-party programs to access mail messages as they are being processed in order to filter meta information and content. Milter is declared in the configuration file as: Xname {, field=value}* where name is the name of the filter (used internally only) and the field=value pairs define attributes of the filter. For more information on Milter, refer to the Sendmail 8.13.3 Programer’s Guide at http://www.docs.hp.com/en/netcom.html#Internet%20Services. The enhanced DNS Black Hole List (EDNSBL) option is an enhanced version of the dnsbl feature. The dnsbl feature rejects mail from hosts in a DNS-based rejection list. The dnsbl feature is used to enable the blocking of email from open relay sites, dialup sites, or known spamming sites. This feature is included in the sendmail.cf configuration file as:
The enhanced dnsbl feature is a superset of the dnsbl feature. This feature is represented in the sendmail.cf file as follows:
You must use the /usr/newconfig/etc/mail/cf/cf/gen_cf script to include the enhdnsbl feature in the sendmail.cf file. You must choose the “5: Enhanced DNSBL” sub-menu option in the “3: Anti-Spamming Options” main menu option, and regenerate the sendmail.cf file. You can use the dns-type database map for the dnsbl and enhdnsbl features. The enhancement consists of additional arguments, that is, one or more literal addresses you expect returned when an address must be rejected. Compared to the dnsbl option, you can specify additional arguments (upto 5) to specify the return values from lookups. Sendmail ignores temporary lookup failures in the absence of a third argument, which must be either t or a full error message. By default, any successful lookup generates an error. Otherwise, the result of the lookup is compared with the supplied arguments, and only if a match occurs an error is generated. Starting with Sendmail 8.13.3, you can define queues according to selected criteria and process each group with custom settings. The rule sets then select the queue group to which the message of a recipient must belong. You can use the -q command-line option to specify which queue to display. This is an option available in earlier versions of Sendmail. Sendmail 8.13.3 has a few additional queue-related options, such as processing only the quarantined items. Sendmail 8.13.3 offers a method to define multiple queue directories and a method to group them by function or specialty. For compatibility with older versions of Sendmail, there is a special queue group called mqueue. This is the default queue group. It takes on all the properties of every -q command, and every queue option. When you declare additional queue groups, they take all their properties from the default group, unless you override a particular property with a specific equate. Table 3-3 “Q Configuration Command Equates” describes the equates and the command-line arguments or options they override. Table 3-3 Q Configuration Command Equates
You can define queue groups using the Q configuration command, which specifies the name of the queue group and a sequence of equates. Following is the syntax for the Q command: Qgroupname, equates You must not insert a space between Q and the groupname. You can optionally specify the equates, but if they are present they must follow the name of the queue group and they must be separated with a comma or whitespace, or both. The equates are formed by selecting one of the keywords shown in the first column in Table 3-3 “Q Configuration Command Equates”, and by following the keyword with an equal sign and the value you wish to assign to that key letter. Sendmail reads only the first letter. Therefore, you can use the shorthand shown in parenthesis in Table 3-3 “Q Configuration Command Equates”. The first letter is case sensitive, that is, R and r are different. For example, the following commands declare a queue directory (the Patch= and P=), and a queue processing interval of 10 minutes (the Interval= and I=):
You must use the gen_cf main menu option to utilize the queuegroup feature to easily select queue groups based on recipient addresses or recipient domains. After enabling the queuegroup feature, the next step is to add lines such as the following to the source file for your access database:
You can define the default group (mqueue) using options and the command line. If a Q configuration command is missing a given equate, that queue group inherits the property defined by the default queue group. However, following are the default queue group properties, which do not have equivalent equates and all queue groups inherit these properties:
You cannot override these properties with a queue-group equate. Sendmail 8.13.3 contains the following performance enhancement features: The following sections discuss the Sendmail 8.13.3 performance features in detail. You can use the FastSplit option to suppress MX lookups before splitting an envelope and to limit the number of envelopes that can be delivered on the initial attempt. The FastSplit option syntax is as follows: -OFastSplit=num where, num is of type numeric. If num is a negative nonnumeric value, or zero, Sendmail enforces initial sorting based on MX records. If num is set to a value greater than zero, the initial MX lookups on addresses are suppressed when they are sorted which may result in faster envelope splitting. If the mail is submitted directly from the command line, then the value also limits the number of processes to deliver the envelopes. When Sendmail expands an alias, as when using aliases to send to a mailing list, Sendmail sorts the list of new recipients by host. Normally, the list of hosts is then sorted by MX records rather than host name. After sorting, the new MX-sorted list is split by Sendmail into multiple envelopes. Envelope splitting creates multiple envelopes when there is originally only one. Each new envelope contains fewer envelope recipients. Normally, all these envelopes are delivered in parallel for delivery efficiency. This feature is an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands improves SMTP performance. SMTP pipelining is an implementation of RFC 1854 (SMTP Service Extension for Command Pipelining). When processing the queue, Sendmail tries to keep the last few open connections open to avoid startup and shutdown costs. This only applies to IPC and LPC connections. When trying to open a connection, the cache is first searched. If an open connection is found, it is probed to see if it is still active by sending a RSET command. If this fails, it is not considered as an error; instead, the connection is closed and reopened. The following parameters control the connection cache:
By default, Sendmail is a set-user-ID program. You can set it to a set-group-ID program by creating a new user smmsp and by using the submit.cf configuration file. If sendmail is called for initial delivery, you must use the submit.cf file with a fallback of sendmail.cf as configuration file. A Mail Submission Program (MSP) is another instance of Sendmail that is used for initial mail submission. MSP uses the /etc/mail/submit.cf file as the configuration file. Sendmail 8.13.3 acts as an MSA or MTA depending on the operational mode. The default configuration starting with Sendmail 8.13.3 uses one sendmail binary which acts differently based on the operation mode and supplied options. For security reasons, Sendmail must be a set-group-ID program to allow for queuing mail in a group-writable directory. When Sendmail runs as a set-group-ID program, the default group is smmsp and the group ID is 25. The sendmail.cf configuration file is required for Sendmail to run as a server and submit.cf configuration file is required to run Sendmail as a mail submission program. You must use the following permissions for the Sendmail configuration and default queue files:
This section discusses the following topics: STARTTLS is the SMTP command to "Start Transport Layer Security”; or in other words to turn on Secure Socket Layer (SSL). Transport Layer Security (TLS) provides authentication (identification), privacy, confidentiality, and integrity for securing a mail transaction. TLS uses different STARTTLS algorithms for encryption, signing, and message authentication. The STARTTLS configuration uses the following variables:
You can use the /usr/newconfig/etc/mail/cf/cf/gen_cf script to generate the sendmail.cf configuration file that supports the STARTTLS feature. The generated configuration file contains all the STARTTLS options discussed previously. But, these options contain default values and are commented by default. The gen_cf script gives you the option to change the default values. If you change the default values for a particular option, the option is enabled or uncommented in the generated sendmail.cf configuration file. To use Sendmail with STARTTLS, you must install the OpenSSL software on your system from http://www.software.hp.com. The Simple Authentication and Security Layer (SASL), is a generic mechanism for protocols to accomplish authentication. Because protocols (such as SMTP or IMAP) use SASL, it is a natural place for code sharing between applications. Some notable applications that use SASL include Sendmail and Cyrus imapd (versions 1.6.0 and higher). Applications use the SASL library to inform it how to accomplish the SASL protocol exchange, and what the results are. SASL is only a framework and specific SASL mechanisms govern the exact protocol exchange. If there are n protocols and m different ways of authenticating, SASL attempts to make it so only n plus m different specifications need be written instead of n times m different specifications. With the Cyrus SASL library, the mechanisms need only be written once, and they work with all servers that use it. How SASL works is governed by what mechanism the client and server choose to use and the exact implementation of that mechanism. This section describes the way these mechanisms act in the Cyrus SASL implementation. The PLAIN mechanism is not a secure method of authentication by itself. It is intended for connections that are being encrypted by another level. For example, the IMAP command "STARTTLS" creates an encrypted connection over which PLAIN can be used. The PLAIN mechanism works by transmitting a user ID, an authentication ID, and a password to the server, and the server then determines whether that is an allowable triple. The principal concern is how the authentication and password are verified. The Cyrus SASL library is flexible in this regard. A standard Cyrus SASL configuration file looks like:
Applications can redefine how the SASL library looks for configuration information. For instance, Cyrus imapd reads its SASL options from its own configuration file, /etc/imapd.conf, by prepending all SASL options with sasl_: The SASL option pwcheck_method is set by changing sasl_pwcheck_option in the /etc/imapd.conf file. To configure Cyrus SASL v2 in Sendmail, you must change the default values for the following options in the Sendmail configuration file:
The submit.cf file is the client configuration file for Sendmail. The /usr/newconfig/etc/mail/cf/cf/submit.cf.gen file is the default Sendmail configuration file. You can also use the /usr/newconfig/etc/mail/cf/cf/gen_cf script to regenerate the submit.cf.gen file in the /usr/newconfig/etc/mail/cf/cf/ directory. You must copy the /usr/newconfig/etc/mail/cf/cf/submit.cf.gen file to the /etc/mail directory as submit.cf. Sendmail 8.13.3 contains the following new menu options in the /usr/newconfig/etc/mail/cf/cf/gen_cf script:
These new menu options are discussed in the subsections under the section “New Features in Sendmail 8.13.3” and “The /usr/newconfig/etc/mail/cf/cf/gen_cf Script”. Compared to the /usr/newconfig/etc/mail/cf/cf/gen_cf script menu options in Sendmail 8.11.1, the main menu options in the /usr/newconfig/etc/mail/cf/cf/gen_cf script in Sendmail 8.13.3 are rearranged as follows:
You can select the relevant option to display the submenu options. The following discusses the main menu options in detail:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||||||
|
|||||||||||||
