Greetings All --
I will soon be unable to service updates to the SmartList FAQ.
Therefore, I believe is is appropriate for me to solicit this forum for
a new maintainer to whom I can pass the baton. Alternately, if a
suitable collaborative FAQ hosting solution can be found then I would
certainly support the migration to that platform.
Note that maintaining the SmartList FAQ makes almost no demands -- the
document has been basically stable for quite a while.
Thank you for your consideration,
Regards,
Pete.
Good to confirm... I checked "confirm" add-on at the Smartlist FAQ but
it does not load to my browser. So I came up a simple 'rc.local.r10'
to do the verifications, attached beblow.
I tried some simple tests and it worked for me. May need more tests
to improve.
Zhiliang
ps:
when I copied to the mail window there are some added line breaks. I
hope one can restore these breaks for tests..
#$Id: rc.local.r10,v 0.01
#
# 2005/08/22 19:28:16 Zhiliang Hu
##############################################################
tmpreqloc='admin/subcktmp'
:0 w
* ^Subject:.*\@
{
FROMADDR =`formail -rtzxTo:`
SUBJADDR =`formail -xSubject: |perl -pe
's/.*sub.*\s+([^\s]+\@[^\s]+)/$1/sg;s/^\s+//g;s/\s+$//g;'`
SUBJCOMD =`formail -xSubject: |perl -pe
's/(.*sub.*)\s+[^\s]+\@[^\s]+/$1/sg;s/^\s+//g;s/\s+$//g;'`
DATEMARK = `date +"%s"`
:0 ic # "i" -- supress "writing errors" ('header/body
passed to nothing' error)
* ^Subject:.*sub
| echo "$SUBJADDR $SUBJCOMD" > $tmpreqloc/$DATEMARK
# If the same address, re-formulate a subscription mail to server
#----------------------------------------------------------------
:0
* ? formail -rtzxTo: | multigram -b1 -x$listreq -x$listaddr \
-l$reject_threshold $tmpreqloc/$DATEMARK
| (formail -I"From: $FROMADDR" -I"Subject: $SUBJCOMD") \
| $SENDMAIL -oi $listreq
# If different address, email the target person for confirmation
#---------------------------------------------------------------
:0 E
| (formail -i"From: $listreq" -i"Subject: subscription confirmation
needed" \
-I "To: $SUBJADDR"; \
echo "Confirmation code: $DATEMARK"; \
echo " "; \
echo "This list server has received a '$SUBJCOMD' request for";
\
echo "$SUBJADDR from $FROMADDR"; \
echo " "; \
echo "If this is what you wanted and wish to confirm, please reply to"; \
echo "this mail, and copy the entire 'Confirmation code' line on
the"; \
echo "top of this mail into the 'Subject:' field. The
confirmation must"; \
echo "be made in 7 days. After 7 days, the request will be
dropped from"; \
echo "the server."; \
echo " "; \
echo "List Daemon for ANGENMAP") | $SENDMAIL -oi $SUBJADDR
}
:0
* ^Subject:.*Confirmation code:
{
CONFNAM =`formail -xSubject: | perl -pe 's/Confirmation
code:\s+([0-9]{9,})/$1/sg; s/[\s]+//g;'`
COMMAND =`cat $tmpreqloc/$CONFNAM | perl -pe
's/^\s+//g;s/\s+$//g;s/\S+\s+(\S+)/$1/g'`
:0 fhw
* ? formail -rtzxTo: | multigram -b1 -x$listreq -x$listaddr \
-l$reject_threshold $tmpreqloc/$CONFNAM
| formail -I"Subject: $COMMAND"
:0 E
| formail -I"Listmarster: sub/unsub help needed" | $SENDMAIL -oi
$listmaster
}
###########
### END ###
###########
On Sun, 21 Aug 2005, Charlie Summers wrote:
> At 1:35 PM -0400 8/21/05, Zhiliang Hu is rumored to have typed:
>
> > as the format in the quoted examples are not consistent
>
> They are PERFECTLY consistant; those with a single "#" are defaults in
> rc.init; those with double "##" _change_ the default action.
>
> This is covered in the FAQ (see 2.1), available at
> http://www.hartzler.net/smartlist/ - I suggest you read it.
>
> Charlie Summers
I am learning PERFECT rules here. Thanks.
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?)
Zhiliang
I did a few tests and found anyone can subscribe/unsubscribe any email
address to my Smartlist by a "sub/unsub anyuser(a)anyaddress.domain".
(The part worries me is the sub'ed/unsub'ed address does not receive a
confirmation from the server - the confirmation is sent to the
address that issued the requests only).
I checked through the 'rc.custom' but didn't identify the line that
control this behavior. Could someone please advice for my possible
oversight?
Also I have a comment on the format of the 'rc.custom' file -- often
I am confused as which line to "uncomment", as in (quote):
----------------------------------------------------quote start
#auto_subscribe = yes
##auto_subscribe # uncomment to disable unattended
# subscription handling
#auto_help
##auto_help = yes # uncomment to enable default help
# responses to all undecipherable
# requests
-----------------------------------------------------quote end
as the format in the quoted examples are not consistent, which leads
one to twist the tongue for the logic wordings -- the first line (with
single '#') or the 2nd line (with double '##')? Or the line with
'yes' or the line without 'yes'? Although I could have a good bet
after a couple seconds on the 2nd ('##') line, I would suggest leave
only one line for "comment"/"un-comment" for more clarity. In my
opinion the first lines as perhaps headers only adds confusions.
Comments?
Thanks in advance.
Zhiliang
Currently my Smartlist saves mail archive with permission 660 and
group of the list account, like in:
-rw-rw---- 1 slist slist 1860 Jun 6 09:38 4298
How may I change it to save with permission 644 or with a
different group? (I have already made ~slist a member of another
group), like in
-rw-r--r-- 1 slist slist 1860 Jun 6 09:38 4298
-rw-rw---- 1 slist web 1860 Jun 6 09:38 4298
I guess it would be somewhere in rc.submit but appreciate any hint.
Thanks,
Zhiliang
Normally I use sendmail on my own server for sending smartlist
mail.
However, for special reasons, I now need to use a remote smtp
server for one particular list.
I could not get the sendmail documentation to reveal to me
the secret for doing that. And presuming that I can find it,
then what would be sensible way to inform smartlist about it.
I have guessed someting along the lines of using rc.custom
and setting $sendmailOPT.
Thanks for your advice.
Sincerely,
Seth Chaiklin
Hello everyone!
I have a problem, that some users cant subscribe to the mailinglist, because
the freemail-provider of these users(it's a german freemailer GMX), "breaks"
the Subject line - look at this mess! :
------------------
Return-Path: <listman(a)vovka.de>
X-Original-To: vladimir(a)vovka.de
Delivered-To: vv(a)vovka.de
Received: by vovka.de id AEBFD22870; Wed, 3 Aug 2005 13:23:24 +0200 (CEST)
X-From_:zucker4@gmx.net Wed Aug 3 13:23:24 2005
X-Original-To: berlin-request(a)vovka.de
Delivered-To: berlin-request(a)vovka.de
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
by vovka.de (Postfix) with SMTP id 0CAD022862
for <berlin-request(a)vovka.de>; Wed, 3 Aug 2005 13:23:23 +0200 (CEST)
Received: (qmail 31339 invoked by uid 17); 3 Aug 2005 11:23:23 -0000
Received: from 195.37.76.167 by www28.gmx.net with HTTP;
Wed, 3 Aug 2005 13:23:23 +0200 (MEST)
Old-Date: Wed, 3 Aug 2005 13:23:23 +0200 (MEST)
From: zucker4(a)gmx.net
To: berlin-request(a)vovka.de
MIME-Version: 1.0
Subject: =?ISO-8859-1?Q?subscribe?=
X-Priority: 3 (Normal)
X-Authenticated: #10973817
Message-ID: <20701.1123068203(a)www28.gmx.net>
X-Mailer: WWW-Mail 1.6 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Diagnostic: Already on the subscriber list
X-Diagnostic: zucker4(a)gmx.net
X-Envelope-To: berlin-request
Date: Wed, 3 Aug 2005 13:23:24 +0200 (CEST)
--------------------------
The subject line is "Subject: =?ISO-8859-1?Q?subscribe?=" instead of
the "Subject: subscribe".
It seems to be the problem only of this provider.
What can be done in such case?
Other software(Mozilla Mail /Thunderbird) do not worry about this "=?ISO-8859-1?Q? ... ?="-line
and displays the Subject-Line correctly.
Ist it a kinda new RFC-Standard for the Subject-lines - to put the encodings information in it?
Or are the programmers of this freemailer simply stupid?
Greetings
Vladimir-
re tmp.lock
I had verbose on. This is the output from a single attempt to subscribe:
procmail: [9466] Wed Jul 13 10:29:52 2005
procmail: Assigning "minbounce=3"
procmail: Assigning "auto_off_threshold=28672"
procmail: Assigning "off_threshold=24476"
procmail: Assigning "reject_threshold=30730"
procmail: Assigning "submit_threshold=28672"
procmail: Assigning "foreign_submit"
procmail: Assigning "auto_help=yes"
procmail: Assigning "moderated_flag=yes"
procmail: Assigning "X_COMMAND_PASSWORD=********"
procmail: Assigning "RC_LOCAL_SUBMIT_20=rc.local.s20"
procmail: Assigning "RC_CUSTOM"
procmail: Assigning "INCLUDERC="
procmail: Assigning "LOCKFILE=tmp.lock"
procmail: Locking "tmp.lock"
procmail: [9427] Wed Jul 13 10:29:55 2005
procmail: Locking "tmp.lock"
procmail: [9466] Wed Jul 13 10:30:00 2005
procmail: Locking "tmp.lock"
The last two lines have now repeated for 4 hours. 4,441 procmail processes
have been started and we're still going.
Seems fairly obvious to me that there's a problem here.
I understand the basic principle of locking the file. What I don't
understand is how to stop the endless repetitions of start process -- lock
... start process -- lock. It would be good to know what caused this problem
and how to fix it.
Thanks,
Kim
I have forms that automatically process subscribe/unsubscribe requests using
x-command. For the past few days, I've been getting an error I've never seen
before.
No changes are made to the dist file. Nothing appears in request. Hundreds
of processes are created, and my smartlist log shows this entry, apparently
every time a process is created:
procmail: Locking "tmp.lock"
Can anybody tell me what the cause and cure are for this?
Thank you for any help you can provide.
Kim
Rich noted:
> > Has anyone experimented with or implemented something like this?
>
> Not with metamail. I used stripmime because it was much more
> straightforward for me.
>
> Rich
I'll take a look at stripmime, too - thanks.
--
Rick DeMattia <rad(a)nshore.org>
The secret of the universe is|^&*||x|NO CARRIER
