Date : Tue, 23 Sep 1986 21:43:00 MDT
From : WANCHO@SIMTEL20.ARPA
Subject: Archive Server response
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