Mailman 3 May 2001 - Mailman-Developers

Error in bin/config_list
by Juan Carlos Rey Anaya May 17, 2001

May 17, 2001

I have received a message with the error description: Vizi Szilard <vizisz(a)freemail.hu> > - I found an error: > [root@tatooin bin]# ./config_list -o /root/config test > Traceback (most recent call last): > File "./config_list", line 261, in ? > main() > File "./config_list", line 254, in main > do_output(listname, outfile) > File "./config_list", line 115, in do_output > info = config[k] > KeyError: altalanos > > altalanos means general in English. What is the problem? I have taken a glance to Mailman code and I have found: in MailList.py.GetConfigInfo: config_info['general'] = [_( "Fundamental list characteristics, including descriptive" " info and basic behaviors."), ('real_name', mm_cfg.String, 50, 0, _('The public name of this list (make case-changes only).'), and in config_list.do_output: config = mlist.GetConfigInfo() categories = (_('general'), _('privacy'), _('nondigest'), _('digest'), _('bounce'), _('archive'), _('gateway'), _('autoreply')) for k in categories: info = config[k] So 'k' must be untranslated, that's because that key does not exists in array 'config' -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey(a)uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------#

1 0

Mailman error Bad Marshal
by Kory Wheatley May 17, 2001

May 17, 2001

Received this for a hour and then it went away everything worked after that, but is there any solution to this problem. ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/wrapper mailowner ccaussec" (expanded from: ccaussec-admin) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/scripts/mailowner", line 33, in ? from Mailman import MailList ValueError: bad marshal data 554 "|/home/mailman/mail/wrapper mailowner ccaussec"... unknown mailer error 1

1 0

How about Auto Discard
by Tokio Kikuchi May 17, 2001

May 17, 2001

Hi! Developers, It is cumbersome to click 'Discard' on the admindb page each time a spam message come to the list address or at least every day basis. If we have an automatic discard function which will be ivoked by cron, we can just check the admin notice and do nothing. The held message will disappear two or three days later. Following script will do the job (I hope). Please review it and comment! Would it be better to define the expiration period in mm_cfg.py ? (I omitted the copyright/license notices) Regards, Tokio Kikuchi #!/usr/bin/env python # import sys import paths import time from Mailman import mm_cfg from Mailman import MailList from Mailman import Utils expire = 2 * 24 * 60 * 60 # 2 days now = time.time() def auto_discard(mlist): if not mlist.NumRequestsPending(): return heldmsgs = mlist.GetHeldMessageIds() total = len(heldmsgs) if total: for id in heldmsgs: info = mlist.GetRecord(id) ptime,sender,subject,reason,filename,msgdata = info if now - ptime > expire: print 'DISCARD',id, ptime, sender, subject mlist.HandleRequest(id, mm_cfg.DISCARD) mlist.Save() def main(): confined_to = sys.argv[1:] for listname in Utils.list_names(): if confined_to and listname not in confined_to: continue mlist = MailList.MailList(listname, lock=0) mlist.Lock() auto_discard(mlist) mlist.Unlock() if __name__ == '__main__': main()

1 0

Feature request
by Marc MERLIN May 16, 2001

May 16, 2001

Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion. The best/worst part is how people made it a lot worse by complaining to the list itself and spamming one another after that: http://www.geocrawler.com/lists/3/SourceForge/10386/0/ Anyway, I patched admin.py to just disallow admin web subscribes altogether. In order of preference, for a future mailman version, it'd be nice if mailman would: - Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password) - Easier: have a sitewide mm_cfg.py variable to allow/disallow web subscribes by the list admin Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

3 4

Virtual hosting
by barry＠digicool.com May 16, 2001

May 16, 2001

I've started to sketch out some requirements for improving the virtual hosting support for Mailman. It's not finished, but I'm soliciting comments anyway. Please see http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting and please add comments to the Wiki page. I'm not sure whether this stuff will make it into Mailman 2.1 or will have to be postponed. Cheers, -Barry

1 0

mailman-developers�� ȳ��ϼ��?
by �¶��ڸ�� May 16, 2001

May 16, 2001

1 0

Administrivia: Move to EZMLM (fwd)
by J C Lawrence May 14, 2001

May 14, 2001

An message interesting for some of the advantages they see in EZMLM as versus ListServ. While obviously not the driving forces, the comments about Precedence: and Sender: headers caught me by surprise. ------- Forwarded Message Date: Sun, 13 May 2001 23:51:27 -0600 From: aleph1(a)securityfocus.com To: bugtraq(a)securityfocus.com Cc: aris-users(a)securityfocus.com, bugtraq-es(a)securityfocus.com, bugtraq-jp(a)securityfocus.com, certification(a)securityfocus.com, cisspstudy(a)securityfocus.com, focus-ids(a)securityfocus.com, focus-linux(a)securityfocus.com, focus-ms(a)securityfocus.com, focus-sun(a)securityfocus.com, focus-virus(a)securityfocus.com, forensics(a)securityfocus.com, incidents(a)securityfocus.com, isn(a)securityfocus.com, libnet(a)securityfocus.com, linux-secnews(a)securityfocus.com, ms-secnews(a)securityfocus.com, pen-test(a)securityfocus.com, secevents(a)securityfocus.com, secpapers(a)securityfocus.com, secprod(a)securityfocus.com, secprog(a)securityfocus.com, sectools(a)securityfocus.com, security-basics(a)securityfocus.com, securityjobs(a)securityfocus.com, sf-news(a)securityfocus.com, vpn(a)securityfocus.com, vuln-dev(a)securityfocus.com, www-mobile-code(a)securityfocus.com Subject: Administrivia: Move to EZMLM Good day, [ I apologize to those that will receive this message multiple times ] As undoubtedly you will have noticed by now we experienced some problem with our mailing lists this past week. In short, LISTSERV finally croaked. It simply could not handle the load. We hoped to perform the these changes in a couple of months as part of our upgrade strategy but we were forced to accelerate our scheduled plans. We have moved the mailing lists over to ezmlm-idx. This will require a little getting used to but it should not be particularly challenging. ezmlm-idx offers most of the features LISTSERV does and a few of its own. Performance wise it should give LISTSERV a good beating. To familiarize yourself with ezmlm-idx review the ezman manual at http://www.ezmlm.org/ezman-0.32/index.html. If you were using the digest option under LISTSERV you will need to unsubscribe from the list and resubscribe to the digest. This can be easily accomplished by sending messages to the <list>-unsubscribe(a)securityfocus.com and <list>-digest-subscribe(a)securityfocus.com addresses. Messages that had been received by LISTSERV but not yet processed, including messages that had become stuck on its queue and appeared to disappear last week, have been re-injected into the mail system. List moderators may, or may not, approve them, as appropriate. Aside from the speed benefits of ezmlm, messages now include a Precedence header which should cut down on the number of out-of-office and similar messages people that post to the list get. This is a feature L-Soft refused to provide. If you ever post to the list this should make you very happy. People that send messages with strange Sender headers should have no more problems either. Another quirk of LISTSERV L-Soft did not believe to be a problem. If you have any questions or comments please feel free to contact me. Cheers. - -- Elias Levy SecurityFocus.com http://www.securityfocus.com/ Si vis pacem, para bellum ------- End of Forwarded Message -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows

3 2

Re: [Mailman-Developers] Administrivia: Move to EZMLM (fwd)
by J C Lawrence May 14, 2001

May 14, 2001

On Mon, 14 May 2001 09:38:41 +0100 Nigel Metheringham <Nigel.Metheringham(a)InTechnology.co.uk> wrote: > The big advantage with EZMLM is the bounce handling - basically > because it uses VERP and mangles the envelope. The downside is > the mail-only one address per function (subscriber) control > interface (although it is proof against the Outlook user incapable > of sending plain unencoded text problem). Those that pay per byte > bandwidth charges might also find ezmlm more expensive to run. It doesn't seem conceptually difficult to setup an Exim filter which could be installed on a smart host such that list mail sent through it is VERPed EZMLM-style. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows

1 0

Re: [Mailman-Developers] Administrivia: Move to EZMLM (fwd)
by Nigel Metheringham May 14, 2001

May 14, 2001

claw(a)kanga.nu said: > An message interesting for some of the advantages they see in EZMLM as > versus ListServ. While obviously not the driving forces, the comments > about Precedence: and Sender: headers caught me by surprise. Relating this to mailman, it appears to me that we do the right thing (tm) with both those headers. The big advantage with EZMLM is the bounce handling - basically because it uses VERP and mangles the envelope. The downside is the mail-only one address per function (subscriber) control interface (although it is proof against the Outlook user incapable of sending plain unencoded text problem). Those that pay per byte bandwidth charges might also find ezmlm more expensive to run. Nigel. -- [ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ]

1 0

Re: Mailman and LDAP integration [was python-ldap and openldap 2.07]
by Donal Hunt May 12, 2001

May 12, 2001

Jens Vagelpohl wrote: > > > Have the authentication bit working at the moment. Having a think about > > how to store the mailman subscription information still. Whether to store > > the attributes (subscription type, nomail option, etc) as a sub-object of > > the person object or to have lots of atrributes named in such a way that > > they are unique to their list, but easily searchable and don't add a lot > > of load to the LDAP protocol. Any suggestions or preferences from a > > general POV?? > > i personally would define an object class that has all the mailman-specific > attributes as "MAY"-attributes. then you simply add this object class into > the object class statements for your user records. all mailman-specific > records are then simply stored on your user record along with the rest of > the information. > > you could also create separate records that carry the email address and > mailman-specific stuff (or better, that carry anything needed by mailman), > but then you'd have to make sure that info is in sync with your "normal" > user records in case someone is defined as a normal user record and has a > separate mailman record as well. I'm sure whether to have something like a sub-object with something like: dn: cn=myname, ou=dept, o=company | ---------------------------------------------------- | | dn: maillist=mylist(a)dom.org, cn=myname, ou=dept, o=company another maillist dn | | |-nomail: yes |-nomail: no |-digest: no |- etc |-etc or dn: cn=myname, ou=dept, o=company | |- some attribute combinations... |- nomail: yes |- digest: yes |- etc the top way of organising things is more scalable and easier to manage (i think). but the second one only allows for one option for all your mailing lists - ie you have digest enabled for all or non e of your mailing list subscriptions. Or maybe i list the mailing list names in the nomail attribute and parse it on the mailman side to see if nomail is set for the particular list. eg: nomail-yes: maillist-1(a)list.org, maillist-2(a)list.org nomail-no: maillist-4(a)list.org, maillist-5(a)list.org or something along those lines... Hmm... think i should cc this onto Mailman-dev actually... > > As regards code, I'll be releasing it to the Mailman developers and anyone > > who wants it once it's working... > > barry warsaw is working for my company ;) I'm cc-ing this to the Mailman-dev mailing list - I'm subscribed to it, but slightly behind in reading the digests (only by some 75 days!! hehe) - just so they know someone is playing with it. I know it's on the WishList for Mailman 3.x, but no harm in seeing what's involved and exploring the unknown... Regards Donal

1 0