Re: [Mailman-Users] attachments dir question
Thanks Stephen. I was wrong - an attachment directory was indeed created for my second message as well. In looking at the creation dates for that list, they always seem to be created sometime the next day after 3:00 am. Since the only cron job I run at that time for Mailman is senddigests, I guess that is what creates it. So I guess the difference between my message being scrubbed, and a message on another list not being scrubbed, is the MUA (as the content-filtering is the same on all of our lists (ie never touched from the original defaults)). And because filter_content is set to NO on all lists, I don't imagine we're doing any filtering anyway. As for the listname.mbox file, there isn't one. That directory has always been empty. The attachments dfirectory is very large though. - jim - On Wed, May 5, 2010 at 7:44 PM, Stephen J. Turnbull step...@xemacs.orgwrote: Savoy, Jim writes: I was wondering what it is that determines if a message has scrubbed attachments. The options you have set for filtering and the MIME structure of the message does. One possible explanation of your observation is that for some reason the first message had only a text/html part, and Mailman scrubbed it, while the second had both text/plain and text/html parts, so that the text/plain part was retained as is and the text/html discarded entirely. why would there be inconsistencies between the message I posted just now and the one I posted 2 days ago? Most likely, because the structures of the messages created by your MUA were different. To determine for sure what's going on we'd need to know the exact settings of your content filtering options, and see the raw messages including all headers from the mailman/archives/private/LIST.mbox/LIST.mbox file. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] attachments dir question
Hi all - I am running Mailman 2.1.5 (still!). I was wondering what it is that determines if a message has scrubbed attachments. For instance, a couple of days ago, I sent a simple message to one of my lists - just a sentence or two of text, and it created a directory under /archives/private/listname/attachments for it. I looked in there and displayed the HTML file it created, and all it had in it was my text and a few BRs. I used the same mailer today and sent out another simple text message, and no directory was created under attachments this time. And then I compare my list (not-archived, digestible, no digest members) to another identical list with plenty of posts sent to it (according to /logs/post), and there is no attachment directory at all. I just assumed it was the mailer I am using that determines if part of it should be scrubbed, but if that were so, why would there be inconsistencies between the message I posted just now and the one I posted 2 days ago? Thanks in advance. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Mark Sapiro wrote: That would be the To: header of the reject notice. Yes. That is the message I am analyzing. Mailman sends a multipart/mixed message with two parts - a text/plain part containing the reject reason and a message/rfc822 part containing the post as received by Mailman. It is the message in this message/rfc822 part that is what Mailman saw. If that is not the original post, but somehow got wrapped by Exchange in the forwarding process, you'll have to take that into account. Got it. Under the message/rfc822 part, the To: header says test.acco...@uleth.ca. So in theory, it should accept this message. I will re-analyze everything to make sure there are no typos. Thanks. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Mark Sapiro wrote: Did you put 'Foo' back in the GLOBAL_PIPELINE prior to 'Moderate' and restart Mailman? I did. What happens when you mail to test.account? Is the mail rejected by Mailman? Does the To: header in the mail in the reject notice contain 'test.account'? Yes, it is rejected. And the To: header does not come from test.account but rather from the actual sender. Inside of what looks like an Exchange attachment, I can see the full original message, with the To: header displaying test.account. So it looks like the Exchange server may be wrapping up the original message and obscuring the headers. Since that regexp 'test.account' is not anchored and is searched for by the re.search() method, it means if the string 'test' in any combination of upper/lower case followed by any single character (the . matches any character) followed by the string 'account' in any combination of upper/lower case is in the To: header, it will match. OK - that's close enough for me. I don't really need to be that specific anyway because my test.account (not the real name of the account) is quite a unique and unusual name. I have just received word from the owners of this list that they no longer care about me doing this (they have just opened the list up to anyone) so I probably won't spend too much more time on it now, especially if the Exchange server (which I don't have access to) is obscuring the original headers from Mailman. Since we have exim as a front-end to Mailman, I can probably just do some sort of a re-write in there instead. But thanks anyway. It was an interesting foray into Python for me! - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Hi Mark,
I got it to compile properly, but it is still not working.
I made the following changes in Foo.py:
import re
cre = re.compile('test.account', re.IGNORECASE)
def process(mlist, msg, msgdata):
if mlist.internal_name 'abc-l':
return
if cre.search(msg.get('to', '')):
msgdata['approved'] = 1
# Used by the Emergency module
msgdata['adminapproved'] = 1
Goal: The account test.acco...@uleth.ca is set to forward mail to the
mailing
list ab...@uleth.ca, which should accept it, regardless of who sent it
to
test.acco...@uleth.ca (all other mail to this list from non-members will
be
rejected).
You also wrote:
if the contents of the To: header of the message matches the regexp in
re.compile() case insensitively, then the approved and adminapproved
flags will be set in the message metadata and the message won't be
subject to any holds.
So when you say matches the regexp do you mean exactly matches? And
if so,
would your regexp work? Or do I need a more specific or accompanying
regexp in
the re.compile statement? eg
cre = re.compile('test.acco...@uleth.ca', re.IGNORECASE)
Thanks.
- jim -
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Mark Sapiro wrote:
What you need is a custom handler. See the FAQ at
http://wiki.list.org/x/l4A9 for how to install one.
Thank you. Done.
In your case, the handler is very simple - just 9 lines.
import re
cre = re.compile('unique\.name', re.IGNORECASE)
def process(mlist, msg, msgdata):
if mlist.internal_name 'abc-l':
return
if cre.search(msg.get('to', '')):
msgdata['approved'] = 1
# Used by the Emergency module
msgdata['adminapproved'] = 1
Of course, you adjust the regexp 'unique\.name' and the list name
'abc-l' to suit. The handler needs to be in the pipeline before
Moderate.
OK - I made a file called Foo.py and put it in /Mailman/Handlers.
I then inserted this module right before 'Moderate' in the pipeline (I
editted
Defaults.py for this - just as a temporary measure to see if it would
work).
I will remove this and add a line to mm_cfg.py later.
I then stopped/started the Mailman processes (not sure if that's
necessary, but
I did it anyway). Now the test email I sent is stuck in the shunt queue
and this
is in the errors log:
File /Mailman/Handlers/Foo.py, line 2
cre = re.compile('unique\.name', re.IGNORECASE) def process(mlist,
msg, msgdata):
^
SyntaxError: invalid syntax
It didn't line up well in this email message, but the carat (^) is
positioned
under the 'f' in the def.
I know diddly about Python (and not that much more about Mailman,
really) so I'm not
sure how to fix the problem. Any ideas? Thanks!
- jim -
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
I also just noticed that the shunt queue started to fill up with messages for other lists as well, so I quickly removed the line I had inserted into Defaults.py, stopped/started the Mailman processes, and successfully unshunted everything. I was hoping the code would only affect the one list I am messing with, but I guess if there is a syntax error in it, it breaks the entire pipeline (maybe). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
I also just noticed that all of the other handlers have an accompanying .pyc file, but my Foo.py does not. Perhaps that 'c' stands for compiled and I was supposed to compile the code first? (probably seems obvious to someone familiar with Mailman/Python). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Mark Sapiro wrote: You used some kind of word processor to create foo.py that concatenated lines 2 and 3 into a single line. Your Foo.py file must be just like my original example with lines 1, 2 and 3 at the left margin, lines 4 and 6 indented 4 spaces and lines 5, 7, 8 and 9 indented 8 spaces. These words you are saying are all true. I just cut your code in Outlook and pasted it in vi. I will try it again with the indenting you suggested (reminds me of Fortran!). Thanks. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Depending on the options set in vi, it can do horrible things to indentation when you paste things in :( I just looked at your original posting (using Outlook) and line 3 is not indented, but rather continuous from line 2, and the other indents are in columns 5 and 9 (not 4 and 8). I shall try viewing it with other mail clients, just for kicks. But now that I know that whitespace is critical in Python, I will be more careful. Python is not at all like Fortran, In Fortran (at least through Fortran IV - I never did much with Fortran 77 and nothing beyond that) white space except for line endings is totally insignificant. True, you have some formatting restrictions like positions 1 - 5 for statement numbers, 6 for continuation and 7 - 72 for statements (although some compilers relaxed these), but consider that the compiler's parser/tokenizer doesn't know whether I was loosely referring to Fortran reserving certain columns for certain things. I barely remember it at all (that was back in my pre-Commodore64 (PEEKin' and POKEin' anyone?), punched-hole card days). - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] regexp help
Sorry to break the thread on this (my previous message didn't go through, so I guess this list is being moderated now). Anyway, just wanted to say that I fixed my regexp problem. I am running an older version of Mailman, so tried this instead: \nfrom:.*unique.name and it worked! - jim - - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] regexp help
Hi all - I am trying to have all of the mail sent to a certain email account automatically forwarded to a moderated mailing list (moderated to everyone accept the mail from this particular email account). So I created the account (we'll call it unique.n...@some.domain) and set up the mailing list (we'll call it ab...@some.domain). The only way I can think of getting the mailing list to accept the forwarded mail is to use the spam filters under [Privacy Options]. I create a new Spam Filter Rule like so: /^.*unique.name.*$/ (I will make this more specific later) But that doesn't seem to work. Mail sent to unique.n...@some.domain returns the error message you are not allowed to post to this mailing list to the original sender. I assumed that unique.name would be somewhere in the email headers, which is what the Spam rules are filtering on, right? Any ideas what I am doing wrong? Thanks. - jim - - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
I wrote: Anyway, just wanted to say that I fixed my regexp problem. I am running an older version of Mailman, so tried this instead: \nfrom:.*unique.name and it worked! Looks like I spoke to soon. It actually did not work. I have also tried \n.*unique.name and that failed as well (I assumed that would just compare to all of the headers, as I am not sure if from was the one I should be looking at). Any ideas? (I am running mailman 2.1.5 still). - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
Jim, try from: .*@(?!.*uleth.ca) The 'anything before the @ sign' is obvious, but the '?!.*' is to test for possible machine names, in case they're there. Nope. That failed. I added a \n to the front of this and that failed as well. I didn't think I would have to make any accommodations for the machine names though because I have given this account a very unique name, so my goal here is just to accept the mail if that unique.name is found in any header at all. This is why I was sure that: \n.*unique.name would be good enough. But it was not. I probably don't really understand what this filter is looking for though... - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
George Booth wrote: Why don't you just add the email account to the list, set it for no mail, and set it so it's unmoderated? Well that was the first thing I did, but that didn't work because the mail is not technically coming from that account. It's coming from whoever originally sent it (the unique.name account just forwards). That is why I thought I could try to circumvent it by using the spam filter to just search all of the headers for an occurance of unique.name. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
I looked at one of the actual headers (I am not posting the actual name I am using as we don't want anyone to mail to it just yet!) but it looked like this: To: Name, Unique unique.n...@uleth.ca Since there is a dot in the username, I thought maybe that was fouling up the regular expression, so I tried all of these: \nto: .*unique\.name to: .*unique\.name to: .*unique to no avail... - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] regexp help
CNulk writes: Hi Jim, I may be completely wrong (heck, wouldn't be the first time), but why not have your unique.name address be an alias to a simple bash/perl/etc. script which simply accepts the email message, rewrites the message to be from the unique.name address, and sends it on to the list. When the list sees the message, it will appear to be from unique.name and the standard mailman moderation and message acceptance rules would apply. I had to do something similar for a different email distribution package to get around a software limitation. It should work unless you really need the from address to be from the actual sender. Yep - I could do that. Have exim rewrite the headers before it sends out the message, but the people on the mailing list do want to know who the email originally came from. They just don't want everyone to have access to their mailing list, just this one account (an inquiries-type of account). I just re-read Mark's comments, and he says: --- So assuming that what you want is to bypass the other header_filter_rules, you need to add new item before the current rule 1 so the new rule becomes #1. Then the new rule 1 regexp should be ^from:.*(\s|)some\.person\.n...@gmail\.com(\s||$) and the action Accept. --- and that is exactly what I want to do - bypass the header_filter_rules. But I am afraid I don't quite understand this advice, Mark. How can I make this spam rule supercede other rules (like the one that says the list is moderated). There is no add new item button when you haven't got any spam rules. That only comes up when after I create me first rule, which is not superceding the moderation rule. I should probably not say anything else until Mark logs in. He's probably looking at this huge chain and wanting to crack our skulls together like Moe. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] New crontab query: senddigests
Jim Savoy wrote: I did check out a couple of the lists that had outstanding digest.mboxes and found that they didn't have any subscribers with the digest option checked. Mark Sapiro wrote: But, assuming this is a more or less standard Mailman (2.1.5), even if no one is subscribed to the digest, when cron/senddigests runs, the digests should still be prepared and the digest.mbox unlinked, even if there are ultimately no recipients. The only thing that affects this is if the list's digestable setting is No, and all this does is keep from creating the digest.mbox in the first place. All of our lists are digestable (that's the default). I did run one of your scripts once-upon-a-time to see how many digest members we had, and there were a few dozen. Unfortunately, I'm still in the state that the only time a digest goes out is when it exceeds 30K in size. Did you run it from cron or by hand. If by hand, did you run it as 'mailman' and did it produce any output? If from cron, and it produced any output, the output was probably mailed to 'mailman' which is probably the 'mailman' list, and where does it go from there? Ran it by cron. I don't see any activity at all when it runs (when I ran the checkdbs program, python lead the way when I did a top, but nothing seems to happen when I run senddigests). There was also no output sent to the mailman mailing list (I am the owner and only subscriber on that list, and it accepts mail from anyone). Nothing in the Mailman logs either. Note: it is a good idea to put a MAILTO= at the beginning of Mailman's crontab to direct any mailed output to a good place. There is normally only mailed output if something goes wrong. Can you give me the exact syntax of that Mark? I am not sure what you mean or how I would do that. I did a man on cron but don't see anything there about MAILTO. Thanks. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Mark Sapiro wrote: Thanks for the MAILTO info. Try su mailman cron/senddigests Boom. That worked. All (but 3) of the 501 digest.mboxes are gone now and I got a delivery from the list I am a digest member of. It ran rather quickly too (1 minute flat). If/when we resolve this, I guess I'll have to start a new thread on why those 3 didn't go away. :-) So obviously, this has something to do with this being run from cron. You would think all of it would fail though (the checkdbs stuff runs fine from cron). It probably won't be any different, but it's worth a try. If it does nothing, what is the contents of the cron/senddigests script. There appears to be something wrong with it. You could compare it to http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/annotate/419/cr on/senddigests to see if you have any modifications. These were identical. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Mark Sapiro wrote: Try su mailman cron/senddigests Since we are trying to troubleshoot a very mysterious problem, I should include all of the information I have. When I ran senddigest by hand (as user mailman), I did get a warning: [mailman cron]$ ./senddigests /mail/mailman/pythonlib/korean/c/euc_kr.py:24: RuntimeWarning: Python C API version mismatch for module _koco: This Python has API version 1012, module _koco has version 1011. import _koco It carried on anyway after that, but perhaps that is what causes cron to fail. As I said, when it is run by cron, I don't see anything when I do a top and there doesn't seem to by any activity at all, so perhaps it's instantly failing because of this Python koco warning. I didn't get anything mailed to me when I added the MAILTO though... - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Jim Savoy wrote: So obviously, this has something to do with this being run from cron. You would think all of it would fail though (the checkdbs stuff runs fine from cron). Hmmm - the above may not be true. Checkdbs did not run this morning. Mark Sapiro wrote: What does crontab -u mailman -l show? I think you nailed it. This is different from cron/crontab.in. The latest changes I made are not reflected. So am I supposed to do the: cd mailman/cron crontab -u mailman crontab.in every time I make a change to the crontab.in file? I believe that was the very first question I asked when I started this thread. :-) - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Savoy, Jim wrote: If/when we resolve this, I guess I'll have to start a new thread on why those 3 didn't go away. :-) Mark Sapiro wrote: Are they for lists that had a post arrive during or immediately after the time the digest was sent? In other words do they just contain messages waiting for the next digest? Two of them yes, but the other two no. I will deal with this later and Start a new thread if they don't go out tomorrow. What does crontab -u mailman -l show? I re-ran the crontab -u mailman crontab.in and my changes have been reflected. The old edit-the-source-code-and-forget-to-recompile problem! All is well now. Thanks for your patience. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Savoy, Jim wrote: Two of them yes, but the other two no. Mark Sapiro wrote: For the two old ones, be sure to check the list's digest_send_periodic setting. Right. That was the difference. They are the only two that say NO to this query. Thanks for everything, Mark. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
Jim Savoy wrote: I am not all that familiar with cron. Is that crontab -u mailman crontab.in something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those). Mark Sapiro wrote: As you discovered it puts the commands from crontab.in into the mailman user's crontab which is likely /var/spool/cron/mailman. It stays there across boots. This is the correct place for the mailman crontab. The ones in cron.d are a slightly different format. Got it. And yes, there is an entry now in /var/spool/cron for mailman. But note, that almost all the jobs in crontab.in should be run. They all have a function and the only one you can safely ignore is gate_news if you aren't running any lists with a news-mail gateway. I will run more of them eventually. Since we hadn't run any of these in years (ever, in fact) I thought it might be a bad idea to release the hounds all at once. The madness that took place with the -1 pending requests confirmed that. By the way - thanks for your excellent script. Saved me and the owners the hassle of fixing the minus-one problem (243 lists were in that state and they are all fixed now!). For the others, you need to at least read the comments in crontab.in and understand what the job does before deciding not to run it. I will probably leave the gateway news stuff out forever. And also the password reminder thing, as we don't want to bombard our students with more info (most of our 900+ lists are NOT opt-in, and most are read-only, and we rotate thousands of different users through these lists each semester, without their knowledge). I probably won't run the disabled users reminder either, for the same reason as above. So that just leaves two more things to run via cron: digests and archive gzipping. I will run the digests thing next and if that goes smoothly, unleash the archive gzipping. This issue only existed with lists that were migrated from pre 2.1.5 to 2.1.5 and only exists in 2.1.5. Precisely our situation. Thanks. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
Jim Savoy wrote: I will probably leave the gateway news stuff out forever. And also the password reminder thing, as we don't want to bombard our students with more info... Mark Sapiro wrote: Fair enough, although the sending of reminders is a list option. You can set DEFAULT_SEND_REMINDERS = No Yep - that is the default we have set for all lists, so passwords have to be found by the user themselves (through the links in their email) or by sending me mail. So I guess the downside to not running that cron job is that if an owner changed that setting, nothing would happen as far as a monthly reminder goes. I probably won't run the disabled users reminder either, for the same reason as above. This has a side effect which may not be important in your environment. If bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set 0, when a user's bounce score reaches the threshold, the users delivery is disabled by bounce and the first notice is sent. From there the entire process of sending subsequent notices and removing bouncing members from the list is don by cron/disabled, so if you have bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set 0 and you don't run cron/disabled, the members who have been disabled by bounce will never be removed. I see. OK I will add this one in a bit later on to clean up some of these lists. Some of our more ancient lists that are not updated by cron (and have most likely been abandoned) have nothing but bad addresses subscribed to them. Now I know why! So that just leaves two more things to run via cron: digests and archive gzipping. I will run the digests thing next and if that goes smoothly, unleash the archive gzipping. Actually, gzipping of the archive is the one I don't run. I won't either then (!). I was only considering running that to save space anyway, but I can probably free up lots of archive space by deleting some abandoned lists. Thanks Mark. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] New crontab query: senddigests
Hi all, I started a new thread for this as it no longer applies to cron, but rather digests. I just ran the senddigests cron option (again, for the first time ever) but it didn't seem to do anything. I can't really understand what it does anyway (from the description given). All of our lists allow users to select the digest option (digestable=yes), and the digests are sent out when the 30k threshold is reached (digest_size_threshold=30). The next option asks if a digest should be sent out DAILY when the threshold isn't reached (digest_send_periodic=yes). So that is how all of our lists have been set all this time, and the digest mails seem to have been working, despite not having run anything in crontab. The crontab entry for senddigests says: # Noon, mail digests for lists that do periodic as well as threshhold delivery. 0 12 * * * /usr/bin/python -S /mail/mailman/cron/senddigests Not sure what this does differently, other than maybe force the digests to go out at noon, rather than the vague DAILY option from above. Can anyone share any light? I just ran it and nothing seemed to happen. Thanks! -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Mark Sapiro wrote: The digest messages are accumulated for a list in a mbox format file lists/LISTNAME/digest.mbox. When a new message arrives and is added to digest.mbox and the size of digest.mbox is now greater than the list's digest_size_threshold, a digest is sent at that time for that list, and the digest.mbox is removed. So, digests based on digest_size_threshold will work whether or not cron/senddigests is run. Right. I'm with you so far. Running cron/senddigests will send a digest for any list which has a digest.mbox file and for which digest_send_periodic=yes regardless of how big the digest is. This is where we part ways. Without the senddigests cron job, isn't the above statement also true anyway? Because the digest_sent_periodic=yes setting also doesn't care if the digest.mbox is over 30K. It just sends out a message daily (what time, I do not know) whenever a digest.mbox exists. So my question was: Is the only reason you run the cron job in the first place, Is to force that daily run to a specific time (eg noon)? I say this because I have never ran that cron job, but I'm pretty sure everyone gets their digests anyway. So, if you ran it and nothing happened, there were no such lists. This seems unlikely. Are you sure no digests were sent? I guess it's possible no digest.mboxes exist. There aren't that many digest users here. And yes, running it at noon daily forces the periodic digests at noon, but you can chose another time. I prefer mine to go over night so I run cron/senddigests daily at 03:30. I will probably set it up to run at 3:00 am as well. I just ran it at 12:48 today so I could watch it (do nothing (!)). I suppose I should change the setting that sends a digest if it exceeds 30K too (change it to 1000K or something, so that people never get more than one digest-per-day), and just use the cron job to send once a day, regardless of size, at 3:00. I just am not clear on why I need a cronjob to do that, unless its only purpose is to force a specific time. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Mark Sapiro wrote: The digest messages are accumulated for a list in a mbox format file lists/LISTNAME/digest.mbox. When a new message arrives and is added to digest.mbox and the size of digest.mbox is now greater than the list's digest_size_threshold, a digest is sent at that time for that list, and the digest.mbox is removed. Hmmm. Removed huh? Maybe our digesting situation isn't so healthy afterall. I just did a recursive listing of the /lists directory and there are quite a few digest.mboxes in there! A lot of them have really old dates on them, and NONE of them is over 30K. So I think the problem we have here is that our digests ONLY go out when the digest.mbox exceeds 30K, and not daily, regardless of size. Maybe that's where the senddigests cron job kicks in. That still doesn't explain why they are all still there and nothing was delivered when I ran the cron job at 12:48 today... -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] New crontab query: senddigests
Mark Sapiro wrote: You need the cron job because nothing else in Mailman sends digests periodically. The only other mechanism sends a digest when the list's digest.mbox exceeds a certain size, which may not happen for weeks on a low traffic list. Ok I understand 100% now. The only reason I kept telling you that I am pretty sure people are getting their digests, is because I went to someone's office once and saw that they had some digests in their inbox. And I personally forced one of my own tests lists to get a 30K digest.mbox so I could see what a digest delivery looked like. In looking over my recursive listing closely, I see that there are 501 total digest.mboxes out there (!). All of them are 30K or under. That still doesn't explain why they are all still there and nothing was delivered when I ran the cron job at 12:48 today... Are you sure digest_send_periodic is set to Yes for those lists that have old digest.mbox files? Absolutely. That is the default we set up and I just checked a bunch of lists to verify it. I did check out a couple of the lists that had outstanding digest.mboxes and found that they didn't have any subscribers with the digest option checked (as I said, very few of our users know about and use this feature) so perhaps nothing was delivered today because there was just nothing to be delivered. I take it a digest.mobx is created regardless of whether or not a list has any members using that option. So perhaps everything is fine and starting this daily senddigests cron job will be a seamless transition. Thanks! - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
Jim Savoy wrote: Reading this reminded me that I have a similar problem. All of our lists are set by default to be admin_immed_notify=yes, but the list owners only get a message when something new arrives (that is put on hold). They never get a daily reminder about the queued-up stuff. Is this a known problem for v2.1.5 (we will be upgrading to v2.1.12 this summer). I have no idea how long this has been going on, and only remembered it because I own one of the lists and realized that I only get the one warning. Mark Shapiro wrote: The daily summary is sent by cron/checkdbs. Does mailman have a crontab? Does it have an entry to run cron/checkdbs daily? Is crond running? Hi Mark, The answers to your questions are: yes, yes yes. But I don't think the person who installed Mailman many years ago ever did the crontab -u mailman crontab.in bit, so I just did it now. First I commented out everything in that crontab.in file except the checkdbs line, and set that to run immediately. It worked like a charm and sent out hundreds of reminders to all list owners. I am not all that familiar with cron. Is that crontab -u mailman crontab.in something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those). But I noticed that many of the reminders it sent out, pointing people to the admindb page were blank (ie there is nothing pending). So I'm not sure what that means. There aren't that many .pck files in /mailman/data and I am not sure where else it is pulling that false information from. The next run is set for 8:00 am tomorrow, but I might have to put it on hold until I find out why there are so many bogus warnings going out. If someone was to clear out a bunch of pending requests from the mailman/data directory just by deleting them, instead of doing it properly with the admindb web interface, would that cause this problem? If so, can I remedy this somehow? Any pointers would be helpful. I don't fully understand all of the workings of Mailman (like many of the others on this list - I just sort of babysit it and we've never had too many problems). Thanks! -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
Jim Savoy wrote: I am not all that familiar with cron. Is that crontab -u mailman crontab.in something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those). Jim Savoy answers himself: Before I get blasted with RTFMs, I did just read the manpage for crontab, and it says that each user may maintain their own separate crontabs, so I have now deduced that the command I ran activated that. I am still not sure if I am supposed to run that every time we reboot or if it's permanent (and if I change crontab.in (to comment out tomorrow's 8:00 am run, for instance) do I have to execute that command again?). Thanks. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
I think I have my phantom requests (eg the -1 request(s) pending) question answered. Googling it I see that Mark provided a fix, but also said that by going to that admin page once should clear it. That may save me from manually having to fix hundreds of lists. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Tricky admin_immed_notify problem
George Bannerman wrote: I've got a tricky problem on my mailman server. Right now, I have admin_immed_notify set to yes, but I'm not getting notifications when there are emails to approve. I'm also not getting the once-a-day # list moderator request(s) waiting either. Forward messages (individually) to: doesn't work. They all mysteriously stopped last Friday. I'm running Exim version 4.50 #1, Mailman 2.1.5, Python 2.3.5, and Linux version 2.6.16.13-xenU (Red Hat 4.0.2-8 running on Xen). Reading this reminded me that I have a similar problem. All of our lists are set by default to be admin_immed_notify=yes, but the list owners only get a message when something new arrives (that is put on hold). They never get a daily reminder about the queued-up stuff. Is this a known problem for v2.1.5 (we will be upgrading to v2.1.12 this summer). I have no idea how long this has been going on, and only remembered it because I own one of the lists and realized that I only get the one warning. Thanks! PS Our set-up: RedHat Enterprise Linux AS release 4 (Nahant Update 6) Python 2.3 Exim 4.69 Mailman v2.1.5 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Feature Request: Selective Mass Subscription
Brad Knowles wrote: Mailing lists are useful for a wide variety of things, but VT-type emergencies are not among them. Well we definitely know that it isn't the *only* solution (there are speakers and alarms and sirens and lights and cameras everywhere on campus). But it is just one more thing we can add to the basket of helpful security goodies. IIRC, just a day or two after that event, the CIO of VT came to this very list to ask for assistance in setting up Mailman for future cases like this, to send out emergency notices to everyone on campus. I must have missed that discussion. My understanding is that he went away very disheartened... I think his expectations were unreasonably high. E-Mail has its caveats, just like everything else. We had lots of meetings here after the VT (and Dawson College (Montreal)) attacks. I think everyone in security understood that none of their solutions were 100% guaranteed, but they also agreed that a saturation warning (by every means possible) was better than nothing. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Feature Request: Selective Mass Subscription
I guess we might be considered a fascist regime, but mass-subscribe is an invauable tool here at our university. Hardly any of our lists are opt-in (what a nightmare that would be for us - we need our lists up and populated on exact dates and ready to roll). We have class lists, lab lists, club lists, team lists, student lists, employee lists, security lists (some of which contain every soul on our campus - rarely ever used (never used yet, in fact, knock wood) for Virginia Tech-type campus-wide emergencies, etc). Many of the lists are automatically populated by cron on certain dates. There is very little involvement really, and all of the email addresses used to populate these lists are from our own domains. Sure we have the odd cranky professor or student who wants off, and we comply by setting their no-mail flag for them (unless it's the security list - they have no opt-out option on that one (and a few others) and that is written into their contract when they aquire an account from us). But in all these years, we've had very few complaints and everything has run very smoothly. We usually comply quickly if someone wants out, but we would never in a million years want people to have to opt-in! That would truly be a disaster (confused users, thousands of phone calls and help queries, and worst of all, porously-populated, inconsistent lists, with no guarantees that the right students got critical class/lab-related messages, etc). This invisible behind-the-scenes subscription method is the way to go for us. None of our Mailman subscribers even know they have their own list passwords, and we don't want them to! (I'd say about .01% are clever/curious enough to figure it out - I'm not implying that they are dopes, but rather they are just overwhelmed by the hundreds of new things they have to learn coming to a university - we don't want to pile on with even more stuff they need to know). I think that by running the server ourselves (and using only addresses from our domains) warrants this admittedly fascist attitude. Perhaps the safest way to handle this (in future releases) is to make mass-subscribe=NO the default setting for new installs, but not removing the option altogether. Thanks. - jim - PS I am pretty sure that this discussion only involves removing mass-subscribe from the GUI (and not the command line) but many of our lists require mass- subscribes on certain dates from the GUI as well (usually conducted by the departmental secretaries). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Muti-Mailman install
Brad Knowles wrote: Correct. The Mailman developers feel that forcing all replies to go back to the list causes much more harm than good. For a real-world example: We run several thousand lists here at our university (not all in Mailman) and we had a class list set up with replies go to list (the professor/owner had inadvertantly changed that setting from the default). One night, the professor sent out a message to the class list, giving them some instructions or something. Well one student on the list didn't realize this and thought the prof had sent the message only to her, basically targetting her (I guess she didn't look at the headers). She replied with a pretty personal message back to the prof, and it went to the entire class (180 students). She was so embarrassed and humiliated the next day to know that entire class had read her personal message and were talking about her, that she dropped the class. This is basically why you want people to specifically address the list, if they mean to send to it. Sure it was her fault, but it's wiser to use the strongly recommended defaults than to try to teach a revolving group of 15,000 students an email lesson. - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] archive/attachment preening
Hi all, We have 870+ mailing lists and about 20 gigs worth of stuff in the private/archives directory. I thought I would do a little spring cleaning, such as sending mail to list owners to see if they still want their lists. But I would also like to pare down the size of the archives directory, which have been allowed to grow wild, using cron jobs. Before I do that, I want to get assurance from this list that I fully understand how the archives are written. We are currently running Mailman v2.1.5 and we'll upgrade to v2.1.10 later this summer. Please confirm the assumptions I am about to make before I write the preening scripts for cron. I also want to write a bunch of scripts that look for certain information. 1) If a list is digestable and archiving was never turned on, then the archives/private/listname/index.html will contain only the originally-created file (which basically says No messages have been posted to this list yet, so the archives are currently empty). 2) If there is no mbox file in the /archives/private/listname.mbox directory, then the list has never had archiving turned on. 3) If a list is digestable but there is no attachments directory in /archives/private/listname, then the list has never had a message posted to it. 4) If the list is digestable, and archiving has never been turned on, then files in the archives/private/listname/attachments directory are only useful to already-existing subscribers who have digesting turned on (ie if I poll a list and it has no members subscribed as digest users, then it is safe to delete all files in the attachments tree). If all of my above assumptions are correct, my psuedo-code would do something like this: if (list is not archived and has no digest members) keep stuff in attachments dir for 1 month; if (list is not archived but does have digest members) keep stuff in attachments dir for 1 year; if (list is archived) keep stuff in attachments dir for 3 years; For the archived lists (we have about 150 of them) I will contact the owners first, to warn them that I plan to pare their archive down to 3 years max. If they protest, I will add them as an exception to the rule and skip over them during the cron job run. I know that there is more to be done with regards to reducing the size of archives (ie running arch --wipe on the editted, pared down .mbox file, but I will do that manually). For now I am mostly interesting in keeping the stuff in the attachments directories to a minimum. I realize that deleting stuff in /attachments breaks links in the archive and digest messages, but I think that is reasonable for the really old messages (provided the list owner concurs). One final question. I know that you can change a list's settings with /bin/config_list, but can you poll a list for settings? For example, you can use /bin/list_members -d to see which members of a list read in digest mode, but how can I find out which lists have archiving turned on? Or do I have to examine the archives/private tree to garner that kind of info? Thanks! - jim - -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
