From: ezyang@MIT.EDU (Edward Z. Yang)
Subject: [sup-talk] Reply calculation
Date: Mon, 27 Jul 2009 13:09:13 -0400 [thread overview]
Message-ID: <1248713591-sup-8324@javelin> (raw)
In-Reply-To: <1248713182-sup-172@entry>
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: correct@example.com
To: correct at example.com
Reply-To: correct at example.com
List-Post: mailto:incorrect at example.com
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: person@example.com
To: list at example.com
Reply-To: person at example.com
List-Post: mailto:list at example.com
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: persona@example.com
To: list at example.com
Cc: me at example.com
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.
next prev parent reply other threads:[~2009-07-27 17:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 18:10 Edward Z. Yang
2009-07-25 18:24 ` Edward Z. Yang
2009-07-25 19:03 ` Edward Z. Yang
2009-07-25 19:15 ` Edward Z. Yang
2009-07-27 16:49 ` William Morgan
2009-07-27 17:09 ` Edward Z. Yang [this message]
2009-07-28 15:48 ` William Morgan
2009-07-28 18:34 ` Edward Z. Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1248713591-sup-8324@javelin \
--to=ezyang@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox