RE: Responses to the list (oops)
> From: Steve Lamb [mailto:grey@dmiyu.org]
> Sent: Monday, September 26, 2005 2:50 AM
>
>
> 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.
I am well aware of the differences between the two standards. You would do
well to read them both carefully as well as RFC1123.
>
> > 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.
I've spent more hours studying that and related standards than I care to
think about. Your 30 second peek has produced laughable results and the
insults alone are reason to kill-file your posts. However, others on the
list may be interested as why your conclusions are incorrect.
>
> -----
>
> 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.
The From:, Sender: and Reply-To: have historically been called originator
fields. You have chosen to strictly interpret that term, out of context, as
the original author. Unfortunately, it doesn't mean that at all. When an
original author sends a message to a recipient, the author and originator
happen to be the same, but there are a number of other cases where the
author and originator are different. Among these are mailing lists, end
user resending and submission on behalf of another party. In RFC2821/2822,
as well as 1123, originator means the party submitting a message for
transmission through an originating gateway MTA to a destination gateway MTA
for delivery to one or more mailboxes.
A mailing list operates according to a redistribution model which is
distinct from list exploding, alias forwarding, or end user encapsulation
forwarding. It is related to, but distinct from, end user resending. Here
is the relevant citation from RFC2821:
|3.10.2 List
|
| A mailing list may be said to operate by "redistribution" rather than
| by "forwarding". To expand a list, the recipient mailer replaces the
| pseudo-mailbox address in the envelope with all of the expanded
| addresses. The return address in the envelope is changed so that all
| error messages generated by the final deliveries will be returned to
| a list administrator, not to the message originator, who generally
| has no control over the contents of the list and will typically find
| error messages annoying.
Redistribution means that the list MX first accepts a message, which is then
considered to have achieved final delivery. The life of that message, as
far as SMTP is concerned, is now _over_. The list then creates a _new_
message, which it _reinjects_ into the message stream to a new list of
recipients. As far as SMTP is concerned, this is a completely new message
and the list is the originator. This has nothing to do with authorship, it
has to do with message submission into a transport environment.
In the redistribution case, the only prohibition for 2822 headers is that
the list MUST NOT change the From: header. The Reply-To: header is optional
in the first place, and as the new originator, the list is free to do what
it wants with it. To show that the list is resending the message, rather
than just forwarding it, most lists set the Sender: header to the list
address. Thus, there are two headers, MAIL FROM: in the envelope and
Sender: in the body where the list explicitly claims to be originator.
> Since the message isn't the originator it doesn't get to touch those.
See the above. You don't seem to understand the concept of message
origination.
> The exception, as noted, is sender.
No, it's part and parcel of the whole framework, not an exception. This is
just one of the cases where author and originator are not the same. When a
party submits a message for transmission on behalf of another party, the
original author is listed in From: and the party submitting the message for
transmission MUST list their address in Sender:. Another use of Sender: is
if there are more than one original authors listed in From:, in which case
Sender: is also REQUIRED, since only one individual or system submits a
given message. Again, note that the message originator is the party listed
in Sender:, not the original author listed in From:. The Date:, Message-ID:
and first Received: header all correspond to the submission of the message,
not when it was authored. As far as the RFC's are concerned, the message
could have been authored by someone last year in handwritten form and it has
no bearing on the current message submission, _except_ that the original
author's identity belongs in From:.
Another case of reinjection of a message is when an end user receives a
message (final delivery is achieved) and decides to reinject it but wishes
to keep the originator fields the same. In this special case, which is
completely different from forwarding, the end user who reinjects the message
MUST write the Resent-From: and Resent-Date: headers to show that they are
the new message originator. This is rarely used, as only a few MUA's (i.e.
Pine) are capable of these semantics. It is also confusing because most
MTA's don't display the Resent-*: headers and unless you look at the
complete set of headers, it is an apparent forgery (none of the commonly
displayed headers show who sent you the message). From the standpoint of a
message in a transport environment, the end user that receives and reinjects
the message is the new originator because the original message achieved
final delivery and is now dead. Even though much of the content is
identical to the original, this message is a new instance in the transport
environment. It has a new sender who submits the message to an originating
gateway MTA, and a new recipient that is behind a destination gateway MTA.
I hope you are beginning to understand the concept of message origination as
differentiated from authorship.
> 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.
That is the only the case for transit between the original author and the
destination. Once the mailing list MX accepts the message, it is deemed to
have achieved final delivery and that message's life is over. The mailing
list creates multiple new messages which it reinjects into the transport
environment with new recipients. The list is the originator of each of
these messages. Since these are new messages, the mailing list is free to
do what it wants with everything except the From: header.
>
> 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.
Resent-From: and Resent-Sender: have the same semantics. Though they are
technically informational headers, they perform the same function as
Sender:.
> In fact as noted Reply-To is given protection by the explicit mention of
> author, not sending agent, and From is given father protection with the
> stronger "must not" language, From must not be set to any mailbox the
> author does not control.
You are misunderstanding what the standard is about. The party who submits
the message fills in the originator fields. If they are submitting a
message on behalf of a third party, it is their responsibility to list that
party in From:. The message may have been conveyed verbally or in
handwritten form and there is no requirement that the message come to the
submitter in electronic form with (2)822 headers.
>
> This is reinforced 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."
Yes, for a completely different case. This is end user resending, not
mailing list redistribution. They may appear similar, but they are distinct
cases.
>
> 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.
That is your opinion only. You are grossly oversimplifying the situation.
> 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.
As I said, mailing lists != end user resending. You may wish they were the
same, but they are not. While I said previously that it would have been
better if mailing lists had adopted the practice of using Resent-*:, they
instead adopted Sender: for this purpose and thus most MUA's don't display
Resent-*:. If they did, very few people would have any idea what it meant.
>
> In short, Seth, there is no wording in RFC2822 which even remotely
> suggestions that mailing lists can touch reply-to. None.
More importantly, there is nothing that says they can't. Most mailing lists
_do_ change Reply-To:, so your insistence on the one true interpretation is
quite irrelevant. You can't change that and neither can I. Get a life.
> At all. Want to know why? Well, that's where the history lesson comes
in.
Oh wonderful, you are going to give me a history lesson? Where do I get off
this bus.
>
> RFC822 *DID* mention it, quite explicitly.
<irrelevant citation snipped>
Published in 1982 before mailing lists, as we know them today, were even
conceived of.
>
> 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.
I really don't care what you argued in 1990. That was then and this is now.
Industry practice is what it is. You can ignore and pretend or you can
accept how things are really done and get on with it.
>
> 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.
The debate ended long ago when most mailing lists began setting Reply-To: as
they please.
> 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!
That's an interesting hypothesis, but you didn't write the standard and you
don't know why they changed the language. Not that it matters, it still
doesn't change existing practice.
>
> > 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.
That can happen, but it is not the general case. The great majority of
responses to questions on a mailing list belong on the list so that
a) other people with similar questions can see the answer, and
b) the answer is in the archives, so if someone looks, they don't have to
ask the same question again
This is the reason for a public mailing list. Offlist replies are the
exception, not the rule.
> 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.
Yes, I think I see exactly what you mean.
> 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!
I didn't say they don't exist, only that it is the exception and
inappropriate in the normal case. Why do most other mailing lists set
Reply-To: to the list? Because that's what their users prefer and it became
the norm. Sorry you don't approve.
<...>
> > 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.
That is the primary reason and the only one that justifies volunteers
putting in effort to answer questions. If it was meant to be a one-on-one
conversation, a public mailing list would not be the medium of choice.
<...>
> > 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.
OK, the rest of the world is wrong, you are right, and we should change all
mailing lists and MUA software to suit your interpretation. It should be
happening real soon now.
>
> > 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.
Even proponents of the way this list operates admitted that it was different
from the rest of the world.
> Furthermore I tend to err on the side of what the offical standards
> say lest we venture into Microsoftism of incompatibility.
I guess no one asked you when the present practice became the norm. This
list is the one with the compatibility problem.
>
>
> > 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.
In what universe do you live? The one the rest of us live in already does
things in a way you consider wrong. Shall everyone marginalize everyone
else (except for you) for their communal bad behavior?
>
>
> > 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!
Among a lot of others. When you have a de facto standard, it doesn't matter
if you like the source of it or not. I don't like the source of this one,
but that doesn't change things a whit.
> Are you now arguing those are better than the alternatives,
> zombie spam, virus vector and all? :P
Nope, just that this is what current practice is, whether you or I happen to
like it or not.
>
> > 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.
What we have is compliance with a de facto standard. An open standard would
have been better, but it didn't work out that way. You can't turn time back
and you can't change what is.
>
> > 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.
Except that no one is going to implement your proposal. Looks like you're
the only one who's going to be unhappy.
>
> 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.
First of all, it's not _my_ way. It's the way that everyone else decided to
operate, so don't shoot the messenger. It really doesn't matter what the
original drafters of those standards intended, which is very debatable
anyway. What has become general practice works well enough. As far as your
List-Reply: proposal, there's nothing wrong with it on technical grounds, it
just is never going to happen since the problem is already solved.
>
> > 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.
If he said that (and I wouldn't know), it would be one of the few cases
where I agree with him.
>
> > 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.
In your minority opinion. And if that were actually the case, so what? It
is an open standard published by a group that does not exactly operate
democratically and adoption is voluntary. It would be nice if everybody
obeyed all published RFC's, but there a lot of cases where people bend or
even break the "rules" for very practical reasons. Nobody had even thought
of the concept of spam in 1982, and until very recently, operating an open
relay was thought to be a courteous thing to do. Things change quickly but
the RFC's can't due to the nature of the process. The people who write them
are also not perfect and can't predict the future. The point is, nobody is
going to the gallows because you believe that the common practice on mailing
lists is contrary to the intent of one RFC. I doubt that even RFC-ignorant
would accept a submission on that basis. Open standards are great,
especially when they represent consensus. When most users choose to adopt a
different practice, that's the standard, written or not.
>
> > 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.
I didn't write those RFC's nor did I establish the practices that now exist.
It has nothing to do with what I want. I don't want Microsoft to exist, but
that doesn't change the fact that they control the majority of desktops
today. I won't ignore that, even though I dislike it.
>
> > 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.
A tiny minority of deployed MUA's on a minority OS meet your criteria. And
exactly how does that makes me ignorant? I didn't write Windows, I didn't
build Outlook Express and I didn't set up tens of thousands of mailing lists
that operate in a way you don't like. Why do you call me ignorant when I
simply point out how things are?
>
>
> > 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.
So you really believe that there has been a huge groundswell of complaints
about how mailing lists and MUA's currently operate? Gee, I must have
missed that. The real pesky fact here is that precious few lists and MUA's
operate the way you would like them to and people on those lists don't
complain. That's a bit hard to explain. Surely, the majority of mail
system admins have read the same standards we are discussing. The other
pesky fact is that no one cares if you think it is wrong.
>
> > 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.
You've got a lot of gall to publicly state the above. I'm a newcomer to
this list, but no newcomer to email standards and practice. I certainly
don't need any instruction from you. As far as having "egg on my face", it
seems that since most lists and MUA's operate the way that I have described,
you have a much bigger credibility problem than I.
--
Seth Goodman
Reply to: