[ Julian Frost writes: ]
> On Tue, 20 Aug 1996, Dave Wolfe wrote:
> > [ Julian Frost writes: ]
> > >
> > > It seems that both messages that were bounced as "administration
> > > requests" had, in the body of the message, either the name of the
> > > list, or something approaching the name of the list.
> > Don't think so. The first one bounced because you had "help" in the
> > subject. The 2nd apparently had something in the 1st 5 lines of the body
> > that triggered the administrivia checks to bounce it.
> Here's the first 5 lines:
> Over the past few weeks that SIG-L has been operating, I have noticed that
> many of the subscribers to the list have more than one email address.
> While this is all well and good, it can create problems when they
> subscribe to the list from one address, then submit an article from
> another address!
That'll do it!
> Maybe majordomo needs to have a better "administration request" checking
> algorithm? Just searching for "random" words burried somewhere in the text
> of a message does not seem particularly optimal!
Hardly random words, but if you have a better heuristic coded up,
please, let's see it.
> I have deleted the /tmp/resendxxxx.* files, and do so regularly! I've read
> in the documentation that it is necessary to escape-out some tokens in the
> code, and have done this, but it doesn't make any difference (as others on
> this list have pointed out).
Exactly what are you referring to here? The '@' characters in quotish
strings for Perl 5 or the "/tmp/resend$$.*" vs </tmp/resend$$.*> fix for
1.92 mentioned in the FAQ? (Yes, that's 1.92, not 1.93.)
> When approve does its stuff, somewhere along the line, a
> resend.xxxx.in file is created. It is not deleted, and that causes the
Since approve normally doesn't even run on the same machine, I find
that scenario unlikely. Furthermore, the 'xxxx' in these file names is
resend's process number, which is different every time it runs (although
Unix does cycle through process numbers eventually, thus the name
collision), so any given message sent by the approve program causing a
particular process number to be assigned to resend is, shall we say,
"problematical". In order to get these name collisions, resend would
have to be leaving an awful lot of temp files lying around, far more
than would be generated by occasionally running approve.
I'm sorry if this sounds condescending, but I'm more inclined to
think that you changed some of the unlink() statements in resend from
or who knows what so that resend *never* removes its temp files. Care to
show us the output of 'grep unlink resend'? At least if they're all OK
then we know to look for another problem.
Dave Wolfe *Not a spokesman for Motorola*
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598