From philb at philb.us Wed Sep 3 04:53:04 2003 From: philb at philb.us (Phil Barnett) Date: Thu Sep 4 20:28:34 2003 Subject: [Mailman-Developers] script In-Reply-To: <200308202335.51703.philb@philb.us> References: <200308202335.51703.philb@philb.us> Message-ID: <200309030353.04243.philb@philb.us> On Wednesday 20 August 2003 11:35 pm, Phil Barnett wrote: > Has anyone created a script they'd like to share that kills off the sobig > stuff sitting on hold? > > I'll make one but if there's one already out there, it'd save me some time. > I'm leaving on vacation Friday night. Lots to do 'till then... In the grand tradition of replying to myself... Here is the script I cobbled up. It deletes the worst of the muck. I let cron run it hourly. Watch the wrap. All lines should start with /bin/grep. ******************* 45 * * * * /home/mailman/data/cleanup.sh ****************** #! /bin/bash cd /home/mailman/data /bin/grep -H -m 1 -l -i '6.00.2600.0000' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'nigeria' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'winning notification' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: Invalid address' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: Warning! Virus found in message from you!' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'INTRODUCTORY OFFER' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: Undeliverable' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: PRECIOS DE TRANSFERENCIA' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: PROGRAMA MEDICO' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Amalgamated Bank of South Africa' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Prescription Weight Loss' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: URGENT ASSISTANCE' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: EXPO CAPACITATE EMPRESARIAL' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: DONATION FOR THE LORD' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: ALERT:' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 /bin/grep -H -m 1 -l -i 'Subject: your opinion is worth money' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 ****************** -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. From colin at mackinlay.demon.co.uk Wed Sep 3 22:31:27 2003 From: colin at mackinlay.demon.co.uk (Colin Mackinlay) Date: Thu Sep 4 22:37:58 2003 Subject: [Mailman-Developers] Adding unrecognised bounce formats? Message-ID: <004b01c3725a$59e85f90$0100a8c0@VENUS> How easy is it to add a new bounce format? My SMTP server sends all mai through the messagelabs virus scan servers and 550 bounces for unrecognised addresses typically come back in the format: This is the mail delivery agent at messagelabs.com. I was not able to deliver your message to the following addresses. : 65.54.166.230 does not like recipient. Remote host said: 550 Requested action not taken: mailbox unavailable Everytime a mailing or membership reminder goes out I get stacks of these! If someone can point me in the right direction with a few clues I can probably figure out what to do. Thanks Colin From shaikli at yahoo.com Thu Sep 4 23:48:16 2003 From: shaikli at yahoo.com (Nadim Shaikli) Date: Fri Sep 5 01:48:27 2003 Subject: [Mailman-Developers] script In-Reply-To: <200309030353.04243.philb@philb.us> Message-ID: <20030905054816.5410.qmail@web14908.mail.yahoo.com> --- Phil Barnett wrote: > On Wednesday 20 August 2003 11:35 pm, Phil Barnett wrote: > > Has anyone created a script they'd like to share that kills off the sobig > > stuff sitting on hold? > > In the grand tradition of replying to myself... > > Here is the script I cobbled up. > > It deletes the worst of the muck. I let cron run it hourly. Watch the wrap. > All lines should start with /bin/grep. > > ******************* > > 45 * * * * /home/mailman/data/cleanup.sh > > ****************** > > #! /bin/bash > > cd /home/mailman/data > > /bin/grep -H -m 1 -l -i 'nigeria' *.txt | /usr/bin/xargs rm >/dev/null 2>&1 How do you go about getting .txt files in your /home/mailman/data dir ? All I see are binary pck files (which one could run dumpdb on, but was curious to know). I'm running mailman-2.1.2. BTW, does deleting those .pck files have any baring on anything else (is it dangerous) ? Meaning, are there any adverse affects in doing that (is there a db that cares or anything) ? BTW: for those mailman users looking to incorporate spamassassin, do look into this site - it would be wonderful if mailman proper included these hooks natively in its future releases (or at a min include the info on the URL below on list.org or the FAQ). http://www.daa.com.au/~james/articles/mailman-spamassassin/ One thing this setup is lacking is "learning" - ie. the ability for spamassassin to play nicer with mailman (ie. to know what things you discarded to build-up a more profound history affecting future action). Regards, - Nadim __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From shaikli at yahoo.com Fri Sep 5 00:41:21 2003 From: shaikli at yahoo.com (Nadim Shaikli) Date: Fri Sep 5 02:41:32 2003 Subject: [Mailman-Developers] Message held emails In-Reply-To: <004b01c3725a$59e85f90$0100a8c0@VENUS> Message-ID: <20030905064121.11145.qmail@web14908.mail.yahoo.com> I've been meaning to mention this for awhile - its nothing major just something that's annoyed a number of us. Whenever an email is held, the list owner gets an email of the following format, ## Begin From: LISTNAME-owner@HOST.org Sender: mailman-bounces@HOST.org Subject: LISTNAME post from someone@somewhere.net requires approval [Mailman Header with some info] List: LISTNAME@HOST.org From: someone@somewhere.net [Actual Email] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm c67f31fde320f99a020ac08deca7b4185f27d24f Sender: LISTNAME-request@HOST.org From: LISTNAME-request@HOST.org If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. ## End (A number of things above were excluded - check a held email notification for details) A few notes -- 1. The title and the email's contents are redundant with regard to letting the admin know which list and from whom the offending email is from. 2. Replying to the email ought to go to 'LISTNAME-request' and not 'LISTNAME-owner' again (the Reply-To header needs to be added). 3. The instructions on what to do with the email are more important than the email itself (to an admin), so I'd put it right below the info-stage of the notification email. 4. The instructions are rather confusing at first. Why would I 'confirm' an email message. It would be best if the email reply to 'LISTNAME-request' was of the form, discard c67f31fde320f99a020ac08deca7b4185f27d24f reject c67f31fde320f99a020ac08deca7b4185f27d24f accept c67f31fde320f99a020ac08deca7b4185f27d24f (PASSWORD) Not sure the password is needed - as the email address and the title value is sufficient, but whatever. The options listed above are the same ones seen on the webpage, so there is a one-to-one correspondence. I would even suggest adding that text to the email itself so that it can be cut-n-pasted into the new title. Regards, - Nadim __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From barry at python.org Fri Sep 5 13:08:45 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 5 08:08:47 2003 Subject: [Mailman-Developers] script In-Reply-To: <20030905054816.5410.qmail@web14908.mail.yahoo.com> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> Message-ID: <1062763720.3357.3.camel@anthem> Take a look in cvs. There's a script called bin/discard which takes a list of file names and does proper discards on all those files. I'll be testing it on mail.python.org when 1) I dig out from the mail hell we've been in for the last few days, and 2) SF's CVS stops sucking . -Barry From amk at amk.ca Fri Sep 5 08:58:30 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Sep 5 08:18:23 2003 Subject: [Mailman-Developers] Running Mailman via POP Message-ID: <20030905115830.GA18818@rogue.amk.ca> Here's a little script I just wrote for having Mailman retrieve messages to process via POP. This is useful in my current situation, where reconfiguring the corporate mail server isn't an option. Instead I plan to set up aliases directing mail to foo, foo-subscribe, foo-bounces, etc. into a single 'mailman' mailbox. This script will run from cron, getting the messages via POP, and passing them to the right command. Does anyone have comments on this code? Especially any potential problems with it... In the next day or two I'll put this up on my web pages somewhere so it gets Googled. --amk # # Mailman via POP # import os, poplib, rfc822, cStringIO # Configuration information POP_HOST = 'pop.example.com' POP_USER = 'mailman' POP_PASSWORD = 'password' MESSAGE_ID_FILE = '/tmp/message-ids' # List of domains containing mailing list addresses. # e.g. if this is ['x', 'y'], then foo@x and foo@y are both treated # as an e-mail to the 'foo' mailing list. LIST_DOMAINS = ['example.com', 'lists.example.com'] def process_message (list_name, script_name, msg_id, message): print list_name, script_name, msg_id # Check if list exists if not os.path.exists('/home/mailman/lists/%s' % list_name): # It must not be a list return # Check if this message has already been processed for this list. try: input = open(MESSAGE_ID_FILE, 'r') except IOError: pass else: for line in input: sent_msg_id, sent_list = line.split() if (msg_id == sent_msg_id and sent_list == list_name): print 'Already processed message %r -- skipping' % msg_id input.close() return input.close() # Try to open the message ID file for writing before doing anything # further. output = open(MESSAGE_ID_FILE, 'a') # XXX process message pipe = os.popen('/home/mailman/mail/mailman %s %s' % (script_name, list_name), 'w') pipe.write(message) pipe.close() output.write('%s %s\n' % (msg_id, list_name)) output.close() def display_message(message, show_body=False): print 'From:', message.getheader('From') print 'Subject:', message.getheader('Subject') print 'To:', message.getheader('To') print 'Cc:', message.getheader('Cc') print 'Message-ID:', message.getheader('Message-ID') if show_body: message.rewindbody() print message.fp.read() def main(): conn = poplib.POP3(POP_HOST) conn.user(POP_USER) conn.pass_(POP_PASSWORD) count, size = conn.stat() ##print count, 'messages' # Read the messages and figure out which lists they belong to for i in range(1, count+1): resp, lines, octets = conn.retr(i) msg_text = '\n'.join(lines) fp = cStringIO.StringIO(msg_text) msg = rfc822.Message(fp) lists = [] for human_name, email_addr in (msg.getaddrlist('to') + msg.getaddrlist('cc')): for domain in LIST_DOMAINS: if email_addr.endswith('@'+domain): index = email_addr.find('@') list_name = email_addr[:index].lower() # Remove suffixes script_name = 'post' for suffix in ['admin', 'bounces', 'confirm', 'join', 'leave', 'owner', 'request', 'subscribe', 'unsubscribe']: if list_name.endswith('-'+suffix): list_name = list_name.replace('-'+suffix, '') script_name = suffix if list_name not in lists: lists.append(list_name) if len(lists) == 0: print 'Ignoring message:' display_message(msg, show_body=True) else: message_id = msg.getheader('Message-ID') for list in lists: process_message(list, script_name, message_id, msg_text) conn.dele(i) conn.quit() if __name__ == '__main__': main() From jam at jamux.com Fri Sep 5 12:46:53 2003 From: jam at jamux.com (John A. Martin) Date: Fri Sep 5 11:47:11 2003 Subject: [Mailman-Developers] script In-Reply-To: <1062763720.3357.3.camel@anthem> (Barry Warsaw's message of "05 Sep 2003 08:08:41 -0400") References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> <1062763720.3357.3.camel@anthem> Message-ID: <871xuv44r6.fsf@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "baw" == Barry Warsaw >>>>> "Re: [Mailman-Developers] script" >>>>> 05 Sep 2003 08:08:41 -0400 baw> Take a look in cvs. There's a script called bin/discard baw> which takes a list of file names and does proper discards on baw> all those files. I'll be testing it on mail.python.org when baw> 1) I dig out from the mail hell we've been in for the last baw> few days, and 2) SF's CVS stops sucking . I hope this is something where the choice of what to discard rests with the individual list owner/moderator. Until now, with Mailman, content discrimination has been solely up to the individual list owner and his minions. IMHO it is good to make it easy for the individual list owners to do their job, but anything that requires content decisions to be made across all lists on a Mailman will be inappropriate for at least some, and probably many, mailing list operators. Consider a Mailman that carries many diverse lists including some that, for example, are directly involved with Nigerian affairs and Nigerian folk. Also, depending who operates Mailman and under what auspices and under what jurisdiction, an operator that exercises some discrimination based upon content may viewed as being responsible for content in general. For the sake of those operators who cannot take such responsibility, please continue to make any facilities for discriminating based upon content be tailored to the needs of individual lists and by the individual list owners. Elsewhere recently there has been mention of Baysen spam filters or the like for Mailman. Again, to be generally useful, it would, IMHO, be necessary to allow these features to be tailored to the needs of individual lists and to continue to plaice all responsibility firmly with the individual list owner where that is the policy of the Mailman operator. jam -----BEGIN PGP SIGNATURE----- iD8DBQE/WK/oUEvv1b/iXy8RAuNFAKCHAsjxKoi8KjvfVd4TQTyoYcNH9ACbBB5M 7n6h6vlje0h83mvozPghpPU= =NUsK -----END PGP SIGNATURE----- From barry at python.org Fri Sep 5 17:16:25 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 5 12:16:29 2003 Subject: [Mailman-Developers] script In-Reply-To: <871xuv44r6.fsf@athene.jamux.com> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> <1062763720.3357.3.camel@anthem> <871xuv44r6.fsf@athene.jamux.com> Message-ID: <1062778578.4084.4.camel@yyz> On Fri, 2003-09-05 at 11:46, John A. Martin wrote: > I hope this is something where the choice of what to discard rests > with the individual list owner/moderator. The script is just a hack, and must be run by the site admin on the command line. It's just a way to mass discard a ton of crap. It works on file names so it's easy to focus it on a single list. > Elsewhere recently there has been mention of Baysen spam filters or > the like for Mailman. Again, to be generally useful, it would, IMHO, > be necessary to allow these features to be tailored to the needs of > individual lists and to continue to plaice all responsibility firmly > with the individual list owner where that is the policy of the Mailman > operator. That's how my Spambayes patch to Mailman works. It hooks into the normal approval process. It'll likely need updating to the latest versions of Spambayes (which recently underwent an interface upheaval). I'd probably be inclined to put this on the feature list for Mailman 2.2. -Barry From pioppo at ferrara.linux.it Fri Sep 5 23:33:56 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Fri Sep 5 16:33:50 2003 Subject: [Mailman-Developers] script In-Reply-To: <1062778578.4084.4.camel@yyz> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> <871xuv44r6.fsf@athene.jamux.com> <1062778578.4084.4.camel@yyz> Message-ID: <200309052233.56206.pioppo@ferrara.linux.it> On Friday 05 September 2003 18:16, Barry Warsaw wrote: > > Elsewhere recently there has been mention of Baysen spam filters or > > the like for Mailman. Again, to be generally useful, it would, IMHO, > > That's how my Spambayes patch to Mailman works. It hooks into the > normal approval process. It'll likely need updating to the latest > versions of Spambayes (which recently underwent an interface upheaval). > I'd probably be inclined to put this on the feature list for Mailman > 2.2. I'm using this patch (slightly adapted) on our servers since early april. It works almost seamlessly and its very effective but still lacks some UI controls, e.g. actually there's no way to train the filter TTW with a message which is not in the moderation queue. Also, if a message gets discarded or posted to the list, there's no way to recoved the pristine copy, the one that was inspected by the filter, and the only copy one can use is Decorate'ed, mangled and/or filled with unwanted Received headers. Hopefully I'm going to work again on this patch in the next few months. -- Adde parvum parvo magnus acervus erit -- Ovidio From barry at python.org Fri Sep 5 22:14:31 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 5 17:14:33 2003 Subject: [Mailman-Developers] script In-Reply-To: <200309052233.56206.pioppo@ferrara.linux.it> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> <871xuv44r6.fsf@athene.jamux.com> <1062778578.4084.4.camel@yyz> <200309052233.56206.pioppo@ferrara.linux.it> Message-ID: <1062796469.4084.18.camel@yyz> On Fri, 2003-09-05 at 16:33, Simone Piunno wrote: > I'm using this patch (slightly adapted) on our servers since early april. It > works almost seamlessly and its very effective but still lacks some UI > controls, e.g. actually there's no way to train the filter TTW with a message > which is not in the moderation queue. Also, if a message gets discarded or > posted to the list, there's no way to recoved the pristine copy, the one that > was inspected by the filter, and the only copy one can use is Decorate'ed, > mangled and/or filled with unwanted Received headers. > Hopefully I'm going to work again on this patch in the next few months. Excellent feedback, thanks Simone! I think we can fix the u/i problems, but it's nice to know the basic approach has utility. -Barry From philb at philb.us Fri Sep 5 23:58:43 2003 From: philb at philb.us (Phil Barnett) Date: Fri Sep 5 22:58:49 2003 Subject: [Mailman-Developers] script In-Reply-To: <20030905054816.5410.qmail@web14908.mail.yahoo.com> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> Message-ID: <200309052258.43817.philb@philb.us> On Friday 05 September 2003 1:48 am, Nadim Shaikli wrote: > How do you go about getting .txt files in your /home/mailman/data dir ? > All I see are binary pck files (which one could run dumpdb on, but > was curious to know). I'm running mailman-2.1.2. BTW, does deleting > those .pck files have any baring on anything else (is it dangerous) ? > Meaning, are there any adverse affects in doing that (is there a db > that cares or anything) ? It only deletes the messages that are caught by my filters. In this case, it is: # Lines that *start* with a '#' are comments. to: friend@public.com message-id: relay.comanche.denmark.eu from: list@listme.com from: .*@uplinkpro.com from: .*@lithesoft.com from: .*@paid4survey.net from: .*@freegift4u.com.* from: .*q-crystal.com.* subject: .*@Podtal.* subject: .*URGENT ASSISTANCE.* from: .*etoyshop.* from: .*bdavisa.* subject: .*new photos from my party.* Content-type: text/html Content-type: text/enriched Content-type: text/x-vcard Content-type: multipart/alternative Content-type: multipart/related Content-type: multipart/mixed Content-type: application/octet-stream Content-Type: text/html Content-Type: text/enriched Content-Type: text/x-vcard Content-Type: multipart/alternative Content-Type: multipart/related Content-Type: multipart/mixed Content-Type: application/octet-stream Content-Disposition: attachment from: .*@lehugo.com.br.* subject: .*Autoreply:.* Precedence: .*bulk.* -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. From harald.meland at usit.uio.no Mon Sep 8 00:30:50 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Sun Sep 7 17:30:56 2003 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0 In-Reply-To: <1053756028.20316.9.camel@geddy> (Barry Warsaw's message of "24 May 2003 02:00:28 -0400") References: <20030524043759.GD25509@lazarus> <1053756028.20316.9.camel@geddy> Message-ID: [Barry Warsaw] > On Sat, 2003-05-24 at 00:37, Jeff Waugh wrote: > >> It might be a bit of extra work, but why not just copy the files around in >> the repository? History is important! :-) > > Two reasons: > > - I'm not even sure what the directory structure is going to look like > yet, and I don't really know how, if, or which old files will map into > new files. > > - It's a royal PITA to do this when you don't have direct access to the > repository. > > For now, this is all extremely experimental. I just need a place to > check in some noodlings so the code isn't just sitting on my disk. [ Replying to a 3.5-months-old message... hopefully my response lag time will improve shortly. :-) ] If there is enough demand for tree reorganization to require using a completely new CVS module, has any thought been given to switching to a revision control system that actually *supports* renames? There seems to be quite a few of them about, and in particular GNU Arch appears to have gotten a popularity boost recently. -- Harald From barry at python.org Mon Sep 8 14:30:57 2003 From: barry at python.org (Barry Warsaw) Date: Mon Sep 8 09:30:58 2003 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0 In-Reply-To: References: <20030524043759.GD25509@lazarus> <1053756028.20316.9.camel@geddy> Message-ID: <1063027852.16344.11.camel@anthem> On Sun, 2003-09-07 at 17:30, Harald Meland wrote: > [ Replying to a 3.5-months-old message... hopefully my response lag > time will improve shortly. :-) ] Yours and mine both! :) > If there is enough demand for tree reorganization to require using a > completely new CVS module, has any thought been given to switching to > a revision control system that actually *supports* renames? > > There seems to be quite a few of them about, and in particular GNU > Arch appears to have gotten a popularity boost recently. Thought about it, but as long as we're on SF and SF uses CVS, it's too much work to switch. -Barry From harald.meland at usit.uio.no Mon Sep 8 18:16:34 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Mon Sep 8 11:16:46 2003 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0 In-Reply-To: <1063027852.16344.11.camel@anthem> (Barry Warsaw's message of "08 Sep 2003 09:30:52 -0400") References: <20030524043759.GD25509@lazarus> <1053756028.20316.9.camel@geddy> <1063027852.16344.11.camel@anthem> Message-ID: [Barry Warsaw] > On Sun, 2003-09-07 at 17:30, Harald Meland wrote: > >> If there is enough demand for tree reorganization to require using a >> completely new CVS module, has any thought been given to switching to >> a revision control system that actually *supports* renames? > > Thought about it, but as long as we're on SF and SF uses CVS, it's too > much work to switch. I'm not sure which aspect(s) of "SF uses CVS" you're referring to: 1) SF hosts the "official" CVS repository. 2) SF has a system for granting project developers commit access to the central repository. 3) SF hosts an anonymous access version of the repository. 4) SF has routines for gathering "project activity metrics" that are (partly) based on CVS access. 5) Users familiar with SF more or less expect all projects hosted there to use CVS. ... or something else? A complete switch to e.g. GNU Arch (http://www.gnu.org/directory/GNU/arch.html) does not conflict with all of these: 1) SF provides both sftp and http access. Arch can do archive (Arch's name for "repository") access (r/w) over sftp, and read-only access over http. 2) It is possible to use the same file groups SF uses for CVS access to do Arch commit access (over e.g. sftp). However, with Arch's support for distributed archives, it might not be necessary. 3) With Arch, one could either use the devel archive directly (because the same archive could be accessed through both sftp and http), or one could leverage Arch's support for mirroring of archives. 4) No good solution here -- but then again, I'm not convinced it really is necessary to "solve" this. I don't think SF's popularity-meter is particularly important to Mailman... 5) Well, I think users with such expectations are bound to be wrong sooner or later. :-) Additionally, a "complete switch" might not be necessary; some projects are using both CVS and Arch simultaneously. These setups typically leave it to the Arch users to do the gatewaying to/from CVS -- but the CVS users are more likely to get into trouble when files/directories are moved around, as such changes will be seen as delete+add operations in CVS. Finally, there are other systems than Arch our there. In particular, Meta-CVS (http://users.footprints.net/~kaz/mcvs.html) provides an easy (if not backwards compatible) solution to items 1-4 (but still requires users to change their expectations). -- Harald From philb at philb.us Mon Sep 8 14:05:25 2003 From: philb at philb.us (Phil Barnett) Date: Mon Sep 8 13:05:30 2003 Subject: [Mailman-Developers] script In-Reply-To: <20030905054816.5410.qmail@web14908.mail.yahoo.com> References: <20030905054816.5410.qmail@web14908.mail.yahoo.com> Message-ID: <200309081305.25626.philb@philb.us> On Friday 05 September 2003 1:48 am, Nadim Shaikli wrote: > BTW, does deleting > those .pck files have any baring on anything else (is it dangerous) ? > Meaning, are there any adverse affects in doing that (is there a db > that cares or anything) ? I forgot to answer this. Yes, the html admin page complains that the mail is lost. Hit the submit button and it cleans up after itself. Doesn't appear to cause any problems. -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. From r.barrett at ftel.co.uk Mon Sep 8 19:33:15 2003 From: r.barrett at ftel.co.uk (Richard Barrett) Date: Mon Sep 8 13:33:42 2003 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0 In-Reply-To: Message-ID: <876EAFD8-E222-11D7-A865-000A957C9A50@ftel.co.uk> I would assume that Barry is working on the "it ain't broke so don't fix it" principle and he is sufficiently busy that getting real work done is enough to be going on with (like outstanding bug fixes checked and applied to the CVS so that 2.1.3 can be generated and shipped). If that is the case I would support the view that adopting a new version control approach may not be the most important task currently to hand for the Mailman project leader. On Monday, September 8, 2003, at 04:16 pm, Harald Meland wrote: > [Barry Warsaw] > >> On Sun, 2003-09-07 at 17:30, Harald Meland wrote: >> >>> If there is enough demand for tree reorganization to require using a >>> completely new CVS module, has any thought been given to switching to >>> a revision control system that actually *supports* renames? >> >> Thought about it, but as long as we're on SF and SF uses CVS, it's too >> much work to switch. > > I'm not sure which aspect(s) of "SF uses CVS" you're referring to: > > 1) SF hosts the "official" CVS repository. > 2) SF has a system for granting project developers commit access to > the central repository. > 3) SF hosts an anonymous access version of the repository. > 4) SF has routines for gathering "project activity metrics" that are > (partly) based on CVS access. > 5) Users familiar with SF more or less expect all projects hosted > there to use CVS. > > ... or something else? > > A complete switch to e.g. GNU Arch > (http://www.gnu.org/directory/GNU/arch.html) does not conflict with > all of these: > > 1) SF provides both sftp and http access. Arch can do archive > (Arch's name for "repository") access (r/w) over sftp, and > read-only access over http. > 2) It is possible to use the same file groups SF uses for CVS access > to do Arch commit access (over e.g. sftp). However, with Arch's > support for distributed archives, it might not be necessary. > 3) With Arch, one could either use the devel archive directly > (because the same archive could be accessed through both sftp and > http), or one could leverage Arch's support for mirroring of > archives. > 4) No good solution here -- but then again, I'm not convinced it > really is necessary to "solve" this. I don't think SF's > popularity-meter is particularly important to Mailman... > 5) Well, I think users with such expectations are bound to be wrong > sooner or later. :-) > > Additionally, a "complete switch" might not be necessary; some > projects are using both CVS and Arch simultaneously. These setups > typically leave it to the Arch users to do the gatewaying to/from CVS > -- but the CVS users are more likely to get into trouble when > files/directories are moved around, as such changes will be seen as > delete+add operations in CVS. > > Finally, there are other systems than Arch our there. In particular, > Meta-CVS (http://users.footprints.net/~kaz/mcvs.html) provides an easy > (if not backwards compatible) solution to items 1-4 (but still > requires users to change their expectations). > -- > Harald From harald.meland at usit.uio.no Tue Sep 9 03:21:49 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Mon Sep 8 20:21:54 2003 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0 In-Reply-To: <876EAFD8-E222-11D7-A865-000A957C9A50@ftel.co.uk> (Richard Barrett's message of "Mon, 8 Sep 2003 18:33:15 +0100") References: <876EAFD8-E222-11D7-A865-000A957C9A50@ftel.co.uk> Message-ID: [Richard Barrett] > I would assume that Barry is working on the "it ain't broke so don't > fix it" principle Well, while I agree with that principle, I'm reading mailman3/README.txt to be yet another phrasing of the conclusion that CVS *is* broken -- at the very least for projects where renames are needed. > and he is sufficiently busy that getting real work done is enough to > be going on with (like outstanding bug fixes checked and applied to > the CVS so that 2.1.3 can be generated and shipped). Sure. That means someone else should help out with researching how the "not real work" stuff could be done, in order to make the (necessary, if a rename-supporting VC is needed) learning curve less steep. As a bonus, such usage sketches might reveal which aspects of VC is important to the project -- by letting the project contributors comment on them. If all contributors are indeed happy with CVS, there is no reason to change, and I'll be happy to spend my "Mailman time" (of which there hasn't been a great deal for some years, but hopefully will be more shortly) on other issues. Cheers, -- Harald From maechler at stat.math.ethz.ch Fri Sep 12 11:44:59 2003 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Fri Sep 12 04:45:23 2003 Subject: [Mailman-Developers] Uncaught bounce {that should be caught!} Message-ID: <16225.34699.947434.211192@gargle.gargle.HOWL> Dear developers, I'm still getting several such messages every day. I believe most of these *should* be caught by mailman. Here is one obvious example. This is with current mailman 2.1.2 , using Python 2.3 - on Solaris 8 Please ask for more details if needed -------------- next part -------------- An embedded message was scrubbed... From: mailman-bounces@stat.math.ethz.ch Subject: Uncaught bounce notification Date: Thu, 11 Sep 2003 12:02:57 +0200 Size: 23730 Url: http://mail.python.org/pipermail/mailman-developers/attachments/20030912/55c6f6f2/attachment.eml From barry at python.org Fri Sep 12 09:39:58 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 12 09:40:06 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <200308200045.23234.pioppo@ferrara.linux.it> References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> Message-ID: <1063373997.19907.44.camel@anthem> Catching up... On Tue, 2003-08-19 at 18:45, Simone Piunno wrote: > MTAs usually provide a configuration setting to enable cache flush for each > transaction (by use of fsync()), but this is disabled by default because of > the severe impact in performance. Indeed. I could add an optional flag to enable fsync'ing in the _ext_write() calls in Switchboard.py, but I wouldn't want to enable it by default. It really kills performance. For 2.1.3, I'll add a flag to Switchboard.py but disable it by default; I'm not going to expose the flag in mm_cfg.py, but it'll be possible for the adventurous to experiment. -Barry From brad.knowles at skynet.be Fri Sep 12 12:28:39 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Sep 12 12:31:31 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <1063373997.19907.44.camel@anthem> References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> Message-ID: At 9:39 AM -0400 2003/09/12, Barry Warsaw wrote: > Indeed. I could add an optional flag to enable fsync'ing in the > _ext_write() calls in Switchboard.py, but I wouldn't want to enable it > by default. It really kills performance. > > For 2.1.3, I'll add a flag to Switchboard.py but disable it by default; > I'm not going to expose the flag in mm_cfg.py, but it'll be possible for > the adventurous to experiment. I would suggest making this flag visible on certain OSes. For example, turned off by default but visible on Linux, and not even visible (without hacking) on OSes that don't need it. I know it kills performance, but this feature is needed for a reason, and RFC 1123 and 2821 make it clear that we can't lose mail just because we've had a system crash or some other known foreseeable problem. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From barry at python.org Fri Sep 12 12:35:32 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 12 12:35:46 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> Message-ID: <1063384531.19907.67.camel@anthem> On Fri, 2003-09-12 at 12:28, Brad Knowles wrote: > I would suggest making this flag visible on certain OSes. For > example, turned off by default but visible on Linux, and not even > visible (without hacking) on OSes that don't need it. Hmm, I don't know what "make it visible on some OSs" would mean. ;) There's a flag in the file with a helpful comment which is easily edited, just not in mm_cfg.py. There will be a note about it in the release notes for 2.1.3. -Barry From brad.knowles at skynet.be Fri Sep 12 12:42:20 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Sep 12 12:42:51 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <1063384531.19907.67.camel@anthem> References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> Message-ID: At 12:35 PM -0400 2003/09/12, Barry Warsaw wrote: > Hmm, I don't know what "make it visible on some OSs" would mean. ;) So that no hacking is required to make it something the user can see and modify. We'd still be doing the dangerous thing by leaving it set to default off (in the case of Linux), but at least we wouldn't be requiring that they hack the code in order to be able to tweak this option. All you should need to do is check the output from `uname -a`. > There's a flag in the file with a helpful comment which is easily > edited, just not in mm_cfg.py. There will be a note about it in the > release notes for 2.1.3. I understand, but there are many people who use mailman on Linux who won't be able to make even that kind of simple change. They can't install anything themselves from source, only using rpm. Unfortunately, they are likely to be the bulk of the users, and the ones most likely to be hurt by this sort of thing. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From jam at jamux.com Fri Sep 12 12:56:24 2003 From: jam at jamux.com (John A. Martin) Date: Fri Sep 12 12:56:36 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <1063384531.19907.67.camel@anthem> (Barry Warsaw's message of "12 Sep 2003 12:35:32 -0400") References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> Message-ID: <87wuce6j47.fsf@athene.jamux.com> >>>>> "baw" == Barry Warsaw >>>>> "Re: [Mailman-Developers] Problem with MM after power outage" >>>>> 12 Sep 2003 12:35:32 -0400 baw> On Fri, 2003-09-12 at 12:28, Brad Knowles wrote: >> I would suggest making this flag visible on certain OSes. For >> example, turned off by default but visible on Linux, and not >> even visible (without hacking) on OSes that don't need it. baw> Hmm, I don't know what "make it visible on some OSs" would baw> mean. ;) There's a flag in the file with a helpful comment baw> which is easily edited, just not in mm_cfg.py. There will be baw> a note about it in the release notes for 2.1.3. And, moreover, the choice should depend upon the file system and file system options. As you know, all Linux boxen do not necessarily only run ext2 even by distribution default. jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030912/61be1057/attachment.bin From marco_henriques at yahoo.com.br Fri Sep 12 16:45:21 2003 From: marco_henriques at yahoo.com.br (Marco Antonio Reis Henriques) Date: Fri Sep 12 16:45:31 2003 Subject: [Mailman-Developers] Mailman Backup References: <87y8y4pob4.fsf@yiwaz.raw.no> <1060470638.1047.3.camel@geddy> Message-ID: <013301c3796e$ca41a8d0$39fec1c8@MARHNTB> Hi All, We are moving entire mail system from a host to another (a machine modification) . Our list server, with MM of course, is on this mail server too. How can I migrate lists, configs, users, etc ... to new server ?!? Thanks in advance. Cheers, Marco From brad.knowles at skynet.be Fri Sep 12 15:58:18 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Sep 12 17:04:07 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <87wuce6j47.fsf@athene.jamux.com> References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> Message-ID: At 12:56 PM -0400 2003/09/12, John A. Martin wrote: > And, moreover, the choice should depend upon the file system and file > system options. As you know, all Linux boxen do not necessarily only > run ext2 even by distribution default. It's easy enough to check the type of filesystem to be used, and whether "chatter +S" has been run on the particular directory structure. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From spacey-mailman at lenin.nu Fri Sep 12 17:14:25 2003 From: spacey-mailman at lenin.nu (Peter C. Norton) Date: Fri Sep 12 17:14:30 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> Message-ID: <20030912211425.GK5719@lenin.nu> On Fri, Sep 12, 2003 at 09:58:18PM +0200, Brad Knowles wrote: > At 12:56 PM -0400 2003/09/12, John A. Martin wrote: > > > And, moreover, the choice should depend upon the file system and file > > system options. As you know, all Linux boxen do not necessarily only > > run ext2 even by distribution default. > > It's easy enough to check the type of filesystem to be used, and > whether "chatter +S" has been run on the particular directory > structure. This has gotten silly. 99% of the sites out there don't about the tradeoff, and mailman could write synchronously without impacting the performance. Playing fast and loose could be done if a site admin wanted it. Doing OS-specific checks just to set this variable is silly because the admin can make the business decision as to whether they can afford to let the system run with async writes, write-back cache, etc. and its their problem. -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From harald.meland at usit.uio.no Fri Sep 12 17:40:24 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Fri Sep 12 17:40:35 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <20030912211425.GK5719@lenin.nu> (Peter C. Norton's message of "Fri, 12 Sep 2003 14:14:25 -0700") References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> <20030912211425.GK5719@lenin.nu> Message-ID: [Peter C. Norton] > On Fri, Sep 12, 2003 at 09:58:18PM +0200, Brad Knowles wrote: >> At 12:56 PM -0400 2003/09/12, John A. Martin wrote: >> >> > And, moreover, the choice should depend upon the file system and file >> > system options. As you know, all Linux boxen do not necessarily only >> > run ext2 even by distribution default. >> >> It's easy enough to check the type of filesystem to be used, and >> whether "chatter +S" has been run on the particular directory >> structure. > > This has gotten silly. 99% of the sites out there don't about the > tradeoff, and mailman could write synchronously without impacting the > performance. Playing fast and loose could be done if a site admin > wanted it. Doing OS-specific checks just to set this variable is > silly because the admin can make the business decision as to whether > they can afford to let the system run with async writes, write-back > cache, etc. and its their problem. Hear, hear. :-) Although I haven't done any testing as to how much performance is lost by fsync(2)ing, I suspect that the sites who actually *need* this lost performance are (much) more likely to read the upgrade notes than your average Mailman site admin. Hence, I think it makes more sense to have the default be "do fsync(2)", and let any performance-conscious site decide whether it wants to explicitly value performance over safety. -- Harald From barry at python.org Fri Sep 12 17:56:00 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 12 17:56:09 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> <20030912211425.GK5719@lenin.nu> Message-ID: <1063403760.19907.93.camel@anthem> On Fri, 2003-09-12 at 17:40, Harald Meland wrote: > Although I haven't done any testing as to how much performance is lost > by fsync(2)ing, I suspect that the sites who actually *need* this lost > performance are (much) more likely to read the upgrade notes than your > average Mailman site admin. > > Hence, I think it makes more sense to have the default be "do > fsync(2)", and let any performance-conscious site decide whether it > wants to explicitly value performance over safety. Except that when I did some very simple tests, I saw a 97% hit in performance with fsync turned on. This on a RH9, ext3 Linux box of the Dell Optiplex variety. That makes me very nervous to add in a patch release that won't have any beta testing. I've also never seen the bug on python.org, which may or may not be representative of the world at large. I'm happy to re-address this for the next major release, but for 2.1.3 I don't want to enable fsync by default, and I definitely don't want to do any probing/guessing of filesystems, etc. -Barry From harald.meland at usit.uio.no Fri Sep 12 18:50:28 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Fri Sep 12 18:50:49 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <1063403760.19907.93.camel@anthem> (Barry Warsaw's message of "12 Sep 2003 17:56:00 -0400") References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> <20030912211425.GK5719@lenin.nu> <1063403760.19907.93.camel@anthem> Message-ID: [Barry Warsaw] > Except that when I did some very simple tests, I saw a 97% hit in > performance with fsync turned on. Ouch. That's pretty severe, all right. Even though I would *guess* that most "casual" Mailman sites would pull through an effective halving of performance without any problems, that is merely a guess... thus, I'm not at all sure that set of sites that would be in trouble with such a big performance hit is disjoint from the set of sites that don't read upgrade documentation very carefully. > This on a RH9, ext3 Linux box of the Dell Optiplex variety. That > makes me very nervous to add in a patch release that won't have any > beta testing. I hadn't considered the "no beta testing" part of this. Reconsidering now, I agree that such a big performance hit in a "bugfix" release ought to be the cause of quite a bit of nervousness on behalf of the release issuer... :-) > I'm happy to re-address this for the next major release, but for > 2.1.3 I don't want to enable fsync by default, and I definitely > don't want to do any probing/guessing of filesystems, etc. That sounds like a good plan to me. However, I'm not sure I understand why this shouldn't be configurable in mm_cfg; is that just to keep the number of configurable variables down? FWIW, PostgreSQL exposes an "do fsync(2)" option in it's global config file; on my Debian system, the option is preceded with this comment: # A special note on FSYNC: # FSYNC only affects writes to the WAL (Write-Ahead Log). Turning it # off will give some increase in performance, but at the risk of data- # corruption in the event of power failure or other disaster. It is on # by default. I strongly recommend you not to turn it off. -- Harald From barry at python.org Sat Sep 13 00:55:14 2003 From: barry at python.org (Barry Warsaw) Date: Sat Sep 13 00:55:23 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> Message-ID: <1063428914.19907.126.camel@anthem> On Fri, 2003-09-12 at 12:42, Brad Knowles wrote: > At 12:35 PM -0400 2003/09/12, Barry Warsaw wrote: > > > Hmm, I don't know what "make it visible on some OSs" would mean. ;) > > So that no hacking is required to make it something the user can > see and modify. We'd still be doing the dangerous thing by leaving > it set to default off (in the case of Linux), but at least we > wouldn't be requiring that they hack the code in order to be able to > tweak this option. But, really, they have to hack the code either way. Either you're editing the mm_cfg.py file, or you're editing the Switchboard.py file. The former is a little more visible, since that's the file people are trained to touch. But here's the thing. For a bug fix release, it seems wrong to expose this in mm_cfg.py because that implies some higher state of blessing. I'm not convinced that we've hit upon the ultimate right solution so I don't want to commit to it. After folks have had a chance to test it and see if 1) it fixes the problem, and 2) what the real world trade-offs are, then we can decide whether it deserves higher profile, or maybe just us choosing to hard code it to always fsync(). > > There's a flag in the file with a helpful comment which is easily > > edited, just not in mm_cfg.py. There will be a note about it in the > > release notes for 2.1.3. > > I understand, but there are many people who use mailman on Linux > who won't be able to make even that kind of simple change. They > can't install anything themselves from source, only using rpm. > Unfortunately, they are likely to be the bulk of the users, and the > ones most likely to be hurt by this sort of thing. I'm mostly unconvinced by this argument. IWBNI Mailman were as simple as a pinball machine but I think folks will still have to read some instructions. Plus, I'm not sure the majority of sites will care, either because their traffic is low enough that it doesn't matter, or they're on reliable power, etc. -Barry From barry at python.org Sat Sep 13 00:59:19 2003 From: barry at python.org (Barry Warsaw) Date: Sat Sep 13 00:59:27 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> Message-ID: <1063429158.19907.128.camel@anthem> On Fri, 2003-09-12 at 15:58, Brad Knowles wrote: > It's easy enough to check the type of filesystem to be used, and > whether "chatter +S" has been run on the particular directory > structure. Maybe there should be a FAQ or README.LINUX items discussing the issue, and suggesting filesystem settings to improve reliability. Any volunteers to write some documentation? -Barry From barry at python.org Sat Sep 13 01:03:16 2003 From: barry at python.org (Barry Warsaw) Date: Sat Sep 13 01:03:24 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: References: <20030815145839.GM460@mrbill.net> <200308192117.38899.pioppo@ferrara.linux.it> <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> <20030912211425.GK5719@lenin.nu> <1063403760.19907.93.camel@anthem> Message-ID: <1063429396.19907.132.camel@anthem> On Fri, 2003-09-12 at 18:50, Harald Meland wrote: > However, I'm not sure I understand why this shouldn't be configurable > in mm_cfg; is that just to keep the number of configurable variables > down? That, and because I kind of see visibility in mm_cfg.py as a blessing of sorts for the configuration option. See my previous message. Anyway, I'd encourage people to set SYNC_AFTER_WRITE=True once 2.1.3 comes out (or when you update to CVS ) and observe what actually happens. Does it solve the problem? How bad is the performance hit? Don't forget that if you experiment and post results, let us know essentials such as Python version, OS version, filesystem type, disk subsystem, etc. -Barry From manuyamin at SAFe-mail.net Sat Sep 6 18:15:36 2003 From: manuyamin at SAFe-mail.net (manuyamin@SAFe-mail.net) Date: Sat Sep 13 09:17:22 2003 Subject: [Mailman-Developers] Subscriber list Message-ID: Hi, I would like to retrieve my complete list of subscriber (i'm using mailman) in a text file but i don't know how to do it, can someone help me please ? (i've more than 20000 subscribers) Thank you very much (sorry for my poor english talking, i'm french) From kl at vsen.dk Sun Sep 7 03:26:19 2003 From: kl at vsen.dk (Klavs Klavsen) Date: Sat Sep 13 09:17:27 2003 Subject: [Mailman-Developers] implementing real virtual domain support in mailman Message-ID: <1062919578.3351.12.camel@amd.vsen.dk> Hi guys, I'm new to mailman, but I can see that it does't support real virtual domains, because it stores all lists as lists/listname - instead of lists/listname@virtualdomain.tld I was thinking that support for this could easily be added by manipulating this variable: LIST_DATA_DIR = os.path.join(VAR_PREFIX, 'lists') I'm thinking it could be done in two ways, where each virtualdomain would have their own lists-folder: 1) every occurence of VAR_PREFIX in the code, would then just be replaced with VAR_PREFIX . VAR_VIRT (or some variable name, indicating the virtualdomainname requested) - and the lists folder would be lists-virtualdomainname for everything except for the main address, where VAR_VIRT would ofcourse be empty. This also includes that the VAR pointing to the mailbox/maildir's should have VAR_VIRT appended to the name. 2) Instead going through all the code, and adding VAR_VIRT to selected variables, perhaps perhaps a better way exists? I've never coded python before, but it looks as this would be easily doable, but then again I'm new to mailman and therefore I'm hoping to get your feedback on this idea, before I start working on implementing it. I'm sure you've had thoughts about how this could be done best - afterall this is on the ToDo-List - please share them :) I've never coded python before, but It looks as this would be easily doable, but then again, I'm new to mailman and there I was hoping to get your feedback on this idea, before I start implementing it. -- Regards, Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 See my new CMS Hosting Service at http://www.VirkPaaNettet.dk Working with Unix is like wrestling a worthy opponent. Working with windows is like attacking a small whining child who is carrying a .38. From steve at z3u.com Mon Sep 8 05:46:30 2003 From: steve at z3u.com (Steve Alexander) Date: Sat Sep 13 09:17:30 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch Message-ID: <3F5C4FF6.6080308@z3u.com> Hi folks, Mailman 2.1.2 writes out a "sendmail-style" virtual-mailman file rather than a "postfix-style" virtual-mailman file. I don't know whether this is what is intended, but it seems counter to what I read in the README.POSTFIX file, and using the POSTFIX_STYLE_VIRTUAL_DOMAINS setting. The only difference between a sendmail-style file and a postfix-style file is that the postfix-style one starts with a line like: domain.tld IGNORED Here's a patch that I'm using to make Mailman work with postfix-style virtual domains. --- Mailman/MTA/Postfix.py Mon Mar 31 22:49:43 2003 +++ /tmp/Postfix.py Mon Sep 8 10:35:40 2003 @@ -136,10 +136,12 @@ # Note that you should already have this virtual domain set up properly in # your Postfix installation. See README.POSTFIX for details. +# Hack by SteveA to make postfix-style virtuals work again +%s IGNORED # LOOP ADDRESSES START %s\t%s # LOOP ADDRESSES END -""" % (loopaddr, loopdest) +""" % (hostname, loopaddr, loopdest) # The text file entries get a little extra info print >> fp, '# STANZA START:', listname print >> fp, '# CREATED:', time.ctime(time.time()) -- Steve Alexander From fox_muld at quakenet.org Mon Sep 8 06:22:47 2003 From: fox_muld at quakenet.org (fox_muld@quakenet.org) Date: Sat Sep 13 09:17:34 2003 Subject: [Mailman-Developers] Bug (missing sanity check) in parseaddr.py Message-ID: <20030908122247.00004a32.fox_muld@quakenet.org> I'm sorry if this is a known bug, the buglist on sourceforge isn't exactly helpful, there is just too much in it and no adequate method for searching it; and google didn't find anything on this. Recently one of our Mailinglists stopped working, and senddigests would die everytime it ran with this error: Traceback (most recent call last): File "/home/mailman/cron/senddigests", line 94, in ? main() File "/home/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/home/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests msg = scrubber(mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 162, in process dir = calculate_attachments_dir(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 120, in calculate_attachments_dir now = parsedate(datestr) File "/home/mailman/pythonlib/email/Utils.py", line 249, in parsedate return _parsedate(data) File "/home/mailman/pythonlib/email/_parseaddr.py", line 133, in parsedate t = parsedate_tz(data) File "/home/mailman/pythonlib/email/_parseaddr.py", line 126, in parsedate_tz tzoffset = tzsign * ( (tzoffset/100)*3600 + (tzoffset % 100)*60) OverflowError: integer multiplication It turned out to be caused by some invalid Date: header in a mail in digest.mbox (strange it was accepted, but then killed mailman everytime it tried to do something with it?). The header was: Date: Tue, 26 Aug 2003 19:10:55 -119304547 That messed up timezone-offset obviously kills parseaddr. The obvious fix is to add some sanity check to that calculation, but as I don't speak python, I won't submit a patch for that. From john at giosico.com Tue Sep 9 02:01:53 2003 From: john at giosico.com (john@giosico.com) Date: Sat Sep 13 09:17:40 2003 Subject: [Mailman-Developers] Posting OK but getting not allowed to post message In-Reply-To: <1063086034.3f5d67d3034f0@fthood.ezoshosting.com> References: <1063086034.3f5d67d3034f0@fthood.ezoshosting.com> Message-ID: <1063087313.3f5d6cd15ad56@fthood.ezoshosting.com> I have search for a resolution to the problem with no luck ... perhaps you could help ... I am using mailman 2.1.2 and everything seems to be working ok except that when a user makes a post they get a message back saying ... You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at I have tried deleting and recreating the list but I still get the message. Creating a new list with a different name does not have this problem. Text searches have been done to find residual info after a list has been deleted has resulted with no luck. Its weird that creating a new list with a new name does not have the error but deleting an old list and recreating it does. Any help or guidance is much appreciated. From david at johmar.com Wed Sep 10 13:37:13 2003 From: david at johmar.com (david@johmar.com) Date: Sat Sep 13 09:17:48 2003 Subject: [Mailman-Developers] customise html templates Message-ID: On the 'Administrative requests for mailing list' html page I want to make it default to 'Discard' rather than 'Defer'. This way I can delete all the spam by just clicking submit rather than have to mark each one for 'discard' and then press submit. I assume I can do this if I could find the name of this page and then use the 'Edit the HTML for the public list pages', anyone know what it is called e.g. 'listinfo.html', 'subscribe.html' 'options.html' and 'handle_opts.html'. I've tried the obvious like admindb.html etc.. anyone know what it is called or otherwise how to make the change? David From Philip.Ponton at morganstanley.com Wed Sep 10 16:22:07 2003 From: Philip.Ponton at morganstanley.com (Phillip Ponton) Date: Sat Sep 13 09:17:58 2003 Subject: [Mailman-Developers] Ssubscribe area Message-ID: <3F5F87EF.D0D2384F@morganstanley.com> Hello, does anyone know how to change the text in the subscribable area of the mailing list. I would like to add more information such as geographical location. Please, can somebody aid in this... Thanks -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. From ms-nospam-0306 at arcor.de Fri Sep 12 10:35:59 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat Sep 13 09:18:09 2003 Subject: [Mailman-Developers] Mailman transparency Message-ID: <20030912163559.7588cbdc.ms-nospam-0306@arcor.de> For some time I've been experiencing the following two problems on a few Mailman mailing-lists: 1) Messages which contain lines that start with a leading "From" are escaped to ">From" prior to being distributed to all subscribers. This damages signed message content. E.g. PGP/SMIME signatures attached to such messages no longer match the message body and verify as BAD because the subscribers receive the message with escaped lines. One of my recent messages posted to a mailing-list hosted by Red Hat suffers from that problem: http://www.redhat.com/archives/rhl-devel-list/2003-September/msg00068.html The same message mailed to me directly via several servers does not contain escaped "From" lines. Therefore its signature verifies as GOOD. [The only additional change in the archive is that the quoted mail address has been obfuscated.] I understand that Mailman escapes the "From" lines in the message body before archiving the messages. But it should not distribute the modified messages. [...] 2) Occasionally, a subscriber finds that a posted message has made it to the mailing-list only truncated. It turns out that the message contained a line with only a single dot by itself. Mailman cuts off the message body at that line before distributing the truncated message to all subscribers. It looks much like the dot is treated as SMTP message body delimiter but in a non-transparent way. The users should be protected from something like that. [...] Does any of this make sense? ;) In case it doesn't, I need to look for other tools in the chain which could be responsible for the described symptoms. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030912/63f50902/attachment-0001.bin From jam at jamux.com Sat Sep 13 11:24:15 2003 From: jam at jamux.com (John A. Martin) Date: Sat Sep 13 11:24:29 2003 Subject: [Mailman-Developers] [ 805630 ] Mail to foo-bar list languishes in maildir Message-ID: <878yosogo0.fsf@athene.jamux.com> Mail to a list with a hyphen in its name languishes forever in qfiles/maildir. The culprit might be in MaildirRunner.py ,----[ MaildirRunner.py lines 65-74 ] # We only care about the listname and the subq as in listname@ or # listname-request@ lre = re.compile(r""" ^ # start of string (?P[^-@]+) # listname@ or listname-subq@ (?: # non-grouping - # dash separator (?P[^-+@]+) # everything up to + or - or @ )? # if it exists """, re.VERBOSE | re.IGNORECASE) `---- How about list-name@? jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030913/a23cf8dd/attachment.bin From rmg at terc.edu Sat Sep 13 12:46:54 2003 From: rmg at terc.edu (Robby Griffin) Date: Sat Sep 13 12:46:57 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch In-Reply-To: <3F5C4FF6.6080308@z3u.com> Message-ID: On Monday, September 8, 2003, at 05:46 AM, Steve Alexander wrote: > The only difference between a sendmail-style file and a postfix-style > file is that the postfix-style one starts with a line like: > > domain.tld IGNORED I find this unnecessary in my environment, so I think this is not strictly true. I have two virtual maps configured -- one in /etc/postfix, containing the IGNORED lines you mention as well as useful non-mailman aliases such as postmaster@domain.tld; the other is mailman's data/virtual-mailman, which does not need duplicate copies of the IGNORED lines. That said, your patch probably wouldn't do any harm. --Robby From r.barrett at openinfo.co.uk Sat Sep 13 14:56:00 2003 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Sat Sep 13 14:56:10 2003 Subject: [Mailman-Developers] [ 805630 ] Mail to foo-bar list languishes in maildir In-Reply-To: <878yosogo0.fsf@athene.jamux.com> Message-ID: On Saturday, September 13, 2003, at 04:24 pm, John A. Martin wrote: > Mail to a list with a hyphen in its name languishes forever in > qfiles/maildir. The culprit might be in MaildirRunner.py > > ,----[ MaildirRunner.py lines 65-74 ] > # We only care about the listname and the subq as in listname@ or > # listname-request@ > lre = re.compile(r""" > ^ # start of string > (?P[^-@]+) # listname@ or listname-subq@ > (?: # non-grouping > - # dash separator > (?P[^-+@]+) # everything up to + or - or @ > )? # if it exists > """, re.VERBOSE | re.IGNORECASE) > `---- > > How about list-name@? > > jam > You seem to have spotted an error in this experimental code. If it is of any use, I use essentially the following code in my Mailman mailer for Sendmail, which eliminates the need for maintaining an aliases file/db, and has to solve the same problem. # Possible VERP regexes and associated extraction variables # which may be defined in from mm_cfg.py # Add to this tuple if more VERP patterns are defined. POSSIBLE_VERP_REGEX_LIST = (('VERP_REGEXP', 'bounces'), ('VERP_CONFIRM_REGEXP', 'addr')) _VALID_SUFFIX_MAP = {'admin': 'admin', 'bounces': 'bounces', 'confirm': 'confirm', 'join': 'join', 'leave': 'leave', 'owner': 'owner', 'request': 'request', 'subscribe': 'subscribe', 'unsubscribe': 'unsubscribe', } _suffix_pat = re.compile(r'(?P.+)-(?P[^-]+)$') def split_addr(address): # We are here trying to split the target alias as passed in # by the MTA because it was not simply a listname. We could # have a VERP'ed return address and/or a listname- alias. # Because there are multiple VERP formats and associated regexes # and these can be redefined in mm_cfg.py we cannot hardwire a # regex here to extract from VERP'ed return addresses. command = None listname, server = address.split('@', 1) for regex_pat_name, regex_var in POSSIBLE_VERP_REGEX_LIST: if hasattr(mm_cfg, regex_pat_name): regex_obj = re.compile(getattr(mm_cfg, regex_pat_name)) match_obj = regex_obj.search(address) if match_obj: listname = match_obj.group(regex_var) break suffix_match = _suffix_pat.match(listname) if suffix_match and \ _VALID_SUFFIX_MAP.has_key(suffix_match.group('suffix')) and \ Utils.list_exists(suffix_match.group('listname')): listname = suffix_match.group('listname') command = _VALID_SUFFIX_MAP[suffix_match.group('suffix')] return (listname, command) ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From barry at python.org Sat Sep 13 18:43:42 2003 From: barry at python.org (Barry Warsaw) Date: Sat Sep 13 18:43:49 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch In-Reply-To: <3F5C4FF6.6080308@z3u.com> References: <3F5C4FF6.6080308@z3u.com> Message-ID: <1063493021.19907.180.camel@anthem> On Mon, 2003-09-08 at 05:46, Steve Alexander wrote: > Mailman 2.1.2 writes out a "sendmail-style" virtual-mailman file rather > than a "postfix-style" virtual-mailman file. > > I don't know whether this is what is intended, but it seems counter to > what I read in the README.POSTFIX file, and using the > POSTFIX_STYLE_VIRTUAL_DOMAINS setting. Actually, while it may not be entirely clear from README.POSTFIX, my intention was that you set up your Postfix-style virtual domains in Postfix first, e.g. such that /path/to/postfix/etc/virtual-example would contain the "example.com IGNORE" line. As Robby said though, any duplicate IGNORED lines probably won't hurt, so your patch may be helpful for some sites. I'll test it on my own servers to make sure. -Barry From jam at jamux.com Sat Sep 13 21:07:53 2003 From: jam at jamux.com (John A. Martin) Date: Sat Sep 13 21:08:04 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch In-Reply-To: <1063493021.19907.180.camel@anthem> (Barry Warsaw's message of "13 Sep 2003 18:43:42 -0400") References: <3F5C4FF6.6080308@z3u.com> <1063493021.19907.180.camel@anthem> Message-ID: <8765jwmb2u.fsf@athene.jamux.com> >>>>> "baw" == Barry Warsaw >>>>> "Re: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch" >>>>> 13 Sep 2003 18:43:42 -0400 baw> On Mon, 2003-09-08 at 05:46, Steve Alexander wrote: >> Mailman 2.1.2 writes out a "sendmail-style" virtual-mailman >> file rather than a "postfix-style" virtual-mailman file. >> >> I don't know whether this is what is intended, but it seems >> counter to what I read in the README.POSTFIX file, and using >> the POSTFIX_STYLE_VIRTUAL_DOMAINS setting. baw> Actually, while it may not be entirely clear from baw> README.POSTFIX, my intention was that you set up your baw> Postfix-style virtual domains in Postfix first, e.g. such baw> that /path/to/postfix/etc/virtual-example would contain the baw> "example.com IGNORE" line. baw> As Robby said though, any duplicate IGNORED lines probably baw> won't hurt, so your patch may be helpful for some sites. baw> I'll test it on my own servers to make sure. ISTM the Postfix documentation is pretty clear with one virtual-alias.domain anything line. Anything else even that might "work" would be exploiting an undocumented feature that might well change without notice, IMHO. ,----[ man virtual ] VIRTUAL(5) VIRTUAL(5) NAME virtual - format of Postfix virtual alias table [[ .... ]] Support for a virtual alias domain looks like: /etc/postfix/main.cf: virtual_alias_maps = hash:/etc/postfix/virtual Note: some systems use dbm databases instead of hash. See the out- put from postconf -m for available database types. /etc/postfix/virtual: virtual-alias.domain anything (right-hand content does not matter) postmaster@virtual-alias.domain postmaster user1@virtual-alias.domain address1 user2@virtual-alias.domain address2, address3 The virtual-alias.domain anything entry is required for a virtual alias domain. Without this entry, mail is rejected with "relay access denied", or bounces with "mail loops back to myself". [[ .... ]] `---- jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030913/5dade55e/attachment.bin From philb at philb.us Sat Sep 13 21:45:30 2003 From: philb at philb.us (Phil Barnett) Date: Sat Sep 13 21:45:39 2003 Subject: [Mailman-Developers] Subscriber list In-Reply-To: References: Message-ID: <200309132145.30566.philb@philb.us> On Saturday 06 September 2003 6:15 pm, manuyamin@SAFe-mail.net wrote: > I would like to retrieve my complete list of subscriber (i'm using mailman) > in a text file but i don't know how to do it, can someone help me please ? > (i've more than 20000 subscribers) > > Thank you very much (sorry for my poor english talking, i'm french) /home/mailman/bin/list_members listname > ./listname.out -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. From barry at python.org Sun Sep 14 00:32:45 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 14 00:32:51 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch In-Reply-To: <8765jwmb2u.fsf@athene.jamux.com> References: <3F5C4FF6.6080308@z3u.com> <1063493021.19907.180.camel@anthem> <8765jwmb2u.fsf@athene.jamux.com> Message-ID: <1063513965.3361.4.camel@geddy> On Sat, 2003-09-13 at 21:07, John A. Martin wrote: > ISTM the Postfix documentation is pretty clear with one > > virtual-alias.domain anything > > line. Anything else even that might "work" would be exploiting an > undocumented feature that might well change without notice, IMHO. Interesting. You prompted me to go back and read the documentation for virtual domains, which I realize I hadn't done since switching to Postfix 2.0.x. The terminology has changed -- what used to be called Postfix-style virtual domains is now just virtual host domains, and there's no mention of Sendmail-style domains. I think the deal is that if you have other aliases in your virtual domain, you've already got the IGNORED line in those other virtual files. But if you've only got mailing lists in those virtual domains, then you might not have the IGNORED lines set up. I'm tempted to update the documentation and back out the patch (which didn't work anyway when there are multiple virtual domains present). -Barry From barry at python.org Sun Sep 14 01:08:03 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 14 01:07:58 2003 Subject: [Mailman-Developers] Mailman 2.1.2 doesn't work with postfix-style virtual domains + patch In-Reply-To: <1063513965.3361.4.camel@geddy> References: <3F5C4FF6.6080308@z3u.com> <1063493021.19907.180.camel@anthem> <8765jwmb2u.fsf@athene.jamux.com> <1063513965.3361.4.camel@geddy> Message-ID: <1063516083.3361.6.camel@geddy> On Sun, 2003-09-14 at 00:32, Barry Warsaw wrote: > The terminology has changed -- what used to be called > Postfix-style virtual domains is now just virtual host domains Correction, make that "virtual alias domains". -Barry From marc_news at merlins.org Mon Sep 15 01:38:31 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Mon Sep 15 01:38:37 2003 Subject: [Mailman-Developers] Attachments In-Reply-To: <20038230226.395430@alfa> References: <20038230226.395430@alfa> Message-ID: <20030915053831.GC20470@merlins.org> On Sat, Aug 23, 2003 at 12:02:26AM -0700, Mike Burton wrote: > Does anyone know if there is a patch to strip an attachment from list > mail, save it to disk (in the web directory), and insert a URL to the file > in it's place with Mailman 2.x? If not, some clues on where this might > fit in would be appreciated (I would be willing to look at coding it). The feature isn't there, but you can code it with minimal work IMO because pipermail already has code that does just that. The idea would be to call the pipermail code to modify the body of the message before it's sent back out (of course, that would only work if the list is archived, and it would be a pain in the butt for lists that require you to log in before viewing archives) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jwblist at olympus.net Mon Sep 15 02:04:55 2003 From: jwblist at olympus.net (John W. Baxter) Date: Mon Sep 15 02:05:20 2003 Subject: [Mailman-Developers] Subscriber list In-Reply-To: <200309132145.30566.philb@philb.us> Message-ID: On 9/13/2003 18:45, "Phil Barnett" wrote: > On Saturday 06 September 2003 6:15 pm, manuyamin@SAFe-mail.net wrote: > >> I would like to retrieve my complete list of subscriber (i'm using mailman) >> in a text file but i don't know how to do it, can someone help me please ? >> (i've more than 20000 subscribers) >> >> Thank you very much (sorry for my poor english talking, i'm french) > > /home/mailman/bin/list_members listname > ./listname.out The above is the reply we always see to this question, on mailman-developers and on mailman-users, but it is impractical for some fraction of the list administrators out there. Either the email help command is out of date, or the list can be retrieved from email *without* having to bother some curmudgeonly sysadmin (such as myself). The help command says: who password See everyone who is on this mailing list. The roster is limited to list administrators and moderators only; you must supply the list admin or moderator password to retrieve the roster. I just checked...the command works for me...for a smallish list (under 70 subscribers). --John From spacey-mailman at lenin.nu Mon Sep 15 14:50:33 2003 From: spacey-mailman at lenin.nu (Peter C. Norton) Date: Mon Sep 15 14:50:40 2003 Subject: [Mailman-Developers] Problem with MM after power outage In-Reply-To: <1063403760.19907.93.camel@anthem> References: <1061330802.1131.18.camel@geddy> <200308200045.23234.pioppo@ferrara.linux.it> <1063373997.19907.44.camel@anthem> <1063384531.19907.67.camel@anthem> <87wuce6j47.fsf@athene.jamux.com> <20030912211425.GK5719@lenin.nu> <1063403760.19907.93.camel@anthem> Message-ID: <20030915185033.GE27313@lenin.nu> On Fri, Sep 12, 2003 at 05:56:00PM -0400, Barry Warsaw wrote: > On Fri, 2003-09-12 at 17:40, Harald Meland wrote: > > Hence, I think it makes more sense to have the default be "do > > fsync(2)", and let any performance-conscious site decide whether it > > wants to explicitly value performance over safety. > > Except that when I did some very simple tests, I saw a 97% hit in > performance with fsync turned on. This on a RH9, ext3 Linux box of the > Dell Optiplex variety. That makes me very nervous to add in a patch > release that won't have any beta testing. I've also never seen the bug > on python.org, which may or may not be representative of the world at > large. Wow. 97%? That's way too high. I'd expect about 50% at worst - for the extra sync to disk when it enters mailman's queue and one more to flush the message when its made it though the outbound queue to the MTA. This is just a question, because I still don't know much about the mm 2.1 internals, but is there a chance you're sync()'ing more often then you need? > I'm happy to re-address this for the next major release, but for 2.1.3 I > don't want to enable fsync by default, and I definitely don't want to do > any probing/guessing of filesystems, etc. That makes sense to me. -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From shaikli at yahoo.com Tue Sep 16 19:18:59 2003 From: shaikli at yahoo.com (Nadim Shaikli) Date: Tue Sep 16 19:19:03 2003 Subject: [Mailman-Developers] Scripts' consistency Message-ID: <20030916231859.52760.qmail@web14909.mail.yahoo.com> A minor (non-critical) suggestion. It would be ideal if all the scripts had similar input/command-line formats and were grouped per type. For instance add_members clone_member find_member list_members remove_members sync_members all deal with members so maybe they should be named members_* so you'd end-up with members_add members_clone members_find members_list members_remove members_sync Currently the command-line of the above consists of, add_members [options] listname -r in_file (regular) -d in_file (digest) remove_members [options] [listname] [addr1 ...] -f in_file Here it would be ideal if the options were the same esp on the command-line (ie. offer addr1, etc to add_members). The usage of brackets is also a bit misleading as it denotes all optionals (not true in 'remove_members' and 'newlist', among others). I'd suggest, members_add [options] listname [addr1 ...] -i in_file (regular) -d in_file (digest) members_remove [options] listname [addr1 ...] -i in_file To ease life for the list administrators, I would humbly suggest to change the following script names from, check_db dumpdb config_list list_admins list_lists list_owners newlist rmlist be replaced with, db_check db_dump list_config list_admins list_lists list_owners list_new list_remove this would also match the suggested 'members' scripts above. Finally, all the other scripts that relate to mailman administration could be changed from, genaliases inject transcheck unshunt update version withlist mailmanctl to admin_genaliases admin_inject admin_trans_check admin_unshunt admin_update admin_version admin_withlist mailman_ctl (or maybe ctl_mailman) where other control/qrunner/etc scripts could be bunched into the mailman_* group. Just a suggestion. Its rather hard to make one's way through all the scripts and to know what they all do and what format they all require. Consistency and grouping would be nice. NOTE: various other .py* scripts within same dir were skipped. Sorry for the noise. Regards, - Nadim __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From Tom at ESEstudios.com Wed Sep 17 01:46:47 2003 From: Tom at ESEstudios.com (Tom Eagle) Date: Wed Sep 17 01:49:13 2003 Subject: [Mailman-Developers] Real Name in addition to email addresses on Roster page Message-ID: <003d01c37cdf$190030e0$6401a8c0@ESEstudios.com> Can the "Real Name" field be added to the Roster page along with the Email Address? Tom Eagle From wheakory at isu.edu Wed Sep 17 18:12:46 2003 From: wheakory at isu.edu (Kory Wheatley) Date: Wed Sep 17 18:13:05 2003 Subject: [Mailman-Developers] Unsubscribe Email command Message-ID: <3F68DC5E.1070407@isu.edu> I know that a subscriber can unsubscribe themselves without a password using the email command, or someone else can unsubscribe the user if they know their password to the mailing list., with this command Example: "unsubscribe mail11 address=wheakorypersonal@yahoo.com" and sending this to list-request@mm.isu.edu But how can the Administrator of the list unsubscribe anyone without knowing their password, I know that the Administrator can do it through the membership management option and through the command line, But I need to do this through the email command. I tried unsubscribing an user by using the admin password and the global password, but this don't work, it requires the subscriber password. I would like to know if there is a work around for this? -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From jason at mastaler.com Wed Sep 17 19:38:13 2003 From: jason at mastaler.com (Jason R. Mastaler) Date: Wed Sep 17 19:38:20 2003 Subject: [Mailman-Developers] Re: TMDA fronted Mailman v2.1 lists References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <12736.1056429809@kanga.nu> <1056458063.2667.1.camel@anthem> Message-ID: Barry Warsaw writes: > On Tue, 2003-06-24 at 00:43, J C Lawrence wrote: > >> ObNote2: TMDA as of v0.75 (latest .deb)is not able to read >> Mailman v2.1 list configurations to extract the membership >> rosters (the pickle now contains bounce objects so the naive >> cPickle.load fails). This doesn't create a major problem, just >> means that you have to comment sections of your TMDA filters >> until that's fixed. (Jason: If you want example configs and >> other details, just give me the word and I'll attach them over). > > That might be a simple matter of putting $prefix on your PYTHONPATH > when you start up TMDA. It needs to find the Mailman.Bouncer module > to get the _BounceInfo class. I'm in the middle of migrating my TMDA/Mailman setup from Mailman 2.0.13 to 2.1.2 and had expected to hit this, but I didn't. Things "just work" as they did. e.g, from TMDA's log: Date: Wed Sep 17 18:22:11 CDT 2003 From: Jason R Mastaler To: tmda-testing@Mastaler.COM Subj: there Actn: OK (from-mailman -attr=members /var/lib/mailman/lists/tmda-testing ok)(619) So I'm scratching my head wondering why I'm so lucky. Was this fixed in Mailman 2.1.2? Nothing has changed in TMDA between 0.75 and the current 0.84 that would account for this I don't think. From PieterB at gewis.nl Mon Sep 22 09:27:29 2003 From: PieterB at gewis.nl (PieterB) Date: Mon Sep 22 09:27:37 2003 Subject: [Mailman-Developers] OutgoingRunner qrunning 100% CPU Message-ID: <20030922152728.A72857@gewis.win.tue.nl> Hi, One of my qrunners (--runner=OutgoingRunner:0:1 -s) is eating 100% cpu continuously. I can't find what is causing it to do that. I found out I forgot one of the "-owner"-aliases for a specific list, but even after fixing that it is still eating away all CPU-cycles. I can't find anything strange in the mailman or postfix logs. Can anybody give me a clue, how I can see what is going wrong? My system: FreeBSD 4.8, python 2.2.3, mailman 2.1.2 Regards, Pieter -- Don't look back, something may be gaining on you. From barry at python.org Mon Sep 22 18:18:31 2003 From: barry at python.org (Barry Warsaw) Date: Mon Sep 22 18:18:41 2003 Subject: [Mailman-Developers] OutgoingRunner qrunning 100% CPU In-Reply-To: <20030922152728.A72857@gewis.win.tue.nl> References: <20030922152728.A72857@gewis.win.tue.nl> Message-ID: <1064269111.1986.83.camel@anthem> On Mon, 2003-09-22 at 09:27, PieterB wrote: > One of my qrunners (--runner=OutgoingRunner:0:1 -s) is eating 100% > cpu continuously. I can't find what is causing it to do that. > > I found out I forgot one of the "-owner"-aliases for a specific list, > but even after fixing that it is still eating away all CPU-cycles. > I can't find anything strange in the mailman or postfix logs. > > Can anybody give me a clue, how I can see what is going wrong? > > My system: FreeBSD 4.8, python 2.2.3, mailman 2.1.2 I wonder if this could be the Postfix-returning-450-instead-of-550 known bug in Mailman 2.1.2. If you have local addresses on your list that are non-existent, MM2.1.2 will spin heavily retrying delivery. There's a FAQ entry describing changes you can make to your main.cf file to prevent this. MM2.1.3 will also fix this problem. I expect 2.1.3 to be released next weekend -- we need to clear up some i18n issues before I can make the release. -Barry From barry at python.org Mon Sep 22 18:32:19 2003 From: barry at python.org (Barry Warsaw) Date: Mon Sep 22 18:32:33 2003 Subject: [Mailman-Developers] Mailman & CPanel? Message-ID: <1064269938.1986.98.camel@anthem> I recently received a message about problems with Mailman and CPanel. I don't know anything about CPanel, or why Mailman and CPanel might not be working together, but that doesn't mean I wouldn't be interested in helping to make sure this is still a viable solution. I know a lot of people use Mailman under CPanel, and I think that's a worthwhile thing to keep available. I'm perplexed by something the message said though: After many complaints, support at the host company said this: "Well, mailman has just released a statement that they will not support CPanel-based mailman installations anymore due to the fact that the CPanel developers have not correctly implemented their solution and causing it to fail, so there isn't much we can do either if both mailman an cpanel developers do not support it. CPanel will most likely be discontinuing it from all servers, too." There are many things I don't understand about this, but let's start with "mailman has just released a statement...". I'm pretty sure /I/ didn't release such a statement, so unless someone has hijacked or forged my address, I don't believe this is accurate. :) Does anybody know anything about this? I'd like to get the record corrected: I have nothing against supporting CPanel in principle, and I'd be willing to learn more about what the problems were, and if there was anything we could do in Mailman to make this combination continue to work. Cheers, -Barry From chuqui at plaidworks.com Mon Sep 22 18:49:22 2003 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Mon Sep 22 18:49:35 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <1064269938.1986.98.camel@anthem> Message-ID: <024C10B1-ED4F-11D7-8068-0003934516A8@plaidworks.com> On Monday, September 22, 2003, at 03:32 PM, Barry Warsaw wrote: > I recently received a message about problems with Mailman and CPanel. www.cpanel.net It's a commercial tool ($1500/CPU, roughly) for gui access to administration of things. Basically seems designed for the colo/hosting market. One of the tools they've built a widget for is Mailman. That widget seems broken on at least one site. > helping to make sure this is still a viable solution. I know a lot of > people use Mailman under CPanel, and I think that's a worthwhile thing > to keep available. I think, given it's a commercial product, that we don't have much responsibility ot make sure cpanel works, not unless they pay for us to support it. They've taken Mailman, attached their system to manage it, and so it's up to cpanel to make sure cpanel works. > I'm perplexed by something the message said though: > > After many complaints, support at the host company said this: > "Well, > mailman has just released a statement that they will not > support > CPanel-based mailman installations anymore so am I. Not sure who might have said that. I think the appropriate response is really "we have no relationship with cPanel, and so it's up to cpanel to make sure the product it sells works, and the Mailman team has never been involved with cpanel in any way" > > Does anybody know anything about this? I've seen people asking about it on ListOwners. I've kept my head down because I didn't know what you'd said/done, but it sort of sounds like it's either the cPanel folks trying to blame Mailman for its own problems, or an ISP trying to blame cPanel and/or mailman. I know we've never explicitly supported cPanel in the mailman projects. it seems like cPanel is the crew to bring this up with, not us. From rob at ecommerce-magic.com Mon Sep 22 19:02:43 2003 From: rob at ecommerce-magic.com (Robert Anderson) Date: Mon Sep 22 19:02:58 2003 Subject: [Mailman-Developers] Mailman & CPanel? In-Reply-To: <1064269938.1986.98.camel@anthem> References: <1064269938.1986.98.camel@anthem> Message-ID: <1064271762.2072.104.camel@homer.ecommerce-magic.com> A little off topic perhaps but I believe that at least one other open source project (Interchange Ecommerce System) does have a NO SUPPORT policy for CPanel users. I believe that they where having problems with the amount of very inexperienced webmasters who where sold a CPanel hosting solution and told that the guys over at the icdevgroup.org (interchange development group) provide free support. These webmasters expected that if they checked the "Interchange" box on a web page they would get a free full featured ecommerce software package. And if it didn't work it was up to the open source community to fix their problems for free. I don't know the answer but is mailman really an out of the box solution that is suitable for users without basic programming or linux sysadmin skills? Because there are a lot of CPanel users in this category. -- Robert Anderson Managing Director Ecommerce Magic Ltd http://www.ecommerce-magic.com +64 21 808 525 From rob at ecommerce-magic.com Mon Sep 22 19:02:43 2003 From: rob at ecommerce-magic.com (Robert Anderson) Date: Mon Sep 22 19:03:26 2003 Subject: [Mailman-Developers] Mailman & CPanel? In-Reply-To: <1064269938.1986.98.camel@anthem> References: <1064269938.1986.98.camel@anthem> Message-ID: <1064271762.2072.104.camel@homer.ecommerce-magic.com> A little off topic perhaps but I believe that at least one other open source project (Interchange Ecommerce System) does have a NO SUPPORT policy for CPanel users. I believe that they where having problems with the amount of very inexperienced webmasters who where sold a CPanel hosting solution and told that the guys over at the icdevgroup.org (interchange development group) provide free support. These webmasters expected that if they checked the "Interchange" box on a web page they would get a free full featured ecommerce software package. And if it didn't work it was up to the open source community to fix their problems for free. I don't know the answer but is mailman really an out of the box solution that is suitable for users without basic programming or linux sysadmin skills? Because there are a lot of CPanel users in this category. -- Robert Anderson Managing Director Ecommerce Magic Ltd http://www.ecommerce-magic.com +64 21 808 525 From barry at python.org Mon Sep 22 19:09:40 2003 From: barry at python.org (Barry Warsaw) Date: Mon Sep 22 19:09:47 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <024C10B1-ED4F-11D7-8068-0003934516A8@plaidworks.com> References: <024C10B1-ED4F-11D7-8068-0003934516A8@plaidworks.com> Message-ID: <1064272179.1986.123.camel@anthem> On Mon, 2003-09-22 at 18:49, Chuq Von Rospach wrote: > > Does anybody know anything about this? > > I've seen people asking about it on ListOwners. I've kept my head down > because I didn't know what you'd said/done, but it sort of sounds like > it's either the cPanel folks trying to blame Mailman for its own > problems, or an ISP trying to blame cPanel and/or mailman. I know we've > never explicitly supported cPanel in the mailman projects. it seems > like cPanel is the crew to bring this up with, not us. Ah, thanks for the info Chuq. I think you've got the right take on things, except that I'd add this: if the cPanel developers have specific issues with Mailman that are causing them problems, I'd be happy to hear about them, and if it makes sense, to address them. I also wouldn't turn down their money . Other than that, you're right, we really don't have any relationship with them, which is different than saying we're actively not supporting it anymore (not that we did in the first place :). -Barry From barry at python.org Mon Sep 22 19:25:33 2003 From: barry at python.org (Barry Warsaw) Date: Mon Sep 22 19:25:45 2003 Subject: [Mailman-Developers] Mailman & CPanel? In-Reply-To: <1064271762.2072.104.camel@homer.ecommerce-magic.com> References: <1064269938.1986.98.camel@anthem> <1064271762.2072.104.camel@homer.ecommerce-magic.com> Message-ID: <1064273133.1986.140.camel@anthem> On Mon, 2003-09-22 at 19:02, Robert Anderson wrote: > I don't know the answer but is mailman really an out of the box solution > that is suitable for users without basic programming or linux sysadmin > skills? Because there are a lot of CPanel users in this category. Installation and setup definitely requires sysadmin guru status, but I think /use/ doesn't (or at least, shouldn't). There's still some things you can't do through the web, but we'll eventually support most of the more common things people would want to do. -Barry From PieterB at gewis.nl Mon Sep 22 19:21:42 2003 From: PieterB at gewis.nl (PieterB) Date: Mon Sep 22 19:36:00 2003 Subject: [Mailman-Developers] OutgoingRunner qrunning 100% CPU In-Reply-To: <1064269111.1986.83.camel@anthem>; from barry@python.org on Mon, Sep 22, 2003 at 06:18:31PM -0400 References: <20030922152728.A72857@gewis.win.tue.nl> <1064269111.1986.83.camel@anthem> Message-ID: <20030923012142.A98732@gewis.win.tue.nl> On Mon, Sep 22, 2003 at 06:18:31PM -0400, Barry Warsaw wrote: > On Mon, 2003-09-22 at 09:27, PieterB wrote: > > > One of my qrunners (--runner=OutgoingRunner:0:1 -s) is eating 100% > > cpu continuously. I can't find what is causing it to do that. > I wonder if this could be the Postfix-returning-450-instead-of-550 known > bug in Mailman 2.1.2. If you have local addresses on your list that are > non-existent, MM2.1.2 will spin heavily retrying delivery. There's a > FAQ entry describing changes you can make to your main.cf file to > prevent this. MM2.1.3 will also fix this problem. I expect 2.1.3 to be > released next weekend -- we need to clear up some i18n issues before I > can make the release. I had some 450's in my maillog, but they were all because another local alias didn't exist. Creating the alias didn't change the 100% CPU time eating of the qrunner. I also changed my Postfix to http://www.python.org/cgi-bin/faqw-mm.py?query=450&querytype=simple&casefold=yes&req=search (but no avail). I think maybe my qfiles/ dir or data/pending.pck is corrupt (or something completly different), but I can't find anything strange with "check_db" or "dump_db". I'll give mailman 2.1.3 a try when it's available. Is there a way a way to get some more debug info on what the OutgoingRunner is doing? Pieter -- "Close" only counts in horseshoes, handgrenades and thermonuclear devices. From jonc at nc.rr.com Mon Sep 22 20:34:09 2003 From: jonc at nc.rr.com (Jon Carnes) Date: Mon Sep 22 20:34:28 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <1064272179.1986.123.camel@anthem> References: <024C10B1-ED4F-11D7-8068-0003934516A8@plaidworks.com> <1064272179.1986.123.camel@anthem> Message-ID: <1064277249.5049.34.camel@Anncons4> On Mon, 2003-09-22 at 19:09, Barry Warsaw wrote: > On Mon, 2003-09-22 at 18:49, Chuq Von Rospach wrote: > > > > Does anybody know anything about this? > > > > I've seen people asking about it on ListOwners. I've kept my head down > > because I didn't know what you'd said/done, but it sort of sounds like > > it's either the cPanel folks trying to blame Mailman for its own > > problems, or an ISP trying to blame cPanel and/or mailman. I know we've > > never explicitly supported cPanel in the mailman projects. it seems > > like cPanel is the crew to bring this up with, not us. > > Ah, thanks for the info Chuq. I think you've got the right take on > things, except that I'd add this: if the cPanel developers have specific > issues with Mailman that are causing them problems, I'd be happy to hear > about them, and if it makes sense, to address them. I also wouldn't > turn down their money . > > Other than that, you're right, we really don't have any relationship > with them, which is different than saying we're actively not supporting > it anymore (not that we did in the first place :). > > -Barry > We've seen a lot of CPanel folks coming here for help. I basically delete those, since we can never help them. But a few times folks on the list have expressed that we can't help them; that could easily be interpreted as "Mailman won't support CPanel installs". One frustrating item that is expressed periodically is that CPanel won't open their source up. It would be nice if they would provide some sort of API or if they would release the source of their "Mailman widget" that controls Mailman - then we *could* help them. I'm very surprised that no one from CPanel has approached Barry or the developers-list yet. There is a lot broken with CPanel that could be made much better with some shared ideas. Jon Carnes From brad.knowles at skynet.be Mon Sep 22 20:33:43 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon Sep 22 20:58:00 2003 Subject: [Mailman-Developers] Mailman & CPanel? In-Reply-To: <1064273133.1986.140.camel@anthem> References: <1064269938.1986.98.camel@anthem> <1064271762.2072.104.camel@homer.ecommerce-magic.com> <1064273133.1986.140.camel@anthem> Message-ID: At 7:25 PM -0400 2003/09/22, Barry Warsaw wrote: > Installation and setup definitely requires sysadmin guru status, but I > think /use/ doesn't (or at least, shouldn't). There's still some things > you can't do through the web, but we'll eventually support most of the > more common things people would want to do. Guru status? Mrf? Okay, so we've gone to quite a bit more pain thanks to the way our apache2 chroot is set up, and someone else has done most of that work, but I've seen the mailman installation instructions and nothing there seems to be particularly difficult. Certainly not something that would require "guru" status. Have I missed something? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From bob at nleaudio.com Mon Sep 22 21:17:02 2003 From: bob at nleaudio.com (Bob Puff@NLE) Date: Mon Sep 22 21:17:05 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <1064277249.5049.34.camel@Anncons4> References: <024C10B1-ED4F-11D7-8068-0003934516A8@plaidworks.com> <1064272179.1986.123.camel@anthem> <1064277249.5049.34.camel@Anncons4> Message-ID: <20030923011702.M88632@nleaudio.com> Yeah, I totally agree. I looked at cpanel about a year or so ago. Tried it on a test server. The thing's config is just so screwy that I couldn't make (quick) sense of how they handled even just postfix, let alone mailman and all the virtual domains stuff. Definitely not "stock" installs of any of the programs bundled with them, or "stock" configs. And the fact that they are not open source makes me want to stay away even more. Bob ---------- Original Message ----------- From: Jon Carnes To: Barry Warsaw Sent: 22 Sep 2003 20:34:09 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? > On Mon, 2003-09-22 at 19:09, Barry Warsaw wrote: > > On Mon, 2003-09-22 at 18:49, Chuq Von Rospach wrote: > > > > > > Does anybody know anything about this? > > > > > > I've seen people asking about it on ListOwners. I've kept my head down > > > because I didn't know what you'd said/done, but it sort of sounds like > > > it's either the cPanel folks trying to blame Mailman for its own > > > problems, or an ISP trying to blame cPanel and/or mailman. I know we've > > > never explicitly supported cPanel in the mailman projects. it seems > > > like cPanel is the crew to bring this up with, not us. > > > > Ah, thanks for the info Chuq. I think you've got the right take on > > things, except that I'd add this: if the cPanel developers have specific > > issues with Mailman that are causing them problems, I'd be happy to hear > > about them, and if it makes sense, to address them. I also wouldn't > > turn down their money . > > > > Other than that, you're right, we really don't have any relationship > > with them, which is different than saying we're actively not supporting > > it anymore (not that we did in the first place :). > > > > -Barry > > > > We've seen a lot of CPanel folks coming here for help. I basically > delete those, since we can never help them. But a few times folks on > the list have expressed that we can't help them; that could easily be > interpreted as "Mailman won't support CPanel installs". > > One frustrating item that is expressed periodically is that CPanel won't > open their source up. It would be nice if they would provide some sort > of API or if they would release the source of their "Mailman widget" > that controls Mailman - then we *could* help them. > > I'm very surprised that no one from CPanel has approached Barry or > the developers-list yet. There is a lot broken with CPanel that > could be made much better with some shared ideas. > > Jon Carnes > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers ------- End of Original Message ------- From chuqui at plaidworks.com Mon Sep 22 22:40:55 2003 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Mon Sep 22 22:42:33 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <20030923011702.M88632@nleaudio.com> Message-ID: <5B432BD2-ED6F-11D7-8068-0003934516A8@plaidworks.com> so perhaps the Mailman FAQ should have an item suggesting Cpanel users contact Cpanel for support? On Monday, September 22, 2003, at 06:17 PM, Bob Puff@NLE wrote: > Definitely not "stock" installs of any of the > programs bundled with them, or "stock" configs. From rob at ecommerce-magic.com Mon Sep 22 23:01:26 2003 From: rob at ecommerce-magic.com (Robert Anderson) Date: Mon Sep 22 23:02:35 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman & CPanel? In-Reply-To: <5B432BD2-ED6F-11D7-8068-0003934516A8@plaidworks.com> References: <5B432BD2-ED6F-11D7-8068-0003934516A8@plaidworks.com> Message-ID: <1064286086.2072.165.camel@homer.ecommerce-magic.com> On Tue, 2003-09-23 at 14:40, Chuq Von Rospach wrote: > so perhaps the Mailman FAQ should have an item suggesting Cpanel users > contact Cpanel for support? > For what it's worth this idea has my vote. > > On Monday, September 22, 2003, at 06:17 PM, Bob Puff@NLE wrote: > > > Definitely not "stock" installs of any of the > > programs bundled with them, or "stock" configs. > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- Robert Anderson Managing Director Ecommerce Magic Ltd http://www.ecommerce-magic.com +64 21 808 525 From wheakory at isu.edu Tue Sep 23 01:15:01 2003 From: wheakory at isu.edu (Kory Wheatley) Date: Tue Sep 23 01:15:10 2003 Subject: [Mailman-Developers] lost data files for filebase Message-ID: <3F6FD6D5.4020500@isu.edu> I'm going these errors in the error log for mailman 2.1 on RED HAT 9 , Python 2.2 Here's the errors Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243291.09331+d473693c98d3d8d8b251c45f7b36ef47009afbc1 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243292.06778+eb8df709a22017653552825e42ddaadebc2ed27f Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243296.583845+a33368a7b5929d3651a9857237d3b0bf73e47599 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243345.690969+cba1a653bc7c104a639147d8f5d68156d603db0f Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243382.699338+ee1a8616c1dd74b2b38d6a5a00cbd900611aa4b6 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064243559.031534+d70b87da87bd35dc7a8ed376b0914a447ed50284 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064244308.556132+47da5be929c7e4895caa21e917fa4233352ee932 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064244559.5556411+dc264fc752653b09650609afc700738a1b6ca57 Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064257065.58655+b5f6b7eb3a0808f81e3776ffa2dbcfed58318cad Sep 22 23:02:47 2003 (26500) lost data files for filebase: 1064288683.7312551+3d3abeb8c3649419b571a98a87f524e1d2ff667 From gsstark at mit.edu Wed Sep 24 11:57:39 2003 From: gsstark at mit.edu (Greg Stark) Date: Wed Sep 24 11:57:43 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <871y32qzae.fsf@stark.dyndns.tv> References: <871y32qzae.fsf@stark.dyndns.tv> Message-ID: <87eky6kwlo.fsf@stark.dyndns.tv> The problem I described in January is still happening. I find the current bounce processing of mailman to be inadequate. Something more like the bounce processing of ezmlm is needed. I should not be removed from a mailing list purely on the basis of bounces of uncontrolled messages. The messages that bounced could have been spam or outlook worms or whatever. Before removing a subscriber mailman should send a message with known content testing the address. Only if such a message bounces should a user be dropped. As it is I'm being removed from mailing lists whenever a new Outlook worm appears and sends multiple messages in a row. Or a new spammer discovers a list I'm on and sends multiple messages in a row to the list. It's especially bad on low-volume lists where it's quite possible for spam or Outlook worm messages to be the only messages for days. Greg Stark writes: > I find I am being removed from mailman mailing lists left and right. I believe > the default values for the bounce removal should be reconsidered. It's > possible that you haven't had many users in my situation and so haven't really > had a chance to tune these parameters on the low end yet. But they clearly > aren't working for me at a few sites. > > My particular situation is that my site has seen fit to filter viruses by > refusing delivery. This causes a bounce from the remote MTA every time someone > sends me an Outlook virus. Why my site administrators felt this was necessary > is a question for another day, it's not like I use Outlook or like my spam > filters wouldn't have thrown these messages away anyways, but whatever. > > The net result is that some small fraction of messages to me bounce and list > management software notices this. The only reason I became aware of the > problem was because ezmlm also does this type of processing but it sends a > warning message before removing users. It only removes you if the warning > message itself bounces. In fact it sends two such warning messages and only > removes the user if *both* bounce. This provides the user with a chance to > react to the first message and fix the problem -- if they ever see the > message. > > I could beg for a similar feature in mailman, but I'm not sure it's necessary. > But I am sure it's necessary to tune the bounce processing parameters. The > relatively few bounces I'm generating shouldn't be causing me to get removed > when all the real messages are being delivered fine. > > It seems the legitimate messages that are correctly delivered should reset the > count of bounces to 0. Reading the source it seems it has to see > DEFAULT_MAX_POSTS_BETWEEN_BOUNCES such legitimate posts between messages. I'm > fairly convinced this parameter should always be 0. If any successful delivery > occurs the user should never be removed due to bounces. > > What I don't understand is how DEFAULT_MAX_POSTS_BETWEEN_BOUNCES relates to > the parameters I see in the admin. None of the parameters in the admin > corresponds to this. How is it calculated? > > -- > greg > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > > -- greg From andrew.clark at ucsb.edu Wed Sep 24 18:38:10 2003 From: andrew.clark at ucsb.edu (Andrew D. Clark) Date: Wed Sep 24 18:38:13 2003 Subject: [Mailman-Developers] unremovable/broken member addresses Message-ID: <170680000.1064443090@modulus.oit.ucsb.edu> Hello all, I've encountered some list member addresses like so (I've substituted the domain name here to protect the guilty): %./list_members some-list bbest@goaway.spammer * ben I can't remove a member address like this: %./remove_members -n -N some-list "bbest@goaway.spammer * ben" Traceback (most recent call last): File "./remove_members", line 186, in ? main() File "./remove_members", line 176, in main admin_notif, userack) File "/home/services/mailman/Mailman/MailList.py", line 941, in ApprovedDeleteMember self.removeMember(emailaddr) File "/home/services/mailman/Mailman/OldStyleMemberships.py", line 220, in removeMember self.__assertIsMember(member) File "/home/services/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member Mailman.Errors.NotAMemberError: bbest@goaway.spammer*ben Nor does it work by escaping the spaces and/or the *. Doesn't work via the web front end either. Any ideas? -- Andrew Clark Campus Network Programmer Office of Information Technology University of California, Santa Barbara andrew.clark@ucsb.edu (805) 893-5311 From larva at linux.ucla.edu Wed Sep 24 20:59:20 2003 From: larva at linux.ucla.edu (Matt Helsley) Date: Wed Sep 24 20:59:25 2003 Subject: [Mailman-Developers] unremovable/broken member addresses In-Reply-To: <170680000.1064443090@modulus.oit.ucsb.edu> Message-ID: How about using single quotes (in Bbash)?: %./remove_members -n -N some-list 'bbest@goaway.spammer * ben' I think that should pass the whole thing as one element of remove_members' argv. This would only work if the missing space was what "caused the problem". What's the policy on reporting errors back to the user? Should exceptions like this cause termination or should they usually be caught by the caller etc.. ? Cheers, -Matt Helsley On Wed, 24 Sep 2003, Andrew D. Clark wrote: > I can't remove a member address like this: > > %./remove_members -n -N some-list "bbest@goaway.spammer * ben" > Traceback (most recent call last): > File "./remove_members", line 186, in ? > main() > File "./remove_members", line 176, in main > admin_notif, userack) > File "/home/services/mailman/Mailman/MailList.py", line 941, in > ApprovedDeleteMember > self.removeMember(emailaddr) > File "/home/services/mailman/Mailman/OldStyleMemberships.py", line > 220, in removeMember > self.__assertIsMember(member) > File "/home/services/mailman/Mailman/OldStyleMemberships.py", line > 113, in __assertIsMember > raise Errors.NotAMemberError, member > Mailman.Errors.NotAMemberError: bbest@goaway.spammer*ben From andrew.clark at ucsb.edu Wed Sep 24 21:34:35 2003 From: andrew.clark at ucsb.edu (Andrew D. Clark) Date: Wed Sep 24 21:34:40 2003 Subject: [Mailman-Developers] unremovable/broken member addresses In-Reply-To: References: Message-ID: <189000000.1064453675@modulus.oit.ucsb.edu> Nope, same traceback. Seems like maybe remove_members is doing some string scrubbing that it perhaps should not. I should have stated I've tried nearly all permutations of shell single/double quoting and escaping I can think of (but please don't let that stop anyone from suggesting one of which I might not have thought). But I'd much rather do some quoting and escaping than go Python code diving. --Andrew --On Wednesday, September 24, 2003 05:59:20 PM -0700 Matt Helsley wrote: > How about using single quotes (in Bbash)?: > %./remove_members -n -N some-list 'bbest@goaway.spammer * ben' > > I think that should pass the whole thing as one element of > remove_members' argv. This would only work if the missing space was > what "caused the problem". > > What's the policy on reporting errors back to the user? Should > exceptions like this cause termination or should they usually be > caught by the caller etc.. ? > > Cheers, > -Matt Helsley > > On Wed, 24 Sep 2003, Andrew D. Clark wrote: > >> I can't remove a member address like this: >> >> %./remove_members -n -N some-list "bbest@goaway.spammer * ben" >> Traceback (most recent call last): >> File "./remove_members", line 186, in ? >> main() >> File "./remove_members", line 176, in main >> admin_notif, userack) >> File "/home/services/mailman/Mailman/MailList.py", line 941, in >> ApprovedDeleteMember >> self.removeMember(emailaddr) >> File "/home/services/mailman/Mailman/OldStyleMemberships.py", line >> 220, in removeMember >> self.__assertIsMember(member) >> File "/home/services/mailman/Mailman/OldStyleMemberships.py", line >> 113, in __assertIsMember >> raise Errors.NotAMemberError, member >> Mailman.Errors.NotAMemberError: bbest@goaway.spammer*ben > From tkikuchi at is.kochi-u.ac.jp Wed Sep 24 22:23:30 2003 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Sep 24 22:23:51 2003 Subject: [Mailman-Developers] unremovable/broken member addresses In-Reply-To: <189000000.1064453675@modulus.oit.ucsb.edu> References: <189000000.1064453675@modulus.oit.ucsb.edu> Message-ID: <3F7251A2.3060605@is.kochi-u.ac.jp> Try this; http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp Andrew D. Clark wrote: > Nope, same traceback. Seems like maybe remove_members is doing some > string scrubbing that it perhaps should not. I should have stated I've > tried nearly all permutations of shell single/double quoting and > escaping I can think of (but please don't let that stop anyone from > suggesting one of which I might not have thought). But I'd much rather > do some quoting and escaping than go Python code diving. > > --Andrew > > --On Wednesday, September 24, 2003 05:59:20 PM -0700 Matt Helsley > wrote: > >> How about using single quotes (in Bbash)?: >> %./remove_members -n -N some-list 'bbest@goaway.spammer * ben' >> -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Thu Sep 25 09:15:03 2003 From: barry at python.org (Barry Warsaw) Date: Thu Sep 25 09:15:09 2003 Subject: [Mailman-Developers] unremovable/broken member addresses In-Reply-To: <3F7251A2.3060605@is.kochi-u.ac.jp> References: <189000000.1064453675@modulus.oit.ucsb.edu> <3F7251A2.3060605@is.kochi-u.ac.jp> Message-ID: <1064495702.12343.81.camel@anthem> On Wed, 2003-09-24 at 22:23, Tokio Kikuchi wrote: > Try this; > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp I've updated this FAQ entry to describe the removeMember() method which would be better to use, if possible. Also, I remember providing a remove_members recipe in some email message, but I haven't been able to track it down with Google. Oh well, I guess it's somewhere there in the great mass of forgotten wisdom. -Barry From eclauset at webslingerZ.com Tue Sep 16 02:14:36 2003 From: eclauset at webslingerZ.com (Ethan Clauset) Date: Thu Sep 25 09:36:51 2003 Subject: [Mailman-Developers] Full Personalization Message-ID: <0C457968-E80D-11D7-BA4C-000393D560E6@webslingerZ.com> I have full personalization on now and it seems to work fine, the to: header is rewritten with the recipient's address. Is there a way to tell mailman not to also include the cc: with the list address? This is an announce-only list and there's no need for the recipients to see the list address. thanks, Ethan From lisa at groupjazz.com Tue Sep 16 18:19:18 2003 From: lisa at groupjazz.com (Lisa Kimball) Date: Thu Sep 25 09:36:57 2003 Subject: [Mailman-Developers] Looking for resource Message-ID: We're looking for someone with Mailman expertise that we could hire to work with us on our Mailman application. If you are interested and available, please send me an email with your resume or description of qualifications and fees. Thank you. Lisa Kimball Group Jazz lisa@groupjazz.com From kohler at icir.org Mon Sep 22 11:51:21 2003 From: kohler at icir.org (Eddie Kohler) Date: Thu Sep 25 09:37:02 2003 Subject: [Mailman-Developers] patch: 'Discard all messages marked "Defer"' Message-ID: <200309221551.h8MFpMp0063069@coyote.icir.org> Hi, I just submitted a patch to SourceForge (#810675) that adds a checkbox 'Discard all messages marked "Defer"' to the admindb page. This checkbox greatly reduces the time I spend processing spam, since I need to click only on messages to be accepted or explicitly rejected. Patch applies to "mailman" CVS and to 2.1.2. The Mailman pages suggested informing this list of patches, as well as SourceForge, so.... Thanks, Eddie From tech-mail at prupref.com Thu Sep 18 00:00:14 2003 From: tech-mail at prupref.com (McKeever, Chris) Date: Thu Sep 25 09:38:39 2003 Subject: [Mailman-Developers] RE: [Mailman-Users] Unsubscribe Email command Message-ID: <5F71B3C180C8D4119F3200B0D049A7AE0297F438@PRUPREF-MAIL> > -----Original Message----- > From: Kory Wheatley [mailto:wheakory@isu.edu] > Sent: Wednesday, September 17, 2003 5:13 PM > > > I know that a subscriber can unsubscribe themselves without a > password > using the email command, or someone else can > unsubscribe the user if they know their password to the > mailing list., > with this command > Example: "unsubscribe mail11 address=wheakorypersonal@yahoo.com" and > sending this to list-request@mm.isu.edu > > But how can the Administrator of the list unsubscribe anyone without > knowing their password, I know that the Administrator can do > it through > the membership management option and through the command line, But I > need to do this through the email command. I tried > unsubscribing an user > by using the admin password and the global password, but this don't > work, it requires the subscriber password. I would like to know if > there is a work around for this? > This is only a suggestion, but you could have a cron job (or similar) check the email account and run a command (or url) off of the information in the email... just a thought.. Is there a reason why you are trying to avoid the admin-interface? I made some URI with the adminpw for easy subscribe and unsubscribe of users...If you need the format, let me know, but it seems you are looking for a pure email method.. > -- > Kory Wheatley > Academic Computing Analyst Sr. > Phone 282-3874 > ######################################### > Everything must point to him. > > > > ------------------------------------------------------ > 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/ > > This message was sent to: tech-mail@prupref.com > Unsubscribe or change your options at > http://mail.python.org/mailman/options/mailman-users/tech-mail > %40prupref.com > From skip at pobox.com Thu Sep 25 09:17:08 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Sep 25 09:38:42 2003 Subject: [Mailman-Developers] Trivial mm wording nit Message-ID: <16242.60116.434026.645764@montanaro.dyndns.org> I know this is anal, but it bugs me every time Mailman discards a message then sends me a note with this text: The attached message has been automatically discarded. It should be The attached message was automatically discarded. FYI. -- Skip Montanaro Got gigs? http://www.musi-cal.com/ http://www.mojam.com/ Got spam? http://spambayes.sf.net/ From dan.mick at sun.com Thu Sep 25 13:09:30 2003 From: dan.mick at sun.com (Dan Mick) Date: Thu Sep 25 13:12:39 2003 Subject: [Mailman-Developers] Trivial mm wording nit In-Reply-To: <16242.60116.434026.645764@montanaro.dyndns.org> References: <16242.60116.434026.645764@montanaro.dyndns.org> Message-ID: <3F73214A.3090401@sun.com> On 9/25/03 6:17 AM, Skip Montanaro wrote: > I know this is anal, but it bugs me every time Mailman discards a message > then sends me a note with this text: > > The attached message has been automatically discarded. > > It should be > > The attached message was automatically discarded. > > FYI. > I don't agree. Why is the latter more correct? From skip at pobox.com Thu Sep 25 14:14:49 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Sep 25 14:14:57 2003 Subject: [Mailman-Developers] Trivial mm wording nit In-Reply-To: <3F73214A.3090401@sun.com> References: <16242.60116.434026.645764@montanaro.dyndns.org> <3F73214A.3090401@sun.com> Message-ID: <16243.12441.263959.698909@montanaro.dyndns.org> >> I know this is anal, but it bugs me every time Mailman discards a >> message then sends me a note with this text: >> >> The attached message has been automatically discarded. >> >> It should be >> >> The attached message was automatically discarded. Dan> I don't agree. Why is the latter more correct? "was" connotes that an action happened in the past and is over and done with. "has been" connotes that the action was started, but might not have completed. Skip From kmccann at bellanet.org Thu Sep 25 14:51:16 2003 From: kmccann at bellanet.org (Kevin McCann) Date: Thu Sep 25 14:51:22 2003 Subject: [Mailman-Developers] Trivial mm wording nit In-Reply-To: <16243.12441.263959.698909@montanaro.dyndns.org> References: <16242.60116.434026.645764@montanaro.dyndns.org> <3F73214A.3090401@sun.com> <16243.12441.263959.698909@montanaro.dyndns.org> Message-ID: <1064515876.31059.1748.camel@localhost.localdomain> > "was" connotes that an action happened in the past and is over and done > with. "has been" connotes that the action was started, but might not have > completed. I disagree. To me, the sentence with "was" gives the impression that it just simply happened. The sentence with "has been" seems more official and assured, indicating that the action was purposefully taken. I agree that it is nitpicking, but I much prefer "has been" over "was." - Kevin From claw at kanga.nu Thu Sep 25 15:49:07 2003 From: claw at kanga.nu (J C Lawrence) Date: Thu Sep 25 15:49:11 2003 Subject: [Mailman-Developers] Topic feature request Message-ID: <1138.1064519347@kanga.nu> I would like to be able to flag specific topics as mandatory. For example "ADMIN:", as a topic, would also go to every user no matter their topic selection. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From dan.mick at sun.com Thu Sep 25 16:18:10 2003 From: dan.mick at sun.com (Dan Mick) Date: Thu Sep 25 16:25:24 2003 Subject: [Mailman-Developers] Trivial mm wording nit In-Reply-To: <16243.12441.263959.698909@montanaro.dyndns.org> References: <16242.60116.434026.645764@montanaro.dyndns.org> <3F73214A.3090401@sun.com> <16243.12441.263959.698909@montanaro.dyndns.org> Message-ID: <3F734D82.7070303@sun.com> Skip Montanaro wrote: > >> I know this is anal, but it bugs me every time Mailman discards a > >> message then sends me a note with this text: > >> > >> The attached message has been automatically discarded. > >> > >> It should be > >> > >> The attached message was automatically discarded. > > Dan> I don't agree. Why is the latter more correct? > > "was" connotes that an action happened in the past and is over and done > with. "has been" connotes that the action was started, but might not have > completed. doesn't connote that to me..."has been" is clearly past tense, just as is "was". > I disagree. To me, the sentence with "was" gives the impression that it > just simply happened. The sentence with "has been" seems more official > and assured, indicating that the action was purposefully taken. doesn't connote that either to me. Neither "has been" nor "was" implies more or less purpose. I don't see a lot of difference either way. And yes, it's certainly a nit. From pioppo at ferrara.linux.it Thu Sep 25 16:44:50 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Thu Sep 25 16:39:31 2003 Subject: [Mailman-Developers] Trivial mm wording nit In-Reply-To: <16243.12441.263959.698909@montanaro.dyndns.org> References: <16242.60116.434026.645764@montanaro.dyndns.org> <3F73214A.3090401@sun.com> <16243.12441.263959.698909@montanaro.dyndns.org> Message-ID: <200309252244.50761.pioppo@ferrara.linux.it> On Thursday 25 September 2003 20:14, Skip Montanaro wrote: > >> The attached message has been automatically discarded. > >> It should be > >> The attached message was automatically discarded. > > Dan> I don't agree. Why is the latter more correct? > > "was" connotes that an action happened in the past and is over and done > with. "has been" connotes that the action was started, but might not have > completed. IIRC this is exacly what we non-native-speakers are thaught when we study english, but I've seen (note: have seen <-> *so far*) people use both forms in any context. Maybe the rule was lost (note: was <-> *definitely*) in everyday speak, or maybe only brits still care. HTH, Simone -- Adde parvum parvo magnus acervus erit -- Ovidio From harald.meland at usit.uio.no Fri Sep 26 11:34:28 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Fri Sep 26 11:36:15 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <87eky6kwlo.fsf@stark.dyndns.tv> (Greg Stark's message of "24 Sep 2003 11:57:39 -0400") References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> Message-ID: [Greg Stark] > Before removing a subscriber mailman should send a message with > known content testing the address. Only if such a message bounces > should a user be dropped. Uhm... what parts of such a known content message do you think can safely be assumed to still be discernible when Mailman receives the bounce message? Remember to take the real world into account here; IMO Mailman can't require bounce messages to be formatted in this-or-that particular fashion merely because that format is "common". -- Harald From gsstark at mit.edu Fri Sep 26 11:41:08 2003 From: gsstark at mit.edu (Greg Stark) Date: Fri Sep 26 11:41:13 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> Message-ID: <87isnfh817.fsf@stark.dyndns.tv> Harald Meland writes: > [Greg Stark] > > > Before removing a subscriber mailman should send a message with > > known content testing the address. Only if such a message bounces > > should a user be dropped. > > Uhm... what parts of such a known content message do you think can > safely be assumed to still be discernible when Mailman receives the > bounce message? You've misunderstood me. I'm not suggesting it should expect the bounce message to have known content. What I'm suggesting is that Mailman should *send* a message with known content itself, and only if that message bounces should it decide the address is invalid. This is what ezmlm does. As much as I dislike ezmlm and qmail for other reasons and like Mailman for other reasons, this is one thing it gets right and Mailman gets wrong. Deciding an address is invalid on the basis of messages posted to the list is bogus. Mailman can't know whether the message posted to the list bounced because the address was invalid, or merely because the content of that particular message triggered a content-based filter. -- greg From barry at python.org Fri Sep 26 11:47:19 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 11:47:25 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <87eky6kwlo.fsf@stark.dyndns.tv> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> Message-ID: <1064591239.30783.23.camel@anthem> On Wed, 2003-09-24 at 11:57, Greg Stark wrote: > I should not be removed from a mailing list purely on the basis of bounces of > uncontrolled messages. The messages that bounced could have been spam or > outlook worms or whatever. In the default configuration, you won't be. You might get /disabled/ but you won't get removed, unless your MTA also bounces the 3 notices that Mailman sends out at regular intervals to warn disabled users of their subscription status. > Before removing a subscriber mailman should send a message with known content > testing the address. Only if such a message bounces should a user be dropped. That's what it does. The default is to send 3 notices over the course of 3 weeks. Each of those notices contains a url you need to click on to re-instate your subscription. We can't test for a negative (i.e. that the notices don't bounce) so you need to take explicit action to get re-enabled. > As it is I'm being removed from mailing lists whenever a new Outlook worm > appears and sends multiple messages in a row. Or a new spammer discovers a > list I'm on and sends multiple messages in a row to the list. > > It's especially bad on low-volume lists where it's quite possible for spam or > Outlook worm messages to be the only messages for days. Admins of low volume lists might want to change some of the bounce processing defaults. However, by default if a list gets no bounces from you in 7 days, it considers any previous bounce info to be stale and throws it away. So the list would need to get one bounce per day from you for 5 days in a row for you to get disabled. The other option I would suggest is that list owners start turning on personalization, in order to take advantage of VERP. I think it's harder to get spoof-disabled when VERP is enabled because then Mailman looks for the bouncing address in the encoded recipient header. But I'm open to specific suggestions for improvement. -Barry From barry at python.org Fri Sep 26 11:51:45 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 11:51:58 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <87isnfh817.fsf@stark.dyndns.tv> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> Message-ID: <1064591505.30783.28.camel@anthem> On Fri, 2003-09-26 at 11:41, Greg Stark wrote: > What I'm suggesting is that Mailman should *send* a message with known content > itself, and only if that message bounces should it decide the address is > invalid. It seems difficult to test a negative (what? it doesn't bounce after 10 days? I guess it'll never bounce). I prefer Mailman's positive test approach of sending several notices and requiring an explicit confirmation for reinstatement. > This is what ezmlm does. As much as I dislike ezmlm and qmail for other > reasons and like Mailman for other reasons, this is one thing it gets right > and Mailman gets wrong. > > Deciding an address is invalid on the basis of messages posted to the list is > bogus. Mailman can't know whether the message posted to the list bounced > because the address was invalid, or merely because the content of that > particular message triggered a content-based filter. Bounce messages triggered by content-based filters are evil and must be eradicated. When SoBig.F came out, we had effective filters in place within a day or so for the specific viruses themselves. What absolutely killed us was all the "helpful" bounces that the zillions of content filters send when they block such a message. And even if you think /that's/ okay, not putting limits on those block messages is still evil. -Barry From maechler at stat.math.ethz.ch Fri Sep 26 12:15:20 2003 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Fri Sep 26 12:15:40 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: References: <16229.54685.100766.810816@gargle.gargle.HOWL> Message-ID: <16244.26136.365001.503283@gargle.gargle.HOWL> >>>>> "Roger" == Roger Bivand >>>>> on Fri, 26 Sep 2003 14:26:58 +0200 (CEST) writes: ..... Roger> The second thing, ...: my answer on r-help to a pixmap question Roger> was: Roger> ... Roger> xx@col[1:20] Roger> ... Roger> which in the archives is rendered: Roger> ... Roger> xx at col[1:20] Roger> ... aaarg! The mailman-builtin archiving engine (pipermail) is really not that great.... At the moment I have to stay with it. I can only switch back to keep e-mail addresses unaltered. which caters to the spammers address-collection robots... Of course that's a bug in mailman/pipermail ===> forwarding to the developers. Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< From pioppo at ferrara.linux.it Fri Sep 26 12:24:12 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Fri Sep 26 12:18:29 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <1064591239.30783.23.camel@anthem> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <1064591239.30783.23.camel@anthem> Message-ID: <200309261824.12716.pioppo@ferrara.linux.it> On Friday 26 September 2003 17:47, Barry Warsaw wrote: > Admins of low volume lists might want to change some of the bounce > processing defaults. However, by default if a list gets no bounces from > you in 7 days, it considers any previous bounce info to be stale and > throws it away. So the list would need to get one bounce per day from > you for 5 days in a row for you to get disabled. You write it as it was extremely difficult... but in reality on the server I manage it happened a dozen times in the last month (4 times to me alone). This is getting pretty annoying. I get disabled on 20-30 lists, spread on different virtual domains, so even the "globally" option in the re-enabling form doesn't help much (cause globally = virtual-domain-wide). I don't have any solution but please don't dismiss this problem. > The other option I would suggest is that list owners start turning on > personalization, in order to take advantage of VERP. I think it's > harder to get spoof-disabled when VERP is enabled because then Mailman > looks for the bouncing address in the encoded recipient header. This looks promising. Is there any howto explaining how to migrate to VERP on a running list and what gotchas to pay attention? -- Adde parvum parvo magnus acervus erit -- Ovidio From barry at python.org Fri Sep 26 12:27:49 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 12:28:03 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <200309261824.12716.pioppo@ferrara.linux.it> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <1064591239.30783.23.camel@anthem> <200309261824.12716.pioppo@ferrara.linux.it> Message-ID: <1064593669.31604.6.camel@anthem> On Fri, 2003-09-26 at 12:24, Simone Piunno wrote: > On Friday 26 September 2003 17:47, Barry Warsaw wrote: > > > Admins of low volume lists might want to change some of the bounce > > processing defaults. However, by default if a list gets no bounces from > > you in 7 days, it considers any previous bounce info to be stale and > > throws it away. So the list would need to get one bounce per day from > > you for 5 days in a row for you to get disabled. > > You write it as it was extremely difficult... but in reality on the server I > manage it happened a dozen times in the last month (4 times to me alone). > This is getting pretty annoying. I get disabled on 20-30 lists, spread on > different virtual domains, so even the "globally" option in the re-enabling > form doesn't help much (cause globally = virtual-domain-wide). > I don't have any solution but please don't dismiss this problem. I won't, and I'm definitely interested in specific suggestions, but of course there are other contributing factors to the problem. Are there better defaults we could be shipping Mailman with that would make the problem less severe without making automatic bounce processing useless? > > The other option I would suggest is that list owners start turning on > > personalization, in order to take advantage of VERP. I think it's > > harder to get spoof-disabled when VERP is enabled because then Mailman > > looks for the bouncing address in the encoded recipient header. > > This looks promising. Is there any howto explaining how to migrate to VERP on > a running list and what gotchas to pay attention? Part of setting up VERP is MTA specific, and there are instructions in README.POSTFIX and README.EXIM covering those MTAs. Once that's done, its a matter of setting the various VERP_* variables in mm_cfg.py to your tastes, and then turning on personalization (not full) in Non-Digest deliveries. The bigger question is what the impact of VERPing is on bandwidth and performance. Other than doing the math, I don't have much to add, except that I've started to enable it on most python.org lists and it doesn't seem to be a problem. -Barry From barry at python.org Fri Sep 26 12:30:12 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 12:30:19 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: <16244.26136.365001.503283@gargle.gargle.HOWL> References: <16229.54685.100766.810816@gargle.gargle.HOWL> <16244.26136.365001.503283@gargle.gargle.HOWL> Message-ID: <1064593811.31604.9.camel@anthem> On Fri, 2003-09-26 at 12:15, Martin Maechler wrote: > The mailman-builtin archiving engine (pipermail) is really not that > great.... It's better than nothing, but no one has ever made great claims about it. Unfortunately, no one has stepped up to improve it either although there have been several fits and starts. I continue to await volunteers! -Barry From gsstark at mit.edu Fri Sep 26 12:45:46 2003 From: gsstark at mit.edu (Greg Stark) Date: Fri Sep 26 12:46:01 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <1064591505.30783.28.camel@anthem> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <1064591505.30783.28.camel@anthem> Message-ID: <87d6dnh51h.fsf@stark.dyndns.tv> Barry Warsaw writes: > On Fri, 2003-09-26 at 11:41, Greg Stark wrote: > > > What I'm suggesting is that Mailman should *send* a message with known content > > itself, and only if that message bounces should it decide the address is > > invalid. > > It seems difficult to test a negative (what? it doesn't bounce after 10 > days? I guess it'll never bounce). I prefer Mailman's positive test > approach of sending several notices and requiring an explicit > confirmation for reinstatement. That sounds great, except I'm subscribed to 183 lists, mostly low volume. Periodically I get interested in some project I put aside long ago, check my mail folder for it and discover I've stopped receiving messages months ago. That sucks. I don't see why using a message with known content is any more of a "negative" test than basing the decision on list messages with unknown content. If you get a bounce from a probe you disable the recipient. That's as much a positive test as looking for bounces. > > Deciding an address is invalid on the basis of messages posted to the list is > > bogus. Mailman can't know whether the message posted to the list bounced > > because the address was invalid, or merely because the content of that > > particular message triggered a content-based filter. > > Bounce messages triggered by content-based filters are evil and must be > eradicated. As it turns out in this case the mail server isn't directly generating a bounce, it's returning an SMTP 5xx error. So the previous SMTP server in the chain generates a proper bounce to the envelope address. I've discussed this with the mail admins and their position is that the filters aren't perfect and have caught valid mail in the past. They're worried that simply bitbucketing the mail will cause valid mail to be lost. Causing valid bounces to be sent to the envelope sender means the innocent victim in the forged From header isn't harassed with bounce messages. Instead the list that resent the message gets the bounce and processes it as a failed message -- which in fact is exactly what happened. It just shouldn't extrapolate from those messages to assuming the mailbox itself is down. > When SoBig.F came out, we had effective filters in place within a day or so > for the specific viruses themselves. What absolutely killed us was all the > "helpful" bounces that the zillions of content filters send when they block > such a message. And even if you think /that's/ okay, not putting limits on > those block messages is still evil. Most of this only applies to the stupid filters that incorrectly send bounce messages to the From header, and often do it with a valid envelope sender themselves so they're just asking for mail loops. -- greg From barry at python.org Fri Sep 26 13:18:22 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 13:18:29 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <87d6dnh51h.fsf@stark.dyndns.tv> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <1064591505.30783.28.camel@anthem> <87d6dnh51h.fsf@stark.dyndns.tv> Message-ID: <1064596701.31604.22.camel@anthem> On Fri, 2003-09-26 at 12:45, Greg Stark wrote: > That sounds great, except I'm subscribed to 183 lists, mostly low volume. > Periodically I get interested in some project I put aside long ago, check my > mail folder for it and discover I've stopped receiving messages months ago. > That sucks. Agreed. > I don't see why using a message with known content is any more of a "negative" > test than basing the decision on list messages with unknown content. If you > get a bounce from a probe you disable the recipient. That's as much a positive > test as looking for bounces. Let me see if I understand your proposal then: - Once your bounce score reaches a certain level, you don't get disabled, but you get on a "hello? are you there" list. - We probe your address for a while, and if we get a bounce, then we disable you and do the normal notifications for reinstatement. - If we /don't/ get a bounce from you for, what? X number of days, what happens? We send another probe and don't disable you? The probe could contain a message similar to the reinstatement message so that you could stop the probes, but otherwise, how long do we keep sending probes? I don't necessarily trust that we can send only one, but OTOH I don't want to fill up your inbox with probe messages. -Barry From jam at jamux.com Fri Sep 26 13:22:45 2003 From: jam at jamux.com (John A. Martin) Date: Fri Sep 26 13:25:13 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <87d6dnh51h.fsf@stark.dyndns.tv> (Greg Stark's message of "26 Sep 2003 12:45:46 -0400") References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <1064591505.30783.28.camel@anthem> <87d6dnh51h.fsf@stark.dyndns.tv> Message-ID: <87fzijv50a.fsf@athene.jamux.com> >>>>> "Greg" == Greg Stark >>>>> "Re: [Mailman-Developers] Re: Bounce removal parameters default values" >>>>> 26 Sep 2003 12:45:46 -0400 Greg> Barry Warsaw writes: Greg> Causing valid bounces to be sent to the envelope sender Is required by the standards. Greg> Instead the list that resent the message gets the bounce and Greg> processes it as a failed message -- which in fact is exactly Greg> what happened. The mailing list is the envelope sender of mail sent to the list. For example the envelope sender of the mail to which this is a reply is mailman-developers-bounces@python.org which is correct and compliant with the standards. A standards compliant MTA will send any DSN (Delivery Status Notice) to that address. Greg> It just shouldn't extrapolate from those messages to Greg> assuming the mailbox itself is down. If any mail is rejected or bounced (ie, initially accepted for delivery but later a DSN is returned indicating a delivery failure) then that is a delivery failure. If you do not like what your receiving mail systems reject or bounce that is not a Mailman problem. jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030926/4c3a4c2f/attachment.bin From shaikli at yahoo.com Fri Sep 26 13:22:56 2003 From: shaikli at yahoo.com (Nadim Shaikli) Date: Fri Sep 26 13:31:22 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: <1064593811.31604.9.camel@anthem> Message-ID: <20030926172256.88684.qmail@web14916.mail.yahoo.com> --- Barry Warsaw wrote: > On Fri, 2003-09-26 at 12:15, Martin Maechler wrote: > > > The mailman-builtin archiving engine (pipermail) is really not that > > great.... > > It's better than nothing, but no one has ever made great claims about > it. Unfortunately, no one has stepped up to improve it either although > there have been several fits and starts. I continue to await > volunteers! Dump pipermail completely and include (or point to) MHonARC, it does a great job and is easily integrated (UTF-8 support and all). - Nadim __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From barry at python.org Fri Sep 26 13:34:04 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 13:34:10 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: <20030926172256.88684.qmail@web14916.mail.yahoo.com> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> Message-ID: <1064597644.31604.25.camel@anthem> On Fri, 2003-09-26 at 13:22, Nadim Shaikli wrote: > Dump pipermail completely and include (or point to) MHonARC, it does a great > job and is easily integrated (UTF-8 support and all). In the tradition of Python's "batteries included" philosophy, I still want to bundle Pipermail. But I'm happy to make it more obvious, or easier, or whatever, to point people at MHonArc. I'm leery of including MHonArc in our distribution. -Barry From barry at python.org Fri Sep 26 13:40:18 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 13:40:24 2003 Subject: [Mailman-Developers] Planning for the next release Message-ID: <1064598018.31604.32.camel@anthem> Not that I have any more free time than I used to, but I'd like to start planning for the next major release of Mailman. Over the summer I made some good progress on Mailman 3, but I'm beginning to think that we'll need a MM2.2 release sooner than that. There's a ton of stuff backed up that can't really go into 2.1.x. MM2.2 would be more modest, with no fundamental architectural changes, but hopefully some useful new features nonetheless. So I've started a wiki page to start collecting ideas. I'm not committing to any of them, but we need a place to document and discuss things that might go into Mailman 2.2. Here's the url: http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotTwo Feel free to comment, or add other wish list items. I'll garden the wiki as necessary. -Barry From claw at kanga.nu Fri Sep 26 12:36:49 2003 From: claw at kanga.nu (J C Lawrence) Date: Fri Sep 26 14:23:21 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: Message from Greg Stark of "26 Sep 2003 11:41:08 EDT." <87isnfh817.fsf@stark.dyndns.tv> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> Message-ID: <27287.1064594209@kanga.nu> On 26 Sep 2003 11:41:08 -0400 Greg Stark wrote: > Deciding an address is invalid on the basis of messages posted to the > list is bogus. Mailman can't know whether the message posted to the > list bounced because the address was invalid, or merely because the > content of that particular message triggered a content-based filter. At its core this is an argument between pragmatism and principle. My principled side says that an alarming number of sites actually do use content filters and that they are a reality of email life and we should properly handle reality. My pragmatic side says that content filters are inherently and necessarily broken and like any other technical brain-damage, shouldn't be accommodated. As always, you get to choose. Currently I'm very happy with the principled side. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From gsstark at mit.edu Fri Sep 26 14:58:47 2003 From: gsstark at mit.edu (Greg Stark) Date: Fri Sep 26 14:58:52 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <1064596701.31604.22.camel@anthem> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <1064591505.30783.28.camel@anthem> <87d6dnh51h.fsf@stark.dyndns.tv> <1064596701.31604.22.camel@anthem> Message-ID: <871xu3gyvs.fsf@stark.dyndns.tv> Barry Warsaw writes: > - We probe your address for a while, and if we get a bounce, then we > disable you and do the normal notifications for reinstatement. I don't understand this one. Why would you have to poll to check for bounces. You handle the bounce as it comes in. > - If we /don't/ get a bounce from you for, what? X number of days, what If you don't get a bounce you don't do anything. Do you normally do things when nothing happens? > I don't necessarily trust that we can send only one, but OTOH I don't want > to fill up your inbox with probe messages. Why would you keep sending probes? You only send probes when the conditions are met which are the current conditions for disabling a user. So what I'm suggesting is: . When you get a bounce from a list message you record it and see if the limits have been reached. If N consecutive previous list messages to the address have bounced covering the minimum time period etc then you send a probe. . When you get a bounce from a probe you always disable the address. You could add a check to see if the probe was within the last few days and check whether any list messages have gotten through since the probe was sent, but all of that is just for paranoia's sake, in case someone flushes an old mail spool after fixing a mailbox. Actually ezmlm takes that one step further. If a probe bounces then it waits some time period and sends another probe. If the second probe bounces then you're dropped. -- greg From gsstark at mit.edu Fri Sep 26 15:03:46 2003 From: gsstark at mit.edu (Greg Stark) Date: Fri Sep 26 15:16:21 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <27287.1064594209@kanga.nu> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <27287.1064594209@kanga.nu> Message-ID: <87vfrffk31.fsf@stark.dyndns.tv> > My principled side says that an alarming number of sites actually do > use content filters and that they are a reality of email life and we > should properly handle reality. Content filters are not necessarily evil. It's bouncing to the From header that's evil. If it makes you feel better consider the case of somebody who has their MTA configured to refuse messages over a certain size, like all old installations of sendmail for example. So if for a few days only large kernel patches are send to the mailing list and mailman sees every message to that user bounce. It doesn't mean the address is any worse off than usual, it's just those messages that were refused. -- greg From amk at amk.ca Fri Sep 26 16:44:47 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Sep 26 16:44:52 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: <1064597644.31604.25.camel@anthem> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <1064597644.31604.25.camel@anthem> Message-ID: <20030926204447.GA935@rogue.amk.ca> On Fri, Sep 26, 2003 at 01:34:04PM -0400, Barry Warsaw wrote: > want to bundle Pipermail. But I'm happy to make it more obvious, or > easier, or whatever, to point people at MHonArc. I'm leery of including A simple step toward this for Mailman 2.2 would be to change the URL layout for the archives from host/pipermail/ to host/archives/ or host/mm-archives/ . --amk From barry at python.org Fri Sep 26 17:07:47 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 17:07:54 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced in archives In-Reply-To: <20030926204447.GA935@rogue.amk.ca> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <1064597644.31604.25.camel@anthem> <20030926204447.GA935@rogue.amk.ca> Message-ID: <1064610466.31604.68.camel@anthem> On Fri, 2003-09-26 at 16:44, amk@amk.ca wrote: > On Fri, Sep 26, 2003 at 01:34:04PM -0400, Barry Warsaw wrote: > > want to bundle Pipermail. But I'm happy to make it more obvious, or > > easier, or whatever, to point people at MHonArc. I'm leery of including > > A simple step toward this for Mailman 2.2 would be to change the URL layout > for the archives from host/pipermail/ to host/archives/ or host/mm-archives/ . Added to the wiki! -Barry From barry at python.org Fri Sep 26 17:10:35 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 17:10:42 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: <27287.1064594209@kanga.nu> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <27287.1064594209@kanga.nu> Message-ID: <1064610635.31604.70.camel@anthem> On Fri, 2003-09-26 at 12:36, J C Lawrence wrote: > At its core this is an argument between pragmatism and principle. > > My principled side says that an alarming number of sites actually do > use content filters and that they are a reality of email life and we > should properly handle reality. I would have thought this was the pragmatic side... > My pragmatic side says that content filters are inherently and > necessarily broken and like any other technical brain-damage, > shouldn't be accommodated. ...and this was the principled side. ;) -Barry From brad.knowles at skynet.be Fri Sep 26 18:30:33 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Sep 26 18:39:15 2003 Subject: [Mailman-Developers] Planning for the next release In-Reply-To: <1064598018.31604.32.camel@anthem> References: <1064598018.31604.32.camel@anthem> Message-ID: At 1:40 PM -0400 2003/09/26, Barry Warsaw wrote: > So I've started a wiki page to start collecting ideas. I'm not > committing to any of them, but we need a place to document and discuss > things that might go into Mailman 2.2. Here's the url: > > http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotTwo I've added a few ideas. > Feel free to comment, or add other wish list items. I'll garden the > wiki as necessary. Note that you have to create a Zope account before you can edit. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From claw at kanga.nu Fri Sep 26 18:42:28 2003 From: claw at kanga.nu (J C Lawrence) Date: Fri Sep 26 18:42:32 2003 Subject: [Mailman-Developers] Re: Bounce removal parameters default values In-Reply-To: Message from Barry Warsaw of "Fri, 26 Sep 2003 17:10:35 EDT." <1064610635.31604.70.camel@anthem> References: <871y32qzae.fsf@stark.dyndns.tv> <87eky6kwlo.fsf@stark.dyndns.tv> <87isnfh817.fsf@stark.dyndns.tv> <27287.1064594209@kanga.nu> <1064610635.31604.70.camel@anthem> Message-ID: <19954.1064616148@kanga.nu> On Fri, 26 Sep 2003 17:10:35 -0400 Barry Warsaw wrote: > On Fri, 2003-09-26 at 12:36, J C Lawrence wrote: >> At its core this is an argument between pragmatism and principle. >> >> My principled side says that an alarming number of sites actually do >> use content filters and that they are a reality of email life and we >> should properly handle reality. > I would have thought this was the pragmatic side... >> My pragmatic side says that content filters are inherently and >> necessarily broken and like any other technical brain-damage, >> shouldn't be accommodated. > ...and this was the principled side. ;) Yeah. Damn. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From kmccann at bellanet.org Fri Sep 26 20:22:15 2003 From: kmccann at bellanet.org (Kevin McCann) Date: Fri Sep 26 20:08:25 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> Message-ID: <036c01c3848d$6808acc0$0501a8c0@kevinduron> > Dump pipermail completely and include (or point to) MHonARC, it does a great > job and is easily integrated (UTF-8 support and all). I agree. Earl Hood has been doing a marvelous job with MHonarc for years now. The guy is meticulous, keeps his software current and well documented, and understands mail issues as well as anyone. I understand Barry's hesitation to integrate a non-Python product but there is no denying that MHonarc is rock solid and it would be a shame to not look at it more closely as a replacement for pipermail. Two thumbs way up for MHonarc. - k From barry at python.org Fri Sep 26 20:44:51 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 20:44:58 2003 Subject: [Mailman-Developers] Planning for the next release In-Reply-To: References: <1064598018.31604.32.camel@anthem> Message-ID: <1064623490.31604.77.camel@anthem> On Fri, 2003-09-26 at 18:30, Brad Knowles wrote: > At 1:40 PM -0400 2003/09/26, Barry Warsaw wrote: > > > So I've started a wiki page to start collecting ideas. I'm not > > committing to any of them, but we need a place to document and discuss > > things that might go into Mailman 2.2. Here's the url: > > > > http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotTwo > > I've added a few ideas. Are you [shub]? If so, can you fill in some details, especially for bullets like "Need better tools to customize the archive and mailman in general"? -Barry From barry at python.org Fri Sep 26 20:48:17 2003 From: barry at python.org (Barry Warsaw) Date: Fri Sep 26 20:48:25 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <036c01c3848d$6808acc0$0501a8c0@kevinduron> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> Message-ID: <1064623697.31604.79.camel@anthem> On Fri, 2003-09-26 at 20:22, Kevin McCann wrote: > I agree. Earl Hood has been doing a marvelous job with MHonarc for years > now. The guy is meticulous, keeps his software current and well documented, > and understands mail issues as well as anyone. I understand Barry's > hesitation to integrate a non-Python product but there is no denying that > MHonarc is rock solid and it would be a shame to not look at it more closely > as a replacement for pipermail. Two thumbs way up for MHonarc. At least it's GPL'd so it would be /possible/. -Barry From tkikuchi at is.kochi-u.ac.jp Fri Sep 26 21:18:58 2003 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Sep 26 21:19:37 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064623697.31604.79.camel@anthem> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <1064623697.31604.79.camel@anthem> Message-ID: <3F74E582.8030901@is.kochi-u.ac.jp> Hi, Barry Warsaw wrote: > On Fri, 2003-09-26 at 20:22, Kevin McCann wrote: > > >>I agree. Earl Hood has been doing a marvelous job with MHonarc for years >>now. The guy is meticulous, keeps his software current and well documented, >>and understands mail issues as well as anyone. I understand Barry's >>hesitation to integrate a non-Python product but there is no denying that >>MHonarc is rock solid and it would be a shame to not look at it more closely >>as a replacement for pipermail. Two thumbs way up for MHonarc. > > > At least it's GPL'd so it would be /possible/. > What is the status of i18n of MHonarc ? At least, MHonArc-ed japanese mail archives doesn't impress me much. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad.knowles at skynet.be Sat Sep 27 07:56:59 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Sep 27 09:34:45 2003 Subject: [Mailman-Developers] Planning for the next release In-Reply-To: <1064623490.31604.77.camel@anthem> References: <1064598018.31604.32.camel@anthem> <1064623490.31604.77.camel@anthem> Message-ID: At 8:44 PM -0400 2003/09/26, Barry Warsaw wrote: >> I've added a few ideas. > > Are you [shub]? Yup. > If so, can you fill in some details, especially for bullets like "Need > better tools to customize the archive and mailman in general"? Will do. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From brad.knowles at skynet.be Sat Sep 27 07:59:20 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Sep 27 09:34:52 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <036c01c3848d$6808acc0$0501a8c0@kevinduron> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> Message-ID: At 8:22 PM -0400 2003/09/26, Kevin McCann wrote: >> Dump pipermail completely and include (or point to) MHonARC, it does a >> great job and is easily integrated (UTF-8 support and all). > > I agree. Earl Hood has been doing a marvelous job with MHonarc for years > now. The guy is meticulous, keeps his software current and well documented, > and understands mail issues as well as anyone. This is seriously weird. Back before pipermail was integrated into mailman, my understanding is that the then-current version was the best available MLM archive tool, heads and shoulders above everything else -- especially mhonarc. Moreover, my understanding was that pipermail had only improved significantly beyond where it was at the time of initial integration. Has mhonarc improved so much in the meantime that it has now overtaken the current version of pipermail? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From kmccann at bellanet.org Sat Sep 27 09:59:24 2003 From: kmccann at bellanet.org (Kevin McCann) Date: Sat Sep 27 09:45:24 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> Message-ID: <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> > This is seriously weird. Back before pipermail was integrated > into mailman, my understanding is that the then-current version was > the best available MLM archive tool, heads and shoulders above > everything else -- especially mhonarc. Moreover, my understanding > was that pipermail had only improved significantly beyond where it > was at the time of initial integration. > > Has mhonarc improved so much in the meantime that it has now > overtaken the current version of pipermail? Hi Brad, Try it for yourself. Maybe your needs are different. But if I want an archiver that will process huge mbox file from other systems - without crapping out, will decode encoded binary attachments, have flexible, customizable output, etc., I can't think of anything else I would rather use. If MHonarc is so bad, why do so many people go the extra lengths currently required in order to use it instead of pipermail? As I say, it works for me. And very well. Maybe worth a second look? If you try it again let me know what you find. - Kevin From amk at amk.ca Sat Sep 27 17:31:02 2003 From: amk at amk.ca (amk@amk.ca) Date: Sat Sep 27 18:04:30 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> Message-ID: <20030927213102.GA5947@rogue.amk.ca> On Sat, Sep 27, 2003 at 01:59:20PM +0200, Brad Knowles wrote: > Has mhonarc improved so much in the meantime that it has now > overtaken the current version of pipermail? Pipermail hasn't been developed for a while, though. When I originally started writing it, the leading archiver was Hypermail, and it hadn't been maintained in a while, so Pipermail could easily beat it just by being in a scripting language instead of C. --amk From barry at python.org Sun Sep 28 01:30:19 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 01:30:27 2003 Subject: [Mailman-i18n] Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <1064623697.31604.79.camel@anthem> <3F74E582.8030901@is.kochi-u.ac.jp> Message-ID: <1064727019.31604.111.camel@anthem> On Sat, 2003-09-27 at 03:18, Martin v. L?wis wrote: > > At least, MHonArc-ed japanese mail archives doesn't impress me much. > > Seconded. I once wrote a patch to MHonarc to support UTF-8 on all > pages, and it was eventually incorporated, but MHonarc's > multiple-encoding techniques are much behind pipermail's. That's great to know, and would definitely influence any final decision. Also, I just spewed the mailman-developers archive through mhonarc 2.6.8. One thing I noticed off the bat is that message files are given sequential numbers just like pipermail. That isn't what I want! -Barry From barry at python.org Sun Sep 28 01:37:22 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 01:37:31 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> Message-ID: <1064727442.31604.119.camel@anthem> On Sat, 2003-09-27 at 09:59, Kevin McCann wrote: > Try it for yourself. Maybe your needs are different. But if I want an > archiver that will process huge mbox file from other systems - without > crapping out, will decode encoded binary attachments, have flexible, > customizable output, etc., I can't think of anything else I would rather > use. If MHonarc is so bad, why do so many people go the extra lengths > currently required in order to use it instead of pipermail? > > As I say, it works for me. And very well. Maybe worth a second look? If you > try it again let me know what you find. Pipermail definitely has some distinct advantages, so I'm glad we include it. It has some problems too, most notably its memory consumption, and I think inefficient on-disk storage. The most often cited problem is that it cannot handle regenerating entire very-large archives because of memory usage. I really really want to use something like message-ids to generate message file names. I want to be able to generate links to archived messages in the footers, but I think the best way to do that is to agree on a reproducible, independent algorithm for calculating them. Another approach would be to put even the public archives behind a cgi and have that implement a mapping between message-id derived links and the sequential file names (although that won't fix the regen problem). It would also be nice if we could more easily customize its look and feel. Anything more and we're getting into arch-ng and zest territories. -Barry From harald.meland at usit.uio.no Sun Sep 28 05:13:55 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Sun Sep 28 05:14:20 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064727442.31604.119.camel@anthem> (Barry Warsaw's message of "Sun, 28 Sep 2003 01:37:22 -0400") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> Message-ID: [Barry Warsaw] > I really really want to use something like message-ids to generate > message file names. I want to be able to generate links to archived > messages in the footers, but I think the best way to do that is to agree > on a reproducible, independent algorithm for calculating them. What input parameters should such an algorithm have? I take it that you want to use just * list name and * message-id and I think that would mostly work. However, the "mostly" part means that Mailman would need to implement some policy for dealing with posts that use an already-archived message-id. Some possible policies would be: 1) On message arrival, Mailman checks whether the archives already contains that message-id. If it does, the message is rejected, so the sender gets a chance to re-post the message with a fresh message-id. 2) Whenever Mailman receives a message whose message-id is already present in the archives, the original Message-Id: header is renamed to e.g. X-Original-Message-Id:, and Mailman generates a fresh (as in "not yet present in the archives") message-id before the message is either archived or sent to the list members. 3) Messages with duplicate message-ids are posted to the members as-is, but won't be archived. -- Harald From barry at python.org Sun Sep 28 09:45:32 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 09:45:37 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> Message-ID: <1064756731.31604.143.camel@anthem> On Sun, 2003-09-28 at 05:13, Harald Meland wrote: > [Barry Warsaw] > > > I really really want to use something like message-ids to generate > > message file names. I want to be able to generate links to archived > > messages in the footers, but I think the best way to do that is to agree > > on a reproducible, independent algorithm for calculating them. > > What input parameters should such an algorithm have? I take it that > you want to use just > > * list name and > * message-id Exactly. > 2) Whenever Mailman receives a message whose message-id is already > present in the archives, the original Message-Id: header is > renamed to e.g. X-Original-Message-Id:, and Mailman generates a > fresh (as in "not yet present in the archives") message-id before > the message is either archived or sent to the list members. This is what I was thinking about. Alternatively we could rewrite all message-id headers when we accept the message. That would guarantee uniqueness but it would break the correlation of message-ids between list copies and direct copies. Is that bad? (note that we already do this for NNTP posted messages, and there has been some off-list discussion about that). -Barry From barry at python.org Sun Sep 28 09:45:54 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 09:46:00 2003 Subject: [Mailman-i18n] Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064729161.3612.10.camel@musa> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <1064623697.31604.79.camel@anthem> <3F74E582.8030901@is.kochi-u.ac.jp> <1064727019.31604.111.camel@anthem> <1064729161.3612.10.camel@musa> Message-ID: <1064756753.31604.145.camel@anthem> On Sun, 2003-09-28 at 02:06, Alessio Bragadini wrote: > MHonArc has a lengthy configuration file, not to mention the possibility > of patches. What's exactly the result you would like to see? See my other followup. -Barry From nd at felinemenace.org Fri Sep 26 09:21:36 2003 From: nd at felinemenace.org (ned) Date: Sun Sep 28 09:53:45 2003 Subject: [Mailman-Developers] bugs in 2.1.2 Message-ID: Hello list, i've been poking and prodding mailman for about an hour now...found a few things which could be not seen as secure (although they dont have any real impact...): first there is a XSS (cross site scripting) bug in create.py in Cgi/. just enter ">. putting a Utils.Websafe (is that right) shoudl fix it... second small bug in Mailist.Mailist, here's a quick demo: http://mail.python.org/mailman/listinfo/(X * 500). nice little info disclosure hole...easily fixed by restricting lengths on filenames that open() uses. but you already knew that! anyway, nothing a few length checks and some url-fixups wont fix! aapologies too if this should have gone throuhg bugzilla or something...it's late right now and im excited by the grand final tomorrow. regards, Ned Dawes -- http://felinemenace.org/~nd From Roger.Bivand at nhh.no Fri Sep 26 13:13:05 2003 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Sun Sep 28 09:53:48 2003 Subject: [Mailman-Developers] Re: "@" in mail **text** gets replaced in archives In-Reply-To: <16244.26136.365001.503283@gargle.gargle.HOWL> Message-ID: On Fri, 26 Sep 2003, Martin Maechler wrote: > >>>>> "Roger" == Roger Bivand > >>>>> on Fri, 26 Sep 2003 14:26:58 +0200 (CEST) writes: > > ..... > > > Roger> The second thing, ...: my answer on r-help to a pixmap question > Roger> was: > > Roger> ... > Roger> xx@col[1:20] > Roger> ... > > Roger> which in the archives is rendered: > > Roger> ... > Roger> xx at col[1:20] > Roger> ... > > aaarg! > > The mailman-builtin archiving engine (pipermail) is really not that > great.... > > At the moment I have to stay with it. > I can only switch back to keep e-mail addresses unaltered. > which caters to the spammers address-collection robots... > > Of course that's a bug in mailman/pipermail > ===> forwarding to the developers. I could see that they would try to convert all "@", but actually the hits should be "@" followed by a dot-separated address, at least one dot, shouldn't they? Regexp? Python can do that, I'm sure. Turning off protection would be a last resort, really. Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Breiviksveien 40, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93 e-mail: Roger.Bivand@nhh.no From martin at v.loewis.de Sat Sep 27 03:18:46 2003 From: martin at v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: Sun Sep 28 09:53:50 2003 Subject: [Mailman-i18n] Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <3F74E582.8030901@is.kochi-u.ac.jp> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <1064623697.31604.79.camel@anthem> <3F74E582.8030901@is.kochi-u.ac.jp> Message-ID: Tokio Kikuchi writes: > What is the status of i18n of MHonarc ? > > At least, MHonArc-ed japanese mail archives doesn't impress me much. Seconded. I once wrote a patch to MHonarc to support UTF-8 on all pages, and it was eventually incorporated, but MHonarc's multiple-encoding techniques are much behind pipermail's. Regards, Martin From alessio at albourne.com Sun Sep 28 02:06:01 2003 From: alessio at albourne.com (Alessio Bragadini) Date: Sun Sep 28 09:53:52 2003 Subject: [Mailman-i18n] Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064727019.31604.111.camel@anthem> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <1064623697.31604.79.camel@anthem> <3F74E582.8030901@is.kochi-u.ac.jp> <1064727019.31604.111.camel@anthem> Message-ID: <1064729161.3612.10.camel@musa> On Sun, 2003-09-28 at 08:30, Barry Warsaw wrote: > Also, I just spewed the mailman-developers archive through > mhonarc 2.6.8. One thing I noticed off the bat is that message files > are given sequential numbers just like pipermail. That isn't what I > want! MHonArc has a lengthy configuration file, not to mention the possibility of patches. What's exactly the result you would like to see? -- Alessio Bragadini APL Financial Services (Overseas) Ltd From barry at python.org Sun Sep 28 11:56:24 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 11:56:29 2003 Subject: [Mailman-Developers] bugs in 2.1.2 In-Reply-To: References: Message-ID: <1064764583.31604.152.camel@anthem> On Fri, 2003-09-26 at 09:21, ned wrote: > Hello list, > i've been poking and prodding mailman for about an hour now...found a few > things which could be not seen as secure (although they dont have any real > impact...): > first there is a XSS (cross site scripting) bug in create.py in Cgi/. just > enter > ">. putting a Utils.Websafe (is that right) > shoudl fix it... > > second small bug in Mailist.Mailist, here's a quick demo: > http://mail.python.org/mailman/listinfo/(X * 500). nice little info > disclosure hole...easily fixed by restricting lengths on filenames that > open() uses. but you already knew that! Good catches and good timing! The fixes will be in Mailman 2.1.3. -Barry From barry at python.org Sun Sep 28 13:31:12 2003 From: barry at python.org (Barry Warsaw) Date: Sun Sep 28 13:31:15 2003 Subject: [Mailman-Developers] Cutting Mailman 2.1.3 Message-ID: <1064770271.1084.4.camel@geddy> Okay, I'm going to be cutting Mailman 2.1.3 over the next hour or so. avalon and duke9 are getting their 11th hour updates in, but those will probably be the last. :) -Barry From jam at jamux.com Sun Sep 28 14:10:26 2003 From: jam at jamux.com (John A. Martin) Date: Sun Sep 28 14:10:37 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064756731.31604.143.camel@anthem> (Barry Warsaw's message of "Sun, 28 Sep 2003 09:45:32 -0400") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> Message-ID: <87k77sokbx.fsf@athene.jamux.com> >>>>> "baw" == Barry Warsaw >>>>> "Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives" >>>>> Sun, 28 Sep 2003 09:45:32 -0400 baw> On Sun, 2003-09-28 at 05:13, Harald Meland wrote: >> [Barry Warsaw] >> >> > I really really want to use something like message-ids to >> > generate message file names. I want to be able to generate >> > links to archived messages in the footers, In the header, please. All messages have headers, not all have footers. Footers are optional, no? This will go on the wire, right? Also, it would be nice if the URL/link/filename, or some other token, were serialized in some way so that a subscriber could tell easily (like by looking at the fill headers, whether he had actually received all list mail and which he was missing if any. Smartlist, IIRC, did that nicely in the header. baw> we could rewrite all message-id headers when we accept the baw> message. That would guarantee uniqueness but it would break baw> the correlation of message-ids between list copies and direct baw> copies. Is that bad? Yes. The RFCs are clear that MTAs must not muck with Message-Id other that to create one if there is none. What happened to the notion that archives are supposed to represent a true record of what was "on the wire"? Why should mailing list managers take liberties that are inappropriate to MTAs other than adding to, but not altering nor deleting anything either in the header or the body. The standards define, although somewhat loosely, how "Resent-" header fields are to be employed but "X-" header fields are not even mentioned in rfc2822. There have been several suggestions recently that would break the notion that list archives be a true record of what was on the wire. For public mailing lists in particular much would be lost if the lists own archives could be shown to differ from archives taken off the wire by others. We do not rewrite history and we must not be seen to be rewriting history by altering even esoteric details. I know of several instances where the availability of accurate public archives that were easily corroborated by other archives have simplified handling issues that might otherwise been very hard to deal with. A simple public example is the email in a mailing list archive that for several years was cited by URL in an early infamous Nigerian spam/scam. The ability to point to that email in the context of a long established mailing list concerning civic affairs in Nigeria deflected many would be actions against the organization running that list and those who hosted the mailing list service. Mailman presumably serves many uses besides public mailing lists. Many lists may not need to maintain their archives as a public record. However, unless you wish to make Mailman unsuitable for those that need accurate archives I suggest that you make it possible for the site to option individual lists in a way that permits the archives to serve as a public record of what was on the wire. If you must munge the archives I suggest you arrange options such that the site administrator can coerce certain lists to have accurate archives while leaving the option open for other lists. I also urge that the archive not break signatures on signed mail. baw> (note that we already do this for NNTP posted messages, and baw> there has been some off-list discussion about that). I am not as conversant with either the standards nor the practice for NNTP but IIRC news archives have always been supposed to represent what was on the wire, no? jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030928/6a19cee6/attachment.bin From harald.meland at usit.uio.no Sun Sep 28 14:25:29 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Sun Sep 28 14:25:53 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064756731.31604.143.camel@anthem> (Barry Warsaw's message of "Sun, 28 Sep 2003 09:45:32 -0400") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> Message-ID: [Barry Warsaw] > On Sun, 2003-09-28 at 05:13, Harald Meland wrote: >> 2) Whenever Mailman receives a message whose message-id is already >> present in the archives, the original Message-Id: header is >> renamed to e.g. X-Original-Message-Id:, and Mailman generates a >> fresh (as in "not yet present in the archives") message-id before >> the message is either archived or sent to the list members. > > This is what I was thinking about. Alternatively we could rewrite all > message-id headers when we accept the message. That would guarantee > uniqueness but it would break the correlation of message-ids between > list copies and direct copies. Is that bad? I don't think the RFCs speak clearly of this either way; however, it would break things for people who use message-id-based techniques to correlate received duplicates. On the other hand, such message-id-based techniques are IMHO workarounds for the ((still) very common) problem of people/programs not respecting the various (more-or-less standard) headers for directing where replies should go. The less aggressive approach would surely be to only generate new Message-Id:s for messages that already exist in a list's archive. > (note that we already do this for NNTP posted messages, and there > has been some off-list discussion about that). The Message-Id: field is (very) much more significant in NNTP than it is in SMTP. -- Harald From gary.frederick at jsoft.com Sun Sep 28 16:02:19 2003 From: gary.frederick at jsoft.com (Gary Frederick) Date: Sun Sep 28 16:02:35 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <87k77sokbx.fsf@athene.jamux.com> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> <87k77sokbx.fsf@athene.jamux.com> Message-ID: <3F773E4B.9000302@jsoft.com> FWIW: We have Mailman archive recent email and then use MHonArc to build our 'permanent' archives. I'm happy as long as I can get a copy of the original email. I may put up an edited version of some messages but keep the original - just in case. Gary John A. Martin wrote: trim > I am not as conversant with either the standards nor the practice for > NNTP but IIRC news archives have always been supposed to represent > what was on the wire, no? > > jam I agree. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From harald.meland at usit.uio.no Sun Sep 28 16:09:09 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Sun Sep 28 16:09:32 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <87k77sokbx.fsf@athene.jamux.com> (John A. Martin's message of "Sun, 28 Sep 2003 14:10:26 -0400") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> <87k77sokbx.fsf@athene.jamux.com> Message-ID: [John A. Martin] >>>>>> "baw" == Barry Warsaw >>>>>> "Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives" >>>>>> Sun, 28 Sep 2003 09:45:32 -0400 > > baw> On Sun, 2003-09-28 at 05:13, Harald Meland wrote: > >> [Barry Warsaw] > >> > >> > I really really want to use something like message-ids to > >> > generate message file names. I want to be able to generate > >> > links to archived messages in the footers, > > In the header, please. All messages have headers, not all have > footers. Footers are optional, no? This will go on the wire, right? "Be able to" is not (necessarily) the same as "will always". I read Barry as saying "it should be _possible_ to configure Mailman to add the archive URL of the message to the (Mailman-added) footer of the message". That being said, it would be nice if a standardized header could be used for this. However, to the best of my knowledge, presently there is no standard specifying an header for such a purpose. > baw> we could rewrite all message-id headers when we accept the > baw> message. That would guarantee uniqueness but it would break > baw> the correlation of message-ids between list copies and direct > baw> copies. Is that bad? > > Yes. The RFCs are clear that MTAs must not muck with Message-Id > other that to create one if there is none. It is not clear to me that Mailman *is* an MTA. It is not an SMTP server, and is not (necessarily) an SMTP client. However, even if Mailman isn't an MTA, it would be nice if it *mostly* tries to follow the MTA rules. (As a side note, I am unable to find *clear* references to the effect of your statement in RFCs 2821 or 2822.) > What happened to the notion that archives are supposed to represent a > true record of what was "on the wire"? Um. Mailman lists have numerous configuration options for changing messages (e.g. adding footers) before they are sent to the list members, and it has had such options since time immemorial. As such, Mailman has to choose; should the messages be archived as they appeared on the wire _coming in_ or _going out_? To me, it is obvious that messages in the archives should reflect, as closely as possible, the messages members receive. As to the particular issue of changing a message's message-id iff the incoming message-id is already present in the list's archives: * According to RFC 2822, section 3.6.4, it is up to the host that "generates" a message to assure that the message's message-id is unique: The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it (see below). This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. * To my mind it would not be obviously wrong to view Mailman as the *generator* of messages, at the very least in the cases where it is obvious that the previous generator didn't do its job of guaranteeing message-id uniqueness properly. > I also urge that the archive not break signatures on signed mail. I certainly agree that this would be very nice, both for mail obtained from archives and mail received "live" through a Mailman list. -- Harald From brad.knowles at skynet.be Sun Sep 28 10:33:45 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Sep 28 16:40:37 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <1064727442.31604.119.camel@anthem> References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> Message-ID: At 1:37 AM -0400 2003/09/28, Barry Warsaw wrote: > I really really want to use something like message-ids to generate > message file names. IIRC, Earl talks about this in the FAQ. In short, for security reasons, you can't trust any of the information you are given anywhere in the message, unless you can scrub that information and guarantee that it is now safe. Otherwise, you could get a message-id like "<../.htaccess>" or some other equally nasty thing that could potentially cause other files to be over-written inappropriately. Moreover, given that there are a lot of people out there with home networks using RFC 1918 private addressing, and this information is being used to help generate otherwise properly formatted message-ids, the probability of message-id collision increases significantly. This issue was recently brought to my attention because of my own RFC 1918 private networking here at home, and the information my MUA uses to generate message-ids. Therefore, I think we might want to be a bit more careful in how we generate the file names. > I want to be able to generate links to archived > messages in the footers, but I think the best way to do that is to agree > on a reproducible, independent algorithm for calculating them. One thing that MHonArc does for messages that are not assigned a message-id (to help detect and eliminate duplicates) is to calculate an MD5 hash of the message headers and uses that as a substitute. We could do the same, or perhaps even use the MD5 hash instead of the message-id, and then store hash/message-id mappings in a database. > Another > approach would be to put even the public archives behind a cgi and have > that implement a mapping between message-id derived links and the > sequential file names (although that won't fix the regen problem). One problem that most OSes have is with too many files in a single directory -- go much over 1000 files in a directory and accessing anything in that directory starts taking significantly longer than it used to. If you use a sequential message numbering system, it's hard to break those up into smaller chunks of messages in a hashed directory scheme. With MD5 hashes, it would be a lot easier to convert the hash into a path name, just by adding slashes every so often in the hash value. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From barry at python.org Mon Sep 29 09:10:14 2003 From: barry at python.org (Barry A. Warsaw) Date: Mon Sep 29 09:10:24 2003 Subject: [Mailman-Developers] RELEASED Mailman 2.1.3 Message-ID: <16248.12086.587819.677899@gargle.gargle.HOWL> I have released Mailman 2.1.3, a bug fix release which also contains support for four new languages: Ukrainian, Serbian, Euskara (Basque), and Danish. This release also contains a fix for a cross-site scripting vulnerability in the 'create' cgi script, as well as improved performance of the bounce and outgoing queue runners. I recommend all sites running versions of the 2.1.x line upgrade to the new version. The full source tarball has been made available from the usual sites (although the gnu.org sites have not yet been updated). Sorry, there is no patch available, but you should be able to install 2.1.3 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. After installing, be sure you restart your Mailman daemon by doing a "mailmanctl restart". See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.3 (28-Sep-2003) Performance, Reliability, Security - Closed a cross-site scripting exploit in the create cgi script. - Improvements in the performance of the bounce processor. Now, instead of processing each bounce immediately (which can cause severe lock contention), bounce events are queued. Every 15 minutes by default, the queued bounce events are processed en masse, on a list-per-list basis, so that each list only needs to be locked once. - When some or all of a message's recipients have temporary delivery failures, the message is moved to a "retry" queue. This queue wakes up occasionally and moves the file back to the outgoing queue for attempted redelivery. This should fix most observed OutgoingRunner 100% cpu consumption, especially for bounces to local recipients when using the Postfix MTA. - Optional support for fsync()'ing qfile data after writing. Under some catastrophic system failures (e.g. power lose), it would be possible to lose messages because the data wasn't sync'd to disk. By setting SYNC_AFTER_WRITE to True in Mailman/Queue/Switchboard.py, you can force Mailman to fsync() queue files after flushing them. The benefits are debatable for most operating environments, and you must ensure that your Python has the os.fsync() function defined before enabling this feature (it isn't, even on all Unix-like operating systems). Internationalization - New languages Ukrainian, Serbian, Danish, Euskara/Basque. - Fixes to template lookup. Lists with local overriding templates would find the wrong template. - .mo files (for internationalization) are now generated at build time instead of coming as part of the source distribution. Documentation - A first draft of member documentation by Terri Oda. There is also a Japanese translation of this manual by Ikeda Soji. Archiver / Pipermail - In the configuration variables PUBLIC_EXTERNAL_ARCHIVER, and PRIVATE_EXTERNAL_ARCHIVER, %(hostname)s has been added to the list of allowable substitution variables. - The timezone is now taken into account when figuring the posting date for an article. Scripts / Cron - Fixes to cron/disabled for NotAMemberError crashes. - New script bin/show_qfiles which prints the contents of .pck message files. New script bin/discard which can be used to mass discard held messages. - Fixes to cron/mailpasswds to account for old password-less subscriptions. - bin/list_members has grown two new options: --invalid/-i prints only the addresses in the member database that are invalid (which could have snuck in via old releases); --unicode/-u prints addresses which are stored as Unicode objects instead of as normal strings. Miscellaneous - Fixes to problems in some configurations where Python wouldn't be able to find its standard library. - Fixes to the digest which could cause MIME-losing missing newlines when parts are scrubbed via the content filters. - In the News/Mail gateway admin page, the configuration variable nntp_host can now be a name:port pair. - When messages are pulled from NNTP, the member moderation checks are short-circuited. - email 2.5.4 is included. This fixes an RFC 2231 bug, among possibly others. - Fixed some extra spaces that could appear in the List-ID header. - Fixes to ensure that invalid email addresses can't be invited. - WEB_LINK_COLOR in Defaults.py/mm_cfg.py should now work. - Fixes so that shunted message file names actually match those logged in log/errors. - An improved pending action cookie generation algorithm has been added. - Fixes to the DSN bounce detector. - The usual additional u/i, internationalization, unicode, and other miscellaneous fixes. From RabbiSim at earthlink.net Mon Sep 29 14:30:32 2003 From: RabbiSim at earthlink.net (Rabbi Simcha Backman) Date: Mon Sep 29 14:30:47 2003 Subject: [Mailman-Developers] RE: [Mailman-Announce] RELEASED Mailman 2.1.3 In-Reply-To: <16248.12086.587819.677899@gargle.gargle.HOWL> Message-ID: <003801c386b7$c40f9ac0$6601a8c0@smile> Are you planning on a Hebrew language release anytime soon? Thanks -----Original Message----- From: mailman-announce-bounces@python.org [mailto:mailman-announce-bounces@python.org] On Behalf Of Barry A. Warsaw Sent: Monday, September 29, 2003 6:10 AM To: mailman-announce@python.org Cc: mailman-developers@python.org; mailman-users@python.org Subject: [Mailman-Announce] RELEASED Mailman 2.1.3 I have released Mailman 2.1.3, a bug fix release which also contains support for four new languages: Ukrainian, Serbian, Euskara (Basque), and Danish. This release also contains a fix for a cross-site scripting vulnerability in the 'create' cgi script, as well as improved performance of the bounce and outgoing queue runners. I recommend all sites running versions of the 2.1.x line upgrade to the new version. The full source tarball has been made available from the usual sites (although the gnu.org sites have not yet been updated). Sorry, there is no patch available, but you should be able to install 2.1.3 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. After installing, be sure you restart your Mailman daemon by doing a "mailmanctl restart". See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.3 (28-Sep-2003) Performance, Reliability, Security - Closed a cross-site scripting exploit in the create cgi script. - Improvements in the performance of the bounce processor. Now, instead of processing each bounce immediately (which can cause severe lock contention), bounce events are queued. Every 15 minutes by default, the queued bounce events are processed en masse, on a list-per-list basis, so that each list only needs to be locked once. - When some or all of a message's recipients have temporary delivery failures, the message is moved to a "retry" queue. This queue wakes up occasionally and moves the file back to the outgoing queue for attempted redelivery. This should fix most observed OutgoingRunner 100% cpu consumption, especially for bounces to local recipients when using the Postfix MTA. - Optional support for fsync()'ing qfile data after writing. Under some catastrophic system failures (e.g. power lose), it would be possible to lose messages because the data wasn't sync'd to disk. By setting SYNC_AFTER_WRITE to True in Mailman/Queue/Switchboard.py, you can force Mailman to fsync() queue files after flushing them. The benefits are debatable for most operating environments, and you must ensure that your Python has the os.fsync() function defined before enabling this feature (it isn't, even on all Unix-like operating systems). Internationalization - New languages Ukrainian, Serbian, Danish, Euskara/Basque. - Fixes to template lookup. Lists with local overriding templates would find the wrong template. - .mo files (for internationalization) are now generated at build time instead of coming as part of the source distribution. Documentation - A first draft of member documentation by Terri Oda. There is also a Japanese translation of this manual by Ikeda Soji. Archiver / Pipermail - In the configuration variables PUBLIC_EXTERNAL_ARCHIVER, and PRIVATE_EXTERNAL_ARCHIVER, %(hostname)s has been added to the list of allowable substitution variables. - The timezone is now taken into account when figuring the posting date for an article. Scripts / Cron - Fixes to cron/disabled for NotAMemberError crashes. - New script bin/show_qfiles which prints the contents of .pck message files. New script bin/discard which can be used to mass discard held messages. - Fixes to cron/mailpasswds to account for old password-less subscriptions. - bin/list_members has grown two new options: --invalid/-i prints only the addresses in the member database that are invalid (which could have snuck in via old releases); --unicode/-u prints addresses which are stored as Unicode objects instead of as normal strings. Miscellaneous - Fixes to problems in some configurations where Python wouldn't be able to find its standard library. - Fixes to the digest which could cause MIME-losing missing newlines when parts are scrubbed via the content filters. - In the News/Mail gateway admin page, the configuration variable nntp_host can now be a name:port pair. - When messages are pulled from NNTP, the member moderation checks are short-circuited. - email 2.5.4 is included. This fixes an RFC 2231 bug, among possibly others. - Fixed some extra spaces that could appear in the List-ID header. - Fixes to ensure that invalid email addresses can't be invited. - WEB_LINK_COLOR in Defaults.py/mm_cfg.py should now work. - Fixes so that shunted message file names actually match those logged in log/errors. - An improved pending action cookie generation algorithm has been added. - Fixes to the DSN bounce detector. - The usual additional u/i, internationalization, unicode, and other miscellaneous fixes. _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From jam at jamux.com Mon Sep 29 15:17:37 2003 From: jam at jamux.com (John A. Martin) Date: Mon Sep 29 15:17:53 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: (Harald Meland's message of "Sun, 28 Sep 2003 22:09:09 +0200") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> <87k77sokbx.fsf@athene.jamux.com> Message-ID: <87u16vl7zi.fsf@athene.jamux.com> >>>>> "Harald" == Harald Meland >>>>> "Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives" >>>>> Sun, 28 Sep 2003 22:09:09 +0200 >>>>>>> "baw" == Barry Warsaw "Re: [Mailman-Developers] "@" in >>>>>>> mail **text** gets replaced inarchives" Sun, 28 Sep 2003 >>>>>>> 09:45:32 -0400 baw> we could rewrite all message-id headers when we accept the baw> message. That would guarantee uniqueness but it would break baw> the correlation of message-ids between list copies and direct baw> copies. Is that bad? >> >> Yes. The RFCs are clear that MTAs must not muck with >> Message-Id other that to create one if there is none. Harald> It is not clear to me that Mailman *is* an MTA. It is not Harald> an SMTP server, and is not (necessarily) an SMTP client. To have been precise perhaps I should have said something like "a mail agent must not muck with an existing Message-Id except as specified by the applicable standards". The Applicable Standards, to quote for example rfc2822,, apply as follows: This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. The applicable standards govern what goes on the wire and therefore what Mailman causes to be put on the wire through a MTA should be compliant. Harald> However, even if Mailman isn't an MTA, it would be nice if Harald> it *mostly* tries to follow the MTA rules. Harald> (As a side note, I am unable to find *clear* references to Harald> the effect of your statement in RFCs 2821 or 2822.) Rfc2822 Section 3.6.4 (the first paragraph below is the same paragraph you quoted elsewhere) [[ ... ]] The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it (see below). This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. Rfc822 Section 4.6.1 (in its entirety): This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers. Rfc2822 in this case merely codifies long established practice interpreting rfc822. Rfc2822 Appendix A.3 may be helpful for the present discussion. To test for compliance with the rfc2822 determination "whether this is the same message or a different message" one might stipulate that if the PGP signature verifies it is the same message, if the PGP signature does not verify it is a different message. As can be seen with the version of this here message that Mailman will send, a trailer can be added to the body without breaking the signature. The rule might be "if you break the signature, it is a new message and needs (at least) a new Message-Id" (One certainly can see by inspection what would break a signature without actually verifying the signature, right?) Harald> Um. Mailman lists have numerous configuration options for Harald> changing messages (e.g. adding footers) before they are Harald> sent to the list members, and it has had such options Harald> since time immemorial. Who reads the RFCs to say that footers cannot be added without changing the message? Other munging of the message is IMHO unsuitable for public archives and have not been obligatory AFIK. Harald> As such, Mailman has to choose; should the messages be Harald> archived as they appeared on the wire _coming in_ or Harald> _going out_? To me, it is obvious that messages in the Harald> archives should reflect, as closely as possible, the Harald> messages members receive. Agreed, the archive should record what Mailman put on the wire. No choice required! At least as you put it. I suppose a case could be made for archiving the mail received "from the wire" but I haven't thought of a good reason why that would be better. Harald> * To my mind it would not be obviously wrong to view Harald> Mailman as the *generator* of messages, at the very Harald> least in the cases where it is obvious that the Harald> previous generator didn't do its job of guaranteeing Harald> message-id uniqueness properly. Why? ISTM the problem you are trying to solve is how to identify the archive image of the message. Why not construct a URL containing a scrubbed Message-Id (as Brad Knowles has indicated) and a serial number (as I have indicated)? Such a URL should go into the "List-Archive" header field pointing to the specific message without doing violence to rfc2369 Section 3.6, right? jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030929/da4e6908/attachment.bin From harald.meland at usit.uio.no Mon Sep 29 19:29:54 2003 From: harald.meland at usit.uio.no (Harald Meland) Date: Mon Sep 29 19:30:24 2003 Subject: [Mailman-Developers] "@" in mail **text** gets replaced inarchives In-Reply-To: <87u16vl7zi.fsf@athene.jamux.com> (John A. Martin's message of "Mon, 29 Sep 2003 15:17:37 -0400") References: <20030926172256.88684.qmail@web14916.mail.yahoo.com> <036c01c3848d$6808acc0$0501a8c0@kevinduron> <03ba01c384ff$8eca10c0$0501a8c0@kevinduron> <1064727442.31604.119.camel@anthem> <1064756731.31604.143.camel@anthem> <87k77sokbx.fsf@athene.jamux.com> <87u16vl7zi.fsf@athene.jamux.com> Message-ID: [John A. Martin] >>>>>> "Harald" == Harald Meland > > Harald> It is not clear to me that Mailman *is* an MTA. It is not > Harald> an SMTP server, and is not (necessarily) an SMTP client. > > To have been precise perhaps I should have said something like "a mail > agent must not muck with an existing Message-Id except as specified by > the applicable standards". The Applicable Standards, to quote for > example rfc2822,, apply as follows: > > This standard specifies a syntax for text messages that are sent > between computer users, within the framework of "electronic mail" > messages. I agree that it is obvious that Mailman should strive to avoid sending non-RFC2822-compliant messages. However, I would think that the issue at hand is not about message *syntax*, but rather about the *semantic* value of a message's Message-Id. Now that that nit is off my chest :-), I'll be quick to agree that RFC 2822 surely do contain a fair bit of semantic specifications as well; more on that below. > The applicable standards govern what goes on the wire and therefore > what Mailman causes to be put on the wire through a MTA should be > compliant. Mailman is sort of between a rock and a hard place here, as it occupies a double role: * Mailman should be liberal in what it accepts -- which seems to imply that it should accept incoming messages even if they do not not conform strictly to all aspects of RFC 2822. As one example, Mailman shouldn't offhandedly reject an incoming message just because there is a slight address syntax error in the message's From: header. * At the same time, Mailman should be conservative in what it sends. Naively, this would mean that Mailman ought to ensure that any message it puts on the wire conforms with RFC 2822; however, that would then have to either clash with the "liberal in what you expect" idea, or with the "don't change the message" maxim. > Harald> However, even if Mailman isn't an MTA, it would be nice if > Harald> it *mostly* tries to follow the MTA rules. > > Harald> (As a side note, I am unable to find *clear* references to > Harald> the effect of your statement in RFCs 2821 or 2822.) > > Rfc2822 Section 3.6.4 (the first paragraph below is the same paragraph > you quoted elsewhere) > > [[ ... ]] > > The "Message-ID:" field provides a unique message identifier that > refers to a particular version of a particular message. The > uniqueness of the message identifier is guaranteed by the host that > generates it (see below). This message identifier is intended to be > machine readable and not necessarily meaningful to humans. A message > identifier pertains to exactly one instantiation of a particular > message; subsequent revisions to the message each receive new message > identifiers. > > Note: There are many instances when messages are "changed", but those > changes do not constitute a new instantiation of that message, and > therefore the message would not get a new message identifier. For > example, when messages are introduced into the transport system, they > are often prepended with additional header fields such as trace > fields (described in section 3.6.7) and resent fields (described in > section 3.6.6). The addition of such header fields does not change > the identity of the message and therefore the original "Message-ID:" > field is retained. In all cases, it is the meaning that the sender > of the message wishes to convey (i.e., whether this is the same > message or a different message) that determines whether or not the > "Message-ID:" field changes, not any particular syntactic difference > that appears (or does not appear) in the message. > > Rfc822 Section 4.6.1 (in its entirety): > > This field contains a unique identifier (the local-part > address unit) which refers to THIS version of THIS message. > The uniqueness of the message identifier is guaranteed by the > host which generates it. This identifier is intended to be > machine readable and not necessarily meaningful to humans. A > message identifier pertains to exactly one instantiation of a > particular message; subsequent revisions to the message should > each receive new message identifiers. > > Rfc2822 in this case merely codifies long established practice > interpreting rfc822. Rfc2822 Appendix A.3 may be helpful for the > present discussion. The part that (still) isn't clear to me, is whether Mailman's action of putting the message back on the wire can be said to be either 1) generation of a new message (personally, I wouldn't think so) or 2) a new instantiation of the message. > To test for compliance with the rfc2822 determination "whether this is > the same message or a different message" one might stipulate that if > the PGP signature verifies it is the same message, if the PGP > signature does not verify it is a different message. Now we're deeply into message semantics. :-) I'd like to point out to things about your argument: Firstly, the RFC does not merely distinguish between "the same message or a different message"; it also allows Message-ID: to be changed whenever there is a new instantiation of a (single) message. Secondly, having to resort to (your) *interpretation* of the RFC, by using verification of PGP signatures for the test, is in my book a clear indication that the RFC is *not* crystal clear on this issue. > (One certainly can see by inspection what would break a signature > without actually verifying the signature, right?) That is my (rather shallow, I'm afraid) understanding of PGP email signatures, yes. > Harald> Um. Mailman lists have numerous configuration options for > Harald> changing messages (e.g. adding footers) before they are > Harald> sent to the list members, and it has had such options > Harald> since time immemorial. > > Who reads the RFCs to say that footers cannot be added without > changing the message? The more interesting issue, I think, is where should the line be drawn; how much is Mailman allowed to change (various parts of) a message before it should be considered a new message? And, how does the Mailman modus operandi fit in with the RFCs "new instantiation" use of words? > Harald> * To my mind it would not be obviously wrong to view > Harald> Mailman as the *generator* of messages, at the very > Harald> least in the cases where it is obvious that the > Harald> previous generator didn't do its job of guaranteeing > Harald> message-id uniqueness properly. > > Why? Given that there exists two (or more) distinct messages that share the same message-id, the uniqueness of this identifier (as proscribed by RFC 2822) is clearly not satisfied. Hence, if Mailman really wants to have the messages it puts on the wire conform with RFC 2822, it should take on the role of message generator, and issue distinct message-ids for such distinct messages. The hard problem, of course, is to properly discover whether or not two messages are indeed distinct; they might differ slightly by e.g. an automatically added footer, or in some other minor, but programmatically hard to discover, fashion. > ISTM the problem you are trying to solve is how to identify the > archive image of the message. > > Why not construct a URL containing a scrubbed Message-Id (as Brad > Knowles has indicated) and a serial number (as I have indicated)? Because, as Barry said, that would mean the "archive image identity" of the messages could change whenever the archive needs to be rebuilt (e.g. after a disk crash, the archives are gone, and there are no backups; then some kind list member comes forward with a partial archive constructed from the messages they've received from the list). > Such a URL should go into the "List-Archive" header field pointing to > the specific message without doing violence to rfc2369 Section 3.6, > right? I don't think that's too far from the intention of that header, no. That section seems rather loosely worded, something I hope was done intentionally: 3.6. List-Archive The List-Archive field describes how to access archives for the list. Examples: List-Archive: List-Archive: List-Archive: (Web Archive) -- Harald From gsstark at mit.edu Tue Sep 30 11:10:31 2003 From: gsstark at mit.edu (Greg Stark) Date: Tue Sep 30 11:10:35 2003 Subject: [Mailman-Developers] [java-help@gcc.gnu.org] ezmlm warning Message-ID: <87vfracnx4.fsf@stark.dyndns.tv> As an example of what I mean this is the notice that ezmlm sends. It's really helpful too, it explains that the messages have been bouncing, provides an example of the bounce so the user can make a guess *why* they're bouncing, and provides a link to the archives (actually instructions on retrieving them by e-mail). It also explains that in order to drop you from the list the bounce notification message has to itself bounce. In fact it goes a step further and sends a followup message. It will only remove you if that message bounces too. I think mailman really needs something like this. I haven't been removed from any ezmlm lists even though I periodically get these notifications from lots of them. In fact I wouldn't even know *why* I was being dropped from mailman lists regularly if it weren't for these ezmlm notifications. That's really bad. Mailman drops people without any warning or notification of what it's doing or why. -------------- next part -------------- An embedded message was scrubbed... From: java-help@gcc.gnu.org Subject: ezmlm warning Date: 30 Sep 2003 01:19:07 -0000 Size: 3111 Url: http://mail.python.org/pipermail/mailman-developers/attachments/20030930/5b6f247c/attachment-0001.mht -------------- next part -------------- -- greg From r.barrett at openinfo.co.uk Tue Sep 30 16:58:39 2003 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Tue Sep 30 16:58:47 2003 Subject: [Mailman-Developers] MM 2.1.3 version Mailman-htdig integration patches available Message-ID: I have uploaded updated files to sourceforge for the following patches and bugs I maintain, which include my Mailman-HTdig integration patches. You can reach them through: http://sourceforge.net/tracker/?group_id=103 Mailman - Patches ----------------- #444879 - Archive indexer control to improve index #444884 - Integration of Mailman & htdig for archi #644797 - Revised mailer exit status #644810 - Sendmail mailer in Python #760567 - moderation request message content Mailman - Bugs -------------- #777444 - mailmanctl doesn't setgroups when run as root They are also available through: http://www.openinfo.co.uk/mailman/index.html If you encounter any problems with downloading or using these patches then let me know. ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From r.barrett at openinfo.co.uk Tue Sep 30 18:01:08 2003 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Tue Sep 30 18:03:20 2003 Subject: [Mailman-Developers] Mailman/pipermail/MHonArc Message-ID: <9890D8B2-F391-11D7-8EE8-000A957C9A50@openinfo.co.uk> This topic got some airtime on the list recently and I thought I would share my thoughts on it. Mailman/pipermail has got some strengths and some weaknesses. Ditto MHonArc. Being greedy and unable to wait for the Mailman 3's wizzy archiver/archive-search solution I decided to try for the best of both worlds from what code is currently available. The result is a patch for Mailman 2.1.3 (the MM 2.1.2 solution was strictly in-house) which creates a Mailman/pipermail/MHonArc integration/fusion. This may be rubbish or the greatest thing since sliced bread. That being the case I have yet to upload the patch to sourceforge. Anybody with an opinion on such an action is welcome to (politely) give their opinion about it. My description of the patch and the patch is available at: http://www.openinfo.co.uk/mailman/patches/mhonarc/index.html This patch of mine works but is a crude hack and I would really love to work on a really good replacement for pipermail + search engine. As an aside, I have been using Perl since 1993 and have a love-hate relationship with it. It works extremely well and has advanced our capabilities but it offends most of my sensibilities. There has to be be a better solution than MHonArc (and pipermail) but Earl Hood does do such a good job with Perl. Enough rant/navel-fluff-checking. ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From gaclark at attglobal.net Tue Sep 30 17:00:48 2003 From: gaclark at attglobal.net (Gregory A. Clark) Date: Wed Oct 1 12:49:46 2003 Subject: [Mailman-Developers] MailMan Archives and more cPanel Control Message-ID: <003501c38795$ee5bb410$1c0d1f0a@us.oracle.com> I can only create and maintain my mailing list options via cPanel. The actual mailman files are not in a user accessible area for me. I have private archival set on. When I look at the generated archive page there is: 1. a link to download the full raw archive 2. a link "Downloadable version [ Gzip'd Text xx KB ]" Is there any development initiative to allow more control of the MailMail archiving via cPanel? Is there any current way I can suppress these, given my obvious lack of system privileges? I don't want these archive download links to appear. I have the following at my current web hosting account: MailMan Version 2.1.2 Pipermail 0.09 cPanel Version 7.4.2 MySQL Version 4.0.15 PHP Version 4.3.3 Regards, Greg From marius at gazduire.ro Sun Sep 28 16:40:09 2003 From: marius at gazduire.ro (Marius Herea / Gazduire.ro) Date: Wed Oct 1 12:50:15 2003 Subject: [Mailman-Developers] loginpage Message-ID: <043d01c38600$b7552b40$21946050@urban> Hi, I have mailman v 2.1.2 and I have no idea how to edit the loginpage for a website. Is there a way to put a condition somewhere in order to show a page defined by me for every list under a domain.tld? Regards, Marius From mark at pdc-racing.net Tue Sep 30 17:03:28 2003 From: mark at pdc-racing.net (Mark Dadgar) Date: Wed Oct 1 12:50:28 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] MM 2.1.3 version Mailman-htdig integration patches available In-Reply-To: Message-ID: <8A703294-F389-11D7-BE7A-003065553436@pdc-racing.net> On Tuesday, September 30, 2003, at 01:58 PM, Richard Barrett wrote: > I have uploaded updated files to sourceforge for the following patches > and bugs I maintain, which include my Mailman-HTdig integration > patches. You can reach them through: [munch] > #444879 - Archive indexer control to improve index > > #444884 - Integration of Mailman & htdig for archi THANK YOU, Richard! - Mark ----- mark@pdc-racing.net From pug at pug.net Tue Sep 30 12:37:35 2003 From: pug at pug.net (Pug Bainter) Date: Wed Oct 1 12:51:38 2003 Subject: [Mailman-Developers] Not sleeping for locks? Message-ID: <20030930113735.A17184@stardock.pug.net> Good Morning, We've been noticing a very high load on our fileserver that holds our mailman spool. This morning when I ran 2 archivers at once because of a backlog to a list, I noticed that the stat request volume sky rocketed. From strace'ing a second archiver running, I see that the system doesn't even a tenth of a second in what I assume is the time.sleep call. [...] 11:15:10.712914 gettimeofday({1064938510, 712937}, NULL) = 0 11:15:10.712976 gettimeofday({1064938510, 712998}, NULL) = 0 11:15:11.512977 gettimeofday({1064938511, 512995}, NULL) = 0 11:15:11.513035 gettimeofday({1064938511, 513051}, NULL) = 0 [...] Now maybe I'm not understanding what the following code is supposed to do: def __sleep(self): interval = random.random() * 2.0 + 0.01 time.sleep(interval) but I read it to be sleeping for between 0.01 and 2.01 seconds. During my traces, I never saw it sleep even 0.01 seconds, let alone anything ressembling something reasonably random. Am I just missing something? This was noticed on: Mailman version: 2.1.2 Python version: 2.2.2 OS version: Solaris 2.8 and RedHat 7.3 Thanks for any help! NOTE: I'm not on the developers list, but I thought they might have an answer for this behavior. Ciao, -- Pug Bainter | AMD, Inc. System Engineer, MTS | Mail Stop 625 Pug.Bainter@amd.com | pug@pug.net | 5900 E. Ben White Blvd Phone: (512) 602-0364 | Fax: (512) 602-6970 | Austin, TX 78741 Note: The views may not reflect my employers, or even my own for that matter.