| Summary: | "Reply by Guess" prefers List-Post over the Reply-To header | ||
|---|---|---|---|
| Product: | [Applications] trojita | Reporter: | kavol <kavol> |
| Component: | Desktop GUI | Assignee: | Trojita default assignee <trojita-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 0.3.93 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | http://thread.gmane.org/gmane.mail.trojita.general/395 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
kavol
2013-06-06 11:09:25 UTC
This is a matter of preference, I guess. The "Reply by Guess" is intended to do the "reasonable thing"; the logic is roughly "prefer list replies" followed by "reply to everybody but me, if there's more addresses involved", followed by "reply just to the sender, aka private reply". The "private reply" is also a bit of a hack (see prepareReplySenderOnly in src/Composer/Recipients.cpp); it will try to respect the Reply-To when the message had not arrived via a mailing list (check is done through the List-Post header). It looks like "private reply" is what you should have chosen here, and that the heuristic behind "reply by guessing" works more or less as advertised. It could be improved by recognizing that the "Reply-To" points somewhere else than to the ML. I'll bring this up on the mailing list for further discussion. Could you please post all relevant headers (To, Cc, Bcc, From, Sender, Reply-To, List-Post)? Feel free to redact them, but I'd like to have this covered by proper regression tests -- the choice of a proper replying mode is nothing but heuristic after all due to the way how MLs munge the Reply-To in real world. Can you please elaborate on the circumstances?
In general, on-list should stay on-list and if you want to go off-list, that should be an explicit operation, otherwise the topic ends in various open threads because ppl. blindly clicked/shortcutted "reply" (what happens too often anyway) - agreed?
So the question is, who actually controls the reply-to here.
Looking at some lists mail headers, the reply-to is equal to list-post, so i assume usually the list dispatcher sets that.
-> Who set that in your case and why?
The list trying to get a topic away or the user?
Otherwise, if your (any) list just lets the users reply-to pass, honouring the (users global?) reply-to would contradict the made premise, ie. if a user just sets a general reply-to ("please reply to A, even if it came from B") or his mailer always sets reply-to, he'd trap list fellows into off-listing threads.
(In reply to comment #1) > This is a matter of preference, I guess. no big problem with that, as long as "reply to reply-to" is an easily accessible option - but I don't see it anywhere in the menu > The "Reply by Guess" is intended to do the "reasonable thing"; the logic is > roughly "prefer list replies" followed by "reply to everybody but me, if there's > more addresses involved", followed by "reply just to the sender, aka private > reply". see above - the logic completely omits "Reply-To" header, which I'd see as the most preferable option ... from RFC5322: When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. ... and I see no point in "guessing" that replying anywhere else than where the poster specified is better idea (OTOH, I agree that if something comes through a list, it is better to reply to list by default rather than to use "from" as suggested by the "SHOULD" part) > The "private reply" is also a bit of a hack (see prepareReplySenderOnly in > src/Composer/Recipients.cpp); it will try to respect the Reply-To when the > message had not arrived via a mailing list (check is done through the > List-Post header). > > It looks like "private reply" is what you should have chosen here, I see another problem here, if "private reply" does not allow to choose between "from" and "reply-to" there may be a good reason for the poster to set "reply-to" different from "from" (I'd refer to the explanation in section 4.4.3 of the now obsoleted RFC822) but there may also be a good reason to override it manually and reply to from address (e.g. when not agreeing with the selection of person made responsible for the reply) > and that the heuristic behind "reply by guessing" works more or less as > advertised. well, the code is probably okay but the logic doesn't correspond with what I'd expect with regards to the abovementioned RFC text > It could be improved by recognizing that the "Reply-To" points somewhere > else than to the ML. I'll bring this up on the mailing list for further > discussion. isn't this a bit too complicated? - what's expected from the comparison? > Could you please post all relevant headers (To, Cc, Bcc, From, Sender, > Reply-To, List-Post)? Feel free to redact them, but I'd like to have this > covered by proper regression tests -- the choice of a proper replying mode > is nothing but heuristic after all due to the way how MLs munge the Reply-To > in real world. Return-Path: this-mailinglist-bounces@example.com From: Some Guy <the-guys-address@example.com> To: this-mailinglist@example.com X-loop: this-mailinglist@example.com X-BeenThere: this-mailinglist@example.com Reply-To: the-guys-address@example.com List-Post: <mailto:this-mailinglist@example.com> Sender: this-mailinglist-bounces@example.com Errors-To: this-mailinglist-bounces@example.com (In reply to comment #2) > Can you please elaborate on the circumstances? see above > In general, on-list should stay on-list and if you want to go off-list, that > should be an explicit operation, otherwise the topic ends in various open > threads because ppl. blindly clicked/shortcutted "reply" (what happens too > often anyway) - agreed? yes, except that with this default behaviour we're seeing the opposite - replies on the list that were meant private which is sometimes just a bit embarassing and sometimes really dangerous > -> Who set that in your case and why? > The list trying to get a topic away or the user? see above, the user > Otherwise, if your (any) list just lets the users reply-to pass, honouring > the (users global?) reply-to would contradict the made premise, ie. if a > user just sets a general reply-to ("please reply to A, even if it came from > B") or his mailer always sets reply-to, he'd trap list fellows into > off-listing threads. okay, maybe I'm just not used to people setting general reply-to instead of using this feature only when they really want the reply to go to some nondefault address maybe some less AI would be better, like a box "This came through a list but reply-to does not match the list address. This is too ambiguous for my little mind, please help me guess. Would you like to reply to list (hit ctrl+l next time) or to <the-reply-to-address> (hit [this function is missing ATM] next time)?" :-) > no big problem with that, as long as "reply to reply-to" is an easily > accessible option - but I don't see it anywhere in the menu That's because the "private reply" is supposed to fill its role. It works well under most circumstances, but sometimes it fails (see the gentoo-dev-announce message later on). > see above - the logic completely omits "Reply-To" header, which > I'd see as the most preferable option ... from RFC5322: It doesn't omit that header. At first, the list of addresses within that header is filtered so that ML software Reply-To munging is undone, if possible. After that, if anything usable remains within Reply-To, *that* becomes the list of addresses to reply to. Only if nothing remains, the From header is used. But this logic is explicitly *not* triggered when Ctrl-R-ing to a ML message. You have to pick Ctrl-Shift-A here. > ... and I see no point in "guessing" that replying anywhere > else than where the poster specified is better idea It's complicated. Consider the following message: From: someone@gentoo.org Reply-To: Gentoo Development <gentoo-dev@lists.gentoo.org> List-Post: <mailto:gentoo-dev-announce@lists.gentoo.org> To: gentoo-dev-announce@lists.gentoo.org This is from an announcement-only list. I'm not sure who sets Reply-To in there, whether it's up to the developer writing the mail or whether it's done by the ML software. Trojita will currently do the wrong thing and reply to gentoo-dev-announce on "reply by guess" or "reply to list" and to the gentoo-dev ML (!) when selecting the "private reply". I'd argue that "reply to list" is doing the right thing and that the ML's configuration is slightly broken here, that "reply by guess" is also sane in general and only confused by the ML's misconfiguration. But I don't believe that Ctrl-Shift-A is correct here. It looks like your advice is to ask for "use Reply-To: XYZ, or From: xyz" here. That's a good advice, I'll think about how to implement this. So far, I propose the following: - change "private reply" so that it asks whether to use either the filtered Reply-To, or the From fields when they point to different addresses, What *might* make sense in case of the gentoo-dev-announce message, but what will fail horribly when faced with your message (or not, depending on what your end goal is and whether the sender really wanted to force all replies to go to him and nobody else): - detect that a ML message has a Reply-To address different than the ML's address, and ask whether to post to the ML or whether to use the filtered Reply-To when "replying by guess". > okay, maybe I'm just not used to people setting general reply-to instead of > using this feature only when they really want the reply to go to some > nondefault address Yes -- Reply-To is, unfortunately, widely abused. It is common for 3rd party software like MLs to set it, and as such, it's a question whether we shall trust it. > From: someone@gentoo.org > Reply-To: Gentoo Development <gentoo-dev@lists.gentoo.org> > List-Post: <mailto:gentoo-dev-announce@lists.gentoo.org> > To: gentoo-dev-announce@lists.gentoo.org This /is/ broken. http://tools.ietf.org/html/rfc2369 -------------- 3.4. List-Post The List-Post field describes the method for posting to the list. This is typically the address of the list, but MAY be a moderator, or potentially some other form of submission. For the special case of a list that does not allow posting (e.g., an announcements list), the List-Post field may contain the special value "NO". -------------- So it can be ignored ;-P RFC5322 says that the reply-to field is a suggestion of the sender, so it should be honoured, but i guess there's also a reason why MLs override the field, because this > From: Some Guy <the-guys-address@example.com> > Reply-To: the-guys-address@example.com or > From: Some Guy <the-guys-address@example.com> > Reply-To: the-guys-office@office.example.com is what you can get for every mail from some MUA config dialogs (putting "from" and "reply to" fields on top of each other for a simple cnp...) As we cannot determine whether the reply-to is intentional or bs and given the ML overrides, i'd suggest the automatic reply should - indeed account the reply-to field (if different from list-post) - but only if it's equal to the from field (assuming that "reply to me" is actually meant for this case, where "reply to my other mail or my secretary" is not and also because A->ML->B sounds like spam) - and yell a BIG FAT WARNING: MOVING OFF-LIST! dialog with a button to "Reply to list (Ctrl+L)" This will not "fix" the gentoo case, which however is "broken on their side". To handle this, one *could* honor reply-to if it's different from the ML but has the exact same domain (lists.gentoo.org) Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/ Sorry for the inconveniences. |