response 51 of 106:

Dec 3 04:04 UTC 1994

Hm.  I guess it's no bad thing to not send a copy of a message to
its originator, if the mail is being set to a list that happens to
include the originator.  I usually just delete that mail anyway.

response 53 of 106:

Dec 3 08:12 UTC 1994

Hmm, a "file-descriptor leak", interesting bug.

I'm a little worried about not getting a copy back from mail
I send which is cc'ed to staff. I have come to rely on that, and 
often put it in a mail folder while it is a pending issue.
If I expicitly cc myself will sendmail let me have the copy?
If so, I would just have to get used to doing that. I could manage.
If not, I would vote for toggling it back to the way it was before.

I love sendmail, by the way.

Also, to add to the list of things Valerie mentioned, sendmail is putting
grex.cyberspace.org in the return addresses. This must be configurable
and ought to be cyberspace.org like it used to be. Thanks mdw & steve.

response 55 of 106:

Dec 3 19:18 UTC 1994

64 MB memory probably has something to do with it, but I'd guess that
sendmail is the BIG reason Grex is clipping along so much better.  Thanks
for taking the time out of everything else to get that up & working right.
It is really neat.

response 57 of 106:

Dec 4 03:58 UTC 1994

Newmail now seems to be a happy camper.
It's working fine for me.

response 59 of 106:

Dec 5 10:40 UTC 1994

Interesting problem (it seems like a problem anyway). I su'd to
another account and sent email using a long-pre-existing alias.
BONK! 
=====clip note------
  

This is a MIME-encapsulated message

--EAA07449.786620055/grex.cyberspace.org

The original message was received at Mon, 5 Dec 1994 04:34:04 -0500
from graymatt@localhost

   ----- The following addresses had delivery problems -----
rfp  (unrecoverable error)

   ----- Transcript of session follows -----
550 rfp... User unknown

   ----- Original message follows -----

--EAA07449.786620055/grex.cyberspace.org
Content-Type: message/rfc822

=======clip note-------
  
Now, if rfp +had+ been a loginid .... things might have been
more interesting. However, I'm happy there wasn't.
  
That alias, and lots more, have been in my .mailrc for aa very
long time.
  
Is there a sendmail situation that is averse to alias's? 
 
Did the fact taht I su-d to that other account have anything
to do with it?

response 61 of 106:

Dec 6 04:49 UTC 1994

What does "su" stand for?

response 63 of 106:

Dec 6 05:23 UTC 1994

  Substitute user (also better but more accurately known as
super user).  A way of "becomming" someone else for a few, to
check mail, etc.

response 65 of 106:

Dec 17 04:36 UTC 1994

A couple of comments.  For those who don't know me (which is probably
everyone I'm not related to :-) I work for MIT as a programmer.
I have also done some system administration here.  While I haven't 
really had to work with sendmail much, I've played with it some.
(I know, what a hobby).
About the "no control file" messages:  I haven't seen this error, I have
seen a fair number of 'orphaned' data files on the dialups servers here.
(They use sendmail to forward everything to a central mailhub).  Anyhow
we've given up on doing anything with these datafiles, since they contain
only hte message body, no headers.  If you figure anything out, i'd be
interested in hearing it.
One unsolicited suggestion is that you raise the ampunt of time before
the sending delay warning messages appear.  Four hours seems awfully low.
I think most of the places I've seen empoly that feature send out the warning
messages after a couple of days.  While that may be too high, I suspect
most Grexers know it can take a while for mail to get out.  I know, just
one more part of sendmail to tune.
BTW: "Om" is appearantlyth sendmail.cf incantation to get it to include
the sender on list mail.  A feature I happen to like (or at least be used to).
Good Luck with all of the tuning.

response 67 of 106:

Dec 17 07:24 UTC 1994

Welcome to grex.

I've seen the "no control file" problem too.  They do kind of disturb
me.  I guess it's nice to know it's not unique to grex.  The only thing
I was able to determine for sure is that there aren't any log messages
for the mail...

4 hours is the default without special magic.  It might actually be an
appropriate setting with a fast internet link but it's got definite
problems, especially here on grex.

response 69 of 106:

Jan 18 22:45 UTC 1995

   Marcus's idea of chaning the hour hour delay is due to our slow, drop
prone PPP link.  Since it can go down becuase of either phone line problems,
or because of router problems, I think he thinking of shortening that limit.
Which makes sense to me, as once we've been knocked off the link we usually
get back on again within ten minutes.

response 71 of 106:

Jan 19 02:03 UTC 1995

   Every site I've heard of using sendmail has the "no control file" problem.
I'd like to see the 4 hour wait ramped down, but it isn't that urgent.  I'd
bet that something like 95% of our outgoing mail isn't effected by this,
and 4 hours isn't that long anyway--how many people I wonder, use the mail
thats just come in over their internet connected machine within four hours
of its arrival?

response 73 of 106:

Jan 20 08:59 UTC 1995

I believe I now have a theory that explains the "no control file"
problem.  Mail is actually queued in 2 files, a "data" file, that
contains the body of the mail, and a "control file" that contains the
headers.  When mail is received, the data file is first created, and the
body is saved.  Only after the body is saved, is the "control file"
created, and log entries posted for the mail.  Hence, even in routine
operation, it's possible to find these files with mailq - chances are a
"ps" after that will find that there is a sendmail running for that
mail, and if that's not the case, chances are there will be log messages
for the mail.

This is the "ordinary" case.  The two exceptional cases are, if the link
goes down, or if the machine crashes.  If the link goes down, the remote
end may break its connection and leave "sendmail" running forever, or at
least, a long time.  A quiescent TCP connection doesn't necessarily
generate any traffic, so it may take a while for the connection to
break.  Writing data to a tcp connection won't leave the connection
quiescent, but reading from a TCP connection does - and depending on
buffering, timing, and remote TCP implementation, there may well be
windows when data is being sent in which a network failure will indeed
leave the connection "quiescent".  Eventually, sendmail does give up - 1
or 4 hours later?

A machine crash is more straight-forward.  Of course, the data file will
be left there "forever".  I haven't gone digging through the sendmail
source for this yet, but I haven't seen many of these files around.  I
think sendmail may be looking for orphaned data files when it's started
up in daemon mode, and getting rid of them.

One of the puzzling things about these is, even though they "seem" to be
quite commmon, they don't seem to cause any problems.  That's not very
strange: if something happens when a remote sendmail is sending data to
Grex, it will just try again in a while.  The message will be the same,
but the local ID will of course be different.

So, I don't think the "missing" control files are a serious problem, and
I'm not going to worry about them.