The word "subscribers" in the second line is administrivia. The word
"subscribe" in the fourth line is administrivia. When I tested around
with administrivia, the subscribe/unsubscribe/sub/unsub strings would
bounce no matter where they were in the message. The commands like
info, lists, help, and others would only bounce if they were in the
first position on the first five lines.
> From: Julian Frost <email@example.com>
> 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!
> 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!
> > > Of course, I still have the errors with the approve script saying that
> > > the /tmp/resendxxxx.in files can not be created because they already
> > > exist!
> > That shouldn't be happening in 1.93. Remove the files when you're
> > reasonably sure resend isn't active (like after you've renamed it and
> > check for outstanding perl processes). If they continue to accumulate,
> > then you have a problem.
> 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). When approve does its stuff, somewhere along
> the line, a resend.xxxx.in file is created. It is not deleted, and that
> causes the problem.
> INET: firstname.lastname@example.org - Public Key for Encrypted Mail available.
> ** Irvine Aikikai (USAF Western Region) Home Page --
> ** http://eclectic.ss.uci.edu/~jfrost/Aikido/Aikido.html
> ## The Unofficial SIG-Sauer Home Page --
> ## http://odaiko.ss.uci.edu/sig/sig.html