Mailman-Developers January 2000

mailman-developers@python.org

36 participants
40 discussions

by Rick Niess

Hi Everyone, I have a several ideas for features that may be of interest. Their implementation would certainly be to my benefit. I've listed them below. FYI, I'm testing out Mailman as a replacement for my campus' existing Majordomo setup. If I can just get a few issued resolved, I think the transition will go easily. 1) Please add an option so subscribers can elect to show only the username part of their e-mail address in the subscriber list instead of the whole thing (regardless of the @->" at " conversion). 2) In the section of the listinfo page where a user can subscribe to the list in question, please add another radio-button option for "Conceal yourself from subscriber list?" if the list's subscriber list can be seen by the list members or the public. I'm somewhat of an anti-spam nut so I don't like having my e-mail address publically visible in any form. 3) Allow the system-wide admin to disable the mail->news and news->mail gatewaying for the whole system and/or for selected lists. (I've got some list admins that want to use this, but I *really* don't want to see that kind of traffic on my server. Not to mention the liability issues...) 4) On the membership management admin page, please setup a mechanism for large lists to limit the display of user options to X number of users per page. It's a killer to try to admin large lists from slow machines with limited memory. (ex, took me a long time and a lot of swapping to load the page for a 3000 member list) 5) Please setup a means by which a user can specify what additional addresses he/she posts from other than their subscription address. (For example, my campus has a mail aliasing system so that all public addresses have the form "firstname.lastname(a)usm.edu" or similar. But the address they post from may be "username(a)host.usm.edu" or similar. This becomes a problem for lists that have member_posting_only turned on.) 6) Please setup a mechanism for a pre-made set of options to be used as defaults when creating new lists. For instance, on our campus, we have a form that prospective list owners fill out to request a new list. On this form, we have the following options for them to "check" that determine how their list is initially setup.: Archived list (Duh) Closed list (Subscriptions requests must be approved list list owner. Otherwise list is "Open" and anyone may subscribe.) Secured list (Only list members may post to the list) Moderated list (list owner must approve all posts to the list) Announcement (List will be used for outgoing announcements only. Implies moderated and secured.) I don't mind creating files with all of the configuration options and their default config values. I just need a snippet of code to read the values in and use those as defaults when creating the list. And then, perhaps if I combined that with #7 below, I could get it to automatically import the configuration of a previous majordomo list... (I don't know how either of these would work with the idea to create lists from a site admin page, tho. Perhaps the site admin could choose from a pull-down menu of option pre-sets or pre-existing majordomo lists when creating a mailman list?) 7) If anyone has written a withlist module that can read in the values in an existing Majordomo 1.94 config file and update the corrosponding values in a Mailman list's config db, I'd be ever so greatful to get a copy. This would make transitioning to mailman *so* much easier than having to do each list by hand through the web interface. 8) The <body> tag is not currently setup right for error pages. 9) Please build-in the option for individual list owners to filter binary attachments. (I think something like this is already in the works, but I'd like it to be a per-list option settable by the list owner.) 10) In the pipermail archives, please do the following: - move the archives to http://host/mailman/archives/listname or provide a redirect from there to http://host/pipermail/listname. - implelement a link for users to reply to posts in an archive by using a mailto: URL to open up a mailer window from their browser. Or perhaps make this optional on a per-list basis. (Note: this might break threading if a specific "In-Reply-to" header can't be added) - in threaded view: (a) add links at the bottom of each post to go back to the previous thread and forward to the next. (b) perhaps setup a mode where a user could see all the threads expanded on one page (as it is now) or see all the thread titles on one page and clicking them expands the thread into a new page. Lastly, I'd like to note that, while I understand most of what's going on in the code, I don't have time ATM to sit down and really learn Python. Hence, I don't have the expertise to go about making most of these modifications myself. I do, however, plan to sit down and learn Python as well as possible over the holiday break. So perhaps I can pitch in directly during the new year. Thank-you for your attention. I look forward to hearing from anyone who can help! ;-) ~ Rick Niess ~ -- .oooO "Man with closed Oooo. Rick C. Niess ( ) mouth gathers ( ) University of Southern Miss. \ ( no foot!" ) / guardian(a)bark.cc.usm.edu --\_)------------------(_/-------------------------------

21 years, 8 months

Forcing the address of a list

by David Sexton

Hi, I've asked this question on the users list but got no answers so I'm trying here. I ahve a box that hosts many virtual domains for mail & web. I have got mailman installed & sendmail configured so that mail sent to list(a)domain1.com goes to a different list than mail to list(a)domain2.com. I have done this by having a unique 'internal' list name in which is embedded the domain name. Mail coming into list-request(a)domain1.com actually gets redirected to the list called 'domain1-com-list-request'. This works fine. However, the outgoing mails sent by mailman are sent as 'From: domain1-com-list(a)domain1.com', which is not what I want. The Administrator's interface suggests that changing the 'Public Name' will change this, but it does not. Is there any way I can change this myself or can someone give me some pointers where I should be looking in the code to change the 'from' address for ougoing mail (Oh, and wherever it references the list in the body of a message). Can anyone help me please? Dave -- David Sexton Network Technician Sapphire Technologies Ltd. Tel: +44 (0) 1642 702100 Fax: +44 (0) 1642 702119 ----------------------------------------------- Any opinions expressed in this message are those of the individual and not necessarily the company. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Sapphire Internet http://www.sapphire.net

21 years, 8 months

Python w/Attachment decoding and archival via WebDAV available

by Bill Bumgarner

See: http://www.codefab.com/mailman-dav/ - decodes MIME attachments in incoming email - archive attachments to WebDAV enabled server - rewrite email messages to contain URL to attachments, instead of actual attachments [URL can be different than DAV URL] - send message to HTTP server [can be used to notify a web based system of incoming email messages] - fully configurable via web based GUI

21 years, 9 months

Another suggestion...

by Rick Niess

Hi All, A couple ideas to add to the pile: 1) Add another option to add_members to disable subscription notifications to the owner of the list only for the duration of this add_members session. (to help with list admins getting deluged with subscription notices when they use add_members) 2) For lists with member_posting_only enabled and subscribe_policy set to require confirmation, subscribe the address that the user responds to the confirmation notice with instead of what they type in on the web page. Possibly even require a second confirmation. (will help with users who subscribe under an "aliased" address but actually post from another) 3) To help in sutuations where an unknown address subscribed to a list is forwarding all messages it receives from the list back to that list, setup a tracking feature that mails each address subscribed to a list with a unique number (perhaps in a diagnostic header?) and an explaination for the message. Then watch for one of those messages to come back through the list, catch it, extract the number, disable delivery for the address it was sent to, and notify the list admin. (A bit of an odd case, I know, but I had to do this manually on a list /w >50 subscribers recently due to a rogue subscriber...) ~ Rick ~ -- .oooO "Man with closed Oooo. Rick C. Niess ( ) mouth gathers ( ) University of Southern Miss. \ ( no foot!" ) / resnet(a)usm.edu --\ )------------------(_/-------------------------------

21 years, 9 months

Reply goes to list error

by Balazs Nagy

Hi, I know that reply to the list address is obsolete and not supported but in my list there're a bunch of people who claim this feature. It worked in the last version but the CVS version doesn't use this option anymore. Here's the patch. -- Regards: Kevin (Balazs)

21 years, 9 months

Only Receive from the List

by gzbigegg

hi All, I'm hosting several mailing lists now by Mailman. My question is: can I restrict the person who can post to the list to a specific group? That is the subscribers only can receive the postings from the list, they cannot post on it. Your answer is highly appreciated! Liu Yan

21 years, 9 months

Customization

by gzbigegg

hi All, I just installed mailman on my system, everything seems OK. Now I want to customize the mailman to the interface I need, would somebody kindly tell me what the entry point of this task is? I will try to modify the files under the directory 'templates', but your tips will save me much time and effort. Thanks a lot! Liu Yan

21 years, 9 months

Ban feature, etc.

by Matthew Ratzloff

Hi, Well, haven't seen any e-mail from this list, so I figured I'd make some of my own. Are there plans for a ban feature, where you can permanently ban problem users? If it already exists, I sure can't find it, and I've looked numerous times. This would be very useful. Also, immature, disgruntled users have the ability to subscribe a list to another mailing list. Even if only members can post, admin requests still pile up. Are there any plans to enable an option to automatically delete mail from mailing list servers, such as egroups.com and onelist.com? Thanks! -Matt

21 years, 9 months

MailMan modifications to support WebDav & Attachments

by Bill Bumgarner

In short, it works and I'm a happy coder... been 2.5 years since I have written any python and it is a joy to dive back in! If anyone wants the code, let me know and I'll drop a tarball on you-- I'm going to be tweaking it over the next few days. This was developed for a client project, but we [CodeFab] convinced them that (a) using MailMan would give us a huge leg up and (b) donating the changes back to the community would be the best possible route to take.... As such, the implementation was geared towards solving a very specific set of requirements for the client. However, the implementation was done in a relative black box-- the implementation was very much done against the question "How would one modify MailMan to intelligently support attachments archived to web accessible servers?" so as to try and maximize the reusability and value to the community [while minimizing the exposure of any proprietary requirements or technologies of the client]. Specifically: MailMan now has the full set of modifications necessary to allow a user to post a message with attachments to a MailMan controlled mailing list, MailMan will detect the attachments that should be deocded, decode said attachments, rewrite the message to indicate that various attachments have been decoded, file the decoded message and attachments to a WebDAV server, and send the rewritten/urlified resulting message out to Usenet/mailing-list/digest/HTTP. The end result is not pretty-- it works, it is relatively well architected, but there is quite a bit of room for optimization/improvement. The one feature that is truly lacking is that the DAV'd archives are not nearly as friendly in structure as are the PiperMail archives..... Generic feature list: - ability to decode binary attachments from incoming messages; configuration options to determine which major types should be decoded, where they should be filed, how they should be accessed, etc,etc,etc.... - ability to file attachments [via WebDAV] into a repository accessible to the end user via HTTP - ability to rewrite messages to reflect availability of attachments via HTTP - use of an open protocol [WebDAV] to file/manage attachments - ability to encapsulate message into an HTTP request made against an arbitrary web server / web application The primary goal of implementation was to render a working solution as quickly as possible. However, a secondary goal of great importance was to render a solution that would be palatable to the MailMan / Open Source development community and, as such, would be picked up and maintained by them ASAP-- licensing requires that this piece of the In short, it works! Specifically: MailMan now has the full set of modifications necessary to allow a user to post a message with attachments to a MailMan controlled mailing list, MailMan will detect the attachments that should be deocded, decode said attachments, rewrite the message to indicate that various attachments have been decoded, file the decoded message and attachments to a WebDAV server, and send the rewritten/urlified resulting message out to Usenet/mailing-list/digest/HTTP. The end result is not pretty-- it works, it is relatively well architected, but there is quite a bit of room for optimization/improvement. In particular, the archive doesn't have near the friendliness of a pipermail archive-- but that shouldn't be *that* hard to add considering how it was originally implemented. ---- Summary of implementation ---- Components: - apache web server [version 1.3.9 -- latest stable release] - mod_dav WebDAV module from Greg Stein [http://www.webdav.org/mod_dav/ -- using latest development version from Greg's CVS repository. Can likely move BACK to last stable release-- though a new stable release is pending shortly] - python [1.5.2 -- latest stable release] - pyexpat module [ftp://ftp.cwi.nl/pub/jack/python/ -- version 1.3 -- includes expat library] -- provides xml parsing toolkit used by both mod_dav [expat] and qp_xml/davlib [pyexpat] - MailMan [using latest cut from MailMan development cvs server. Version 1.2expiremental. Very close to 1.2 release, so it is stable. As the MailMan community is likely to suck in all the changes that I have made, this will be path of least resistance.] - qp_xml / davlib / httplib -- various python modules from Greg Stein's CVS server. davlib had to be modified (see below) - mimecntl -- [version 1.3 -- Michael P Reilly -- http://starship.python.net/~arcege/modules/] Slightly modified to deal with file handles more cleanly. - sendmail -- generic, free, totally unmodified sendmail. Latest version. Basic configuration; no spam filtering, but configured to not allow relaying. Configuration will change slightly once in production. Assembly: APACHE / mod_dav Apache is configured with mod_dav installed and enabled as a dynamically loadable module. Configuration is quite straightforward; the directory identified as the root of all WebDAV MailMan operations has DAV enabled and requires password authentication to perform any operation. PYTHON Straightforward python 1.5.2 installation. Dynamic loading of modules is enabled [required for loading of expat module] PYEXPAT Straightforward dynamic loading build of pyexpat. For production, we might consider moving to a statically linked version of pyexpat-- this will be both more effecient and less prone to failure during upgrades/such-- but will require slightly more maintenance during upgrades. SENDMAIL No assembly required. Configuration details will be documented elsewhere [no changes to document now-- it'll all be performance/feature tweaks reflective of the production environment]. MAILMAN The internal architecture of MailMan was relatively consistent. As well, it is clear that the original architects gave a great deal of thought as to how to create a very flexible and extendable body of code. This proved to be a huge asset-- while the features required were relatively alien to the existing body of code, it was fairly clear how to add functionality while following the existing architecture. The end result is that the architecture of MailMan itself is largely untouched. The integration of certain required features, however, was not so clean or straight forward. The following specific implementation requirements caused a bit of frustration: - dynamically manipulatign MIME messages; it appears that very few people have ever given thought to the value of being able to rewrite a MIME message by replacing various parts of a message with pieces encoded differently. Thankfully, Michael Reilly had already thought through this problem-- the mimecntl.py package proved to be a huge timesaver. - WebDAV: DAV is an immature technology and, as such, the packages available to the developer for manipulating DAV accessible repositories tend to be extremely primitive. Largely, this is due to the extremely primitive/immature state of the XML marketplace combined with the inherently complex nature of a typical XML document. Similarly, DAV requires a client and server that implements HTTP/1.1 -- a version of the protocol that is relatively new. Greg Stein's qp_xml (in conjunction with pyexpat), davlib, and httplib saved a huge amount of time. However, it still required a lot of work to generalize access/control of a webdav server from MailMan. Synopsis of changes/additions:: - added a number of configuration options to various different admin pages throughout MailMan. Allow for setting target DAV server, advertised Dav'd resource retrieval, whether or not attachments are decoded, which types to decode, disabling pre-existing archival functionality, where MailMan->HTTP gateway'd messages should be sent, etc.... - add two additional handlers to the message handling pipeline (see HandlerAPI.py in Handlers in MailMan); Rewrite -- rewrites a mime message, decoding attaachments as needed and ToHTTP -- encapsulates a message and sends it to the configured web server - modified existing post script such that it will instantiate a MimeMessage when a particular list is configured to do so. MimeMessage is a new subclass of Message that encapsulates an instance of MIME_recoder from mimecntl package. MIME_recoder allows for random access and recomposition of MIME based multipart messages. - modified ToArchive handler to be aware of DAV. Added functionality for enumerated messages received by a list and archiving each message into a DAV enabled web server. ToArchive will also automatically validate and create any collections [directories] needed on archive server to service a given list or message. - added a custom subclass of davlib called davxmllib which optimally performs various common DAV operations through the use of well defined XML structured DAV requests. davxmllib also presents an error/exception interface that is much more desirable to high-level manipulation of a DAV based resource server - added ability to turn off pipermail [legacy archival system previously used in MailMan]

21 years, 9 months

Problem in newlist?

by Paul Hebble

Hi, I got this crash when I tried to run bin/newlist (cvs version). Ordinarily I wouldn't post a traceback, but this one actually looks like a syntax error. It pops up right after the script gives me the aliases to put in the config file. If the problem is because of my configuration, any help would be appreciated... Hit enter to continue with test2 owner notification... Traceback (innermost last): File "bin/newlist", line 154, in ? main(sys.argv) File "bin/newlist", line 148, in main HandlerAPI.DeliverToUser(mlist, msg) File "/var/common/mailman/Mailman/Handlers/HandlerAPI.py", line 72, in DeliverToUser func(mlist, msg) File "/var/common/mailman/Mailman/Handlers/CookHeaders.py", line 35, in process if not getattr(msg, 'isdigest', 0) and not getattr(msg, 'fastrack', 0): TypeError: getattr requires exactly 2 arguments; 3 given -- Paul

21 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers January 2000