Feature request: Reply-To Munging etc.
Hi,
as many of you probably would agree, whether you munge the Reply-To headers or not, both ways are not perfect. Just today I had a hard time again, as I'm not happy with both options, and finally came up with some ideas how the situation could be improved, about which I would like to read your comments:
Receiver clean-up (if Reply-To munging is NOT used) One of the problems not using Reply-To munging is, that by using the reply-to-all function of MUAs the list of receivers tends to accumulate. As in open lists the users cannot know, if an address is part of the list, they cannot just delete them without risking to drop people from the discussion. So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list?
Add non-member-senders to Reply-To (if Reply-To munging IS used) One of the annoying things using Reply-To munging in open lists is, that you cannot easily include external authors in replies, whether you are using reply-to or reply-to-all in your MUA. It would be nice, if the sender could be added to the Reply-To addresses in the case, that the sender is not a member of the list, so that replies automatically go to the list AND the author. (Of course, this should be done only, if the sender didn't set his own Reply-To header already.)
Add sender to Reply-To (if Reply-To munging IS used) As an variation to the proposal 2) it also would be nice to have the sender in general be added to the Reply-To header. That would make replies behave similar as the reply-to-all in case of no Reply-To munging. This makes it easier to reply only to the author, and not the whole list, by just deleting the list address while replying. Because you can also have address accumulation in that case, if users use the reply-to-all function, you could combine this option with the "receiver clean-up" option from proposal 1).
As proposal 3) doesn't need to know the member status of addresses, you can also easily implement it in the MTA, therefore it is the least important one.
What do you think about that? (With some help I can also try to implement this on my own, if there are chances to include it into the official Mailman.)
Cheers,
Sven
On Mon, 2007-03-05 03:24:33 +0100, Sven Anderson <sven@anderson.de> wrote:
- Receiver clean-up (if Reply-To munging is NOT used) One of the problems not using Reply-To munging is, that by using the reply-to-all function of MUAs the list of receivers tends to accumulate. As in open lists the users cannot know, if an address is part of the list, they cannot just delete them without risking to drop people from the discussion. So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list?
Depending on the system Mailman is installed on, the email going over the list may take waaay longer time than the direrect mail. So the active persons have a chance to rapidly answer, instead of waiting for the list software.
That is, from my point of view, receiver filtering removes functionality :-)
- Add non-member-senders to Reply-To (if Reply-To munging IS used) One of the annoying things using Reply-To munging in open lists is, that you cannot easily include external authors in replies, whether you are using reply-to or reply-to-all in your MUA. It would be nice, if the sender could be added to the Reply-To addresses in the case, that the sender is not a member of the list, so that replies automatically go to the list AND the author. (Of course, this should be done only, if the sender didn't set his own Reply-To header already.)
With persons like me that either do strict to-list-only or group-replys (depending on the actual audience), this would probably end up with Cc'ed non-subscribers getting mails twice? So here we depend on the MUA's intelligence to filter out doubled email addresses.
But maybe I'm just too used to old habits, though :)
MfG, JBG
-- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine)
Sven Anderson writes:
- Receiver clean-up (if Reply-To munging is NOT used) So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list?
IIRC, if the user sets their subscription to "no-dupes", that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to.
Rather than have this be a list-level option, I would say that you should set the default for new subscribers to no-dupes. (This may also require a patch to Mailman for convenient administration.)
- Add non-member-senders to Reply-To (if Reply-To munging IS used) One of the annoying things using Reply-To munging in open lists is, that you cannot easily include external authors in replies, whether you are using reply-to or reply-to-all in your MUA. It would be nice, if the sender could be added to the Reply-To addresses in the case, that the sender is not a member of the list, so that replies automatically go to the list AND the author.
This is simply not enough. You need to add all the non-list addressees, too. That is equivalent to (1).
- Add sender to Reply-To (if Reply-To munging IS used) As an variation to the proposal 2) it also would be nice to have the sender in general be added to the Reply-To header. That would make replies behave similar as the reply-to-all in case of no Reply-To munging.
In other words, you are suggesting that Mailman should munge Reply-To simply because some users don't know where the reply-to-all function is.
I realize that non-technical users are human beings and have their rights, but it's the MUA vendors, not Mailman, who violate those rights by supplying broken software.
If you have a list where the majority of users are so non-technical that they can't find reply-to-all, just munge and don't worry about it.
Stephen J. Turnbull, 06.03.2007 08:25:
Sven Anderson writes:
- Receiver clean-up (if Reply-To munging is NOT used) So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list?
IIRC, if the user sets their subscription to "no-dupes", that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to.
I just checked this to be sure, but only the latter is true. The user's address stays in the To/Cc header.
And anyway, that's not what I want. I want an option so that the addressee list is cleaned up, no matter if the users wants duplicates or not. That's because addressee accumulation is the most heard argument against reply-to-all usage, which again is needed to live without Reply-To munging. I claim, that such an option would be very useful not just for me but for many Mailman administrators, especially for those who don't want to munge the Reply-To header.
- Add non-member-senders to Reply-To (if Reply-To munging IS used) One of the annoying things using Reply-To munging in open lists is, that you cannot easily include external authors in replies, whether you are using reply-to or reply-to-all in your MUA. It would be nice, if the sender could be added to the Reply-To addresses in the case, that the sender is not a member of the list, so that replies automatically go to the list AND the author.
This is simply not enough. You need to add all the non-list addressees, too. That is equivalent to (1).
No, that is not true, as the "reply-to-all" function includes all the addressees already, but the From address is _never_ included, if the Reply-To is set, neither with simple reply nor with reply-to-all. I'm just addressing this problem with my proposal, that - if Reply-To is set - the
From address is not included in _any_ case with a standard conform MUA.
Anyway, I refined my ideas in the meantime, and I will try to write them down in a further email tonight.
Cheers,
Sven
Sven Anderson writes:
IIRC, if the user sets their subscription to "no-dupes", that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to.
I just checked this to be sure, but only the latter is true. The user's address stays in the To/Cc header.
Hm. I know both are true for my lists (Mailman 2.1.5).
And anyway, that's not what I want. I want an option so that the addressee list is cleaned up, no matter if the users wants duplicates or not.
Ah. You don't care what your users want. I can't argue with that.
Stephen J. Turnbull, 07.03.2007 18:30:
Sven Anderson writes:
IIRC, if the user sets their subscription to "no-dupes", that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to.
I just checked this to be sure, but only the latter is true. The user's address stays in the To/Cc header.
Hm. I know both are true for my lists (Mailman 2.1.5).
Mine is 2.1.6.
And anyway, that's not what I want. I want an option so that the addressee list is cleaned up, no matter if the users wants duplicates or not.
Ah. You don't care what your users want. I can't argue with that.
Of course I care, that _is_ what _my_ users want. You have to distinguish between the option if the user wants to receive duplicates (what he/she still can choose) and the proposed list-wide option, if addresses of list members are removed from the To/Cc headers (not from the distibution list though!) If the users chooses to receive duplicates, he still gets them in form of a Bcc.
Cheers,
Sven
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 7, 2007, at 12:30 PM, Stephen J. Turnbull wrote:
Sven Anderson writes:
IIRC, if the user sets their subscription to "no-dupes", that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to.
I just checked this to be sure, but only the latter is true. The
user's address stays in the To/Cc header.Hm. I know both are true for my lists (Mailman 2.1.5).
I think you're both right :). Mailman 2.1 will strip recipients from
the CC header if explicitly named recipients are members of the list
and have nodup set. But Mailman won't strip To headers, nor juggle
CC and To headers after stripping.
It may not be a bad idea to go all the way with this as Sven
suggests, at least when not munging. I do think it will address a
common complaint about no-munge, and one that's harder to write off
as "fix your MUA".
I'm not inclined to spend much brain power or LoC trying to "fix"
reply-to-munging. I think that's a fundamentally broken use case.
Good MUAs do the right thing here and if Sven's idea addresses the
other major complaint then I'd be happy. If I could drop reply-to
munging in the next version altogether, I'd be ecstatic.
Thanks, I've added this to the wiki.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRfAly3EjvBPtnXfVAQJrLwP/Sk9LbmFfG/hDJ5RddGYpGMdi6YMfFpyl 1/zGj2EeqCThziP0cC+zOMkY7QgdDaQkt8zgOQ1jLsv1UVBEOJ1uxm5Y3JZ/KzDi W5ZE1KGIEs/X8vDctSsUPMhYNTa9yUnVEBCjatxJ/S4c2dT311/gYtb9NgmWhoux jfq8Nqd7QSY= =RjoH -----END PGP SIGNATURE-----
Barry Warsaw writes:
I think you're both right :). Mailman 2.1 will strip recipients from
the CC header if explicitly named recipients are members of the list
and have nodup set. But Mailman won't strip To headers, nor juggle
CC and To headers after stripping.
Ah, right. I rarely see multiple addresses in the To header from @AOL though, so this should be sufficient. I have never seen multiple addresses in From (except in the examples section of RFC 822 :-), so that means that at most one will leak per reply.
It may not be a bad idea to go all the way with this as Sven
suggests, at least when not munging. I do think it will address a
common complaint about no-munge, and one that's harder to write off
as "fix your MUA".
I see your point, but why won't my suggestion of defaulting the per user no-dupes to "on" do fine from that point of view?
Thing is, my experience has been that people who care much about their personal setting invariably want it *on* (the ones who care and want it off use procmail anyway; those who can't or won't use procmail chalk it off as Insh'allah). That's neither here nor there, except that they would be very unhappy if the option were administratively removed (and I would be unhappy too, "ben" is "one of *them*", and what if "jwz" or "mly" were? Ouch!)
I think it would be reasonable to remove *all* no-dupes members, and if the addressees end up empty, then put the list address in To: (or does Mailman already force the list to appear explicitly ... I guess not, since that's one of the addressee filters).
Stephen J. Turnbull quoted out of context:
I see your point, but why won't my suggestion of defaulting the per user no-dupes to "on" do fine from that point of view?
For my selfish purposes, "no-dupes" off is a better default setting. Without a copy of the message to their mailbox, many of my users will keep sending the same message because it "didn't go".
Dan MacNeil writes:
Stephen J. Turnbull quoted out of context:
I see your point, but why won't my suggestion of defaulting the per user no-dupes to "on" do fine from that point of view?
For my selfish purposes, "no-dupes" off is a better default setting. Without a copy of the message to their mailbox, many of my users will keep sending the same message because it "didn't go".
Are you thinking of not-metoo?
Dan MacNeil writes:
For my selfish purposes, "no-dupes" off is a better default setting. Without a copy of the message to their mailbox, many of my users will keep sending the same message because it "didn't go".
Stephen J. Turnbull wrote:
Are you thinking of not-metoo?
Err, yes, I am. Sorry for the distraction.
Stephen J. Turnbull wrote:
Dan MacNeil writes:
Stephen J. Turnbull quoted out of context:
I see your point, but why won't my suggestion of defaulting the per user no-dupes to "on" do fine from that point of view?
For my selfish purposes, "no-dupes" off is a better default setting. Without a copy of the message to their mailbox, many of my users will keep sending the same message because it "didn't go".
Are you thinking of not-metoo?
I think Dan must be thinking of not-metoo, but note that even ensuring that not-metoo is off won't do the job for gmail users thanks to gmail's 'feature' of not showing 'duplicate' messages.
BTW, just for the record, the Defaults.py setting for new_member_options for a new list (DEFAULT_NEW_MEMBER_OPTIONS) is no-dupes.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
I think Dan must be thinking of not-metoo, but note that even ensuring that not-metoo is off won't do the job for gmail users thanks to gmail's 'feature' of not showing 'duplicate' messages.
Yeah, but that's irrelevant to use of no-dupes, because gmail is keying off a locally saved copy as I understand it.
Barry Warsaw wrote:
I think you're both right :). Mailman 2.1 will strip recipients from the CC header if explicitly named recipients are members of the list and have nodup set. But Mailman won't strip To headers, nor juggle CC and To headers after stripping.
Is see. But wouldn't it be better, that the stripping is controlled by an list wide option or (if individual mails are generated anyway, for VERP etc.) by the receiving user, and not by the owner of the address? I would separate the address stripping completely from the no-dups option.
It may not be a bad idea to go all the way with this as Sven suggests, at least when not munging. I do think it will address a common complaint about no-munge, and one that's harder to write off as "fix your MUA".
Just make it an "addressee clean-up" option, then the list admin or the receiving user can choose, if he/she wants it or not.
I'm not inclined to spend much brain power or LoC trying to "fix" reply-to-munging. I think that's a fundamentally broken use case. Good MUAs do the right thing here and if Sven's idea addresses the other major complaint then I'd be happy. If I could drop reply-to munging in the next version altogether, I'd be ecstatic.
Well, as I'm using this "broken use case" on almost every list, and me and my users are happy with this (and that's all that counts for me), I clearly vote against dropping it. ;-) I most probably would still use it, even if the proposed addressee clean-up would exist. But at the moment the Mailman reply-to-munging is not fundamentally but specifically broken. ;-)
I will explain my refined proposal in a separate mail.
Cheers,
Sven
participants (6)
-
Barry Warsaw -
Dan MacNeil -
Jan-Benedict Glaw -
Mark Sapiro -
Stephen J. Turnbull -
Sven Anderson