smtpd is started by the super-daemon inetd. The -f option (the finiky option) causes incoming connections from unknown hosts to be rejected. smtpd notifies the smtpsrvr program to use the finicky option by calling it with argv set to `rsmtpsrvr'.
The smtpsrvr argument is the path to the smtpsrvr program (relative or absolute). Generally this is something like /usr/mmdf/chans/smtpsrvr.
The channels argument is a comma-separated list of channels. When a connection is established, the source host is looked up in the host tables for these channels. If the source host is found, the corresponding channel name is given to submit as the channel it should consider the mail to have come from for authorization purposes. In the finicky mode, if the source host is not found, smtpsrvr will reject the incoming mail. In the normal (non-finicky) mode, if the source host is not found, smtpsrvr will assume the mail came in on the last channel in the channels list.
If your smtp channel table is a nameserver-type channel table and you are running in the finicky mode, then you should include the "local" channel in the list of acceptable channels. If you do not include "local" in this case, you will not be allowed to connect to your own server and submit mail because the nameserver channel will not let you look up your own address. (RFC 974 requires this to prevent mail loops).
Since the smtpsrvr program sets the trustme flag when calling submit, it must be called by a process whose UID is that of a trusted mail submitter (generally only root and mmdf).
smtpsrvr uses the smtp channel configuration
string (the confstr parameter) to
set various parameters. To generate RFC822 source routes for the return
address, set sender_source_route=1. This will cause a return address that
initially looked like
email@example.com, received from a host named
smtp.sending.host, to be converted into
In the past, source routes were used to
ensure that the message could be returned by causing it to be returned via the
same host that it was received from. However, in the modern SMTP environment
it is not neccessary, and is liable to have the opposite effect because many
SMTP sender hosts will not accept mail via SMTP (these are most often desktop
machines that retrieve mail via POP or IMAP and send it via SMTP). Further,
RFC822 source routes are deprecated in RFC2822 and are no longer accepted by
some hosts. They may be useful to solve specific problems in some cases.
The SMTP channel can be configured to reject messages with a return address (envelope sender) that contains a domain name that does not resolve in a manner that would allow mail to be sent to it, meaning that the message could not be bounced if neccessary. This is recommended by RFC2505, and is mainly an anti-spam check, since legitimate mail should never have a bogus hostname in the return address. This check is off by default due to the chance that it could cause a legitimate message to be rejected, either because the message was misconstructed or due to DNS misconfiguration. For most hosts, it will be beneficial (for the purpose of spam rejection) to enable it. This is done with the vrfy_sender_domain confstr parameter (vrfy_sender_domain=1).
A colon-separated list of hostnames/addresses that should be treated as though they do not actually exist can be given with the no_such_domain_hosts confstr parameter. This is used in conjection with the vrfy_sender_domain parameter. If an address is given, it should be enclosed in . For example, spam is sometimes sent with a return address of 'localhost'. To reject attempts to submit such mail, use: no_such_domain_hosts=[127.0.0.1] Legitimate mail sent with an address at the local host as the return address should always use the true name of the host, not 'localhost'. Another example: If a large block of domain names for hosts that do not actually exist have been given a "wildcard" A record such that they appear to resolve to a useful address (thus tripping up the vrfy_sender_domain test), that address can also be given: no_such_domain_hosts=[127.0.0.1]:[18.104.22.168]
Here is an example of a full smtp channel configuration string using some of these parameters to change the default behavior (the first two are used by the outbound smtp channel, the latter two by the inbound channel):