> On 2018-03-24, at 18:21, Greg King <greg.king5@verizon.net> wrote: > >> Besides, Reply-to: is exactly useful for this particular reason: I send from an address "a"; but, please don't respond to it; please respond to address "b", which I give you in the extra header. How a "reasonable mailer" may elect to ignore that _by default_ is beyond me. >> P. S. Do you immediately know what "munging" is? Oxford dictionary doesn't. And, I hardly consider setting a well-established header, or not setting it, "munging". > > The Thunderbird community agrees with you. That's why Thunderbird _won't_ ignore that field when it sees your example. It ignores "Reply-to:" only when looking at messages that came through a mailing list (the author, _not_ the list, is the source of the message). If the list changes address "b" into address "c", then it is abuse (dictionaries know that word). If the list changes me being the author into whatever else - it's wrong. If the list changes the Reply-to: header I have set, it might also be considered wrong. When the lists adds a note, telling recipients that the message came through the mailing list, rather than was sent to you by the author directly, it's the list policy to do so, although some may consider it being "munging" the message. If the list - in a similar way - adds also a Reply-To: header, it is also the list policy to do so. But frankly, I don't care how the header came to be set. I don't care whether Reply-To: has been set by the author, by munging or by abuse. Reply-To: is there and it's the mail client's damned duty to obey the rules and do its job rather than try to be smarter than the list owner, the author and the recipient all together. It's not the mail client's job to decide what is good for me, or - especially - for the list owner or other participants. > That field should be "well-established" for individuals, not for mailing lists! What will be next, that this mail client choose to ignore, disobey or bend because some lead dev becomes opinionated? Never mind. I don't use this particular client and that's just one more reason to stay away from it. EOT. -- SD! - http://e4aws.silverdr.com/Received on 2018-03-25 00:00:02
Archive generated by hypermail 2.2.0.