[PATCH] for the notorious Sender header
Hi folks,
every now and then the Sender header added by Mailman is discussed on this
list. Patches float through the net. The old FAQ is gone but for some
reason I remember that it was point 2.3. Guess I read it too often.
Because every now and then I get bitten by the header breaking somebody's
beloved Outlook. Well, breaking as in "Hey, I got this mail inline
forwarded from a list and don't have the original sender's address because
all Outlook adds is 'From: Full Name (on behalf of list-
owner@example.com'". Today I got pissed enough to actually tackle the
issue.
Instead of the old just-get-rid-of-it patches arriving here, I implemented
yet another option on the General page, just below the RFC 2369 options.
It defaults to On to keep backwards compatibility.
You can find the patch against the 2.1 codebase in this [1] branch. It also applies with a little fuzz against 2.2.
The patch is quite simple but I'm not an expert of the codebase and couldn't really test it because I currently don't have the time to set up a local mailman. But the test suite doesn't throw any errors... well, it does throw a bunch of errors and fails but did this already before I applied my patch.
I guess it shouldn't be too hard to whip up a patch for 3.0 as well. I just wanted to make sure (and start the old discussion again :) if it should default to On or Off. If I interpret this [2] post from 2006 it isn't really needed. (Hm, almost forgot: I took some of the comments from James Ralston's patch from 2006 and added it to mine.)
Cheers, Malte
[1]https://code.launchpad.net/~mss/mailman/2.1-sender-header [2]http://mail.python.org/pipermail/mailman-developers/2006- July/019040.html
On Jun 29, 2010, at 10:49 PM, Malte S. Stretz wrote:
I guess it shouldn't be too hard to whip up a patch for 3.0 as well. I just wanted to make sure (and start the old discussion again :) if it should default to On or Off. If I interpret this [2] post from 2006 it isn't really needed. (Hm, almost forgot: I took some of the comments from James Ralston's patch from 2006 and added it to mine.)
It may just be time to ditch the Sender rewriting in Mailman 3. I don't think a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce processing right with modern MTAs no longer requires it.
-Barry
On 6/29/2010 6:15 PM, Barry Warsaw wrote:
It may just be time to ditch the Sender rewriting in Mailman 3. I don't think a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce processing right with modern MTAs no longer requires it.
+1
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Jun 29, 2010, at 06:19 PM, Mark Sapiro wrote:
On 6/29/2010 6:15 PM, Barry Warsaw wrote:
It may just be time to ditch the Sender rewriting in Mailman 3. I don't think a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce processing right with modern MTAs no longer requires it.
+1
Done in r6915. I also removed the setting of the Errors-To header.
-Barry
On Wednesday 30 June 2010 04:15:46 Barry Warsaw wrote:
On Jun 29, 2010, at 06:19 PM, Mark Sapiro wrote:
On 6/29/2010 6:15 PM, Barry Warsaw wrote:
It may just be time to ditch the Sender rewriting in Mailman 3. I don't think a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce processing right with modern MTAs no longer requires it.
+1
Done in r6915. I also removed the setting of the Errors-To header.
Cool. I set the status of bug 266824 to Fix Committed.
Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I have to take care of some mailing lists on a shared server and I doubt that the admin will upgrade to 3.0 any time soon but I might convince him to go for the next 2.1 release once/if it is out and packaged :)
Cheers, Malte
On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote:
Cool. I set the status of bug 266824 to Fix Committed.
Thanks. I've targeted that to 3.0a6.
Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I have to take care of some mailing lists on a shared server and I doubt that the admin will upgrade to 3.0 any time soon but I might convince him to go for the next 2.1 release once/if it is out and packaged :)
It's Mark's decision, but I would be hesitant about applying it to 2.1. It's a new feature and as such shouldn't (IMO) go into a maintenance release. OTOH, I understand that it's the only version practically available to folks.
Maybe you could create a branch on Launchpad. -Barry
On Wednesday 30 June 2010 16:24:07 Barry Warsaw wrote:
On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote:
Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I have to take care of some mailing lists on a shared server and I doubt that the admin will upgrade to 3.0 any time soon but I might convince him to go for the next 2.1 release once/if it is out and packaged :)
It's Mark's decision, but I would be hesitant about applying it to 2.1. It's a new feature and as such shouldn't (IMO) go into a maintenance release. OTOH, I understand that it's the only version practically available to folks.
That I understand. But my patch is more or less a beefed up version of the patches some people use for ages. Not sure if I did something wrong in the GUI integration though.
Maybe you could create a branch on Launchpad.
Here is a branch for 2.1: https://code.launchpad.net/~mss/mailman/2.1-sender-header And here for 2.2: https://code.launchpad.net/~mss/mailman/2.2-sender-header
Not sure how to proceed from here, shall I try a merge proposal?
Thanks, Malte
On Jun 30, 2010, at 04:38 PM, Malte S. Stretz wrote:
On Wednesday 30 June 2010 16:24:07 Barry Warsaw wrote:
On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote:
Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I have to take care of some mailing lists on a shared server and I doubt that the admin will upgrade to 3.0 any time soon but I might convince him to go for the next 2.1 release once/if it is out and packaged :)
It's Mark's decision, but I would be hesitant about applying it to 2.1. It's a new feature and as such shouldn't (IMO) go into a maintenance release. OTOH, I understand that it's the only version practically available to folks.
That I understand. But my patch is more or less a beefed up version of the patches some people use for ages. Not sure if I did something wrong in the GUI integration though.
Maybe you could create a branch on Launchpad.
Here is a branch for 2.1: https://code.launchpad.net/~mss/mailman/2.1-sender-header And here for 2.2: https://code.launchpad.net/~mss/mailman/2.2-sender-header
Not sure how to proceed from here, shall I try a merge proposal?
That would be great. It would allow folks to comment on specifics of the implementation. It would then be up to Mark to decide whether and when to merge it into the 2.1 branch.
-Barry
Malte S. Stretzwrote:
Here is a branch for 2.1: https://code.launchpad.net/~mss/mailman/2.1-sender-header And here for 2.2: https://code.launchpad.net/~mss/mailman/2.2-sender-header
Not sure how to proceed from here, shall I try a merge proposal?
I looked at your patch yesterday. It seems good, but it's missing a critical piece. It has to increment DATA_FILE_VERSION in Mailman/Version.py. Otherwise, the code in Mailman/versions.py to add the include_sender_header attribute to existing lists will not be called. See the CheckVersion() method in Mailman/MailList.py.
I don't have a problem with including the patch in 2.1, except for the Defaults.py.in
ALLOW_SENDER_OVERRIDES = Yes
If it were no, the feature would be entirely transparent to those who didn't want it, essentially preserving the current situation for those who took no action.
The problem with that is all those cPanel and service provider list owners who would then not have access to the feature even if they were aware and wanted it, so I think the default needs to be Yes which is somewhat disruptive, but probably not excessively so considering the potential benefit.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, Jun 30, 2010 at 07:55:38AM -0700, Mark Sapiro wrote:
I don't have a problem with including the patch in 2.1, except for the Defaults.py.in
ALLOW_SENDER_OVERRIDES = Yes
If it were no, the feature would be entirely transparent to those who didn't want it, essentially preserving the current situation for those who took no action.
Tricky, isn't it?
The problem with that is all those cPanel and service provider list owners who would then not have access to the feature even if they were aware and wanted it, so I think the default needs to be Yes which is somewhat disruptive, but probably not excessively so considering the potential benefit.
I'd have thought given their mods anyhow, an extra one -- particularly one with clearly marked emails -- shouldn't be too difficult for them to maintain/include.
-- ``Another sport which wastes unlimited time is Comma-hunting.'' (Francis Cornford, Microcosmographia Academica)
On Wednesday 30 June 2010 16:55:38 Mark Sapiro wrote:
I looked at your patch yesterday. It seems good, but it's missing a critical piece. It has to increment DATA_FILE_VERSION in Mailman/Version.py. Otherwise, the code in Mailman/versions.py to add the include_sender_header attribute to existing lists will not be called. See the CheckVersion() method in Mailman/MailList.py.
Ah, sorry, seems like I was too quick with my merge proposal. Gnn, now I have to grok how to supersede it on lp. I'll go and fix it.
I don't have a problem with including the patch in 2.1, except for the Defaults.py.in
ALLOW_SENDER_OVERRIDES = Yes
If it were no, the feature would be entirely transparent to those who didn't want it, essentially preserving the current situation for those who took no action.
Hmm. The change is still fairly transparent I think, after an upgrade there will just pop up an additional option for the list admins, defaulting to the old value. In the worst case it (theoretically) allows the list admin to shoot himself or his users in the foot. But nothing the superadmin should be worried about (IMHO).
The problem with that is all those cPanel and service provider list owners who would then not have access to the feature even if they were aware and wanted it, so I think the default needs to be Yes which is somewhat disruptive, but probably not excessively so considering the potential benefit.
As I am one of those cPanel users, trying to push this change down my sysadmins throat the long way round, I'm in favor for Yes :)
Cheers, Malte
On Jun 30, 2010, at 05:14 PM, Malte S. Stretz wrote:
Ah, sorry, seems like I was too quick with my merge proposal. Gnn, now I have to grok how to supersede it on lp. I'll go and fix it.
Just push an update to your existing branch. I believe LP will rescan your branch and update the merge proposal appropriately.
I don't have a problem with including the patch in 2.1, except for the Defaults.py.in
ALLOW_SENDER_OVERRIDES = Yes
If it were no, the feature would be entirely transparent to those who didn't want it, essentially preserving the current situation for those who took no action.
Hmm. The change is still fairly transparent I think, after an upgrade there will just pop up an additional option for the list admins, defaulting to the old value. In the worst case it (theoretically) allows the list admin to shoot himself or his users in the foot. But nothing the superadmin should be worried about (IMHO).
If it does get applied to 2.1.x, be sure this new option (both the Defaults.py.in setting and the list admin option it enables) is clearly discussed in the release notes. I wonder if cPanel folks would ever read that and enable it for their own users?
The problem with that is all those cPanel and service provider list owners who would then not have access to the feature even if they were aware and wanted it, so I think the default needs to be Yes which is somewhat disruptive, but probably not excessively so considering the potential benefit.
As I am one of those cPanel users, trying to push this change down my sysadmins throat the long way round, I'm in favor for Yes :)
:) -Barry
participants (4)
-
Adam McGreggor -
Barry Warsaw -
Malte S. Stretz -
Mark Sapiro