SMTPRCD reads a queue of pending mail to be delivered remotely, that is produced by the SMTP Posting Office Sorting dæmon and schedules invocation(s) of the SMTP Relay Client to perform delivery. The queue directory is taken to be the working directory of the dæmon.
SMTPRCD communicates with the other servers in the SMTP message handling system via three semaphores. The SMTP Posting Office Sorting dæmon triggers SMTPRCD's semaphore whenever it has routed new mail for local delivery, and SMTPRCD in turn triggers the SMTP Cleanup dæmon's and the SMTP Posting Office Sorting dæmon's semaphores, respectively when it has delivered local mail to all target mailboxes and when it has generated a bounce message. Thus the semaphore names supplied on the command line should match the semaphore names supplied to the other dæmons.
run-file specifies the program to run as the SMTP Relay Client. It passes to it, as command-line arguments, a target domain name and the list of messages, and individual envelope recipients for those messages, to deliver to that domain.
RFC 0974 specifies that the MX list for a host is to be determined afresh
at every retry attempt. In this way "stuck" mail can be re-routed by
altering the MX information. SMTPRCD achieves this by dint of the fact
that it is the SMTP Relay Client that performs
and a fresh SMTP Relay Client process is started for evey delivery attempt.
SMTPRCD schedules by domain, rather than by message.
Unlike some other mail systems (e.g. UCB "sendmail" or "exim" in non-queued modes), the SMTP Relay Client dæmon does not have retry schedules for each individual message. That would result in multiple attempts to connect to the same server, one for each outstanding message, since it is very unlikely that multiple messages to the same domain would be submitted such that their retry times happen to be exactly aligned.
Instead the SMTP Relay Client dæmon maintains retry schedules for each domain to which one or more messages are to be sent. The philosophy is that retries are caused by the temporary failure of SMTP Relay servers, rather than the temporary failure of individual messages. Failures for individual messages are usually either permanent, or of such a nature that they apply to all messages to the same server anyway (such as lack of space in the mail queue for storing more messages).
The result is that all messages to a given domain are on the same retry schedule (although a single message could be on multiple retry schedules if it is addressed to multiple recipients on multiple domains, of course), and as a consequence all messages to a given domain can be easily bunched together for delivery over a single SMTP connection.
SMTPRCD performs immediate retry for new mail and uses LIFO ordering for each domain.
Each time that a new message+recipient pair is sent from the SMTP Post Office dæmon, it is added to the head of the list of message+recipient pairs for that domain and the domain is marked for a single immediate retry irrespective of its retry schedule.
The immediate retry avoids the problem where a domain's SMTP Relay servers have been inaccessible, causing pending messages to be queued for it, but have come back up. If no immediate retry were scheduled, new mail would wait until the next connection attempt, which, if the servers had been down for some time, could be several hours away. New mail causes the domain to be probed to see whether its servers have come back up, in other words. If they have, the retry schedule is reset to its initial value since the servers are now accessible. If they haven't, retries continue on the current schedule.
Because the SMTP Relay Client performs connection re-use, old mail queued to the domain "rides on the coat-tails" of the successful transport of new mail, since it is sent down the same connection. Adding the new mail to the head of the list ensures that newer mail is sent before older mail. A delay of a few seconds in delivering old mail, that could have been queued for several hours already, is preferable to the same delay in delivering new mail that has not yet been delayed at all. And in any case, this is only fair, since the old mail would not have been delivered until much later had it not been for the arrival of the new mail.
The upshot is that new mail to a domain is delivered as soon as possible, with priority over older mail.
SMTPRCD performs parallel SMTP conversations, but only where the domains are different.
A separate SMTP Relay Client process is started to handle each retry attempt for each individual domain. Multiple SMTP conversations thus occur in parallel if mail is to be delivered to multiple domains. This means that if the connection to one SMTP Relay server for one domain happens to be slow, it does not hinder traffic to other SMTP Relay servers for other domains. It also means that a large amount of mail to be delivered to a single domain will not prevent mail from being delivered to other hosts in parallel.
The "thundering herd" problem occurs, with some other mail systems, when several messages are queued and waiting delivery to a remote domain that happens to be down. With those mail systems, as soon as the mail transport discovers that the domain's SMTP Relay servers have come back up, it attempts to open multiple SMTP conversations with the servers to deliver all of the pending messages in parallel. This can sometimes overload the remote host's mail system.
SMTPRCD avoids this problem by only attempting one connection at a time for any given domain. Whilst it will will open multiple SMTP conversations in parallel in order to deliver to multiple domains, it will only open one connection at a time for delivering mail to any particular domain.
The "thundering herd" problem could still occur, of course, if two different domains happened to use the same SMTP Relay server, and the server was down and then came back up (and there were no further servers to fall back on). But the maximum level of parellelism will only reflect the number of different domains that the server actually services. In other words, if the target host only serves as SMTP Relay server for two domains, in the worst case (which is where pending mail exists to be delivered to all domains that the server services) SMTPRCD will only open two parallel connections to the SMTP Relay server.
SMTPRCD performs exponential backoff.
The interval between successive invocations of the SMTP Relay Client is increased every time delivery fails to deliver all mail. The schedule is to use intervals of 1 minute, 5 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, 8 hours, 16 hours, and thereafter 24 hours.
SMTPRCD can be managed as a service under RUNSVC, the Service Manager in the OS/2 Command Line Utilities version 2.2, A run file for such a service typically would look similar to:
chdir %MAILQUEUEDIR% program %APPS%\JdeBP\IU\bin\SMTPRCD.exe argument SMTPRCD argument /WAITFOR:\SEM32\IU\SMTP\RD argument /TRIGGER:\SEM32\IU\SMTP\PD argument /IFCLEANPOST:\SEM32\IU\SMTP\CD argument localhost. argument %IMAPROOT%\Personal\
[c:\]smtprcd /WAITFOR:\SEM32\IU\SMTP\RD /TRIGGER:\SEM32\IU\SMTP\PD /IFCLEANPOST:\SEM32\IU\SMTP\CD