Seth Goodman wrote: > Referencing 822 for much of anything these days is not very useful, unless > if you're interested in email history.
Which is something you need to know when blatently getting 822 and 2822
backwards when it comes to reply-to.
> As I pointed out in a previous post,
> Reply-To: is an optional header that is set by the _sender_ of the message.
Incorrect. Have you even read RFC2822? I decided to refresh my memory
and reread it and it took me all of 30s to debunk this notion.
-----
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
-----
Not the sender of the message, or ORIGINATOR of the message. Since the
message isn't the originator it doesn't get to touch those. The exception, as
noted, is sender. Now let's look specifically at reply-to.
-----
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(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.
-----
The author. No mention of mailing list munging. It is where the AUTHOR
wants the mail to go.
Now let's hop to sender...
-----
The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
-----
This states that the agent that actually sent the message sets the sender
field. If the sender and the from field would be the same sender should not
be used. If the sender is different than the originator then sender should be
set. Note that no other originator field gets that provision. None. Not
From. Not Reply-to. Only Sender. In fact as noted Reply-To is given
protection by the explicit mention of author, not sending agent, and From is
given futher protection with the stronger "must not" language, From must not
be set to any mailbox the author does not control.
This is reinfoced further in the document where the Resent-* headers are
defined...
-----
3.6.6. Resent fields
Resent fields SHOULD be added to any message that is reintroduced by
a user into the transport system. A separate set of resent fields
SHOULD be added each time this is done. All of the resent fields
corresponding to a particular resending of the message SHOULD be
together. Each new set of resent fields is prepended to the message;
that is, the most recent set of resent fields appear earlier in the
message. No other fields in the message are changed when resent
fields are added.
-----
Clear language there. "No other fields in the message are changed when
resent fields are added."
So follow the trail. Sender should not be set if sender/from would be the
same. In the case of a mailing list this is not the case so sender is allowed
to be touched. Reply-to is specifically delecated to the author of the
message, not the resending agent. From is stricty prohibited. Furthermore
when reintroducing the message into the transport system (IE, Mailing list!)
resent- headers should be set and no other fields are changed.
In short, Seth, there is no wording in RFC2822 which even remotely
suggestions that mailing lists can touch reply-to. None. At all. Want to
know why? Well, that's where the history lesson comes in.
RFC822 *DID* mention it, quite explicitly.
-----
4.4.3. REPLY-TO / RESENT-REPLY-TO
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.
-----
'A somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution services'...
.... mailing lists!
'include the address of that service in the "Reply-To" field of all
messages submitted to the teleconference'
.... munging the reply-to to point to the list!
Now, why do you think that language was removed from RFC2822 when it was
present in 822? Trust me, you're talking to someone who has argued *FOR*
reply-to being set my mailing lists and cited the above passage of RFC822 for
years before before 2822 came around. Don't believe me do a search on my name
in the Debian lists circa 1990 or so and include "RFC" and "822" and it'll
probably pick up my arguments from then.
You are flat out wrong when you say RFC822 prevented reply-to munging and
RFC2822 allows it. You got it flat backwards because RFC822's wording allowed
it and the debate raged for years. To put that debate to rest that wording
was removed from RFC2822 and protections on reply-to placed so as to make it
absolutely crystal clear that reply-to is not to be touched by mailing lists
and is not an appropriate use for mailing lists!
> Similarly, being a mailing list and not a private conversation, it is both
> inappropriate and cumbersome for the original poster to answer a public post
> with a private reply.
No, it is not inappropriate. It is entirely appropriate when the author
of the reply deems it so. For example if the author of the reply is offering
help and giving personal information which is to be used solely by person he
is replying to the author should not EVER be forced to post that information
to a public forum. Another example is when the author wants to discuss
matters under debate without causing the person they are replying to to lose
face and/or to privately discuss with them how much of a prick someone else on
the list is without airing out dirty laundry. There are a miltitude of
reasonw wherea a private reply is far more appropriate than a public one and
the notion that such reasons don't exist is preposterous!
It is, however, entirely inappropriate to take a private conversation
public at least not without consent from all parties involved.
> The purpose for a public mailing list is to have a
> public conversation, with one answer hopefully satisfying many readers with
> the same question.
That is one of many reasons. However, as noted above not all discourse is
intended for consumption. Only the author can make that determination before
it is going public and that determination should be respected.
> Taking into account how the vast majority of deployed
> MUA's operate, it is perfectly reasonable, and not in conflict with the
> RFC's, for a mailing list to change Reply-To: in order to have the reply
> button do the desired action in the majority of cases.
It conflicts. I've pointed out how RFC2822 constantly reinforces the
notion that reply-to is not to be munged and shown how it changed from a far
looser RFC822.
> Now, you can insist that the majority of the mailing lists have it dead
> wrong,
They are.
> as do the majority of deployed MUA's around the internet.
They are.
> If that's your position, go ahead, you're arguing with a de facto
> standard that is incredibly widely deployed.
Not significantly wider than lists without reply-to. Furthermore I tend
to err on the side of what the offical standards say lest we venture into
Microsoftism of incompatibility.
> Your opinion, as well as mine and that of RFC2822
> are quite irrelevant in this respect.
Not true. RFC2822 is relevant. Those who break it are clearly in the
wrong and should be marginalized, period.
> There are millions of
> deployed MUA's and tens of thousands of mailing lists that already operate
> in a particular way. In fact, most users of those systems _like_ the way
> they operate.
Yes, and most of those are using Outlook or Outlook Express! Are you now
arguing those are better than the alternatives, zombie spam, virus vector and
all? :P
> The chances of changing all that infrastructure, that users
> actually like, is between slim and none. After all that work, the payoff
> would be what?
I dunno, compliance with an open standard and interoperability without the
decades old debate? Sounds good to me.
> Only that mailing lists and MUA's would operate the way
> _you_ think they should. Nothing practical will have been gained.
Really? How I think they should. Funny, here's how I think they should
operate.
Mailing lists don't touch reply-to. They set List-Post. MUAs honor
reply-to on replies when it is set or go to From if it isn't. MUAs honor
List-Post when replying to the list.
What have we gained? Uhm, clear separation of list replies versus
personal replies, the intended functionality of reply-to intact, list-replies
still work. Everyone's happy.
So now the same question is posed to you. By doing it YOUR way what have
we gained? So far what we've lost is the intended functionality of reply-to.
> It's perfectly reasonable to argue technical merit in
> technical committees and in engineering departments, but when it comes to de
> facto standards, you can either recognize them or become a footnote in
> technical development.
You really should attribute your Bill Gates' quotes.
> The answer is simple, it _isn't_ needed for any practical purpose. There is
> already a reply header that the list is allowed to use, and in fact most
> lists _do_ use.
In violation of RFC2822.
> There is no purpose for an additional header that the great
> majority of deployed MUA's don't use anyway.
Except providing a way to reply to lists without destroying a different
header in the process. But, hey, "technology" must march on! Oh, wait, you
mean only to where *YOU* want it to stop but no further.
> Anyone who proposes a solution
> to an email problem that requires the majority of the world's MUA's and
> mailing lists to change is running straight into a brick wall without a
> helmet.
Yes, yes... And yet a large number of MUAs already support List-Post in
just that fashion. Again, the march of progress but only to your ignorant
drummer.
> The people who write institutional standards are more aware than
> most of the tenacity of de facto standards and they know better than trying
> fighting them, unless there is an enormous problem that gives them a mandate
> to do so.
Which would be why RFC2822 removed the reference to mailing lists in
reply-to? Or, sorry, forgot, pesky facts are annoying.
> That is clearly not the case in this instance. It would be
> damaging to the entire standards process if they put something into a
> standard that would be widely ignored. In other words, don't pass an
> unenforceable rule that everyone is going to ignore if you want to be taken
> seriously.
Which is exactly what was done twice over now and argued yet again by you.
Please, go read the RFCs before you start debating them. Also, try to get a
little history under your belt. You're a newcomer to a deades old debate and
so far all you've got to show for it is egg on your face.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
signature.asc
Description: OpenPGP digital signature
