Re: [Mailman-Developers] [Mailman-Users] openID enabled mailman
on 6/13/09 9:16 AM, Malveeka Tewari said: Can I also take a look at the code that the OpenID folks sent you? It'll be great if you can send me any pointers to that code. I asked on their mailing lists too but haven't received any promising response. They never made any attempt to build an OpenID provider in Mailman. All they did was hack in some OpenID Relyer code, and in the process they broke any other kind of authentication. Mailman is the wrong place to put an OpenID provider. That needs to go somewhere else, and then you can put in code that allows Mailman to be an OpenID Relyer. Looking at the code might give me an idea about how to start implementing openID support fr the mailman setup I am running, I really don't think so. They and you seem to have very different ideas as to where the OpenID provider code should go. -- Brad Knowles b...@shub-internet.org LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] openID enabled mailman
on 6/7/09 12:14 PM, Malveeka Tewari said: I want to know if there's already an openID enabled version of mailman available And what files would I need to make changes to include openID support in mailman The OpenID project uses Mailman themselves, and they have hacked it to allow OpenID logins. They even shared with us the code that they have. I took a look at trying to bring this into the main codebase, and I was not able to figure out how to do that -- when they put in OpenID, they broke everything else, and I could never figure out how to get the two to co-exist at the same time. IMO, this may be a better question to ask on their mailing lists, or to ask the people who maintain their mailing lists. -- Brad Knowles b...@shub-internet.org LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] Wiki maintenance
Barry Warsaw wrote: Please note that our hosting provider will be conducting some schedule maintenance on our wiki instance. Thus wiki.list.org will be unavailable starting at 0900 UTC Saturday April 4, for a few hours. So says the FLUFL, so shall it be. -- Brad Knowles b...@python.org Member of the Python.org Postmaster Team Co-Moderator of the mailman-users and mailman-developers mailing lists ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
Terri Oda wrote: The latest version is here: http://terri.zone12.com/mm-website/ So, that's using some red/pink from the logo as link colours as someone suggested to me. I really don't want anyone over-riding my own choices for link colors. More suggestions welcome! Did you want to mention the official Mailman group on LinkedIn? Of course, I can't figure out how to give you a link that will take you to their page for the group as opposed to the home page that I defined for the group (namely www.list.org), but that may be something we can resolve. -- Brad Knowles [EMAIL PROTECTED] Member of the Python.org Postmaster Team Co-Moderator of the mailman-users and mailman-developers mailing lists ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
Terri Oda wrote: The original version I had used the standard link colours (ie - it didn't set them), and comments ranged from just general malaise about the colour scheme of the links to several people who asserted it was nearly unreadable on their setups. That implies their client is misconfigured and that should be their problem and not ours. Right? So I'll take the comment under advisement, but I suspect you're going to be in the minority. I would urge caution about paying too much attention to a vocal minority, to the potential detriment of the majority who aren't complaining. Now, if this was being driven by 508 compliance for accessibility and there simply were no other viable options, it would be more difficult for me to have grounds for a complaint. But so far I haven't heard terms like that. Since I've since changed the original css, here's the current stuff with no link colours specified (so they default to your browser settings): http://terri.zone12.com/mm-website/?css=mailman-nolink IMO, that looks much better. Did you want to mention the official Mailman group on LinkedIn? Of course, I can't figure out how to give you a link that will take you to their page for the group as opposed to the home page that I defined for the group (namely www.list.org), but that may be something we can resolve. Seems like a good fit for the Participate page! I've put it just under the wiki entry. Cool. Thanks! -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been released
Mark Sapiro wrote: I am happy to announce the release of Mailman 2.1.10. Now running on mail.python.org. Please let us know if there are any problems. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been released
Mark Sapiro wrote: I am happy to announce the release of Mailman 2.1.10. This is a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.10 also adds support for three new language translations, Galician, Hebrew and Slovak and a few new features. Remind me next time that we *MUST* upgrade to the betas and RCs on python.org once you've made them available. The changes made to the code which supports skipping unparseable messages means that mmdsr has to be changed to suit, otherwise you could wind up with a daily report that is 800MB in size, depending on how many unparseable messages you might have. We'll need to coordinate the updates to mmdsr and get the official version with all code contributions from all parties out there on the SourceForge page. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been released
On 4/21/08, Barry Warsaw wrote: We should probably have some kind of shunt queue culler cron script in place, either that archives and deletes those files, or just expires them after a certain amount of time. That's easy enough to do with cron and find. You tell me what you want, and I'll be glad to set that up. What to people generally do with their shunt files? Leave them untouched for months or years? ;-) -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been released
On 4/21/08, Mark Sapiro wrote: If you could apply this patch (you can apply it directly to the installation directory, by e.g. cd /usr/local/mailman patch -p0 path/to/2.1.10.patch.txt Patch applied fine, no complaints. and set QRUNNER_SAVE_BAD_MESSAGES = No Done. in mm_cfg.py and restart Mailman, things should be back more or less the way they were in 2.1.9. I have applied the patch to my installation and I'm sure it's good, but I haven't seen any unparseable messages. I haven't seen any more unparseable messages in the last few minutes, but let's see how things go. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been released
On 4/21/08, Brad Knowles wrote: I have applied the patch to my installation and I'm sure it's good, but I haven't seen any unparseable messages. I haven't seen any more unparseable messages in the last few minutes, but let's see how things go. We've now had a couple of unparseable messages since applying the patch, and it seems to be working as expected. Going back to Jun 12 23:48:51 2007, it looks like we've had a total of about 378,989 unparseable messages, although we only have just over 8000 messages in the mailman/qfiles/shunt and mailman/qfiles/shunt.old directories (7759 .psv files, and 312 .pck files). That works out to about 37,900 unparseable messages per month, or something like about 125 unparseable messages per day. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] [Mailman-Announce] Updated message catalogs needed for Mailman 2.1.10
On 3/10/08, liste yoneticisi wrote: (An explanation to all: I just asked if there is anyone who responsible for Turkish translation of Mailman, attended to these lists from Turkiye.) This is a question that is better asked on the mailman-i18n mailing list. That's where all the Internationalization folks should be hanging out. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Email classification
On 1/12/08, Felipe Neuwald wrote: I'm thinking, if some user send one email to the mail list, then the mail server reply one email to the user with one web page addres, and then, the user classify the email (like office, home, study, etc) and before the classification, the email is sent to the mail list. There is some way of email classification like these? Or other ways of email classification? Mailman does not provide any tools to do this sort of thing. You could have users put the classification in the subject line, or you could go through the process outlined in the Mailman FAQ Wizard whereby a moderator can modify a message before it is posted to the list, but as I recall that's a pretty lengthy and painful process. I'm not aware of any other options in this case. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists
At 10:49 AM +0900 10/11/06, [EMAIL PROTECTED] wrote: Mailman Developers: Is the web code set up so that so that admins could fairly easily assemble these UI widgets into a page that suits their usage? Nope. It's all hard-coded. Or would that be a major refactoring? Sorta like reimplementing Plone, I guess, but we really don't want to put import plone at the top! Something like that, or maybe re-implementing Zope. What I was thinking is that there could be a page generator pipeline, similar to the list processor. Of course the objects we want to generate pages from (member lists, moderation queues, etc) would have to grow appropriate interfaces -- sounds like work! but it would be way cool. Yeah, way cool. We can't wait to see the code you're going to contribute to do this. ;) -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance
At 10:36 AM +0900 10/1/06, Tokio Kikuchi wrote: An smtpd.py based LTMP server could provide an interesting proof of concept though. I've almost finished writing this primitive LMTP server. I am no longer on the list. Please do not include me in any future discussions on subjects relating to the list. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Incoming Queue format
At 12:23 PM -0400 9/29/06, emf wrote: Furthermore, many MTAs *do* understand Maildir, MTAs should be sticking to the job of transmitting e-mail between themselves. If they're spending any time mucking about with local mailbox formats, they're making a mistake. That's a job for a Local Delivery Agent, and not an MTA. Now, granted many mail system packages also include one or more sample LDAs in the tarball, either as an official part of the system or in some sort of contrib/ directory somewhere, but let's make sure that we're using the proper terms for the proper objects. Therefore, by definition, MTA != LDA. and most admins do as well; If this discussion has taught me anything, it's that after all these years we still have virtually no one in this business that really does understand Maildir or any other mailbox format, although many claim to do so. using our own queue-on-disk format means MTAs must access Mailman via LTMP, pipe invocation, or the like, and if there are issues with the queue the administrator likely must learn our queue-on-disk format. Our queue-on-disk format is already much simpler than Maildir, at least when it comes to directory structure, and the directory hashing schemes that I've been talking about have been around for many years. No new thought needs to be put into implementing them. I even convinced Wietse that he should implement a lot of the same concepts, back when I first got involved in postfix in '98, when it was still being called VMailer. Now, if you want to get outside of directory structure, our queue-on-disk format includes a lot of things that are Mailman-specific, such as creating message pickles, and I don't think that anyone is talking about getting rid of those aspects. Most of the maildir phenomena you have an issue with wouldn't even arise in the use case under discussion; a mail would enter maildir/new , mailman would suck it out, and that would be that; renaming wouldn't occur and the number of elements in the queue is unlikely to become large enough to pressure filesystem indexing schemes. You really need to go back and review exactly how messages are created using Maildir. With Maildir, when a message comes in, a temporary file is opened with truncate (with certain measures taken to try to ensure that the selected filename will be unique), and if that system call succeeds, then the system appends the incoming message and renames the file, before it ever closes it. If that creat() system call fails, then there is already a file by that name, and the LDA has to try again. This is how they safely create files on NFS, with an operation that is supposed to be atomic, and allows them to avoid file locking. I'd have to check, but I think there are some more synchronous meta-data operations in here, too. Certainly, every time you look to see if more messages have come in, you have to scan the entire directory, and you have to stat() each and every file, and if you want to pick up the message and move that somewhere else, you're going to have to do further synchronous meta-data operations that involve locking the entire directory structure while they are taking place. Now, your application may not see those locking, scanning, and stat operations, you may simply see move this file to another location, but the underlying filesystem code has to do a lot of work to support that. And regardless of whether you're using locking or not, you still have race conditions that you have to code for -- or at least be aware of, because they are potential areas where you may have problems in the future. If you don't read the comments that Mark Crispin has written about the weaknesses in Maildir, and you haven't read the code to see what it's actually doing, then I don't see how you can participate in this discussion. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Incoming Queue format
At 12:23 PM -0400 9/29/06, emf wrote: So your assumptions about what kinds of filesystems may or may not be appropriate are not necessarily going to coincide with the decisions that other people make, or the kinds of hardware and OS they may be forced to live with. I don't disagree with this assertion, nor am I making assumptions about what people get to live with. Actually, that is precisely what you did. You said that we shouldn't bother implementing something that XFS and ReiserFS would fix anyway, and that people who would be running Mailman would obviously choose to run the best filesystem for their application. Your claims to the contrary are disingenuous, at best. Most of the maildir phenomena you have an issue with wouldn't even arise in the use case under discussion; We're talking about maildir-mailbox-per-list. So, all known issues with Maildir mailboxes would be applicable, because they would *be* Maildir mailboxes. The fact that we would be using Maildir mailboxes as a method of handling incoming messages instead of having them written to a 7th edition mbox-format mailbox, is purely an application-level implementation detail. That said, I'm done arguing with you and Barry. You guys go do whatever you want. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Incoming Queue format
At 3:37 PM -0700 9/29/06, Carson Gaspar wrote: Brad, if your _incoming_ queue is so big that you have to worry, your servers are woefully underspec'd. That may or may not be true, but that doesn't make the problem magically go away. If you can provide a detailed use case where it matters for the _incoming_ queue, please do so. Basically, it's any site that has one or more lists that have relatively high levels of incoming traffic, and which run into synchronous meta-data bottleneck issues. This could be a lower-end machine with a filesystem that does not perform as well as could be, and a more moderately sized list. Or, this could be a site where they've already thrown the biggest/best configured machine at the problem that they can, and yet they're still seeing problems. On the high end, from the reports we got after Apple upgraded the system for lists.apple.com, I don't think they're too likely to have these kinds of problems. But the FreeBSD folks might already be there, and I imagine that the SourceForge people are definitely there. But I'm sure there are more relatively smaller lists running on relatively smaller/less well configured hardware, and which are running into the same kinds of problems. All this aside, it's clear that I'm not going to convince anyone here of anything, so I'm just going to unsubscribe from the list and I'll ask everyone to make sure that they do not include me on any further messages on this subject. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
At 10:57 PM -0700 9/27/06, Carson Gaspar wrote: Or is there some way I'm missing that would allow us to segregate some domain traffic to Mailman's LMTP server and other traffic to Postfix's standard transports? What about Sendmail? Shouldn't be an issue with postfix. From the default postfix transport map template: Sendmail should be able to do something comparable, although I have not yet looked at the documentation to see just exactly how you'd implement that. Certainly, looking up addresses in a variety of database types is not a new idea. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] LTMP for incoming mail
At 8:12 AM -0400 9/28/06, Barry Warsaw wrote: What I find really intriguing about this approach is the ability to reject some messages immediately, presumably allowing the MTA to bounce them. Yup. We could reject the message then before it entered Mailman's incoming queue. Indeed, that's a key advantage. IIRC, procmail does this with the system-wide and user-defined rulesets. I did a quick Google search to see if there were any GPL'd LMTP servers we could piggyback on, the idea being that if we could find a shell of a C program we could embed Python in and talk directly to Mailman during the LMTP protocol. Does it have to be GPL? Is a Berkeley-type license not okay? Checking the source for sendmail 8.13.8, I find that there is an official part of the package which includes the LDA mail.local, which is LMTP-capable, among other things. It can also do user mailbox hashing, based on the username. You can either hash directly to a path like /var/mail/u/s/user or use an MD5 hash of the username in a base64 representation (changing / to _), and you can control how many levels of hashing are to be used. Seems to me like this would be a pretty obvious candidate. Postfix has an lmtp server, but it seems fairly heavyweight (being tied into the smtp server) and it's not clear to me we could combine our GPL code with Postfix's license. Please check out the sendmail mail.local stuff and tell me if this is a better alternative. If you need a different license, please let me know -- I've known Eric for many years (since way before the company existed). While I won't make any guarantees, I will say that if we need a different license, I imagine that I can get a more sympathetic ear than you might otherwise be able to find. ISTM that the trade-off then is rolling our own LMTP server vs. doing maildir delivery. Are we confident that we can implement a high performance enough server that would give us better throughput than maildir would? In Python? Dunno about doing it in Python, but I will say that going to Maildir as an additional queue-on-disk mechanism on top of everything else we're already doing seems to be a big step backward in terms of potential performance issues and I don't really see any significant positive benefit. At AOL, we used to use a queue-on-disk method for the Internet mail gateways. Sendmail would take the incoming message, hand it off to a custom LDA, the custom LDA would then dump that in a disk queue asynchronously, then a synchronous queue runner process would come along and pick up the messages and send them over to Stratus. Believe me, this system sucked big time -- we had never ending problems with disk queues building up to the point where the queue runners could never possibly catch up, etc And I'm not seeing any real significant operational differences here between what you're talking about doing and what AOL abandoned years ago. Okay, so you're talking about using Maildir instead of a typical linear queue-on-disk and you don't have to do file locking to guarantee queue entry creation, but that's still dumping everything into a single directory from which we then have to scan and pull stuff out and you probably do still have to do some sort of file locking in order to make sure that the input and output queue mechanisms don't step on each others toes. It might be fun to try, but OTOH it /is/ a distraction from other MM 2.2 work that needs to get done. So unless anybody has any leads on existing GPL-compatible code we could use, or feels really motivated to work on a Python version, I'm inclined to go with maildir for MM2.2. It's not like we couldn't add LMTP at some later point. The single queue directory on disk is already one of our biggest single bottlenecks. I don't see how using Maildir as a delivery mechanism from the MTA to Mailman is going to improve that. In fact, it seems to me like we're just adding yet another bottleneck of exactly the same sort that we're trying to eliminate elsewhere, but with some additional drawbacks that are unique to Maildir and which will make our overall system performance even worse than it is today. If we're going to make a big change, it seems to me that LMTP makes much more sense than Maildir. If we can't do LMTP, then I think we'd be much better off working on eliminating other bottlenecks in the system as opposed to adding yet another totally new source of bottlenecks that result from implementing Maildir. It seems to me that this idea is a case of: 1. We have to do Something. 2. This is something. 3. Therefore, we have to do This. I think we want to think long and hard about this idea and all it's potential drawbacks and new bottleneck sources, before we take that first step off the cliff. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase
Re: [Mailman-Developers] LTMP for incoming mail
hundreds of thousands of messages into a single directory is guaranteed to cause huge performance issues, even if every single mailbox operation didn't involve scanning the entire directory and doing a stat() on every single file, locking the entire directory, creating/renaming/deleting the file(s) as appropriate, and then unlocking the directory. I think we're better off spending our resources working on trying to resolve the real bottleneck issues that we already know are present in our system as opposed to working on cool stuff that may or may not help but would require more overall changes to more parts of the system and with relatively lower potential payoff. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] LTMP for incoming mail
Maildir as a second level of queue-on-disk, before you get to the Mailman-internal queue-on-disk mechanism. Now, if you are talking about two levels of queue-on-disk so that we can get both Maildir and queue directory hashing, I think that's going to be much, much worse than sticking with the existing postfix virtual domain solution. Or someone running a huge site that would really benefit from LMTP could funnel a portion of their profits into paying us to add it wink. I don't think we're doing enough traffic on python.org for them to justify paying for it. I don't think that Apple is doing enough traffic with Mailman for them to justify paying for it -- not with what we've heard about how the new(er) MacOS X hardware is performing, and especially not with the total lack of any support (or even acknowledgement) that we get from the corporate types. I don't think that any of the open-source projects (like FreeBSD) are going to be in a position to pay for something like this, or to develop contribute the necessary code, although they might be doing enough traffic that they could certainly use these features if they were available. I think that only leaves us with a site like SourceForge, and I think you've probably got better contacts there than any of the rest of us. Absolutely. But getting LMTP support into Mailman will still require a developer to step up and write code. I'm not that concerned about LMTP. I think that's a big enough issue that we can leave that alone for now. Maybe Tokio or Mark can be convinced, or maybe there's another developer lurking out there who would be interested. I just want to unbreak Postfix virtual domains and then fry our bigger fish. I would like to see them unbroken, but I also don't want to see anything done that would preclude the use of hashed queue directories, or that would add a second level of queue-on-disk and yet another source of potential bottlenecks. I think the thing you're missing is that we need to get the messages from the MTA into Mailman's incoming queue /somehow/, and we're basically limited by what the various MTAs have to offer. I certainly was not understanding your point that you wanted to use this as a way to unbreak postfix virtual domains, no. No, I didn't get that at all. I'm still not convinced that this is the best way to unbreak postfix virtual domains, however. Fixing Postfix virtual domain integration is a real problem that needs solving, which is how this whole thread started. Agreed, this is a real problem that needs to be resolved. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] LTMP for incoming mail
At 1:29 PM -0400 9/28/06, John A. Martin wrote: Is in not possible to do Postfix virtual mailbox domains _without_ maildir style delivery? Probably, but I'm not sure it really buys us much of anything to have separate mailboxes for each list, as opposed to a queue processing mechanism that is generally more robust and capable of easily handling lots of simultaneous transactions. Independently of the above and at least for Postfix, would it be worthwhile looking at the Postfix policy daemon plug-in as a way to query Mailman information during the rfc821 conversation and rejecting a lot of messages before DATA? That's going to have the same issues as implementing LMTP, at least as far as it concerns performance and ability to handle these kinds of operations on a large-scale/real-time basis. Even more interesting, because of perhaps being portable, might be the milter facility that appeared in Postfix 2.3. I have not yet even looked at the later so it may AFIK be very wide of the mark. Same issues for all. The particular protocol is not particularly relevant to this part of the discussion. Regardless of how you implement the system, it's going to have to do certain types of message scanning and parsing, checking against databases and/or blacklists, etc In all cases, so long as you're holding the sender open while you check all these things, you're going to have pretty much the same concerns regarding performance and scalability. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Incoming Queue format
At 11:19 PM -0400 9/28/06, emf wrote: I can't find a filesystem that has a filename dependency for inode caching, so I suspect I'm completely misunderstanding this. Could you expand on that a bit? Some filesystems implement an in-memory hash of recently accessed files, but the filenames are typically truncated to fourteen characters, and the paths to the files may likewise be truncated. Maybe; but there are at least two filesystems (XFS, reiserfs) and likely more that handle file renaming/creating really cheaply, and have their own ninja ways of dealing with really large directories that are the product of a rather large amount of coding hours. XFS and ReiserFS do not comprise the entire universe of all filesystems in the world in which Mailman will be operated. There will be plenty of BSD, Solaris, HP-UX, MacOS X, and other OSes where Mailman will be used, and even on Linux you're much more likely to run into ext2fs or ext3fs than either XFS or ReiserFS on most of the several hundred distributions that are available. Maildir has the advantage of being bog standard and readily comprehended. While I'm all in favor of some lmtp delivery mechanism, I don't see why we should continue inventing our own queue-on-disk approach merely to cater to poorly designed filesystems. While XFS and ReiserFS may have their advantages (and XFS on SGI Irix is much better than XFS on Linux), we can't assume that any portion of the Mailman community will be using these kinds of filesystems. We must be more conservative in our estimates of what filesystem features will be available, and code accordingly. If we were to assume that everyone had XFS, then let's assume they all have XFS on Irix, or even Veritas VxFS. It seems to me like anyone likely to end up with a huge enough incoming mailman queue to care about Maildir's inefficiencies would also be able to put a sensible filesystem underneath it. That may simply not be possible. Moreover, I have some real operational problems with both XFS on Linux and ReiserFS, and I would not run a production mail system using them. Maybe IBM's JFS, if I were forced to run a production mail system on Linux at all, but certainly not XFS or ReiserFS. To be honest, I wouldn't run a real production mail system on anything less than Veritas VxFS, and I'd be real choosy about my underlying hardware, too -- think Hitachi, not EMC. So your assumptions about what kinds of filesystems may or may not be appropriate are not necessarily going to coincide with the decisions that other people make, or the kinds of hardware and OS they may be forced to live with. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
At 3:04 PM -0400 9/27/06, Barry Warsaw wrote: This appears to allow us to set up true virtual domains without having to encode destination aliases. The trick though is that we would use Maildir delivery for all incoming messages, something I'm keen on switching to for Mailman 2.2 anyway. Maildir is way more efficient than invoking a mail program per incoming message, Mailman already supports Maildir (although it isn't the default), and AFAIK all major MTAs support Maildir. Sendmail knows nothing of the mailbox delivery method. That is left up to the Local Delivery Agent, which is usually /bin/mail and knows about 7th edition mbox-format, and not much else. You could always substitute a different LDA (e.g., procmail), but that would not be a standard part of sendmail. Moreover, I'm not keen on Maildir. It makes a lot of trade-offs to try to get something that is NFS-safe, and I'm not convinced those trade-offs are worthwhile, especially not in a non-NFS environment. I think there are other ways that you could get the same benefits (in a mailbox directory solution), without getting the major drawbacks of Maildir per se. Among other things Maildir creates really hairy long filenames, which can easily blow the iname/inode caching built into most filesystems -- you could get the same benefit by using a better filename naming/hashing scheme with fewer characters. It also does a lot of excessive synchronous meta-data operations (e.g., creating files, renaming files, etc...), and that can place a heavy load on the underlying filesystem. In his paper regarding what they built for the Earthlinnk mail system, Nick Christenson has clearly proven that you can use the atomic creat() system call in a way that eliminates the need for file locking on NFS, without all the various baggage that Maildir brings to the table. Mark Crispin also has a lot of good things to say about the weaknesses inherent in Maildir. You should read his comments, too. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
At 6:33 PM -0700 9/27/06, Carson Gaspar wrote: I love the idea. A fork/exec per message always makes me twitch... I have a feeling it would also provide better fault-tolerance, especially in a replicated filesystem cluster, where you have clear atomic behaviour at your disposal. I agree that fork()/exec() is not an ideal model here, but then postfix doesn't use that model internally -- it uses a single parent with multiple child processes, and then hands off sockets. It also keeps pretty much the entire working queue in memory, as opposed to single-threading through the filesystem. I don't see how using Maildir is going to solve any of these problems. IMO, if we're going to learn from postfix, I think we should learn the right things and take away the right lessons, and not just glom onto some alternative technique that has been known to have a whole host of other problems. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
At 9:34 PM -0500 9/27/06, Brad Knowles wrote: Moreover, I'm not keen on Maildir. It makes a lot of trade-offs to try to get something that is NFS-safe, and I'm not convinced those trade-offs are worthwhile, especially not in a non-NFS environment. One other problem with Maildir -- it throws all message files into the same directory, and doesn't use a hashed directory scheme. If we're going to do directory hashing, I would think we'd want to do it within our mailbox storage mechanism as well as elsewhere in the queueing system. In his paper regarding what they built for the Earthlinnk mail system, Nick Christenson has clearly proven that you can use the atomic creat() system call in a way that eliminates the need for file locking on NFS, without all the various baggage that Maildir brings to the table. If you want to read Nick's paper, go to http://www.jetcafe.org/npc/doc/mail_arch.html. Note that he's also the author of the book _sendmail Performance Tuning_, see http://www.jetcafe.org/npc/book/sendmail/. Mark Crispin also has a lot of good things to say about the weaknesses inherent in Maildir. You should read his comments, too. Mark's comments can be read at http://www.washington.edu/imap/documentation/formats.txt.html. Do a find on the page for maildir, and read from there. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
At 11:56 PM -0400 9/27/06, Barry Warsaw wrote: I'm definitely not proposing to get rid of deliver to program, so at worst, Sendmail users will continue to use this method. Is there a better way to get the message from Sendmail into Mailman's incoming queue? Well, sendmail does LMTP to their custom LDA that they include which is not officially part of the actual sendmail package itself. But you could easily plug in any other LMTP-capable LDA. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] RELEASED Mailman 2.1.9 release candidate 1
At 12:58 AM -0400 2006-09-06, Bryan Fullerton wrote: I upgraded my small production machine to 2.1.9rc1 today, everything seems to be working as usual. We're also running it in production on python.org, and I have yet to see anything out of the ordinary. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
At 10:59 PM -0700 2006-08-14, John W. Baxter wrote: Unfortunately, the would-be posters then have to be notified of the message status. Thus, while you're reducing moderator workload, the backscatter problem isn't solved. No, it's not solved. However, by putting a semi-intelligent time limiter on the thing (i.e., no more than one response per address per day, or somesuch), the backscatter problem is at least contained to a more tolerable level. And this does get back to the balance thing that I was taking about earlier. If doing your best to make sure that people know that their message was rejected, or held for moderation, or whatever, is more important to you (and your community), then you've got the option to make those sorts of things happen. If eliminating all possibility of backscatter is more important, you've got the option to do that, too. The point here is to increase your options available to you, and to also try to help reduce the load on list moderators and list owners to a more tolerable level. At least, that's the idea. I'm hoping that the reality will live up to this theory. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
At 8:19 AM -0400 2006-08-15, Barry Warsaw wrote: I tend to be more sanguine about things. I'm younger than you but I've been around for long enough to have heard about the death of the internet/arpanet for 25 years. It hasn't happened yet and I don't think email and SMTP is going away any time soon. We're certainly getting there for some people. I found out the other night that my Mom no longer bothers doing e-mail. Okay, she's 62, retired six months early due to medical problems (terminal cancer), but she's still got a few good months left and she doesn't want to waste them trying to fight spam in her mailbox. So, she just reads most of the time. My own spam load is around 90-99%, depending on how bad the day is. My ISP routes all their mail for their customers through Postini, and they catch 90% of that, but that still leaves a lot for the ISP to deal with. So, they set up their own secondary anti-spam handling system, which is still as large or larger than the entire rest of the mail system put together. And I still get an annoying amount of spam that gets through to my client, which also has anti-spam features integrated. I can certainly see why many people would get to the point where they start feeling like e-mail no longer has any real value. I certainly feel that way about most USENET newsgroups I know of, and for the same reasons. Maybe all the kids will gravitate toward other modes of communication and leave us dinosaurs to our spam riddled 20th century telegraphs. They already have. It's called IM, chat, or txtng -- depending on the exact platform. Many times I've said that e-mail is the only universal mission-critical platform, but I've also said that each organization may have their own mission-critical applications on top of that. AOL is no different. When I was the Sr. Internet Mail Administrator for AOL, we had only two mission-critical applications -- e-mail and chat. If they weren't available, then most customers would just leave, because there wasn't much of anything else that they wanted to do. And spim is already a major problem, or so I hear. I haven't heard of spat or sptxt being much of an issue, but I'm sure that they'll figure out a way to abuse those systems as well. Thanks to Dateline NBC and Stone Phillips, we have certainly seen way more than we ever wanted to know about how predators use IM to lure kids into abusive situations, and I guess that would probably be the worst form of spim. Or maybe we'll stay just barely ahead of the spammers enough to eek out the benefits of email and mailing lists for another 20 years. I think we'll try, and for some people we will succeed, but my fear is that more and more people are going to start giving up on e-mail and will switch to alternative communication methods. Those methods are likely to be less convenient because if it's too convenient for us then it will probably be much too convenient for spammers. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
At 4:35 PM -0400 2006-08-11, Barry Warsaw wrote: Although I have not implemented it yet, Mailman 2.2 will definitely get auto-moderation. IOW, should a non-member send a message to a mailing list, and if that mailing list is so configured, Mailman will hold the message and send a message to the From address asking for verification of the post. I'm assuming this is what you mean by auto-moderation. I'm confused. Unless I'm misunderstanding what you're talking about, Mailman 2.1.x already does this today. You try to post to a list that is restricted to subscribers only, and then your message may be rejected, or you may get a message saying that the post is being held for moderation, or it may get silently thrown away, etc It all depends on how the listowner has configured things, but to this level, this kind of thing works today. I'm not worried about joe-jobbing because Mailman could easily send just one auto-moderation message per unit of time, or number of posts to limit any backspamming. Okay, now that's different. This actually clicks in very well with the recent article I wrote on fighting spam for publication on the LOPSA website, because backscatter has become one of my biggest hot buttons lately. Putting an intelligent limiter on the potential causes of backscatter (like no more than one notice per recipient per day, or whatever), brings it down into the realm of what I would consider to be less than ideal but at least below the threshold of totally unacceptable. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 11:21 AM +0100 2006-08-10, Ian Eiloart wrote: It's not necessary to understand all interpretations. There are a few codes that mean the remote address isn't available. When we see any other code, we should not count the bounce against the specific address, because the error isn't related to that address. As I said, show me the code, and then show me all the actual bounces and how they were interpreted by the code. I'd like to see how closely reality actually hews to the RFCs. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 10:49 AM +0100 2006-08-09, Ian Eiloart wrote: So, give us one example of a problem that could arise. I don't have to. If you want people to believe you, then you need to prove that you can create a significant enhancement to Mailman in this area, without creating a significant increase in the complexity of the system, or at least with a reasonable balance of complexity versus the modified features you're proposing. I don't have anything to prove here. You do. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 10:49 AM +0100 2006-08-09, Ian Eiloart wrote: Rubbish. The codes are numbers. Right. But, as I said, the codes aren't going to be sufficient. They're going to be misleading in many cases, causing us to make inappropriate conclusions based on faulty information. Therefore, if you want to uphold the spirit of what you're asking for, you're going to have to look deeper and try to start parsing the actual text of the bounce message to try to better understand what the real reason was. And that way lies madness. Otherwise, RFC-1893 would have been sufficient to answer all possible questions about this feature, and all MTA authors and all mail systems administrators would have been able to perfectly follow those guidelines. We wouldn't have needed RFC 3463, or the updates from RFCs 3886, 4468, etc The fact that there was some perceived ambiguity lead to confusion and inappropriate implementation, and incompatibility. Which lead to newer RFCs being written on this subject in order to try to clarify the situation and hopefully lead to greater compatibility. Unfortunately, there's still lots of old code and old installations out there, and they are unable or unwilling to upgrade, so now you've got all this legacy code you're saddled with, along with all this new code as well. So, if you build your parser to handle exclusively RFC 4468 codes, and someone has written or implemented an MTA using codes from 1893 that they misinterpreted, you're probably going to have a hard time figuring out what they meant and why. Keep in mind that you're not only fighting MTA authors here, but also the vast majority of clueless MTA administrators that take a recommended configuration from someone else that is likely to be wrong and apply it inappropriately at their site, and thus perpetuate and worsen the problem far beyond the level of damage that MTA authors would ever possibly be capable of -- and MTA authors are capable of screwing up a whole lot of stuff. So, show me a parser that fully understands all possible correct interpretations of these RFCs, plus all possible incorrect but likely interpretations of these RFCs, and we might have something useful to talk about. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 10:46 AM +0100 2006-08-08, Ian Eiloart quoted Bob [EMAIL PROTECTED] [EMAIL PROTECTED]: If people bounce a message every day for a couple weeks, I consider their ISP broken enough to warrant unsubscription. In my case, it wasn't my ISP, or my server that was at fault. It was the message *senders* mail client that was constructing faulty headers. Right, but that's Yahoo. That's not Mailman. Mailman is unlikely to be doing this sort of thing. If anything, it would most likely be scrubbing the messages in order to remove illegal formatting. I can understand the overall desire in this specific case, but I'm having a hard time painting Mailman with that same brush, which would then reasonably lead to a requirement to make significant changes to the Mailman bounce handling scheme in order to try and guess as to what was the real reason behind a particular type of bounce. I'm not saying that this isn't something that we shouldn't at least look at seriously, I'm just saying I don't quite buy this particular motivation, at least not as it applies to Mailman. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 10:55 AM +0100 2006-08-08, Ian Eiloart wrote: The problem is determining, in a programmatic and systematic way, what really is a content-related bounce and what might mistakenly appear to be a content-related bounce, and the converse. No, that isn't the problem. The RFC says how to do this, and we should trust the RFC. If people have broken servers then actually there's nothing that can go wrong which isn't already going wrong. And if Yahoo jumps off a bridge because they think the RFC tells them to do that, what should we do? And what if AOL, pobox.com, hotmail.com, and all the other big providers make the same mistake? When it comes to parsing the actual reasons behind a message bouncing, the RFC is not sufficient. Indeed, I'm not convinced that it's even necessary. And you'd have to be specific which RFC you're talking about, because some of them are mutually incompatible. Trust me, this is a more complex subject than you think it is. And just blindly applying what you think is the right solution is likely to cause a lot more pain for you and for everyone else, and not necessarily for any real good purpose when everything is said and done. I can't see that data is required. Then go ahead and make the change, and then tell us how it works out for you. There are two categories of error, and the consequences are neutral in both cases: 1. A message is labelled as a content bounce when it's really a recipient bounce. Or some other kind of bounce. The consequence is that the recipient stays subscribed. This isn't a real problem. The worst that happens is a bit of extra traffic, or that the admin reverts to the old behaviour. This can be a very real problem for admins that are running larger sites, and already handling large amounts of traffic. If the admin is forced to disable some new feature in order to restore his site to a reasonably well working state, then he's not likely to make that upgrade. 2. The message is labelled as a recipient bounce when it's really a content bounce. Or some other kind of bounce. This is the status quo. People may already be incorrectly unsubscribed. This is a real problem when it occurs. It can happen because a server refuses messages with illegal (RFC non-compliant) headers, as well as when the content is offensive. Or when the server looks up your IP address and finds it on a black list, or thinks it finds it on a blacklist which no longer exists, or any number of other problems. We can't fix the entire Internet, and when people have misconfigured their servers to generate inappropriate types of bounces, there's not much we can do to help them. In my experience, any kind of guess that we might be able to make programmatically is usually wrong for a statistically significant subset of the population. Moreover, the potential damage from false positives or false negatives is usually worse for the collective whole than simply not trying to guess one way or the other, and to just give people enough lattitude that it shouldn't matter. But you've got the opportunity here to generate real-world data on how this process works, and to put the whole issue to rest. Please let us know how it works out for you. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 10:56 AM +0100 2006-08-08, Ian Eiloart wrote: Right, but if we can't fix the problem of the multitude of broken MTAs out there, and the fact that most of them probably don't assign the appropriate extended response codes in accordance with the RFCs, then the likelihood is that we are going to be lead to make the wrong guesses based on the response we get. We already do that. This is the problem that we're trying to solve, not a new problem introduced by the proposal! No, that's precisely the problem -- the proposal does cause new problems that have to be dealt with. Because of all the broken MTAs out there, I believe that the probability is high that we will be unable to guess correctly what type of bounce we have for a statistically significant subsection of the population, and that the potential consequences of either a false negative or a false positive in this case are higher than taking the K.I.S.S. approach and not making any attempt to guess what type of bounce we're dealing with. So, feel free to go ahead and make this change and to put this entire issue to rest, at least for the data you've collected from your site. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 4:44 PM +0100 2006-08-08, Ian Eiloart wrote: But, the idea is NOT to try to parse bounce *messages*, it's to parse bounce *codes*. Here's the deal. You think it's going to be trivially easy to add this new feature, and to parse the codes correctly, with the correct outcome, all you have to do is follow the RFC and everything will be hunky-dory. I think that the problem is a lot more complex than that, with many sites giving totally inappapropriate response codes for the real underlying reason, and trying to parse them is likely to cause more problems than it solves. Moreover, I think this is going to add unneeded complexity to the system for what I believe will be, at best, relatively minimal benefit. Worse, in order to adhere to the spirit of this idea and make the concept actually work, we'll have to get into trying to parse the actual wording of the error messages, and then we'll have to get into internationalization issues of all those words we're trying to parse, because I'm pretty sure that words like virus are not the same in Polish, Chinese, Farsi, and whatever other various languages we have to support. So, here's the solution. You go implement the code to do what you're talking about, and see how it works on your site. Make sure to collect all the bounce messages in question, and the action that was taken by the system. This way, we humans can compare the performance of your new code. Once you're done tweaking the system to work as well as you can manage, come back to us and show us your code and your input data, and prove to us how well it works. But without a patch and a strong indication that this is a significant improvement for relatively little added complexity, I don't think you're going to get any further traction in this issue. That's it. I've said my piece. Unless you have something new to add to the discussion, I'd suggest you do us all a favour and let this drop. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 4:26 PM -0400 2006-08-07, James Ralston wrote: As a list owner, you shouldn't need to care. Mailman should just Do The Right Thing. My argument is that ignoring content-related bounces is the Right Thing. The problem is determining, in a programmatic and systematic way, what really is a content-related bounce and what might mistakenly appear to be a content-related bounce, and the converse. Then look at what happens when you make the guess the wrong way, what potential additional cost there may be to the system for a false positive versus a false negative, and add some weightings to the situation so as to try to minimize the overall drawbacks to such a technique. The SpamAssassin people do this kind of analysis on a massive amount of spam that they have collected over the years, when re-running their complete collection of rule weightings to try to find an optimum setting. Problem is, it takes them something like a month to make a single complete run through all the rules with all the input spam, to come up with a given set of proposed set of weightings -- and this is on a large set of distributed servers, in a manner somewhat akin to [EMAIL PROTECTED] At that point, they're ready to release a new version, because more rules and techniques have been introduced since the last version they released and the weights have also been updated, and they start the whole process all over again. Now, we're not talking about something quite that intensive, but it could still be a pretty big affair to make sure that we're striking the proper balance of risking false positives versus false negatives. As it stands today, it's just some people talking about abstract theory. No one has collected any appreciable amount of bounce information to tell us what the real-world picture is at their site. If you want to move this discussion beyond the theory stage, I'd suggest that you start collecting some data. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 3:08 PM -0400 2006-08-07, James Ralston wrote: Perhaps, but we cannot solve this problem, and there's a fine line between working around stupidity and coddling it. Right, but if we can't fix the problem of the multitude of broken MTAs out there, and the fact that most of them probably don't assign the appropriate extended response codes in accordance with the RFCs, then the likelihood is that we are going to be lead to make the wrong guesses based on the response we get. I think the question is how damaging are those wrong guesses, and as compared to not making any attempt to guess one way or the other and just treat all bounces as the same? Without any further detailed information, my gut feeling is that we're better off not trying to guess what the real reason was for a given bounce, but to just treat them all the same and to give enough lattitude that people don't get unsubscribed with just a single bounce (or whatever). What further data do you wish to see? I think I've documented the problem well enough. There's no way we know many horribly broken sites are out there. Save a copy of each and every bounce you get over an extended period of time (this may require modifications to the source code), and then try to categorize them by the easy-to-parse numeric response code versus the harder-to-parse description, and actually find out how the cookie crumbles. Describing the one particular type of sub-problem that you've run into doesn't really help us in this situation, not when you're talking about changing the behaviour of an entire subsystem in order to accommodate your one specific issue. Instead, you need to go on a quest to obtain large amounts of data that demonstrate how easy (or hard) it is to determine the real reason why some message bounced and then figure out how you can take that information and modify the source code to suit. Right: the only risk is that bounces coming from a subscriber at a broken site might be ignored, because they look like they're being generated based on the content of certain messages. I'm not convinced that's the only risk, and I'm not convinced that the potential consequences are that minor. But if you can provide sufficient evidence to show that you are correct, at least for the users on your site, I'm willing to be convinced. IMHO, this risk is negligible. If the operators of the broken site in question get annoyed that Mailman keeps trying to send messages to a non-existent address, they should fix their broken site. Well, if the windmill turns out to be Microsoft, you might want to seriously think about whether or not you really want to continue trying to tilt at that thing. You might want to look into how big this problem could potentially be, before you decide to just casually blow off any possible consequences. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] suggested improvement for Mailman's bounce processing
At 5:36 PM -0400 2006-07-28, James Ralston wrote: I admit that this algorithm isn't perfect. But I think it's better than what Mailman does currently, which is to ignore the status field entirely. Unfortunately, there are a whole host of seriously broken MTAs out there, and seriously broken configurations of otherwise good MTAs, and many sites return totally bogus status codes. If everyone read and understood the RFCs half as well as you have done, then there wouldn't be any problem. But that's not what happens. In many cases, site admins will blindly copy stuff from somewhere else that was horribly broken to begin with and won't understand what's wrong with it before they do the cut-n-paste operation. That said, I would not be opposed to seeing more data on this subject, and possibly giving site admins or list admins an option they can enable that would allow Mailman to pay attention to the status codes. Once that's out there, we could let various people try it out and see how it works in the field, and I would be a very happy guy if I were to be proven wrong in this case. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Integrating Mailman with a single sign-on service
At 10:53 AM +0100 2006-07-17, Alisdair Tullo wrote: I have a few questions about Mailman, if someone familiar with the code can answer them I'd be very grateful. Speaking as one of the list co-moderators, we normally try to keep the questions type stuff on the mailman-users mailing list, where you will find many of the Mailman developers are also subscribed. This particular message seemed to be kind of borderline for me, so I went ahead and approved it in the hope that we would get into discussion of Python modifications you're making or would like to make to support your requirements. Other than that, I'm usually more of an observer on this list, and I'm afraid I don't have any answers for you. I'll let someone else that is more knowledgeable about the code try to address your questions. -- Brad Knowles [EMAIL PROTECTED] Member of the Python.org Postmaster Team Co-moderator of mailman-users and mailman-developers mailing lists ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] The Philosophy of Web Use.
Ethan wrote: Have you used http://wiki.list.org/ ? Is it flat out broken or slow and distracting? I find it has a few bugs, but mostly it works well. I have tried to use Confluence, yes. Not all that successfully, however. It seems to be an improvement over TWiki, but that's not saying much. Here's a specific example that works well for me: Does the drag/drop of boxes on the customized google home page not work for you? You don't have to sign in to try it, and it allows drag/drop reordering for me in Safari just fine, and way more intuitively than resubmitting the page after clicking on buttons. I had never tried that particular feature of Google, but I'm not particularly impressed by it. And if the choice is to send a whole bunch of stuff to the other end and then hide most of it or to simply not send it at all, I vote for not sending it. If you read the Slashdot article that I referenced in another message, I believe you'll find that it's the Google people who are saying that the bottleneck in most cases is not the network, but is actually the amazingly low-end Pentium machines that people have at home, and that we (they) have to work hard to avoid overtaxing those systems. So you have no constructive feedback, nor a sufficiently detailed critique that I can even address your concerns. I'm not sure what you would have me do with your advice, beyond my already existing commitment to make the page work without JavaScript. It's not just making sure that the page will work without JavaScript. It's also making sure that the JavaScript which is added is relatively simple and unlikely to break when viewed/used in unexpected or unknown browsers, and will be likely to continue to work in all future browsers and browser versions. It's also not pushing things too far, because I might end up browsing a Mailman admin site with my Treo 650 with JavaScript turned on, across a slow spotty GPRS connection, and I still need this 320x320 screen to be useful when trying to do some emergency list maintenance away from home. * IE 5+, Mozilla (any), Safari from 1.0+ and any other KHTML browsers, JAWS 6+, Opera 6+, Lynx, Links. All in any combination of Images/CSS/JavaScript off/on. You've got PCs on the brain. Or maybe not PCs, but certainly desktop computers. Don't forget about Opera Mini, Brew, the web browser on Palm from Access, the other web browsers for common PDA and phone devices, etc -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] The Philosophy of Web Use.
Ethan wrote: Can you do me a favor and let me know how these examples work for you? http://tool-man.org/examples/sorting.html It seemed to work as the author expected, using Safari 2.x under MacOS X 10.4.x. Using Blazer on my Palm Treo 650, although I enabled everything (especially including JavaScript), the supposedly draggable items were instead rendered as plain text. This is the key problem with something like JavaScript. It advertises that it works, your web application can see that JavaScript is enabled, you test it with your preferred browser(s) and everything seems okay, and you release the code. Only problem is, when it's put out there in the real world you discover that it has interesting failure modes with other browsers that you didn't test with. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
Ethan wrote: One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a overview page variant and then being able to expand as necessary. I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of hidden text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc2822
Ethan quoted John Dennis: It's not at all clear to me that mailman should be responsible for archiving. While I am somewhat in agreement, the current situation is that archiving comes bundled with mailman and represents a significant weakness in its current web UI. Not doing anything about the web UI presented by the archives would, in my mind, represent a substantial failing. One of the reasons I switched from Majordomo to Mailman was because of the better integration of the web control and archive system, so I at least partially agree with you. Archiving and MLM (Mailing List Manager) functionality can be orthogonal to each other. I can imagine - but have never used - a mailing list where access to past emails is 'orthogonal' to the use of the mailing list. Majordomo, older versions of Mailman, as just two examples of many. In fact, most MLMs don't necessarily have integrated archive components. And there are plenty of people who don't care for Pipermail and instead integrate a third-party archive system into Mailman, in accordance with the instructions that we provide in the FAQ Wizard. I am not at all opposed to improving or replacing pipermail with something else that is integrated into Mailman, but we need to make sure we don't lose sight of these other archive systems, and that we don't do anything that would make it more difficult to use them. It is probably just a sign that I haven't explored the extant solutions sufficiently, but I have seen no sign that there are a variety of high-quality archiving solutions out there. There are at least a couple of alternatives mentioned in the FAQ Wizard, and John has clearly found at least one more. I'm sure he can tell you the search process he used to find all the others, so that you can take a look at all the ones he found and then see if there are any others you can discover on top of that. But this is a pretty big undertaking. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
Barry said: We should certainly do everything we can to make sure that Richard's ht:dig solution is nearly trivial to integrate, but I'm not sure we should distribute it with Mailman. Sorry, I guess I wasn't clear -- I just meant for him to look at both Python and non-Python solutions, before deciding what was going to be done and how. I wasn't advocating the incorporation of ht:dig itself into the stuff we ship. At least, I didn't mean for it to come off that way. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] The Philosophy of Web Use.
kerning, or whatever. No autocomplete in any text element? No, my browser is annoying enough when it tries to do autocomplete, and it almost always fails to autocomplete what I'm trying to type in the way I would want it to. No reordering a list without a zillion little checkboxes/number boxes and ambiguous behaviour if the same number is entered twice? Not really, no. When I've seen that done in the past, it was almost always dead-dog slow and far more of an annoyance than any help that it could possibly have been. Like that damn bloody stupid find as you type crap. I've learned a few things about torture over the years. I'd like to test them all on the guy who invented that idea, and then maybe see if I can come up with a few more new concepts in that area that have never previously been explored. And there's no way I'd let that guy pull a Ken Lay and up and die on me before I'm done with my experiments. What do you do when you have a data structure not well suited to tabular display or a list/tree? Just give the user fragments of the content? I'm not sure that I've got any answers for you, with regards to how you should resolve this issue. I'm just telling you the sorts of things I have had experience with in the past, and which I would be very annoyed to ever have to encounter again at any time in the future. That's the part that gets me; if Content is sacrosanct, shouldn't providing as complete a picture in a given page's content be a goal? Yes, but it's not physically possible to test with all possible platform/browser combinations that will exist throughout all of history (at least, throughout the entire history of the program you're designing), and it's not physically possible to know, a priori, everything that any user might ever want to do under any and all possible circumstances. Some things you can guess at, and provide reasonable failure modes should you guess wrong. Other things you can guess at, but the failure modes are going to be quite a bit more nasty. And then there are a lot of things that you would never have guessed in a million years, and you've got to wonder what complex code is going to do under those circumstances and what the failure modes will be. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] The Philosophy of Web Use.
Barry wrote: OTOH, I've used Linux and OSX, and before that NeXT, Solaris and various Unixes for (unfortunately, way :) longer than there's been a web, and except for the Windows programming I do at work, haven't ever used IE for any substantial amount of time. I've been using Unix and the Internet since the summer of 1984, and a Macintosh Fanatic since December of 1983 (when I saw a prototype, before the official unveiling during the SuperBowl commercial). I've never voluntarily used IE, except when I'm at my parents house and I need to do something on the web with her computer -- which is almost never, since I always take my laptop with me. I would love to have a self-discoverable interface, or an interface that can be used to selectively reveal just the parts you're interested. I just read the intro to a Slashdot article at http://slashdot.org/articles/06/07/06/1654242.shtml, which quoted the following section: | Dollar for dollar, network-based computers are faster. Unless you're playing Grand Theft | Auto or watching HDTV, your network isn't the slowest part of your setup. It's the | consumer-grade Pentium and disk drive on your Dell, and the wimpy home data bus | that connects them. Home computers are marketed with slogans like Ultimate | Performance, but the truth is they're engineered to run cool, quiet, and slow compared | to commercial servers. I'm not 100% certain the original author being quoted by Slashdot is right, but at the very least I think you have to give some serious consideration to what the author is saying. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
Ethan wrote: Note that this would be in *addition* to the ability to get a JS-free version of the interface by using a different URL prefix for any user agent that doesn't want the JS action. Speaking only for myself, this is not the kind of approach I'd like to see used. I'd prefer to see the web application auto-detect that JavaScript is not available, and therefore to automatically present the appropriate non-JavaScript interface. Likewise, it should auto-detect that there is a screen reader being used, and present the appropriate screen reader compatible interface. Of course, the manual options should always be there, but if we're forcing the user to manually select a different page in order to get away from the JavaScript stuff, then I think we're doing something wrong. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Please Tell Me How You Translate
Ethan replied to Barry: Pretty please, I need to set up a copy of someone's translation toolchain; can someone using OS X or Linux as their work operating system work with me to get an *exact* replica of their toolset? Have you gotten any love on this issue Ethan? No love as of this writing. I'm continuing to kick the i18n ball down the field until I can do a translation myself (into gods-knows-what - I'll probably have to rely on my lovely and talented wife to give Russian/Italian a stab.) I've got MacOS X 10.4, but I don't do any sort of translation, and I don't have the slightest clue as to how you'd go about trying to do that. I don't speak any foreign language well enough to even think about making any attempt to do so. That said, I'd be glad to provide whatever help I can. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
Barry Warsaw wrote: I will do this for browsers not employing JavaScript. Screen readers employ JavaScript and provide no indication what they do/do not provide feedback to the user for. Will this also work for browsers with JS enabled per-page, a la the Firefox NoScript extension? I use that to control which sites I allow JS on, and while I generally would enable it (and cookies) for most Mailman sites, I could definitely see others disabling it. I also do this with Firefox, and an equivalent for Safari (using PithHelmet). I would generally turn on JavaScript for those sites I consider to be safe, such as the mail.python.org or any other Mailman site I help administer, but I can certainly see that others might not feel the same way. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
Ethan said: In the interest of not reinventing the wheel, I'm looking for existing python (or other!) code that does the things I need. I'm also putting out a call for anybody who likes this sort of thing to help me out (see below). Don't ignore non-Python solutions. In particular, you should take a close look at what Richard Barrett is doing with his ht:dig patch for the current versions of Mailman. At the very least, this is what most Mailman administrators are likely to expect, and you should have some idea of what they're going to be looking for before you throw something totally new and unfamiliar at them. * mbox thread indexing on messages I plan on using [2] to generate mbox thread indexes for rapid navigation of lists. Any suggestions for more robust variants would be welcome; feedback on how to handle threading for message-id-less messages would also be welcome. All messages should have message-ids -- this is one of the most basic requirements of the Internet e-mail related RFCs. If nothing else, the local MTA on the Mailman server should have provided a message-id. That said, if you still don't find one, then I think you should select a suitable method for generating them (take a look at the code in postfix or sendmail), and then apply that. * full-text indexing pylucene seems to be the obvious choice; anything else I should consider? Anyone know of good pylucene/web UI glue code out there? Again, I urge you to look at the existing ht:dig stuff. For that matter, you should probably also look at mail-archive.com and other similar sites to see what they've got and make sure that you either fully implement all the same features (in a way that makes sense), or that you know which features you're not going to implement and why. It all comes down to knowing what the expectations are for people who are going to be administering and using Mailman, and then being able to manage those expectations with regards to what you're doing. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))
David Andrews said: If you have OSX10.4 Tiger there is a built-in screen reader called Voice Over. I believe it is command-F5 to bring it up, but could be wrong there. I have only used it briefly, and not at all with the web, but could probably get access to a machine at work. Correct, this works with MacOS X 10.4 Tiger. I've tried VoiceOver just to play around with it a bit, and I didn't like it. I turned it back off soon thereafter. I wouldn't want to be dependant on a program like this for all my web access. But if someone wants me to do some specific testing, please let me know. This is now my main machine, and I have both Safari and Firefox, and I can install a number of other browsers for testing purposes (including Opera, Camino, etc...). -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
Terri Oda said: 5. Archives? Are you going to get a chance to touch the archives? A lot of the same things apply for templating there, and people always want that same look/feel. Check the Mailman 2.2 ToDo list at http://wiki.list.org/display/DEV/Mailman+2.2. If what you want is not already covered there, please feel free to add a comment at the bottom. Of course, I really really want to replace pipermail with something a bit more modern (I'm looking at finding a nice way to use apache's mbox_mod for my current lists -- if anyone's got instructions for that, drop me a line!), but I think that's a little outside your scope. :) Better support of third-party archiving systems is also on the list. Still, getting it so the archives at least use the same CSS might be nice. Yup. Also note that Ethan has his own ToDo space at http://wiki.list.org/display/DEV/Summer+of+Code. I'll probably think of a dozen more things to say later, but as everyone else seems to have covered the most important things I'll try to restrain myself a bit. :) I'm very excited to see this happen, though -- I think the web interface is often heralded as one of Mailman's strengths, and it'll be nice to see it a bit more polished and modern and less like someone's opened up a dusty panel and let us grab all the live wires we want. :) IME, Mailman is a huge improvement over Majordomo+Majorcool, but could certainly use more work to make it both simpler and easier to use (especially for neophyte list participants and less experienced list admins), while also making it more powerful and easier to use for the more experienced people out there. From everything I've seen, I think Ethan's work is going to be a huge improvement in both areas. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
At 6:57 PM -0400 2006-06-20, emf wrote: Well, I've got me a testing lab right here! I'm only slightly kidding. Aside from the aforementioned TX, I have an intel mac, so I plan on installing Windows soon so I can see how things work on that end. I'm also going to make sure it's fine in links or lynx. That's good enough for me. Thanks! happily I feel like I'm making quite a bit of progress, so I think we might just get something viable out of this. You've already made me feel a lot better about the probably outcome of this project, and I'm pretty confident that you will be fully successful. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
At 9:01 PM -0400 2006-06-15, emf wrote: I'm especially interested in getting any feedback, either on the wiki or here, about any and all WebUI - or UI in general - ideas in people's heads. Speaking only for myself, I think there should be three main design goals: 1. KISS -- I sometimes have to do list administration and moderation from my Treo 650, so anything that depends on graphics, JavaScript, CSS, or anything fancy is really bad news. Stick to a pure text-only UI as much as possible, and try doing some actual tests with various PDAs and phones, as well as all common browsers (including Safari) on all common desktop platforms (including MacOS X). This also means that the size of the pages should be kept as reasonably small as possible -- the smaller they are, the faster they load. Of course, the standard exemplars are Google and Yahoo! IMO, we're doing pretty good in this area today, but I would hate to see all the current WebUI code get thrown out and replaced with a Web2.0 AJAX/.NET framework. 2. Functionality -- As much as possible, make it just work out-of-the-box. We've managed to accumulate a lot of cruft in the FAQ Wizard because there are a whole host of things that list moderators and administrators want to do with their lists, and some of them are easy with the WebUI, and some are not -- while others simply aren't possible at all, at least not from the WebUI. Ideally, I'd like to see everything in the FAQ Wizard get removed because it is no longer applicable. At the very least, for anything that is related to the UI, there should not be any entries to go into any FAQ, because it just works. 3. Completeness -- diametrically opposed to #1 and #2 above, anything that can be done from the command-line should be do-able from the WebUI. This includes things like editing posts in the archives, editing posts before approving them, etc It's going to be tough to balance #3 against #1 and #2. There may be a lot of things that you would like to do in this area that would require support in other parts of the code, and therefore you may not be able to do them. But I would like to see a concerted effort made. While the SoC project is fairly constrained, I want to at least make the future easier. Your work is very important to us. I'm not sure you fully understand how important. Or how difficult. ;) -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 11:06 AM +0100 2006-06-09, Ian Eiloart wrote: Using a per-sender password for the same mechanism will prevent the spoofing, Only if you ensure that the entire email transmission chain is encrypted. Using the existing Approved: mechanism would also prevent the spoofing, and would have the same exposures regarding encryption. We're not trying to fix all of the security problems in Mailman, we're just trying to take an existing mechanism (with known vulnerabilities) and extend that to work in a per-sender manner. That's only possible if you know the sender is on-site (on your campus, in your company, whatever). If that's true, then you can rely on authenticated SMTP anyway. Red Herring. We're not trying to fix all the possible security problems in Mailman. That's a job for Barry, Tokio, Mark, and others. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote: No, that's not true. What's required is that Mailman provide a simple API to allow MTA developers to ask Mailman whether a particular sender is permitted to post to the list. Holding rosters (a v3 proposal) in open databases would solve this problem - at least for Exim. That's fine, for Exim. Although Mailman is capable of filtering on other factors, I don't think the number of cases is significant. However, it might be possible to extend the API to provide information on other list policies. I disagree that it's not significant. If you want to extend the simple API argument to other aspects of the filtering Mailman is capable of doing, that's fine. But you still have to have something to use that API to tell the MTA what it needs to know and when, and I don't think we can necessarily depend on the MTA authors to create that. Maybe the Exim authors could and would do so quickly, but that's not the only MTA we have to concern ourselves with. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 3:26 PM +0100 2006-06-08, Ian Eiloart wrote: where sender-pw is associated with the (claimed) From-address. This is different from, but complementary to, Approved: list-pw. That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. It's far better to insist on authenticated SMTP for ALL message submission. For the application that David is looking at, Authorized would probably be the most appropriate term. I've had a look through that thread, and I'm not sure what you're trying to achieve. Generally, there are two aspects to deciding whether someone can post to a list: authorisation and authentication. David is looking for a way to do a per-sender way of using the existing Approved: mechanism, without having to share the list password across a large number of senders. Each user would get their own password that would achieve the same result. But otherwise, there should be no additional security exposure, and no change to the security threat model. Passwords are usually used for both, but it's far better to separate the functions. Knowledge of a personal password serves to authenticate you, but not to authorise you. Knowledge of a shared password is sometimes used for authorisation, but can't be used for authentication. Even for authorisation, passwords are extremely weak. This is a debate best reserved for discussing the entire Approved: mechanism as a whole, as opposed to something that David should have to try to fix as a part of the extension work that he is looking at. There are lots of deeper technical and architectural details here that need to be addressed, and I think that's more appropriate to ask Barry, Tokio, and Mark to look into those issues as opposed to David. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 4:54 PM +0100 2006-06-08, David Lee wrote: To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable? I think that the authentication thing is a red herring. Stick to the original idea and make relatively minimal modifications to the code, and let Barry, Tokio, Mark, and others deal with the deeper technical and architectural issues that Ian is raising. That would, indeed, probably be the ideal. But that would itself mean that all paths by which the Mailman machine might be reached would have to be known to have an enforced mechanism for authenticated SMTP. (And what about (say) cron jobs generating email which might legitimately go through lists?) Which is part of why you shouldn't worry about trying to solve this problem. With your original concept, you're not really opening any new security holes, and you shouldn't have to worry about trying to close those that already exist. Just make sure that you put in the appropriate cleanup code into place to remove the headers in question, as is done today for the Approved: header. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 5:24 PM +0100 2006-06-08, Ian Eiloart wrote: Well, I guess that a typical Message Submission Agent would require authenticated SMTP *except* for a list of specificed (host IP, sender email address) pairs. Mailman is not an MTA or an MSA. It makes use of MTAs and MSAs, but it is neither of these things itself. Therefore, it's not appropriate to ask David to fix MTA and MSA problems with respect to the code he's trying to add to Mailman. True. But are you really asking people to email secrets around? If you are, them I presume you're going to encrypt communication between your MTAs? Otherwise none of this is going to gain you anything. The only thing that's secret is the password used to authorize their ability to post to the list. I presume you're going to have Mailman remove those tokens before delivery? I'm sure. Otherwise spoofing will be just as easy as before. To be honest, I'm skeptical about all of this. Do you have a history of people spoofing to your lists? Yes. Please re-read the thread. Using the Approved: mechanism will prevent future spoofing, but brings along a whole host of other problems, such as having to share the list password with all the potential senders, which increases the security exposure due to the probability of the password being accidentally exposed. Then there is the issue of having to change the shared list password, and having to have everyone memorize the new shared password. Using a per-sender password for the same mechanism will prevent the spoofing, eliminate the probability of accidentally exposing the shared password, and make recovery from accidental exposure of a password much easier -- only the one user will be affected by having to change and remember the new password. Some additional code will have to be added to handle the addition of storing a per-user Authorized password, and a per-user authorization/approval mechanism (akin to the list of approved_nonmembers), as well as a cleanup mechanism to try and ensure sure that the new password doesn't get inadvertently exposed by Mailman. But extending the existing Approved: mechanism is clearly the way to approach this problem. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 3:46 PM +0100 2006-06-07, Ian Eiloart wrote: Ian mentioned that he thinks we should change Reject to Bounce, but I'm not sure I like that. Rejecting a message or a subscription request is the action that the admin takes. OK, i'm talking about messages here, not subscription requests. List moderators deal mostly with messages, list administrators deal more frequently with things like subscription requests. We need to distinguish here what we call what, in what context. As I understand the terms, a reject is an SMTP response to a remote server (or MTA) trying to send email. It means I'm not accepting this email, you choose what to do with it. The sending MTA may choose to generate a DSN, and a DSN that reports a hard (5xx) rejection is often referred to as a bounce message. Actually, no -- that would be a refusal. A rejection would be something you would send after accepting the message initially, and then discovering that you could not deliver the message for some reason. So, when it comes to spam, you want to refuse it and not reject it. There's a REALLY REALLY REALLY important difference in the case of spam. Most spambots will ignore a reject and NOT generate a DSN bounce message. However, if you choose to bounce the message, then a DNS will be sent to an innocent third party. That's collateral spam, and it's a nightmare. Yes, blowback is a problem. I'm not sure that anyone can resolve this problem any time soon, however. Unfortunately, RFC2821 says that you must generate such collateral spam, and that's why I want my MTA to be able to read Mailman's config - so that it can reject email properly at SMTP time. See my previous responses. We may be able to teach the MTAs how to read some of the databases that Mailman might be using when it would be making its decision to accept or reject the message, but I don't think it's going to be possible to teach the MTAs everything. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 9:26 AM -0400 2006-06-07, Barry Warsaw wrote: I think that will be problematic, given the wide variety of MTA extension frameworks. It's not just the MTA extension frameworks, it's also the myriad of things that Mailman may choose to do or to look at when deciding what to do, based on content in the message. I don't think it's feasible to completely re-write Mailman, or to completely re-write the MTAs, so that each of them has a deep integral understanding of all the nuances and complexities of the work that is being done by the other. Short of doing a rewrite on that scale, I suspect that we're going to continue to have these kinds of problems for some time. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 3:51 PM +0100 2006-06-07, Ian Eiloart wrote: Perhaps. Even better would be to hold rosters in open databases. Exim, for example, can read sql, ldap, flat files and so on. That's just rosters. That's a small part of the overall set of things that Mailman is going to be looking at when it comes to deciding whether or not to accept or reject a given message. Moreover, we've been trying to go to an integrated database model for all data regarding users, but what you're proposing here would be a push towards simplified, almost flat, databases with minimal specific information about users, so that the MTA could parse that information and understand who was subscribed to what list. Unless you've got some ideas of how to teach all MTAs how to reach deeply into our database and pull out subscription information for a given message, I don't see how these two goals are anything but diametrically opposed. We can't just be thinking of a single MTA here. Just because it would be convenient to you to make all this magic happen in a way that would be perfectly fine for Exim, doesn't mean that we can ignore sendmail, postfix, and other programs. If you want to write up some Exim-specific ways that would result in a tighter integration between the MTA and Mailman, I think that would be fine so long as they don't cause architectural changes within Mailman that would result in a significantly worse integration with other MTAs. I don't think it's Mailman's job to examine the content of messages - that's the job of a spam or virus filter. But once the spam or virus filter has done their work, we need to look at that as part of the output in making our decisions. I don't think there's any way in the world that you're going to escape this. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 10:41 AM +0100 2006-06-07, Ian Eiloart wrote: Even better would be to integrate Mailman into MTA's better, so that the MTA can use Mailman data to reject spam. I think we've had this debate in the past. I don't think that's possible, given the sorts of things that Mailman may do with messages, including taking different actions on different messages with the exact same combination of envelope sender and recipient, based on the values of other things in the headers (such as placed there by anti-spam/anti-virus scanning systems). If you want to completely re-write your MTA so that it has a deep understanding of all the internal workings of Mailman, feel free to go ahead and do that. Otherwise, I suspect that we're going to continue to have this kind of problem for quite some time. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Mailman on a cluster
At 10:32 PM +0300 2006-06-07, Dale Newfield wrote: Ian Eiloart wrote: I'm looking at running Mailman on a cluster of servers, sharing a single disk with Apple XSan. Barry, none of the bdb stuff you were working on is in the 2.1 tree, is it? bdb does not guarantee acid properties over networked file systems... My understanding is that Berkeley db doesn't work at all on NFS, because it uses mmap to handle access to the database files, and mmap on NFS is an undefined operation. This is the same problem that people wanting to use Cyrus on NFS face, for the same reason -- Berkely db on NFS doesn't work. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Mailman on a cluster
At 3:54 PM -0400 2006-06-07, Barry Warsaw wrote: I wouldn't put much faith in them though -- does anybody (other than Sleepycat^H^H^H^H^H^H^H^H^H^HOracle) really know how to write robust and reliable BDB systems? ;) Well, I'm pretty sure that Eric Allman can, since he worked closely with those guys back when he was at UCB, and he also spent some time writing the original Postgres database. But one positive example does not prove a trend. ;) -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] archiving size issue
At 4:06 PM -0400 2006-06-07, Barry Warsaw wrote: Ultimately, I think generating the archive html on the fly is the right way to go. That approach provides so many possible benefits at the mere wink cost of cpu time. When the original archive system was designed, that cost was too high, and thus we have the static page rendering approach. But today I think the tradeoff tips in the other direction. I think we need to have both solutions. I have some really anemic machines running Mailman, and I can't imagine what they'd do if they had to generate HTML archives on the fly. As I always say when this topic comes up, I'd love to have some motivated developers come forward to help with an archiver redesign, so if you're interested in doing work here, let me know! I can give some input and feedback based on my own experiences, but I'm not a developer. ;( -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
At 2:35 PM -0400 2006-06-07, Barry Warsaw wrote: Totally agree. OTOH, don't most MTAs provide /some/ way to call external programs on messages at various points in their workflow? Sendmail has milter, and that has now been brought into postfix (as of 2.3), but I can't speak for any other MTAs. What would need to happen would be a custom program would have to be written for each MTA to interact with it in the way that MTA works, but which has a deep understanding of Mailman and the configuration for each list and recipient, and could effectively do a dry run for each message. Of course, this would have to happen after the anti-spam/anti-virus milters, and then some sites are going to use accept scan techniques as opposed to milter, so there may need to be multiple different MTA adapters, even for a particular MTA. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Topic regexps
At 8:33 PM -0700 2006-05-25, Mark Sapiro wrote: There is currently a user option to receive (or not) all posts which don't match any topic. Is this what you mean? Yurffhh. /me removes foot from mouth Yes. /me reinserts food -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Topic regexps
At 1:12 PM -0400 2006-05-24, Barry Warsaw wrote: I have a hard time imagining that anyone would enter one two three and not expect it to match 'one|two|three', so I think I'd opt for 1. That's what I would have expected, and I was very surprised to hear Mark's explanation that this didn't actually happen. I'm not in favor of yet another configuration variable to control this. OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all. I think the concept is a good one, and on busy lists I would gladly subscribe to a few topics and leave the rest, but I think it needs some additional work before we can get to the point where I'd actually use it. For one thing, you need a way of explicitly selecting the null topic. I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern. Not understanding what a verbose pattern is, I'm not really fully understanding this concept. I can say that I think it would be pretty wild to come across a new twist in variable regexps like this, after twenty or so years of mucking about with Unix, etc -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] sender-based authorisation
At 3:19 PM +0100 2006-05-19, David Lee wrote: But then the potentially useful moderation-bypass Approved: listpw mechanism has the problems of requiring many people to share a particular list's password, Yup. and of the passwords across a cluster of lists having to be common. I'm not convinced that's necessary. Each list could have their own approval password, and there is no technical reason why they would need to share that password with any other list. That said, there may be operational reasons why you might end up going down this road, such as people not being good at remembering large numbers of passwords. Beyond that, I'm not sure that I can contribute much of anything more to this discussion. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] sender-based authorisation
At 6:15 PM +0100 2006-05-19, David Lee wrote: My understanding is that to get this email straight through using the Approved: mechanism all those lists (i.e. their superset) would currently need to share a common password. (I haven't seen documented the ability to have multiple one-per-list, Approved: lines.) If you wanted to send to all of those lists with a single message, that's probably true. However, I think that's also a sub-optimal way to send a message to mailing lists. If nothing else, I think it's really ugly for all recipients in all lists to get a complete list of all the other lists that were recipients of the original message. You could resolve that with an umbrella list, but I'm not sure where the list approval mechanism comes into play in that situation. Moreover, if the subset of lists the poster wanted to send to changed, then you'd have to create a new umbrella list, which would be a pain. I'm not sure there is a good/easy solution to this part of the problem, although it is probably mostly just cosmetic. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] thoughts on bounce processing
At 1:24 PM -0400 2006-05-11, James Ralston wrote: The more I think about this, the more I think that silently discarding bounces is an error. Mailman doesn't silently discard bounces. It keeps a counter, and for each day that a bounce is received, that counter is incremented. Multiple additional bounces on a single day do not cause the counter to be incremented, but they are still examined. While some bounces are irrelevant (e.g. vacation messages), in the majority of cases, bounces are information that some entity should act upon. There should be two (and only two) options: 1. Mailman processes all bounces. 2. All bounces are forwarded to the list administrator(s). In your example above, that would only be appropriate if the AA is the list administrator. I think a better method would be to have all bounces sent to the poster, regardless of who that poster is. If it's an announcement-only list, then presumably you have a restricted set of people who can post to that list, and any one of them should be able to handle bounces sent directly back to them. This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of. And hopefully you wouldn't use this kind of mechanism on an announcement-only list with thousands of recipients. That said, I can see that this would be a reasonable enhancement to request. If list admins *really* want to (effectively) discard all bounces, they can e.g. set bounce_info_stale_after to 1 and then set bounce_score_threshold to something impossibly high (e.g. 500,000). Keep in mind that I've seen mail loops quickly spin into the thousands in a matter of minutes, especially when the messages are passing through systems that scrub what they consider to be non-useful headers like Received:. I don't know that there's much of anything you could do about such loops. I think the only thing I'd say here is that I'd tend to be a little more conservative in terms of what I'd call impossibly high. ;) -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] thoughts on bounce processing
At 4:50 PM -0400 2006-05-11, James Ralston wrote: Mailman doesn't silently discard bounces. It does if bounce_processing is set to no. Ahh. Sorry, I had missed that part of the issue. That's my point: turning off bounce processing should mean forward the bounces to the list administrator(s), not discard bounces. s/list administrator(s)/appropriate place/ In some cases, the list moderator(s) might be the appropriate place, in others the original poster will be the appropriate place. I think there's some room here for further discussion. This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of. If the envelope sender is unmodified, then Mailman can't use VERP, which means that the likelihood that the bounce will contain useful information (such as, which address actually bounced) is reduced. :( Not really. VERP could be used, but then that would require that the MTA of the poster would also understand that format. I suppose Mailman could stuff the original envelope sender header into another header (e.g., X-Mailman-Original-Env-Sender) and then pull it back out when processing a bounce, but that smells rather hackish to me. That sort of thing may be the only alternative, if you want to have the bounces sent back to the original poster. Sending things to the list moderator(s) or administrator(s) would be simpler, since you wouldn't have to worry what the original envelope sender address was. But that would only help you if the original poster was also one of the list moderator(s) or administrator(s). Perhaps VERP could be enhanced to encode both the original envelope sender and the recipient? The problem is that subscribers might have their own plus-style addressing, on top of which we're trying to add VERP, and now you're trying to encode both the envelope sender and envelope recipient in the VERP. That might be theoretically possible, but I think it's going to take a lot more thought and design work to see if that can be done. I suspect it would be a lot easier to do some of the other sorts of things we're talking about. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Sender field
At 11:15 PM +0900 2006-04-29, Stephen J. Turnbull wrote: If Mailman sends an RFC 1153 digest, it *must* be the Sender, and the individual messages presumably won't have them. Actually, in the case of a digest, Mailman would be the originator of the message, and put its address in the From: field, leaving the Sender: field blank. The individual messages in the digest would have their own From: and possibly Sender: fields, but those would not be promoted to the digest itself. There's just no way you can do digests using any other method. But, most of what we've been talking about so far has to do with regular list activity with regards to individual messages, and not digests. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Sender field
At 12:00 AM +0900 2006-04-30, Stephen J. Turnbull wrote: Brad If we need something that will be noticed by other MTAs Brad beyond the envelope sender and the Return-Path: Brad Errors-To: headers, then we're going to have to carefully Brad think about this. What's an Errors-To header? I can't find it in the usual suspects. That's the oldest technique for handling bounces. It has been deprecated for a while, but I would be inclined to continue to at least provide the appropriate information. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Sender field
At 5:32 PM -0400 2006-04-28, James Ralston wrote: I will grant that the phrasing of the RFC is suboptimal here--it uses transmission when a better word choice would have been submission. But the immediately proceeding example (of a secretary sending mail on behalf of another person) clarifies the intent beyond any claim of ambiguity. I read through all of section 3.4 pretty carefully. Unfortunately, I haven't been able to find any references to automated agents acting on behalf of other parties. It is not exactly clear to me if a relay agent should be considered as a user (for which examples are given), or if it should be treated in some other manner. There are cases of forwarding mentioned where it is not appropriate to make any modifications to any headers, but there are other cases where modifications are acceptable or even recommended. Additional clarification would be very useful. So, in summary, the disadvantages of Mailman's behavior of rewriting the Sender header is that doing so is not in the intended spirit of RFC2822, causes subscription grief, and breaks Outlook. The advantage is that it helps Mailman detect bounces from a slim minority of brain-dead MTAs that send bounces to the Sender header. On the whole, I'm coming around to the view that Mailman should be using Resent- headers for the things it would like to add to the message (e.g., Resent-From:, Resent-Date:, Resent-Message-ID:, etc...), as well as the standard List- headers. However, it is not clear to me what the impact on the user community would be. Yes, some users would stop seeing things that are confusing them, because we would stop rewriting/replacing the Sender: field. Well-known MTAs would not have any problems with these changes, but I do have to wonder what the negative impact would be from less common MTAs, not to mention all the different MUAs that are out there. I would argue that the best course of action is to excise Sender header rewriting entirely and provide no option to turn it on. (Mailman has way too many options already.) If, however, an option is created to control the behavior, it should definitely default to OFF (no Sender header rewriting), not on. Right now, I'm probably somewhere around 75% convinced that we should not be rewriting/replacing the Sender: header, and should be using appropriate Resent- headers instead. At least, in the ideal world. However, In the real world, I am much less convinced that we should be making a radical change like this, at least not without a lot more experience in how things are actually impacted. I would support adding code to the system to make this change optional and to initially default to the old behaviour (allowing people who want to play with this option to do so), then in a future version to default to the proposed new behaviour (but still giving people the option to go back to the old method), and then finally to removing the option to revert to the old behaviour at some distant point in the future. But I definitely would not support just ripping out the offending code. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Sender field
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote: On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote: As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. Siunce the RFC doesn't specifically talk about relay agents as separate from users, I think we could argue that Mailman would qualify as a user in this context. Therefore, the Resent-* headers seem to be most appropriate. But you are correct that these are purely informational and will be completely ignored by any MTA. If we need something that will be noticed by other MTAs beyond the envelope sender and the Return-Path: Errors-To: headers, then we're going to have to carefully think about this. I am still opposed to blindly making this change and letting the community find out what happens. I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Sender field
At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote: I would like to request that a feature be added in the next version of Mailman to allow a list administrator to disable rewriting of the Sender: header, or (better) for this behavior to be eliminated from Mailman altogether. Have you filed an RFE at the appropriate SourceForge page for Mailman? - Outlook treats the Sender field as a person sending on behalf of another. This seems to me to be a reasonable interpretation of the Sender field, per RFC 2822 3.6.2. When a bounces address is included in the sender field, Outlook displays something along the lines of From [EMAIL PROTECTED] On behalf of [EMAIL PROTECTED]. (See Mailman FAQ entry 2.3). This is undesirable. This is an MUA problem. See FAQ 2.3. - Useful information (the original content of the Sender: header) is lost by doing this. If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. - Bounces go to the envelope sender or Return-Path: header, not the Sender: header, so this is not necessary for proper bounce handling. Mailman does not modify this header for the purpose of routing bounces to the appropriate place. Mailman modifies this header because the original From: header is left unchanged and the RFC specifies that we should indicate when the message has been forwarded or sent by someone/something else on behalf of the entity in the From: field. - Again from RFC 2822 3.6.2, the Sender: header should contain the address of the agent responsible for transmitting the message, meaning that a person who sends mail to the address in that header should expect to reach said agent, not suggest to Mailman that a message bounced. Right. Mailman is the agent responsible for transmitting the message, and this needs to be reflected. However, we want to make sure to capture any potential messages that may be routed to the Sender: field and have them automatically processed through the part of the system that is designed to do that sort of thing. - Information regarding interacting with the list is provided by the List-* headers; including it in the Sender: field is unnecessary. No, it is necessary. It's required by the RFCs. Removing this (IMO) unwanted functionality is trivial: The problem is that you said you wanted to implement an option to allow people to turn it off, not to rip this feature completely out of the system. Implementing the option and putting in the necessary UI features so that site and list administrators can choose whether or not to modify the headers in this way is a considerably more complex task than just ripping out a feature you don't like. Give us some suitable code to make this feature optional and controllable by the site admin (and something that can be delegated to the list admin), and you'll have a much better chance of getting someone to pay attention to your request. Otherwise, keep applying the patch to each new version of Mailman as you install it. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7858] trunk/mailman
At 2:25 PM -0400 2006-04-24, Barry Warsaw wrote: That's probably a good idea. Also, I'm wondering if we should allow users to set the log file encoding in Defaults.py, or whether we should force utf-8, or try to interrogate the system for the encoding value. Personally, I think we should default to US-ASCII in the log files, but I can see where some people might want to select a different encoding in mm_cfg.py. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7858] trunk/mailman
At 11:59 PM -0400 2006-04-23, Barry Warsaw wrote: One thing we may have to do though is set the log file encoding. What do you think about that? Log file encoding? I'm not sure I understand what you mean. I can think of a few different ways that could be interpreted, and I don't know for sure that any of them are the meaning you intended to convey. Could you clarify and/or elaborate? -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] XMLRPC interface
At 4:25 PM +0200 2006-03-29, Rafal Krzewski wrote: We (http://caltha.pl) are currently developing a Java-powered WWW application for group collaboration (http://cyklotron2.cyklotron.org). The application includes (among others) discussion forums. There is already a fair amount of information in the FAQ Wizard about integrating Mailman with web forums, and I think there may also be some information there about XMLRPC. Before you get started doing too much work integrating Mailman into your Java environment, have you read all those entries? My question at this point is whether this is the appropriate list to discuss mailman-xmlrpc specific topics, or should these be taken to somewhere else perhaps a dedicated list should be created at http://savannah.nongnu.org/mail/?group=mailman-xmlrpc ? This list is where the core Mailman developers will be watching the various development related discussions, and I know that some of them are very interested in the XMLRPC stuff. I would suggest keeping these discussions on this list until you are recommended to move them somewhere else by one of the core developers (e.g., someone like Barry, Tokio, Mark, etc...). -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Virtual Domains Redux (w proposal)
At 9:04 PM -0500 2006-03-09, Bob Puff wrote: I think we're drifting here from a logical format. If there is to be shared ownership, I think that needs to be done with a different database. It could be a nightmare from the admin side if you group things by who wants to own what lists, rather than by domain. Actually, his proposed scheme does make sense for a larger-scale environment. Indeed, that's the second-most scalable way I know of to do it. The most scalable would have some sort of side index system and use good hashing algorithms to avoid having a billion subdirectories under /usr/local/mailman/lists/com/ and maybe just a few hundred under /usr/local/mailman/lists/info/. For smaller environments, you might want a different option. I think what we really need is some way to guarantee that any of several different suitable formats could be used, some of which might be more easily understood at a glance, others which might be more complex but also more scalable. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Virtual Domains Redux (w proposal)
At 2:23 PM +0100 2006-03-03, Hans Ulrich Niedermann wrote: Our goal is to give this branch to the Mailman project if they want it. If they do not for any reason, we'll have to maintain our vhost branch until Mailman 3 with all the necessary features has been released. :) If you upload the code to the SourceForge patches page for Mailman, the core developers will be much more likely to look at what you've got and to consider it for inclusion in a future version. The key people you've got to convince are Tokio and Mark -- Barry is primarily working on his real job, and doing what he can for Mailman3 in his non-existent spare time, although he does try to at least keep abreast of what is going on with Mailman 2.x. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Feature Request: message_id as replaceable token for footers etc.
At 12:01 AM -0800 2006-01-17, J C Lawrence wrote: Long time no talk. Whaddya think of adding message_id as a replaceable token for footers and the like? This would allow footers to be constructed which direct URL-reference their own post in an NNTP archive. I like the concept, but the only problem is that message-ids are not guaranteed unique. I'd like to see a guaranteed unique id be generated on the system, and then have that used as the new message-id, displayable in the footers, used as the index reference in the mailing list archives, etc I've been agitating for this one for a while. ;) -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Inactivity deletion of maillist users ?
At 4:13 AM +0100 2006-01-13, Erling Hellenas wrote: This is just an idea for an addition I think would be useful. I think that normally if you create some piece of information with a computer you should also see to that it is taken away when it is no longer needed. In some cases, that may be appropriate. However, it is totally inappropriate to assume that this is correct in all cases. As I see it everything will get much easier if you have only the active users in your databases, instead of having many times that amount of inactive people who don't even read the mails. For most mailing lists, 99.% of the subscribership is silent -- they read, but they never post. In fact, many mailing lists are announcement-only -- subscribers are not allowed to post, even if they want to. On lists where subscribers are allowed to post, if you then force them to periodically respond to an automated query, you will find that many of them decide it's not worth the hassle and they will go somewhere else. You obviously feel that this feature is desirable for your purposes, and therefore you want the Mailman developers to add this functionality. The problem is that Mailman is an open source project and the developers do not have the time to implement even a small fraction of the features they consider to be useful, much less the features that might benefit only a tiny fraction of the community. Mailman is an open-source project. If you want to add code to the system to provide such a feature, or arrange for someone else to do that for you, then you would be welcome to have that code uploaded to the appropriate page on the SourceForge web site and the Mailman developers would consider whether or not to use that code (or create their own code) to add that feature at some point in time in the future. Otherwise, I wouldn't hold your breath. I certainly doubt that anyone is going to give this idea any strong consideration so long as we're still talking about Mailman 2.x and Python pickles for list data and meta-data storage -- the additional data storage and operational performance costs would be too great for far too many lists. Maybe once we get into Mailman 3 (a.k.a., MM3) and having a real back-end database, something like this might be somewhat more feasible -- although I doubt it would be any more attractive or broadly useful to the whole community. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] preferred documentation format, sources for documentation in admin/www
At 4:57 PM +0100 2006-01-04, Joost van Baal wrote: I'd like to document my patch for making Mailman OpenPGP and S/MIME aware ( http://non-gnu.uvt.nl/pub/mailman/ ). Ideally, the patch and documentation should be uploaded to the SourceForge tracker. That way Tokio, Mark, and Barry can look over it and try to get that incorporated into the baseline code. I'd like this documentation to integrate nicely with the official Mailman documenation. What is the preferred format for creating documentation? As for the preferred documentation format, I'll let someone who knows more about that subject provide an answer for you. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 5:32 PM +0900 2006-01-03, Stephen J. Turnbull wrote: 1. All the ban-author options should go, they take up _way_ too much space. In all the lists I've ever subscribed to, I've only seen one case where they would have been appropriate, and that guy quickly learned not only how to change from, sender, and envelope, but also his IP addresses. I've never seen a case on XEmacs lists (ie, in long but limited-scope experience as a moderator). I find that I use those functions pretty frequently on the various lists that I help administer at ntp.isc.org. I don't think I've used them yet in helping to moderate lists at python.org, however. There are lists where identifiable senders _are_ a problem, so this should be optional. I think everybody has a spam problem, though---I'd vote for the spam-oriented layout as the default. I could support that view. For myself, I would turn those options back on, but that would be more of a personal thing. For me, the problem is not one of screen space. The problem is one of server performance. I can hit page down pretty frequently and get through a list of messages reasonably fast. But when I've got a thousand messages queued up for moderation, my entire machine grinds to a halt as it tries to render that page -- very, very, very, very, very slowly. This is why I want those command-line server-side tools. 2. I would sort/group on (prefix-scrubbed) subject rather than sender; Agreed. 3. Where possible, the information _and the controls_ for a single entry should be on a single line. I think it's reasonable to assume as a default that the moderator has at least a 1024px width screen Now there, I disagree. My machine is a few years old, but there are still plenty of laptops being built and shipped today that have relatively small screens, and laptops are quickly becoming the default computer instead of desktops. Morever, we can't know the typeface/font size choices that the moderator has made in their web browser, so what may fit on your one line may wind up being effectively three poorly formatted lines for someone who is visually impaired. The Defer/Approve/Reject/Discard options can be enormously compressed by getting rid of the tags. Based on my other disagreements above, I think it's pretty obvious that anything built on top of those premises would get further and further into the bad idea category. 4. It would be very nice if it could be arranged that each column was of a fixed width but with a horizontal scrollbar every twenty rows or so. IMO, this violates the concept of getting everything onto one line, so that you can compress things as much as physically possible. Either go with an idea or don't, but don't go with an idea and then muck it up at the last moment. From everything you've said, I think you would like Skip's mmfold.py script. I think you should check it out. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 11:38 PM +0900 2006-01-03, Stephen J. Turnbull wrote: My reason for proposing that as default, though, is that if somebody requires bigger fonts or smaller screen, then really, shouldn't somebody with good eyes or equipment volunteer for that burden? I don't think you can make that assumption. Many people are just barely getting by on their own, and we've even got a lot of hosting sites running Plesk or crap like cPanel or MacOS X Server, or with heavily customized normal Mailman configurations, and yet they get absolutely no site administrator support at all. Any default change like this would have to be something that a list moderator could configure for themselves, without any intervention on the part of the list administrator, and especially without any intervention on the part of the site administrator. But I would expect that those with even mild impairment would self-select out of that job on average. When you're in a ghetto and no way out, when the power gas company starts sending you invoices that are not intelligible and your heating bill goes up by a factor of ten in a single month, what do you think people are going to do? BradFrom everything you've said, I think you would like Brad Skip's mmfold.py script. I think you should check it out. I already do like it. Most of the moderators I know don't have the necessary shell access, though. All you need is shell access somewhere. It does everything over HTTP, so it doesn't have to be run on the server where the list is hosted. That should make the job a lot easier, albeit still not as simple as pointing their existing favourite web browser at the appropriate admindb page. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 12:07 PM -0500 2006-01-03, Barry Warsaw wrote: I'm actually thinking we need /less/ magic in command line scripts, especially for typical user and admin tasks, because I think increasingly, fewer people have access to the command line (or know what to do with it when they've got it). The command-line scripts are not for your average joe-user sites. The command-line scripts are for people like me, Chuq, Skip, and anyone else who operates or may want to operate a larger site, and has not written such a tool for themselves -- at least, not yet. That is, unless you can build an admin interface that can deal with hundreds of thousands of queued messages without killing both the server and the client. I'm keen on the idea of making Mailman access available via xmlrpc or somesuch, and then we can provide scripts that can be run on the client w/o requiring a browser. I'm not opposed to that, but I'd want to make sure those kinds of tools could also be run on the server where the list is hosted. IMAP would probably be an improvement over what we have now, assuming you've got a decent IMAP client -- that's not necessarily a valid assumption. But my experience is that IMAP falls down too (especially depending on the IMAP server implementation), and you need something even scalable when that happens. True. (Aside: why do all mail clients suck so much? :) All mail servers suck, too. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 12:21 PM +0900 2006-01-03, Stephen J. Turnbull wrote: Our lists don't have a topicality problem, so I don't think I've ever had need to open a post. The summary subject invariably shows spam vs. ham. I can't speak for Barry or anyone else, but when I use Mailman to handle mailing lists for webmaster, postmaster, etc..., there is a 99% chance that any one particular message is spam, and I have to take a look at the remaining 1% to see if they've managed to forge a plausible subject line on something that we would rather not be allowed through to the list. Since one known tactic of spammers is to take list archives and slice off message bodies and replace them with their own, I think that this is a necessary step -- for me, on the mailing lists I help manage, the way I help to manage them. My only problem with the current interface form is that the form is a little too big to be conveniently used in a format of 3 columns of 6 rows of frames. Which I think is part of why Skip created mmfold.py. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 3:48 AM -0500 2006-01-01, Robby Griffin wrote: Here's what I've done for somewhat unrelated reasons: - patch bin/discard to support rejecting held messages and providing rejection comments. - add a cron job that rejects held messages older than 10 days, with the following comment: Your message was automatically rejected after being on hold too long without moderator action. I like both of these modifications. Have you already submitted patches for them to SourceForge? If not, could I talk you into doing that? I'd certainly like to apply these modifications to the other site I help administer, and I'd like to talk to Barry about incorporating these features on python.org. If I had this to do over, I would probably say the timeout and action (discard, reject with configurable comment, approve) for expiring held messages ought to be configurable sitewide and/or per-list rather than hardwired in a cron job. Agreed. But I would think that this would be a relatively minor enhancement over the original modification. I would also want to consider the relationship of any such configuration with mm_cfg.PENDING_REQUEST_LIFE. It appears that some subscription requests and confirmation cookies for held posts may already expire on their own schedule, and that the rationale for this might inform the design of held message expiration. That's also a good idea. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 12:15 PM -0500 2006-01-01, R. Bernstein wrote: ***If I have this correct, where GNU mailman seems to differ from say sourceforge bug and feature trackers is that in GNU Mailman where there is a password associated with a moderator and an administrator *account*, in sourceforge tracker, there is a moderator or administrator *flag* is associated with a account(s) to grant access. So to moderate or administer an account one uses one's selected user account and password. As a result, is easier to effect such an enforcement described above. The current version of Mailman does not really properly support a database, which I think would be required for the kind of features you're talking about. Yes, there are at least one or two database MemberAdaptors of one sort or another, but all they do is take the existing Mailman method of working and adapt that to be compatible with databases, whereas for the kinds of features you're talking about, the reverse would really be required. The next major version of Mailman (Mailman3) will be much more database-aware, and this would be an excellent idea to get onto their plate now. Again at the risk of beating this horse dead, what we're looking for is a way for mailing lists to distribute the burden of moderation such as by having the mailing list be more self moderating as it appears that the wiki works. (I could be wrong here about the wiki.) Check the recent news about WikiPedia. The lesson is that any project which grows sufficiently large, will have such issues if they are permissive in terms of what they allow their rank-and-file subscribers to do. I certainly occasionally hear about similar problems with the MoinMoin wiki on python.org, and it's not anywhere near as large as WikiPedia. On another site I help administer, we take a more restrictive approach with TWiki -- accounts are free and automatically given, but you at least have to sign up for an account before you are allowed to modify anything, and certain pages are locked down as to which administrative groups are allowed to modify them -- and I haven't heard of any such issues there. On the other hand, we're also much smaller than the MoinMoin wiki on python.org, so it's hard to say what is a result of our tighter security measures and what is a result of our being a lot smaller. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
At 6:56 PM -0800 2005-12-31, JC Dill wrote: That's a very interesting and accurate observation. In fact, the moderated post that started this thread is one that I don't think I would have approved for posting to this list! I felt mildly (but not strongly) that this was a discussion that should probably take place on -users first, because it's a discussion about the possibility of changing the way the mailman list is used (by it's users) rather than a discussion about developing a new feature, per se. But, it's not totally off-topic for -dev so Brad is also correct for approving it. Okay, now that is truly weird. I thought it was kind of off-topic myself, but I thought that it would be one that either you or Barry would have approved of, so I approved it on that basis. I guess that just goes to show that you shouldn't over-think the process too much. ;) The main problem I think Rocky is experiencing is the problem of absent moderators, period. Rather than some automated method of turning the moderator tasks over to others, I suggest that a better way is to more closely oversee pending moderator tasks so that the list owner and the list server administrator receive notices when a moderator's queue has not been recently attended to, and address the lack of moderation while the queue is still small and relatively fresh. We're certainly seeing some issues of absentee moderators on some of the lists at python.org, where my new version of the mmdsr script (see http://mail.python.org/pipermail/mailman-users/2005-December/048362.html) is showing that some lists have as many as 100 messages waiting in the queue to be moderated, and some of those messages date back to May of 2005. I think that this is a problem that needs to be addressed within the Mailman package, and not just something that can be observed externally through tools like mmdsr. However, I am not yet sure what would be the best way to resolve this issue. I would like to see more discussion on that topic, although I'm not sure that mailman-developers is the best place to do that. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
At 6:26 PM -0500 2005-12-14, Barry Warsaw wrote: While in general I think the mailing list is a lousy place to do spam removal (it is better done upstream of the MLM), I do think we could add some useful controls to help here. I can certainly see the advantage in allowing Mailman to take advantage of additional information placed within the headers of the message by the anti-spam processing system (improved in 2.1.6 over previous versions). And I can see the usefulness of having a discard and report as spam option for list owners and moderators, as mentioned by Dale -- basically, just forward the message to a pre-configured e-mail address. However, I would seriously question the usefulness of trying to integrate a full-blown anti-spam system into Mailman (e.g., SpamBayes). IMO, that kind of thing needs to be integrated into the MTA, not Mailman. My bigger concern here is that people understand who sees this discard as spam button, and how it works. This is not something that would be exposed or otherwise available to the regular mailing list recipients, and I believe that it will be important to manage user expectations in this respect. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
At 2:33 PM +0200 2005-12-13, Rui Correia wrote: I've just been cleaning up a list that I administer and suddenly it came to me that we could have a report Scam/Spam button for such items being sent to Mailman lists. Where would this button exist? Who would use it, and how? Where I see the biggest advantage of this is that individual mail users are not going to / seldom do go to the trouble of reporting because it is too much trouble. Do be able to do so at the click of a button, would exponentially increase the number of senders being reported. Mailman does not provide the end-user MUA functionality. It is not possible for Mailman to pop up a button in Exchange saying Report this message as spam?, nor is it possible to support all MUAs in this manner. You could add a new List- header which would allow compliant MUAs to give users a single button to click on, but there are currently no MUAs that would support such a feature. Moreover, to whom would they report the message as spam -- the mail servers operated by their own providers, or the mail server(s) operated by the mailing list host? How do you prevent abuse of such a button by an attacker? There are a lot of questions you'd have to answer before you could come up with a reasonable scheme for creating a new List- header that would perform the desired function while avoiding the creation of any new major weaknesses. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
At 7:38 PM -0600 2005-12-13, Brad Knowles wrote: At 2:33 PM +0200 2005-12-13, Rui Correia wrote: I've just been cleaning up a list that I administer and suddenly it came to me that we could have a report Scam/Spam button for such items being sent to Mailman lists. Where would this button exist? Who would use it, and how? BTW, this thread is operational in nature, and doesn't really belong on this list. If you wanted to discuss Python code that you've written to help implement such features, then this would be the appropriate place to continue this discussion. Otherwise, this thread should be re-started on mailman-users. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
At 11:11 PM -0500 2005-12-13, Dale Newfield wrote: Not only is this suggestion appropriate for this list, but I also think I recall a previous discussion where the idea was hashed out. Unless you're talking about Python code you've developed to implement this feature, or commenting on Python code that someone else has developed to implement this feature, I'm pretty certain that this discussion belongs on mailman-users and not here. When we get down to the point where we're talking about going to the archives of the list to see the previous discussion on this topic, and to see the patch that was produced, etc... then we are definitely into mailman-users territory and not mailman-developers. If Barry or JC disagree, then I'm willing to bow to their greater knowledge on this topic, since they've been moderators of this list longer than I have. If Tokio or Mark disagree, I'm willing to bow to their greater knowledge because I know they've been hacking on the code longer than I've been associated with the project. Anyone else is going to have to work pretty hard to convince me. -- Brad Knowles [EMAIL PROTECTED] Python.org Postmaster Team ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
