Excerpts from William Morgan's message of Mon Jul 27 12:49:11 -0400 2009: > What was the breakage when favoring reply-to over list-id? I was buying > your arguments...
First and foremost, s/list-id/list-post/ in my previous posts; I was quoting the wrong field and double checked message.rb just now. I received mail from a mailing list as a call for applications that should not be sent back to the list. The mail was constructed with headers like: From: [email protected] To: [email protected] Reply-To: [email protected] List-Post: mailto:[email protected] Sup detects List-Post, categorizes the message as a list message, and then sets the default reply mode as list, which results in List-Post being used as the to address. > Is it possible to identify these corner cases? Is it always when there's > a reply-to and a list-id both set? Unfortunately, mailing list administrating is notoriously broken. I'm not sure at all what the right solution is. Take for example this other case: From: [email protected] To: [email protected] Reply-To: [email protected] List-Post: mailto:[email protected] Reply-To, in this case, was set by the mailing list server. This makes having Reply-To be the end-all be-all kind of spurious. If we try to make Sup do the Right Thing (TM), you probably want to send mail to the list as a whole, which means you do want to either "reply all" semantics or "list post" magic. ("reply all" semantics are what you see in traditional mail clients when you hit the "reply all" button.) However, consider the next case: From: [email protected] To: [email protected] Cc: [email protected] Which is when someone else hit "Reply all" and you got CC'ed. This means that the mail never passed through the mailing list agent, the List-Post/Reply-To headers never got set, and the only way to tell that you should reply to the whole list is to explicitly ask for "Reply all" semantics (Sup defaults to "Reply" semantics, which is damn confusing if you're not paying attention). The core problem is that subtle changes in state should not require the user to do things differently; it breaks muscle memory and makes mistakes easy. We could try to make it so that Sup requires /no/ user intervention, but this is seems to be an AI-hard problem. Then, the logical other direction, is to make the interface as consistent as possible. Cheers, Edward PS. Djb wrote an article along these lines: http://cr.yp.to/proto/replyto.html I've skimmed it but I'm kind of skeptical about client support and not sure if it actually gives useful recommendations. _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
