[ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there

Patches item #1906479, was opened at 2008-03-03 11:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 13:55
Message: Logged In: YES user_id=1123998 Originator: NO You miss my point. Perhaps the first paragraph of my prior comment is a configuration error that can be corrected, but your minimizing the consequences seems to me a lot like an argument against reply-to munging. In any case, configuration mistakes aside, there are people who set a meaningful Reply-To: intentionally just because they want replies to go to somewhere other than the From: address. You are asking that these people remember to drop the Reply-To: whenever they make an 'ordinary' post to the list. This seems to me to be exactly discrimination against users who know what they are doing. The fact is that you cannot determine the poster's intent based on the presence or absence of Reply-To: in the incoming post, and trying to do so may 'solve' some problems but will create others. Also, it is my opinion that I, as the poster of a reply, should be the one to determine whether or not my reply goes to the list. Why would I want to give control over (the default for) that decision to the poster of the message to which I'm replying. ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 13:15 Message: Logged In: YES user_id=1137196 Originator: YES Of course, this behaviour will fail in some cases, but at least in my environment such problems are rare and easily solvable. The user will quickly realize that something is wrong, ask the more experienced users what is going on, and be told how to resolve their problem. Removing their Reply-To header is easy, and it is a one-time operation. It also works in all MUAs. Also, having to repost the message because you replied to an erroneously set Reply-To header is a minor annoyance for a single person (the poster), who has to repost the message to the list. In the opposite case, with unconditional Reply-To header munging, every misdirected post is an annoyance to the entire list. It also happens every time someone requests off-list replies, instead of just a single time before the user removes his explicit Reply-To header. If one is concerned about such clients one could for instance start with setting first_strip_reply_to to off, and then enable reply_to_only_set_if_empty after some period of time. During the transitional period the users with malconfigured clients will quickly ask why they suddenly receive two copies of all replies. They will then be told to remove their Reply-To header from their client, and will probably do so. This is a minor annoyance to a single person, the one with a malconfigured client. Believe me, there is nothing I'd rather do than disable the munging completely. However, this would not solve anything, only cause even more e-mails to be sent in the wrong direction. Therefore I'd like a milder form of munging, which doesn't discriminate users who know what they're doing. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 12:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user@example.com configures her MUA to add a Reply-To: user@example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user@example.com. Consider that userb@example.com sets all his MUAs to generate Reply-To: userb@example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103
participants (1)
-
SourceForge.net