Add option for only munging Reply-To if it is not there

[auvor]

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.

[auvor (auvor-users)]

The file mailman-munging.diff was added: Patch to allow only munging Reply-To: if the user didn't specify one

[msapiro (msapiro-users)]

Logged In: YES
user_id=1123998
Originator: NO

Consider that <email address hidden> configures her MUA to add a Reply-To: <email address hidden> 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 <email address hidden>.

Consider that <email address hidden> sets all his MUAs to generate Reply-To: <email address hidden> 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

[auvor (auvor-users)]

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.

[msapiro (msapiro-users)]

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.

[auvor (auvor-users)]

Logged In: YES
user_id=1137196
Originator: YES

I understand that you do not like header munging. I don't either. However, a lot of people seem to depend on it, and quite a few of them are on my server. Unfortionately, the lists on my server are not only used for general discussion, but also for requests that should be responded to off-list. With my user base, some level of reply-to munging is simply unavoidable, whether I like it or not. I would just like a way to make it less of an obstacle for the remaining parts of the user base.

I understand your objections, and I see that they could cause problems in some scenarios. However, they would not cause problems in my case. I don't believe chit-chat lists of this kind are very unusual, so I believe other people than me also could use this feature. Hence the patch.

I am only proposing an option. It will be off by default. Please consider it.

[msapiro (msapiro-users)]

Logged In: YES
user_id=1123998
Originator: NO

That's the beauty of FOSS. You had a problem and you solved it.

I don't think your solution is of sufficient general applicability to warrant adding yet another configuration option. If others disagree, they are encouraged to comment and perhaps convince me that I'm wrong.