Re: Different "replying" modes in a MUA

(oh wow.  here we go again.)

1. I disagree with the RFCs about this, and always have.   (I state this up front just to make it clear that I am not proposing a novel way of interpreting the RFCs; I'm just saying that I disagree with them.   So there's no need to try to reconcile my view with what the RFCs say - we're just diametrically opposed.)

2. Regardless of the presence or absence of Reply-To or any other field, it is ALWAYS the recipient's job to decide to whom he wants to address replies.  

3. It is the job of the recipient's mail user agent ("agent" = acting on the recipient's behalf) to obey the recipient's wishes.   In particular, (a) it should allow the recipient to reply to whomever he wishes to reply and (b) make that behavior as obvious to the recipient as possible, so that the MUA's behavior will be unsurprising to the recipient of the subject message (the author of the reply).   

(Note that "to whomever he wishes to reply" might include addresses from any of the headers of the subject message, and/or addresses  that don't appear in the subject message at all.)

4. UAs that change their behavior based on the presence or absence of fields in the subject message (especially fields that aren't normally displayed) generally FAIL to meet the "unsurprising behavior" test.

5. It's not unusual for a recipient to want to change the set of recipients of a reply, after starting to compose the reply, but before sending it.  (For that matter, it's not unusual for the recipient to want to change the set of reply recipients after sending the reply, but Internet Mail wasn't designed to deal with that.)

6. The best address to which to send a reply is not something that can reliably be determined from the headers of the subject message.   Only the author of the reply understands the reason for replying to the message, and therefore only the author of the reply understands to whom the reply is best addressed.

There's a natural tension here between the expressed interests of several parties: the author of the subject message, the author of a reply to that subject message, and any lists through which that message might have been sent.  But the thing that makes the most sense, and produces the least surprising behavior, is to always entrust the author of the reply with deciding who should receive the reply.

---

now, having said that, here's what I'd recommend:

1. There should always be "Reply" and "Reply All" buttons, even if the two do the same thing.
2. If there's a List-Post header in the subject message, adding a "Reply List" button makes sense.
3. The recipient of the subject message (i.e. the author of the reply) should be able to change the list of recipients at any time prior to sending the reply, including being able to toggle between Reply/ReplyAll/ReplyList, adding additional recipients, and removing others.

Note: The Reply-To field just confuses things because it doesn't really allow the sender to specify his preferences as to where replies should go; it only takes the place of From.   But that behavior is so well-entrenched and widely expected that you probably shouldn't change it.   So when the recipient hits "Reply" or "ReplyAll" to a message for which a Reply-To field is present, you should use the address(es) in the Reply-To field instead of those in the From field.   But you should still allow the recipient the option of replying to the address(es) in the From field, even when the Reply-To field is present.

The best way I've thought of to do this is for the compose window to present filled-in message headers listing all of the possible recipients, with the currently selected recipients in black and the others grayed out.   So if the recipient hits "Reply" then the only addresses initially shown in black are those from the Reply-To field (or the From field if no Reply-To field was present).   But any address could be toggled from black-to-gray or vice versa by clicking on it.   And the Reply / ReplyAll / ReplyList buttons should still be present in the compose window of the reply, so that the recipient can easily reset the set of active recipients to any of those defaults.

Keith


On Jan 4, 2013, at 11:44 AM, Jan Kundrát wrote:

> Hi,
> I'm struggling to come up with the best approach for designing the "reply" feature in Trojitá. As far as I know, there's no single "best practices" document to follow (and many "XYZ considered harmful" ones and an interesting one about how Evolution works [1]). Here's what I'd like to do:
> 
> - Always offer multiple ways to reply. These actions will be represneted by an expandable button (i.e. a button with an arrow on the right which performs the "reasonable thing" by default but allows you to click the arrow to see the other actions).
> 
> - The rules for picking up the recipients will be the following:
> 
> 1) If there's a List-Post header and its value is not set to "NO" (or an equivalent) and there's at least one mailto: URL in there, the "Reply to List" is enabled and listed as the default option. When user selects this action, all of the Sender, From, Reply-To, Cc and Bcc are ignored.
> 
> 
> 2) "Reply All" option is always available and will generate a list of recipients using the following rules:
> 
> - All addresses in the message's From and Reply-To will be used in the "To" field
> - All addresses in the message's To will be in the Cc
> - All addresses in the message's Cc will be in the Cc
> - All addresses in the message's Bcc will be in the Bcc
> 
> After this is complete, a list will be "sanitized":
> - Duplicate enteries in each To/Cc/Bcc are be removed
> - Addresses already in To are removed from Cc and Bcc
> - Addresses already in Cc are removed from Bcc
> 
> The List-Post and the Sender headers are ignored when doing the Reply-All thing.
> 
> The "Reply All" is the second candidate for a default (i.e. the default when "Reply List" is not available).
> 
> 
> 3) "Private Reply" option is always available and produces a message with the following recipient(s) in the "To" field:
> 
> - If the message contains a Reply-To, each of those which are at the same time *not* listed in any List-Post addresses are used. If the resulting set is non-empty, the From header is ignored. This means that any address in the Reply-To which is also listed in the List-Post is silenty ignored and anything not in the List-Post is used.
> - The Sender header is always ignored.
> - If the recipients list is empty at this point, everything from the From field is used.
> - If the resulting set contains more than one address, the duplicates are eliminated.
> 
> 
> 
> I am very interested in hearing what you think about this scheme. I realize that this is a topic with a huge potential for a good flame, and I suspect there are people who have very different opinions as to what is best. Despite that, I'll be happy to hear what issues are lurking in the algorithm I describe and what drawbacks I'm eniterly missing. Please also feel free to point me to any existing discussion as long as it's different from [1], [2] and [3] which I've read already.
> 
> When the discussion settles, I plan to impleemnt the outcome in Trojitá (along with a test case with plenty of examples matching real-world scenarios). Thanks for your help!
> 
> With kind regards,
> Jan
> 
> 
> [1] http://david.woodhou.se/reply-to-list.html
> [2] http://www.unicom.com/pw/reply-to-harmful.html
> [3] http://woozle.org/~neale/papers/reply-to-still-harmful.html
> 
> 
> -- 
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
> _______________________________________________
> ietf-822 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-822

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822