Re:sub/unsub behavior

At 4:07 PM -0400 8/21/05, Zhiliang Hu is rumored to have typed:

> I am learning PERFECT rules here.  Thanks.

   (*sigh*) Being a wise-*ss when you are asking for help isn't the brightest
move.

> How about my first question?  Is it a Smartlist default feature that
> everyone can sub/unsub anyone else? (alternative is uncomment
> auto-sub/unsub to completely disable it?)

   I did not originally answer because I do not see such behaviour on my
lists, but then I'm using the confirm add-on, so I do not face such a
draconian boolean decision. When I send from a throwaway a subscription
request formatted as you describe to my Old-Time Radio discussion list:

Subject: subscribe [email protected]

   [email protected] receives a confirmation message (interestingly
with a To: header field pointing to the throwaway, even though ther target
address testacct3 gets the mail), which says, in part:

> A copy of the (un)subcription request appears below.  In the event that
> you did not send a request to (un)subscribe, the headers of the message
> may help you discover who sent the request; contact your SysAdmin,
> requesting that s/he contact the [email protected] for copies
> of relevant log files.

   ...allowing the bad guy to be rapidly discovered (if it's really
malevolent and not an error, it's probably a zombied machine in Mexico
anyway) - but the target is NOT subscribed to the list unless he confirms, so
ignoring this message gets him no additional email past the one confirm
message. If you don't like this behaviour, it is certainly trivial enough to
write a procmail recipe in rc.local.r00 to look for the string " subscribe"
or " unsubscribe" and the relevant aliases in the subject (possibly also
looking for the "@" character, if you wish), and pipe to formail to modify
the header field, or redirect the message to /dev/null, or mark it for
administrative action, or send it to your grandmother, or whatever else you
might wish.

   Smartlist was originally written in the good old days, when people on the
Internet were trustworthy. Many modifications have had to be made since those
days (the confirm add-on, for example - when I started running mailing lists,
we didn't _need_ to confirm addresses, since no one bothered to revenge-spam
others) because the Internet now is home to the unwashed masses who tend not
to be so nice. But it _is_ open-source and uses simple-to-understand procmail
recipies; you don't like how something works, change it.

         Charlie (who uses a completely different Subject-based approval
                   method on his one-way mailing lists just...becasue)