Mailman 3 July 2004 - Mailman-Developers

RE: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re:Bounceremoval parameters default values
by Brad Knowles 02 Jul '04

02 Jul '04

At 10:21 AM -0700 2004-07-02, Somuchfun wrote: > This is not the point here, J.C. > The important point is the fact that mailman did introduce a new way of > handling bounces without a way to opt-out of this new way. Sure. Just don't upgrade. > Normally every > software package that introduces a new way of doing a certain task (opposed > to a complete new functionality) there is an option to opt-out and continue > "the old way" until all proper changes have been done. Certainly not every package does this. Some do, some don't. If you want to run the latest version of many packages, you might have to upgrade your OS and/or hardware to do that. Even if they aren't issuing patches/fixes for the old version, you have to decide if it's worthwhile to upgrade those other things, in order to get the thing you want. This is called "life". > Take cPanel for example, they have still not gotten around to make the > proper adjustments to their highly complex environment and they are used > hundreds of thousands of times around the world by web hosting companies. > Right now people are unsubscribed because of this all over the place for no > apparent reason (from the view of the user). The only way to not end up in > trouble in this environment is to turn off bounce handling completely in > mailman 2.1.5 Anyone using CPanel with Mailman needs to get their support from CPanel. If they installed a new version of Mailman without getting that from the CPanel folks, and getting it suitably modified to fit their method of working, then they've shot themselves in the foot and they have only themselves to blame. Or do you blame BMW when you swap the engine in your car for the latest and greatest from Mercedes, only to find that things don't work the way you wanted? > So looking at this, do you still think it was wise to introduce VERP bounce > probes by default and by force with no choice? Let's go over this one last time. Repeat after me -- NO ONE IS FORCING YOU TO UPGRADE!!! -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See <http://www.sage.org/> for more info.

1 0

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values
by J C Lawrence 02 Jul '04

02 Jul '04

On Thu, 01 Jul 2004 17:48:21 -0700 John W Baxter <jwblist(a)olympus.net> wrote: > On 7/1/2004 9:57, "J C Lawrence" <claw(a)kanga.nu> wrote: >> They can of course always gain that same time and more by simply not >> upgrading. > Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 > announcement: > This version also contains a fix for an exploit that could allow 3rd > parties to retrieve member passwords. It is thus highly recommended > that all existing sites upgrade to the latest version. Yup, of such hard choices are upgrades made. Of course Mailman passwords are also not the most significant things in the computing universe. -- 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.

2 1

Jira text field
by Bev Scott 02 Jul '04

02 Jul '04

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.…

2 1

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values
by J C Lawrence 02 Jul '04

02 Jul '04

On Thu, 1 Jul 2004 09:46:47 -0700 somuchfun <somuchfun(a)atlantismail.com> wrote: > J.C., I agree with you that there is never a right time. BUT, when > introducing a new feature (like mailman did with the VERP bounce > probes) it is wise to have the option to turn this feature off > (perhaps until 2.1.6 comes out) to give people time to adjust their > settings and systems. They can of course always gain that same time and more by simply not upgrading. -- 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.

2 1

Re: [Mailman-Users] pl translation fix
by Brad Knowles 01 Jul '04

01 Jul '04

At 12:08 PM +0200 2004-07-01, Pawe½ Go½aszewski wrote: > This is small pl translation fix. Without that message from moderator was > ugly and causes line break in some MUA. See <http://www.list.org/i18n.html> and the language champions for Polish. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See <http://www.sage.org/> for more info.

1 0

Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values
by J C Lawrence 01 Jul '04

01 Jul '04

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.

2 1