Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values
On Wed, 30 Jun 2004 09:04:14 -0700 somuchfun <somuchfun@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@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
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.
MANA TANGATA
-----Original Message----- From: J C Lawrence [mailto:claw@kanga.nu] Sent: Wednesday, June 30, 2004 4:19 PM To: Somuchfun Cc: 'Brad Knowles'; mailman-developers@python.org Subject: Re: [Mailman-Developers] [Greg Stark <gsstark@mit.edu>] Re: Bounceremoval parameters default values
On Wed, 30 Jun 2004 09:04:14 -0700 somuchfun <somuchfun@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@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
participants (2)
-
J C Lawrence -
Somuchfun