Mailman 3 November 1999 - Mailman-Developers

Features requested...
by Rick Niess 11 Feb '00

11 Feb '00

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 --\_)------------------(_/-------------------------------

5 7

NT Port
by Adrian Eyre 01 Dec '99

01 Dec '99

Is there, or is anyone working on an NT port of Mailman? If not, I may start working on one myself. -------------------------------------------- Adrian Eyre <mailto:a.eyre@optichrome.com> Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com --------------------------------------------

2 1

Re: [Mailman-Developers] Missed Bounce Message
by claw＠kanga.nu 01 Dec '99

01 Dec '99

On Mon, 29 Nov 1999 22:08:10 +0100 Ricardo Kustner <ricardo(a)miss-janet.com> wrote: > On Mon, Nov 22, 1999 at 10:24:23AM -0600, Ted Cabeen wrote: >> Here's another missed bounce message. Can't SMTP server writers >> decide on a standard for bounces and just use it? Arrgh. > tell me about it... As there is no standard format for bounce messages, and even if there were one we'd still be suffering with non-standard ones due to the great many legacy MTAs as well as the many sites with locally customised bounce messages, another approach is needed. The most commonly recommended solution is VERP. The problem with VERP is that it places a very high load on the local MTA as well as any distribution management you may have set up (eg domain routing). The approach I took back when I was writing my own mailing list server was a middle ground with the intent of avoiding most of VERP's bandwidth concerns while retaining many of its advantages: The list server emitted messages in bundles of 100 RCPT TOs in the normal manner except for every Nth message. For every N'th message (and this encluded digests), that message was sent individually to every subscriber with a custom header field added. The custom header field was ala: x-bounce-detect: ListMgr <listname> <subscriber_address> <count> <score> Where 'count' was just a number that incremented every time N rolled around. It was used to detect how old this bounce was and if there had been any other "bounce-sensitive" messages emitted since that one was received. The 'score' value was just a tracking value indicating how close that subscriber was to being unsubscribed. The intent was that the custom header could be found in the copy of the original email encluded in the bounce message, and could be easily analysed to find the name of the list, the original subscriber's address (in case of the message being forwarded), etc. I then just scanned bounce messages for the header, and kept track of how often and rapidly each subscriber bounced messages, and if the rate exceeded a certain value, unsubscribing that member. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

4 4

Re: [Mailman-Developers] Missed Bounce Message
by claw＠kanga.nu 01 Dec '99

01 Dec '99

On Tue, 30 Nov 1999 16:09:21 -0500 (EST) Barry A Warsaw <bwarsaw(a)cnri.reston.va.us> wrote: > For a while now I've been thinking that we could do this kind of > VERP-like custom messages for the password reminders. Those we > already have to craft specially for each recipient, so why not > include an easily detected header, then catch those bounces and > scan them? Not a bad idea at all! I chose a selectable VERP-ish window as I wanted to be able to tailor the sensitivity to the normal rate of list traffic: It wouldn't be surprising to get 10 bounces a day from one member if your post averages a couple hundred posts a day and you dine one VERP-ish per 10 messages... -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: [Mailman-Developers] Found a privacy loophole...
by claw＠kanga.nu 01 Dec '99

01 Dec '99

On Thu, 25 Nov 1999 17:30:03 -0600 (CST) Rick Niess <rniess(a)netserver3.otr.usm.edu> wrote: > Hi All, I just noticed something. I have some lists which are > "private", so they don't show up in the index of lists that > listinfo generates. However, if you follow the link to the "list > admin overview page", it shows all the list names. Not terribly > useful to the average web browser, but to someone who knows about > mailman... The most they can find out from the admin page without a list password is the fact that a name exists and thereby the knowledge of how to send administration and attempted post messages to the list. If that is a problem, then you have larger problems in that you are implicitly relying on security thru obscurity. There is nothing that that web page can tell anybody that someone merely watching the mail traffic in and out of your site can't also determine. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

3 2

no passord on subscription page ... and others
by Fil 30 Nov '99

30 Nov '99

Hi mailman developers, it seems to me that to request a password from the subscribing page is confusing, overkill, and useless... when you can generate the password on the fly for the user. So the patch would be in Mailman/Cgi/subscribe.py >>>>>>>>>>>>>>>>>>>>>>>>>> if not form.has_key("pw") or not form.has_key("pw-conf"): #################################### patch fil(a)bok.net 27/11/1999 pw = Utils.MakeRandomPassword() pwc = pw # error = 1 # results = (results # + "You must supply a valid password, and confirm it.<br>") <<<<<<<<<<<<<<<<<<<<<<<<<<< and one would have to modify the standard HTML template too. But maybe this could be toggled from the list-admin page ? Secondly: is it possible that the mail-command analyzer catches messages sent to the list-on@server and list-off@server addresses and processes them as subscribe/unsubscribe commands ? This would emulate the LetterRip behaviour (www.fogcity.com), which is quite nice in this respect. Thirdly: I'd like people to be unsubscribed w/o their password. Some users tend to be annoying when then want to leave. Fourthly: I'm trying to see how to add a user-name field in the subscribers database... seems alot of work. Is this a planned feature ? Well, that's all for now; keep on the good work!

2 2

Re: [Mailman-Developers] no passord on subscription page ... and others
by claw＠kanga.nu 30 Nov '99

30 Nov '99

On Mon, 29 Nov 1999 12:17:12 +0100 (MET) Fil <fil(a)bok.net> wrote: > it seems to me that to request a password from the subscribing > page is confusing, overkill, and useless... when you can generate > the password on the fly for the user. Many users like to control their passwords and so wish to select them themselves (usually so that they can use the same password in many places, but that's another matter). Using this patch forces such users to subscribe, confirm their subscription and _then_ go log in with their assigned password to change it to their preference. I don't see the point in being that righteous about what other people use for their passwords. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

2 1

Nick Rout: RE: WebMail/WebAdmin can run on Postfix ?
by John A. Martin 30 Nov '99

30 Nov '99

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Name clash? jam - ------- Forwarded Message From: Nick Rout <nickr(a)ihug.co.nz> To: "postfix-users(a)postfix.org" <postfix-users(a)postfix.org> Subject: RE: WebMail/WebAdmin can run on Postfix ? Date: Tue, 30 Nov 1999 09:11:41 +1300 There is Endymion mail man http://www.endymion.com/products/mailman/ . My isp (www.ihug.co.nz) uses it to give their users web based access to pop email, if thats what u are after. requires perl & cgi. Its not free however :-) [[ ... ]] - ------- End of Forwarded Message -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: By Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE4Qw0iUEvv1b/iXy8RAhJLAJ46sYZuw6p1IShbN/5KCZjMnUCYzgCeKaxt KUUEyDHhRKZ00J6LQG7SONA= =QY6p -----END PGP SIGNATURE-----

2 1

Missed Bounce Message
by Ted Cabeen 30 Nov '99

30 Nov '99

Here's another missed bounce message. Can't SMTP server writers decide on a standard for bounces and just use it? Arrgh. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com ------- Forwarded Message Return-Path: ua-admin(a)lists.uchicago.edu Delivery-Date: Mon Nov 22 08:23:36 1999 Return-Path: <ua-admin(a)lists.uchicago.edu> Received: from einstein.uchicago.edu (einstein.uchicago.edu [128.135.132.24]) by entropy.uchicago.edu (8.9.3/8.8.8) with ESMTP id IAA27074 for <secabeen(a)entropy.uchicago.edu>; Mon, 22 Nov 1999 08:23:36 -0600 (CST) Received: from growl.pobox.com (growl.pobox.com [208.210.124.27]) by einstein.uchicago.edu (8.8.8+Sun/8.8.7) with ESMTP id IAA27870 for <secabeen(a)control.uchicago.edu>; Mon, 22 Nov 1999 08:23:29 -0600 (CST) Received: by growl.pobox.com (Postfix, from userid 15) id 0781B7EF2; Mon, 22 Nov 1999 09:23:29 -0500 (EST) Received: from lists.uchicago.edu (lists.uchicago.edu [128.135.132.161]) by growl.pobox.com (Postfix) with ESMTP id D09057EF2 for <secabeen(a)pobox.com>; Mon, 22 Nov 1999 09:23:26 -0500 (EST) Received: from lists (localhost [127.0.0.1]) by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id OAA14807 for <secabeen(a)pobox.com>; Mon, 22 Nov 1999 14:23:26 GMT Received: from LEXECON.LEXECON.COM (mail.lexecon.com [199.99.121.201]) by lists.uchicago.edu (8.9.3/8.9.3) with SMTP id OAA14781 for <ua-admin(a)lists.uchicago.edu>; Mon, 22 Nov 1999 14:23:23 GMT Message-Id: <199911221423.OAA14781(a)lists.uchicago.edu> Date: Mon, 22 Nov 1999 08:22:05 CST From: <SMTP(a)LEXECON.LEXECON.COM> To: <ua-admin(a)lists.uchicago.edu> Subject: Undeliverable Mail Sender: ua-admin(a)lists.uchicago.edu Attempting to deliver following mail to recipient(s): <brighoff(a)DominoFax.lexecon.com> LEXECON.LEXECON.COM unable to connect for 1 days to recipient host. Delivery will be attempted for a total of 3 days. ** Text of Mail follows ** Received: from lists.uchicago.edu [128.135.132.161] by LEXECON.LEXECON.COM (IBM VM SMTP Level 310) via TCP with SMTP ; Fri, 19 Nov 1999 20:24:31 CST Received: from lists (localhost [127.0.0.1]) by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08065; Sat, 20 Nov 1999 02:25:41 GMT Received: from hme0.mailrouter01.sprint.ca (hme0.mailrouter01.sprint.ca [207.107.250.16]) by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08037 for <ua(a)lists.uchicago.edu>; Sat, 20 Nov 1999 02:25:36 GMT Received: from [209.148.137.13] (spc-isp-wpg-uas-08-66.sprint.ca [209.148.137.13]) by hme0.mailrouter01.sprint.ca (8.8.8/8.8.8) with ESMTP id VAA13278 for <ua(a)lists.uchicago.edu>; Fri, 19 Nov 1999 21:25:30 -0500 (EST) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Fri, 19 Nov 1999 20:25:36 -0600 Subject: Re: [UA] On the structure and arrangement of the occult underground From: Rick Neal <grendel(a)sprint.ca> To: <ua(a)lists.uchicago.edu> Message-ID: <B45B62C0.26D%grendel(a)sprint.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Reply-To: ua(a)lists.uchicago.edu Sender: ua-admin(a)lists.uchicago.edu Errors-To: ua-admin(a)lists.uchicago.edu X-Mailman-Version: 1.1 Precedence: bulk List-Id: The Unknown Armies RPG Mailing List <ua.lists.uchicago.edu> X-BeenThere: ua(a)lists.uchicago.edu <snip> --KAA27849.943287760/entropy.uchicago.edu--

3 2

thoughts on http+smtp
by Ricardo Kustner 30 Nov '99

30 Nov '99

Hi, First of all, I mentioned this on this list earlier but back then I didnt get much response so I'm trying it again, now the list seems a bit more active :) Anyway, i'm running mailman on a P100 with 64mb... even though that isn't much compared to today's hardware... it still suffies for most of the needs (for example, apache is running smoothly on it with quite many hits... with peeks of 5,000 hits/hour ...there's a mysql server on it too.. handling most of those requests through auth_mysql). To get to the point, mailman is the best mailinglist software i found so far, but one thing that still kinda bothers me sinds the beginning is that when using the admin pages to approved messages which are held for approval, the python cgi scripts won't finnish the http request untill all messages have been feed to the MTA... i'm running a list with 1,500+ subscribers and when about 20 messages are being approved at the same time, that means the server will get a huge load in a short period of time. Also, since the cgi script doesn't finnish untill the messages have been submitted to the MTA, sometimes the http request just times out... I personally think that a cgi script do his work *quickly* and finnish outputting the html asap... I think it would be great if the admindb.py could just 'mark' messages to be delivered and a background process handles the dirty work, instead of having cgi scripts doing the SMTP connections... and i still vote for having mail, which is held for approval, in a seperate directory instead of putting them in a python database... well these are just some thoughts, i hope can start some discussion on it :) Ricardo. --

1 0