Smartlist März 2010

smartlist@lists.rwth-aachen.de

10 Teilnehmer
12 Diskussionen

von Kapoor, Nishikant X

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

5 Jahre, 9 Monate

Archive egrep

von Alan Northam

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,

5 Jahre, 9 Monate

modify the subscribe/unsubscribe-mail

von Martin M=?ISO-8859-1?B?/A==?=ller

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

5 Jahre, 9 Monate

Archives?

von Mitchell Darer

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)

5 Jahre, 9 Monate

Re: does anyone find it ironic that smartlist mailing list is using Mailman?

von Charlie Summers

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

5 Jahre, 9 Monate

Re: setting up Smartlist with sendmail

von Zhiliang Hu

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

7 Jahre, 9 Monate

Syntax error in Confirm

von Jo for lists and groups

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

14 Jahre, 1 Monat

Followup on egrep regex problem...

von M.G. Devour

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.

14 Jahre, 1 Monat

Procmail egrep regex problem...

von M. G. Devour

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... ]

14 Jahre, 2 Monate

Display Name for Confirm emails

von Merrick Munday

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/

14 Jahre, 2 Monate

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Smartlist März 2010