Hello:
Does SmartList have an archiving and (hopefully user friendly) search capability?
[I'm not interested in the archives of this Disc List, but of the list I run for my
'users'].
Thanks,
Mitch Darer
--
Mitchell Darer, WebMaster, mitch(a)focusing.org
The Focusing Institute, 34 East Lane, Spring Valley, NY 10977
http://www.focusing.org (845) 362-5222 (phone/fax)
At 11:41 AM -0400 7/28/00, Werner Reisberger is rumored to have typed:
> I never saw any
> admin reply to the numerous complains about spam messages.
Actually, that's not _strictly_ true, since I remember when Stephen was
actually maintaining the list (and probably anally have archives of the list
from that time somewhere on some floppy or MO cart from a long time ago and
far far away). But you're right, it's been _years_ since he's been around.
However, the list belongs to the maintainer (or at least the machine's
admin), not the members. You'll get no argument from me that the list should
be moved (I believe I said exactly that a couple of times), but to suggest
the admins need to take a poll to ask what they may or may not do with the
existing list is silly, to say the least. They are certainly able to move
this list to mailman without the list subscriber's permission - indeed, they
_have_ done so, which makes my point for me.
Whether we should move this list to a SmartList server is a completely
seperate issue...one which Philip should probably weigh in on, since he is
now maintaining the procmail/SmartList source and as such the de facto head
of our band of merry wanderers...
Charlie
> I've set it (correctly I think) on our server, to collect
> email addresses for a company newsletter. I've downloaded
> the manual and read it over and over, but when I send
> X-Commands and try to distribute a newsletter, absolutely
> nothing happens.
>
> I've spent hours trying to figure out what it is I'm doing
> wrong [...]
One thing to check for: The X-Command has to be in the _header_ of
e-mail message sent to list-request(a)domain.com. Some mail clients
won't let you add your own custom header lines, or they make it
difficult.
I modified the way X-Command works, to support list admin commands
in the _body_ of the message. The logic checks to see if the from
address matches the list maintainer address, and if it does,
it allows the list commands. I didn't add a password check, but
that would have been straightforward as well. The list maintainer
check can be easily generalized to allow more than one maintainer.
The mod is in rc.request, just ahead of the recipe that already
handles X-Command. Here's the logic:
#
# Or is it a special remote "admin" command from the maintainer?
#
:0 H wf:dist.lock
* $^From:.*$maintainer
* ^Subject:.*admin
* $!^X-Loop: $listaddr
* $!^X-Loop-Admin: $listaddr
| do_admin
which is inserted just ahead of this part of the recipe:
#
# Or is it a remote X-Command from our maintainer?
#
:0 H wf:dist.lock
* $^$X_COMMAND:.*$maintainer[ ]*$X_COMMAND_PASSWORD
* $!^X-Loop: $listaddr
| x_command
The extra logic looking for X-Loop-Admin checks for the cases where
mail to the maintainer is looping. This can happen sometimes, and
when it does, bad things happen.
The "do_admin" script is in in the .bin directory, and is a slight
variation on "x_command":
#! /bin/sh
:
echo=echo # /bin/echo
test=test # /bin/test
cat=cat # /bin/cat
rm=rm # /bin/rm
formail=formail # /usr/local/bin/formail
subscribe=subscribe # ../.bin/subscribe
unsubscribe=unsubscribe # ../.bin/unsubscribe
multigram=multigram # ../.bin/multigram
tmprequest=tmp.request
tmpfrom=tmp.from
dist=dist
log=log
$test -z "$listaddr" &&
$echo "Don't start this script directly, it is used in rc.request" && exit 64
X_ENVELOPE_TO=$list-request # to convince (un)subscribe we used the right
export X_ENVELOPE_TO # address
$cat >$tmprequest
$formail -a X-Processed: <$tmprequest
set dummy `egrep '^(subscribe|unsubscribe|checkdist|showdist|showlog|help|info|wipelog|version)' < $tmprequest`
shift
while $test $# != 0
do
case "_$1" in
_subscribe|_unsubscribe|_checkdist)
if $test $# = 1
then
$echo "X-Diagnostic: Missing argument for $1"
set help
fi;;
esac
case "_$1" in
_subscribe)
$echo "From $2 " >$tmprequest
$echo "From: request ($listreq)" >>$tmprequest
$echo "Reply-To: $2" >>$tmprequest
$echo "To: $listreq" >>$tmprequest
$echo "Subject: subscribe $2" >>$tmprequest
$echo "$2" >$tmpfrom
$test -z "$subscribe_log" ||
$echo "x_command: subscribe" >>$subscribe_log
$subscribe <$tmprequest ||
$echo "X-Diagnostic: Unscreened, not subscribed"
shift ;;
_unsubscribe)
$echo "From $2 " >$tmprequest
$echo "From: $listreq" >>$tmprequest
$echo "Reply-To: $2" >>$tmprequest
$echo "To: $listreq" >>$tmprequest
$echo "Subject: unsubscribe $2" >>$tmprequest
$echo "$maintainer" "$2" >$tmpfrom
$test -z "$subscribe_log" ||
$echo "x_command: unsubscribe" >>$subscribe_log
$unsubscribe <$tmprequest | $SENDMAIL $sendmailOPT `cat $tmpfrom`
shift ;;
_checkdist)
$echo "Multigram checking the dist file for matches with"
$echo "$2:"
$echo ""
$echo "From $2" | $multigram -b8 -l-32767 dist
$echo ""
shift ;;
_showdist)
$echo "--- Current subscribers:"
$cat $dist
$echo "--- End of subscriber list" ;;
_showlog)
$echo "--- Current log:"
$cat $log
$echo "--- End of log" ;;
_wipelog)
$cat /dev/null >$log ;;
_version)
flist -v 2>&1
echo ""
procmail -v 2>&1 ;;
_help|_info)
$echo "Known $X_COMMAND keywords:"
$echo " subscribe mailaddress"
$echo " unsubscribe mailaddress"
$echo " checkdist mailaddress"
$echo " showdist"
$echo " showlog"
$echo " wipelog"
$echo " version"
$echo " help"
$echo " info" ;;
*) $echo "X-Diagnostic: Unknown command $1" ; set dummy help ;;
esac
shift
done
The key differences between "do_admin" and and "x_commend" are below.
The lines with exclamation points,
$cat >$tmprequest
! $formail -R$X_COMMAND: X-Processed: <$tmprequest
! set dummy `$formail -x$X_COMMAND: <$tmprequest`
! shift; shift
! test "_$X_COMMAND_PASSWORD" = "_$1" && shift
while $test $# != 0
do
case "_$1" in
are replaced with these:
$cat >$tmprequest
! $formail -a X-Processed: <$tmprequest
! set dummy `egrep '^(subscribe|unsubscribe|checkdist|showdist|showlog|help|info
|wipelog|version)' < $tmprequest`
! shift
Basically, instead of looking for X-Commmand in the header, and then
extracting the commands from those lines, the script looks for the
commands as the appearing in the first column, and then works through
those commands one-at-time as the previous script did. The password
handling was removed, but with a little work could be added back in.
For now, the check for the maintainer address is considered to
be sufficient, though this could be spoofed, and something more
robust is desirable for production use. The advantage of allowing
the commands in the body of the message is that the user who is
managing the list can use any mail client, and doesn't need to
figure out how to create custom header lines.
Here's an example of an admin message processed by the method
described above:
From: list_manager(a)domain.com
To: list-request(a)list_domain.com
Subject: admin
unsubscribe old_user_address(a)old.com
subscribe new_user_addr(a)new.com
showdist
On Sep 30, 2:51pm, Charlie Summers wrote:
> Subject: Re: X-Commands (was Smartlist Expert????)
> At 2:28 PM -0400 9/30/00, Gary Funck is rumored to have typed:
>
> > I modified the way X-Command works, to support list admin commands
> > in the _body_ of the message.
>
> Man, are _you_ working too hard.
Story of my life. :)
>
> Please look at .examples/rc.local.r00 for a painfully simple method of
> placing X-Commands in the body that's pre-packaged in the SmartList
> distribution.
Sounds good. I made the X-Command change in a much earlier implementation
of Smartlist, and haven't kept up-to-date with the improvements.
Thanks for pointing out the example.
There is a new web interface for the remote administration/configuration
of SmartList lists available. It's a new version of rconfig I wrote some
time ago but it's completly rewritten and has much more features:
- It let's you access a predefined set of files with your browser
for editing.
- variables and their values are displayed within a html table. yes/no
values can be selected as checkboxes.
- You can define which lists and which files within these lists
should be modifyable by rconfig.
- You can create files, e. g. if you permitted the file footer.txt
for the list testing but the file isn't there it will be created if
an update will be send.
- All commands provided by the SmartList xcommand mechanismn are available.
- The web interface can be used with read access for the web server group
for certain files (default) or without read access. In the latter case
you can send updates via the CGI but you cannot view the files/variables
in advance.
For the purists: You can also use rconfig without HTTP.
- No setuid programms are involved. Authentification is managed through the
xcommand mechanismn.
- Easy installation through an interactive install script.
Available through anonymous ftp:
ftp://ftp.pure.ch/smartlist/rconfig.0.03.tar.gz
I installed and tested rconfig on two linux machines. At the moment it should
be considered beta. Any suggestions and comments are appreciated.
Werner
On Sep 27, 8:45am, Jim Osborn wrote:
> Subject: subscriber looks like daemon
> I've got a subscriber called "mail@<his-domain-name>.com"
> which makes sense to him, but causes SmartList to reject
> his posts. Does anyone know of a trick I can use to
> slip his posts past the daemon screens?
Hi Jim,
There is a hook for this in rc.custom, I've modified the default
setting to reflect the specifics of your example above:
daemon_bias='100^0 ^From:.*mail@<his-domain-name>.com'
# You could set "daemon_bias" to positively discriminate some
# mail address not to be from a daemon. Either with a regexp as demonstrated
# or with more complicated recipes that simply set it to '100^0' or nothing.
To the Gentlemen who helped me by providing a location from which to begin
and some tips to get started, I say THANK YOU!
You have been so helpful.
Cindy
For products designed for chemically sensitive people, try
http://www.zavanahbay.com>
Is there anyone out there I can employ to fine tune the settings on
SmartList?
I've set it (correctly I think) on our server, to collect email addresses
for a company
newsletter. I've downloaded the manual and read it over and over, but when I
send
X-Commands and try to distribute a newsletter, absolutely nothing happens.
I've spent hours trying to figure out what it is I'm doing wrong and I've
reached the
point where I've decided it would be better to pay someone more knowledgable
who will get it right for me.
Please email me at: admin(a)exchangehomes.com if your're interested.
Thanks
Anne
Thanks Philip! It makes perfect sense.
> :0 h
> | ( formail -r -i "From: $listreq" -A"X-Loop: $listaddr"; \
> cat info/reject.attach $tmprequest \
> ) | $SENDMAIL $SENDMAILFLAGS -t
Now I got an extended question: what is the best use of "cat" here?
I got the " |formail .... | (cat; cat file) | $sendmail .... " recipe
for this purpose a long time ago on this list and have been using that
since then, although I thought the first pipe "|" and "cat" were
redundent.
So a little while ago I put a question on "procmail" list asking why
there are 2 "cat"s. In a reply, Volker Kuhlmann
<kuhlmav(a)elec.canterbury.ac.nz> suggested to use:
... | /sbin/cat - info/accept.txt | ...
Now, among the 3 constructs:
1. | formail ....; cat file | $sendmail -t
2. | formail .... | (cat - file) | $sendmail -t
3. | formail .... | (cat; cat file) | $sendmail -t
Number "1" appear to be making the best sense. However number
"2" and "3" must also had a reason to be that way (historically
or associated with older versions of procmail or have something
to do with the nature/version of "cat" or whatsoever).
Could someone put some lights on them?
Thanks!
Zhiliang
Hello.
I am a newbie at running the list software.
It is part of my web hosting package, but no online or paper manual comes
with it. There is the help file that consists of about one paragraph on the
server.
I need to know if there is a handbook or a web page with more instructions
for {SmartList v3.11pre7 1997/04/28 written and created by Stephen R. van
den Berg}?
For instance, I need to know how to ask for more than one message out of the
archive say messages 20 through 45.
I appreciate any help that might be offered.
I promise to read the manual if there is one!
Cindy