Keith Moore wrote:
I don't follow that; which part of the specification do you
believe is responsible for failure of some UAs to display the
field?
The part that doesn't say that it needs to be obvious to the recipient
that replies aren't going to the recipient list of the original message.
UI behavior is rarely prescribed. RFC 2822 is a message format
specification, not an MUA UI design guide. Likewise RFC 2821 is
a message transfer protocol specification, as are the corresponding
RFCs for POP variants, IMAP variants, NNTP, LMTP, etc. So if
there were to be such a UI design guide for MUAs, it would be
some additional document. If an RFC, probably an Informational
one rather than Standards Track.
These exist regardless. By that argument, we don't need reply-to or
mail-followup-to or any other header field to affect how replies are
addressed.
No, that's not the argument. You seem to be conflating the
recipient list with the indication of intent.
You seem to be separating them. This increases the chance that a vital
piece of information will be missed because the recipient has to look in
two places.
There has never been and is not now any place where (from a protocol
point of view) the sender's intent is indicated -- so there's nothing
in the protocol to "separate". Mind you, the specific suggestion was
that an author could choose to use any of the human-readable places
where intent could be indicated, for the benefit of human respondents.
It could be because
the sender is pointing to an alternate address for himself - say
because he wants to get replies on his PDA. Or it could be because the
sender thought replies should go to his secretary, or to a list, or
somewhere else.
Perhaps he only wants responses sent to his PDA (or secretary)
for a limited period of time. Perhaps he expects different
recipients to respond to different addresses. I don't believe
it practical to devise a way to handle the myriad of
circumstances that individual authors might under some
situations like to express -- at least not without adding
more confusion to the situation (which languages should
the authors desires be expressed in, which charsets, what
formats should be used for date and time, how should
precedence relationships be expressed, etc.).
Having too little information is confusing because it's ambiguous.
Having too much information is confusing because it's complex.
The simple solution is to let the author supply text that describes why
the recipient should or should not use a particular reply address, since
the decision is going to be have to be made by a human recipient (rather
than his MUA) anyway.
1. which recipient (any given message may have many recipients)
2. text in which language(s)?
3. text in which charset(s)?
4. if he writes something like "reply to 'foo(_at_)bar(_dot_)com' if before
12/11/10 and to 'foo(_at_)baz(_dot_)edu' after that date", is the date in
question in October, or November, or December, and which day
of the month in which year (and century)?
Simply allowing an author to supply some text doesn't necessarily
clarify matters for all recipients, doesn't simplify matters, and
requires substantial (most likely manual) input from the author,
requires that such text be presented to recipients, and requires
recipients to be able to comprehend the intent.
Not in detail. In brief - it affects the vast majority of MUAs out
there, and it makes existing uses of reply-to much less reliable.
My transition model is that, at least for many years, recipient MUAs
need to keep honoring Reply-to (at least in the sense that they make the
recipient aware that reply-to was used and give him the chance to
explicitly reply to that address) _unless_ the sender of the message
also asserted whatever new reply request gets adopted. If we define a
new reply request field, we can make sure that existing uses of reply-to
don't fail. If we redefine reply-to to behave differently (or to be
ignored), those existing uses will fail.
I'm not proposing any such redefinition; I propose the same syntax
and semantics specified in RFC 2822.
My sense is that that answer doesn't sound good to lots of people.
I'm still trying to understand why. I think there are at least
two issues here. One is that it requires substantial changes to
existing message stores (if you built one from scratch to handle this it
would be fairly easy).
As mentioned, Cyrus IMAP already has a configurable option
for this (implemented in the message store).
so all we have to do is get everyone to switch to Cyrus, and then [...]
No, I was merely pointing out that there exists at least one
implementation (a widely used one at that) which provides a
means to eliminate duplicates at the message store. Duplicate
elimination at an MUA raises several issues, e.g. *which* MUA
(many people use multiple UAs), where is the duplicate actually
eliminated from if not the message store (eliminating duplicates
from a private stash in a proprietary format still leaves any
duplicates that might be in the real message store), etc,
nothing says there can't be multiple ways of suppressing duplicates. it
should be possible to arrange that they won't interfere with each
other. the user with the UA or MS that suppresses duplicates can then
choose whether or not to originate mail with the mechanism that
suppresses duplicates on replies to lists.
So all we have to do is change every UA (and probably many MTAs
as well)?
heck, I can't even get my home ISP to support IMAP/POP over SSL or TLS -
which EVERYBODY should be doing. (and by most metrics they are one of
the better ISPs in the US) I don't imagine that I'll get them to
support duplicate suppression anytime soon. But if someone adds
duplicate suppression to any of several different MUAs, I can install
that MUA on my machines and the fact that my ISP doesn't run the message
store like I want them to becomes irrelevant.
Leaving aside secure transport, switching to a single MUA that
supports one particular feature means living with any peculiarities,
bugs, security weaknesses, etc. that are characteristics of that
particular MUA, as well as having to live without any features which that
MUA does not support.
Oh! Have you never sent a response to the mailbox in the From
field as well as the Reply-To address(es) when Reply-To was
present?
Perhaps, but it's been extremely rare - and I probably only did this
when the Reply-To addresses were redundant with other addresses
that were already in the recipient list.
That wouldn't explain including the From field mailbox when
it was not present in To or Cc.
what does that have to do with the question? (or maybe this is a rathole?)
Well the specific question (still quoted above) was about using
the From field mailbox(es) in addition to Reply-To address(es),
and was unrelated to To and/or Cc fields.