WANCHO@SIMTEL20.ARPA (09/24/86)
The Archive Server program looks for a Reply-To: line, and if it exists, it extracts, as-is, an address to use for the To: line in its replies. If the Reply-To: line is not found, then it uses the From: line, if it exists. If the From: line is not found, it logs the event and proceeds to the next request message. This is exactly the same mechanism used by the Reply command of many user mail handler programs. In any event, the extracted return address is case-preserved and no address conversion whatsoever is done. Our mailer, on the other hand, will convert the host name on the right of the atsign to the Official Host Name IN THE ENVELOPE, not the header, if the host name is found to be an alias. This conversion has not been the source of any of the problems seen so far. Most of the problems in getting the mail out of here stem from a rather severe congestion problem on the ARPANET side of DDN which has been going on for the past two weeks. This has been impacting replies to be sent through CSNET-RELAY and WISCVM in particular. Our mailer tries to send a message immediately, and failing that first try, puts the message in a queue. Failures are typically "Cannot connect to host," which may mean that the host is not up or the host is up but does not respond to a connection request within the two-minute timeout window. The mailer then attempts to send each message in that queue once an hour for the next three days. Notices are sent to the sender (me in this case) when the message has not been sent after the first 24 and then 48 hours. After 36 hourly attempts, the failed message is sent back to the sender (me) and I discard it. However, if the message gets out of here, then the next bottleneck would be at the gateway host or some intermediate site on the other side of that host. Sometimes even those eventually come back as undeliverable because some host in the return address didn't exist or did not respond in the timeout window. Those get tossed too. That's the way it is; it probably isn't going to get any better, and may get a lot worse. Of course it didn't help matters any that we had a severe head crash on our boot disk early Friday morning and did not come back up until late Saturday afternoon. Messages scheduled to be timeout in that period had one more chance when we came back up and then were returned to sender. Lenthy outages such as that one are very rare and the missed attempts an unfortunate side-effect. But, timeouts are the only way to maintain sanity in our queues. As for the server process itself, it appears that I will have to place a limit on how many requests will be honored in any one message. I didn't place one because I thought people would be reasonable - I was wrong. The limit will be five (5) request lines in any one request message, with the remainder ignored, probably with an appropriate message. Also, processing of requests will be suspended during prime time on Fridays while we run our full backups. --Frank