All,
I am trying to use rc.local.s10.mhonarc from
http://www.ha-schneider.de/software/smartlist/
to set up an archive for a mailing list.
I have renamed rc.local.s10.mhonarc to rc.local.s30 and added following line to rc.custom
RC_LOCAL_SUBMIT_30 = rc.local.s30
rc.local.s10 and rc.local.s20 are already in use and since I do not know how to merge the recipe in rc.local.s10.mhonarc with either of the two, I renamed it to rc.local.s30 and added a new line in rc.custom.
Could someone please help me understand as to how it all works.
Thanks
Nishi
The following is a sample of the results of a search that I receive by email.
This there a way to hide the line number?
ARCHIVE egrep august latest/*
BEGIN---------------cut here------------------
latest/10:16:Monday, August 27, 2001
latest/11:16:Tuesday, August 21, 2001
latest/12:16:Wednesday, August 29, 2001
END-----------------cut here------------------
Thanks for your help!
Alan,
hi!
how can i modyfiy the text for the automatic subscribe/unsubscribe-mail?
The possibilities of a *subscribe.txt*-file in my folder are not enough for
me. I want suppress the information about the transmited data and translate
the rest of the mail to german.
TIA, martin
--
"Who needs horror movies when we have Microsoft?"
- Christine Comaford, PC Week
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
Now I am setting up Smartlist with qmail (on a RH mamchine).
qmail is installed and tested.
Previously I only copied Smartlist over from a similar platform (RH
Linux). Now I decided to install from the source:
I unpackaged SmartList-3.15 over procmail-3.22 (I cannot find
procmail-3.15, thus by tweaking the folder name I managed to have them in
the same dirrectory "procmail-3.15").
Now when I run
> cd procmail-3.15/SmartList
> sh install.sh /home/slist
it spit out endlessly the following line:
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
...
that evenually I had to kill the process.
Is it a version problem or else?
Zhiliang
Good day all!
We are getting an error in the logs:
../.bin/extraddr: subscription request from who(a)domain.tld
who(a)domain.tld - assigned cookie s03261058491490
sed: -e expression #1, char 4: Unexpected ','
Would this refer to the comma in the maxcookies line near the bottom of
confirm_add? How to fix?
$cat $confirmtxt
$echo ""
$rm -f _dummy_ `$ls -td cookies/* | $sed -e '1,'$maxcookies' d' `
$sed -e 's/^/>/' $tmprequest
) | $SENDMAIL $sendmailOPT $authaddr
I don't know enough about sed (find all shell hard to grasp), but other
programming experience tells me the two sets of ' are ambiguous or
confusing. Is this what was meant - a delet range 1-to-maxcookies - okay to
drop the inner quotes?
$sed -e '1,$maxcookies d'
Many thanks in advance for any assistance.
Jo
Jim, Bart, Cary,
Thanks for the responses. I had to be away for a couple of days to take
care of other stuff, which had the benefit of giving me some distance
from the problem, too.
Yes, it appears to be related to the match operator and greedy/stingy
behavior.
Here is a solution I've come up with which *SEEMS* to work:
:0 fhw
* ^content-type:(.*\<)?multipart.*\<(boundary=\/[^"; ]+|
boundary="\/[^"; ]+)
{
TESTVAR = $MATCH
}
Since I have two mutually exclusive cases, quoted and unquoted, only one
of the two branches will match at any time:
boundary=\/[^"; ]+ or boundary="\/[^"; ]+
For a quoted string, the first branch will stop matching on the first
character after the \/, but the second branch should match until the
trailing double-quote is reached.
For an unquoted string, the first branch matches the complete boundary
string, while the second branch will not match to the left of the \/.
It works on well behaved samples with both quoted and unquoted boundary
strings but doens't handle all possible whitespace characters after the
string.
I could try to create a [...] expression with all possible characters
(except ; and " and <space>), but it would break if I miss even one
oddball character that might turn up in a boundary string. The following
looks to be adequate after analyzing a few thousand recent list mails
and testing with several clients and webmail systems...
[-+=/_.:A-Za-z0-9]
Substituting this positive bracket expression in the above recipe
(twice!) seems to work decently well as long as the strings behave
themselves.
Instead of this, it would make the most sense to match anything except
double-quote, semi-colon, or whitespace, except that we don't seem to be
allowed to use control characters, POSIX character classes or shortcuts
( e.g.: [:space:] or \s ) inside bracket expressions in procmail? This
seems to be impossible to do:
[^";<something that stands for all whitespace characters>]
I wish I could understand why?
Cary, you say that procmail doesn't allow escaping of control
characters. Does that mean things like \f \n \r \n \t \v will not be
understood in any context? Or just inside bracket expressions? Can you
or anyone point me to where that's documented, please?
Thanks,
Mike D.
I'm doing this on the system I have this e-mail account with,
eskimo.com. It's an old-fashioned geek's ISP, where I have a shell
account on a shared server, rather than a slice, or fancy web-thingies
to handle everything. They're running up-to-date procmail, smartlist
and sendmail.
I've asked support if there are any local configuration considerations
that might be affecting things. I should have a reply in a day or so.
The issue I have is things that ought to work don't, and I suspect
something about the context prevents it, or else I've missed something
I'm supposed to be doing, like escaping characters or putting ticks or
quotes around the regex... though I've not seen any examples that tell
me I should.
I'm trying to extract the boundary string from multipart MIME formatted
messages into a variable so I can do futher processing. This is
happening in rc.local.s00.
The header data will look like a variation on these examples:
Content-Type: multipart/alternative
boundary="a=bunch-of/stuff:and_random=junk"
Content-Type: multipart/alternative;
boundary=a=bunch-of/stuff:and_random=junk
What's reliable is Content-Type: multipart/* occurs on one line; the
boundary string will not contain quotes, backslashes, semicolons or
whitespace; the boundary string is either at the end of the first line
or on a line of its own; whether multi-line or concatenated, the
various pieces are separated by semicolons or whitespace.
As I understand it, the egrep for procmail recipe condition lines
assumes the c flag, and treats multi-line headers as single lines.
Thus, the following recipe works up to a point, even though the '.'
token should not ever match a newline.
I know there are recipes out there for doing this, but I'm stumped as
to why the following approach doesn't work (yet) and am trying to learn
the reason before I just give up and do something else.
Here's the basic strategy:
TESTVAR = 'some initial value'
:0 fhw
* ^content-type:.*multipart.*boundary=\/.*
{
TESTVAR = $MATCH
}
In the two examples above, it yields the following in $TESTVAR:
Example 1) "a=bunch-of/stuff:and_random=junk"
Example 2) a=bunch-of/stuff:and_random=junk
One initial oversight of this recipe is that it won't deal with a multi-
line header where there's another sub-header after the boundary= line.
It would just tack on the rest of that header, right to the end of the
last line. It ought to be easy to stop at the end of the boundary
string, but it's not, as I explain below.
At this point, I start to hit a brick wall. Nothing that's supposed to
work seems to work in this context...
I'd like to get rid of the quote marks. This recipe will strip the
leading quote, at least, but will not match anything if the boundary
string is unquoted, as it is on many messages:
:0 fhw
* ^content-type:.*multipart.*boundary="\/.*
The following ought to solve that problem by matching either 0 or 1
occurrences of the double quote after the equals sign:
:0 fhw
* ^content-type:.*multipart.*boundary="?\/.*
It doesn't. The string still shows up in $MATCH and $TESTVAR with both
quote marks intact. WHY?
Every other syntax I've tried (dozens of them!) refuses to function in
this context, either not changing the value of TESTVAR, setting it to a
null string, or blithely ignoring the quote mark and letting it go
through into $MATCH.
After the \/ token, it seem to be TRIVIAL to match any character that
wasn't a quote, semicolon or whitespace, and that would capture the
entire boundary string... AND solve the multi-line problem -- but,
again, absolutely none of the applicable syntax wants to work here.
So, what is it about the context that refuses to let me do an elective
match on the leading quote mark and prevents almost anything except .*
from working after the \/ ? There must be something pretty basic I'm
missing here, but, damn! I've been studying this for a week and a half
steady, and I have *not* seen an explanation for this behavior.
Am I missing something else, obvious or not? Does it seem like
something in my environment is screwing it up?
I have not turned on logging yet, but will shortly. Am I right to
assume procmail logging is more important than smartlist's for this?
Any help or insight would be appreciated.
Thanks,
Mike D.
[Mike Devour, Citizen, Patriot, Libertarian]
[mdevour(a)eskimo.com ]
[Speaking only for myself... ]
I've been running SmartList for a lot of years now, mostly never need to touch it. But I've needed to move to new hardware for quite a while -- just hadn't gotten around to it. Thanks to Santiago for pointing out that SmartList is available as a package for Debian! That makes the move easier. Also, the Debian package has the Confirm package installed -- installing Confirm is another thing I should have done a while ago. Many thanks to Werner for all your good work on Confirm.
Question -- The Confirm emails come From: SmartList <list-request(a)foo.com>, while the regular subscription reply just comes From: list-request(a)foo.com. Where is the setting to control the display name, so I can replace "SmartList" with something else, or eliminate it?
Since I've never used Confirm before, I haven't run into this in the past, and I was hoping someone could point me to where the setting is located.
Thanks!
Merrick
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/