Mailman-Developers June 2004

mailman-developers@python.org

21 participants
28 discussions

Re: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html

by J C Lawrence

On Fri, 18 Jun 2004 20:38:42 -0300 Christian Robottom Reis <kiko(a)async.com.br> wrote: > Just a heads-up for bug 930819, which has a patch (two now) that adds > onload form focus to the password entry in admlogin.html, a usability > improvement for people using graphical browsers and maintaining many > lists. +1 -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

16 years, 10 months

Jira text field

by Bev Scott

Does anyone know how to make a text field in mailman read only or how to just display the information in the field. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott(a)pps.k12.or.us _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bscott%40pps.k12.…

16 years, 11 months

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values

by J C Lawrence

On Wed, 30 Jun 2004 09:04:14 -0700 somuchfun <somuchfun(a)atlantismail.com> wrote: > The issue is not whether it was obvious or not, the issue is that this > new feature cannot even be turned off, just changed to a different > format. Since there are many configurations out there that might not > work with VERP I find introducing a feature that is on by default and > that cannot be turned off causing more harm than doing good. Without disagreeing with your point: At some point Mailman ends up in the position of pushing technical standard adoption (such as the RFC 2369 List-* headers). No matter when the adoption decision is made someone will be unhappy. Plus addressing is not even close to new. I'm aware of no production MTAs that don't support plus-addressing. At what point should Mailman simply assume technical capability on the part of installation sites? Mailman already currently assumes a number of non-default things about the execution space, why not plus-addressing as well? When is the right time? Remember: You don't have to upgrade. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

16 years, 11 months

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values

by J C Lawrence

On Thu, 24 Jun 2004 03:44:32 -0700 somuchfun <somuchfun(a)atlantismail.com> wrote: > This new VERP probe is ridiculous. One of my customer on a cpanel > system had thousands of unsubscribes because of it. Why? Cpanel does > not support in its current default exim setting VERP and there was no > need for it because it is not on by default in mailman. Now out of the > blue it is used even though VERP is turned off in mm_mfg.py And since > this mailman VERP probe is unforgiving it unsubscribes right away! > Not a good thing at all and the complaints from customers are coming > in big time........ So you deployed a new software into production without first making there were no negative impacts? Nice QC there. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

16 years, 11 months

Jira text field

by Bev Scott

Does anyone know how to make a text field in Jira read only or how to just display the information in the field. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott(a)pps.k12.or.us

16 years, 11 months

Transferring lists

by Joel Ebel

I'm in the process of transferring lists to a new server. The old server runs mailman 2.1.4, and the new one runs 2.1.5. I copied over the lists directory and the archives directory, and I ran update -f to update the lists. It seems to be working except for the fact that now the lists don't show up on the main listinfo page. Before they were listed publicly. How can I get this back? And is there anything else I'm missing in this process of moving lists? Thanks, Joel Ebel

16 years, 11 months

multipart/alternatives and Archive Scrubber behaviour

by Steve Lay

MM 2.1.5 After complaints from some list members about the text of their messages going missing when viewed in the archives I've noticed some slightly undesirable behaviour in the scrubber module. The problem concerns people who regularly send multipart/alternative messages containing text/plain and text/html parts. The scrubbing policy for the site is correctly implemented for these people until the user decides to send an attachment. At that point the message becomes a multipart/mixed message containing two a multipart/alternative and some other attachment, typically application/msword or some such. The scrubber uses the "walk" method of an email message to find and scrub those hard-to-shift HTML stains but when the archiver page is generated in the second pass the scrubber uses the get_payload method instead. As a result, the scrubber never descends into the nested multipart/alternative part and doesn't display either the text of the message or a link to the HTML attachment (your results will vary depending on your site policy for the archiver). Is this a bug or is there a real reason why get_payload is used for the second stage of the scrubber process? Steve Lay

16 years, 12 months

Mailman throwing lost-datafile errors with every message

by foobar＠eh.net

Jun 24 15:49:39 2004 (353) lost data files for filebase: 1088100914.7161551+9a9200d2cba7be877a02453e1f812069b0c78761 <rinse and repeat about once a second> Mailman 2.1.2 (I'll upgrade if you INSIST...) Python 2.2 SunOS eh.net 5.7 Generic_106541-24 sun4u sparc SUNW,Ultra-5_10 I've been getting this line thrown in my error logfile frequently. Additionally, mailman has about 1200 files open when the (aging) computer locks up after taking quite a bit of abuse (it tends to end up with the CPU at 100% iowait, out of swap, with more processes running than is healthy. (The machine only has 256 megabytes of RAM-- and the replacement server was initially due to arrive over a month ago, but Hewlett-Packard has delayed that date to about a month from now). I've seen this question asked before somewhere in the archives ( http://www.mail-archive.com/mailman-developers@python.org/msg06528.html ) but the (very limited) answer does not seem to have helped.

16 years, 12 months

[Greg Stark <gsstark@mit.edu>] Re: Bounce removal parameters default values

by Greg Stark

So the problem I described last January and again mentioned last September is still happening to me, and now to a lot more people. It will only become more and more prevalent as viruses become more common and sites that filter them become more common. Perhaps I should restate the problem more simply. Mailman is committing the basic sin of network security -- receiving data from the network and trusting it for purposes other than as opaque data. It is using messages posted to the list -- the content and format of which it does not control -- to detect bouncing email addresses. Because of this it cannot tell if the bounces it's receiving are caused by a broken email address or caused by some particularity of the posted message. Virus scans are only one type of bounce that could cause someone to be unsubscribed spuriously. For example, most mail servers have a maximum message size for example. Consider the security implications: all I have to do to mass unsubscribe many people--even everyone--on a list is send a message over 50k. Everyone using old versions of sendmail will be unsubscribed. A larger message will unsubscribe anyone using most modern MTAs. Nor do the tests that require multiple bounces protect anything; I just have to send my attack a few times quickly. Really Mailman should simply not trust outside data for any purpose. It should treat the bounces received from mailing list messages purely as hints. It should then send its *own* message with content not subject to any control from outside to the user. Only if that known inoffensive message bounces should it consider removing the user. This is really a DOS security issue, though the worst case attack is unsubscribing many users of a list. That it gets triggered normally even when not specifically under attack only makes the problem apparent. -- greg

16 years, 12 months

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounce removal parameters default values

by J C Lawrence

On Thu, 24 Jun 2004 00:46:09 +0200 Brad Knowles <brad.knowles(a)skynet.be> wrote: > At 10:22 AM -0400 2004-06-19, J C Lawrence wrote: >> Does 2.1.5 formally require plus addressing support in the MTA? > That's only required if you let the MTA generate the VERP. Not quite. It minimally requires plus addressing to be enabled in the MTA (assuming it supports it). >> I thought that was still optional if you didn't use any of the >> VERPish supports. > If the client generates the VERP, the MTA should pass that through > unchanged. At that point, a string-up-to-@ should be a > string-up-to-@. Right, modulo the plus address extension removal. > I've used this on installations I've done, and I have not done > anything special with the MTAs to configure them for VERP > support. What they provided out-of-the-box has worked just fine. I'm not familiar with the various common MTAs current OTB configuration. When last I checked (year+ ago) most didn't enable plus addressing support by default. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

16 years, 12 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers June 2004