[comp.mail.mush] IT'S NOT MY FAULT!

schaefer@ogccse.ogc.edu (Barton E. Schaefer) (06/22/89)

I'm not sending this to mush-users for reasons that will soon become obvious.

I just want you to know I didn't have anything to do with the 5-10 copies
of my "strange mush problems" response that went to this newsgroup and to
the mush-users mailing list.  From what information I have, a newly
installed sendmail at daedalus.ucsf.edu started interpretint the To: lines
on mail sent there.  Because of the way garp.mit.edu forwards mush-users
mail, the To: line on the message that reached daedalus included both
mush-users and the srhqla newsgroup gateway.  Presto, a loop is set up
and everybody gets a batch of copies.

I'm avoiding the mailing list until I hear that this is cleared up, and I
recommend that others do likewise.

In article <533@magnus.UUCP> mml@magnus.UUCP (Mike Levin) writes:
} In article <700@srhqla.UUCP> Bart Scheaffer writes:
} >} When I get an address wrong, my dead.letter file ends up with TWO copies
} >} of the failed article.
} >...
} >That's not a bug, it's a feature. :-)
} >...
} >
} >    set dead = ~/LETTER.DEAD
} 
} Does that also mean that if I do something like:
} 	set dead = /dev/null
} That I will NOT end up with two copies (i.e., if that's what I WANT to force

Yes, you can set dead = /dev/null.  You can even set it to be a pipe to a
program if for some strange reason you want to.

} By the way, Bart-  Are you going to be posting a Patch #5 soon?

The blasted longjmp botch has been reported again, and I'm waiting to hear
more from the reporter.  Also, Dan wants the init code changed to look for
a system-wide Mushrc file before it tries to read Mail.rc, so mail and mush
can have separate system init files.  Consequently, patch #5 will be delayed
at least until Friday and possibly until Monday or Tuesday.
-- 
Bart Schaefer           "And if you believe that, you'll believe anything."
                                                            -- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer