[Mailman-Developers] Reply-To munging considered *carefully*

[Michael B. Trausch]

On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote:
> Michael B. Trausch writes:
> 
> [This was me, stephen, but the attribution was dropped:]

The attribution was _not_ dropped, it was at the top of the message in
standard inline-reply fashion.  You may want to double check the message
to verify that:

http://www.mail-archive.com/mailman-developers%
40python.org/msg11590.html

Short link to the same resource, in case of breakage: http://is.gd/4iD4o

>  > > The upshot is that there is no RFC-sanctioned way for a list to say
>  > > "please respond here", and no way at all that doesn't usurp *both* the
>  > > author's and the receiver's options.
>  > 
>  > The best way to do this far simpler, I think:
>  > 
>  >   1.  Mailer software should reply to From or Reply-To as currently.
>  >   2.  ML software should set Reply-To _UNLESS_ there was _already_ a
>  >       Reply-To.  Then, Reply-To isn't truly broken, because the author
>  >       has control over it still, and it just defaults to the list.
> 
> Reply-To still is truly broken.  The author wants personal replies to
> go to her, but now they go to the list.  The recipient must
> *specifically avoid reply-to-author* in order to reply to the author.
> This is so Orwellian.

Permit me to rephrase so that you understand what I said:

There are two major uses of email, discounting automatically generated
messages, corporate crap and spam:  email from one person or to one
person or a group of people, and email from one person to a mailing list
(presumably with people on it).  Whether the emails are in a personal,
hobbyist, collegiate, educational, or professional context, the patterns
are largely the same.  In both events, 95+% of the time, there is no
reply-to header attached by the authors MUA.

However, the primary use-case for a mailing list is _group_
_discussion_.  Or at least, so I thought.  Call me silly, but if it's
not meant to be group discussion as the primary role, maybe mailing
lists should stop using server software and become ad-hoc, old boys'
club style, personally shared and replicated distribution lists, nothing
more.  Being that is the case, and that is what users of mailing lists
_expect_, it is reasonable to assume that the way reply-to is handled
would be thus:

 * I send an email to the mailing list to start a thread of discussion.
I send no reply-to header on the message, so the list processing
software appends one redirecting replies to the group.  This facilitates
group discussion.  It's not Orwellian, it's common sense---if, of
course, we make the assumption that mailing lists are for, you know,
group discussion and not private communication.  If I want to
communicate privately with someone, I won't be sending the mail to a
mailing list; if I need to communicate with someone who is on a ML
privately, and I don't have their address, that's what ML archives are
for (or, sending a mail to the ML to ping them, or searching my own
archives, if the public archives have that information stripped).

 * During the course of the thread, it becomes clear that some sensitive
information must be sent (to address your use case from your Web page
from earlier in this thread).  That's totally not a problem:  The person
asking for the sensitive information simply adds a reply-to header to
their outbound message.  The mailing list _sees_ this reply-to header,
and then refuses to replace it, transform it, or supercede it, because
the rule SHOULD be "Only add a reply-to to a message if it does not have
one already."  I don't know if there is _any_ software that does this
currently out there, but if there isn't, that's something that is at
least easily fixed in any system even if it's horribly designed.  It
translates to nothing more than a single if statement in code.  It'd be
trivial for users of non-proprietary systems to adopt even if they don't
want to upgrade their mailing list software.

Now, there is of course an alternative mechanism that could be used to
meet the same need:  Have a header, say, X-List-Please-Reply-To-List,
that a MUA could add in a generic fashion to all mail messages.  That
could signal to the list processing software, "Yes, Please, I WANT
people replying to my messages to reply to the list."  However, I don't
see that as at all likely to occur.

For me to fit into your suggested solution, I'd have to wait for both
your algorithm to be ubiquitous in MUA software _and_ all mailing list
software to be upgraded or replaced to make the headers it depends on to
be ubiquitous.

Still, to get truly sane behavior, I'd have to use Alpine.  Why?  The
MUA _can_ do what I meant, and it can do it _easily_.  There is
_nothing_ that will fix the situation of no-duplicate-posts and the
associated "Oops, I sent that to you and I meant to send it to the list
as well," unless the MUA does one of the following (either by default,
or by configuration):

  - Uses "reply to all" as the default behavior (config item), or
  - Asks you what you want to do when there are multiple recipients to
the message that you're replying to (could be a sane default _and_ a
config item)

Alpine does the latter by default.  I have used no MUA that does the
former (that I am aware of; some of them perhaps did, but I've tried
many and quickly fled any that are buggy in areas that I cannot fix and
impact my usage patterns), and I don't know of any other ones that
behave the way Alpine does.  If Alpine fit better into my workflow
overall, I'd use _that_ instead, solely for that single feature.  Why?
Because while it may not be smart enough to do what I meant for it to
do, it is smart enough to recognize that fact and _ask_ what I mean for
it to do.

Unfortunately, most MUA software seems to take as an axiom that humans
are infallible and will always do The Right Thing.  Call me silly, but I
have software to help me to do that in many ways; if I didn't want that,
I'd type my messages directly into a socket, speak SMTP myself, and
likely do so using an 8088 with DOS running a tiny network stack and
with frequent calls to INT 0x21 and INT 0x60.  Thankfully, that's not
required, nor do I desire it.

>  > IOW, reply-to only makes sense in its default (none, that is, reply to
>  > from) in interpersonal communications or self-made "distribution lists"
>  > where From == To and the recipients are all Bcc'd.
> 
> Stop deprecating use cases that you don't use.  They exist, are
> important to their users, and what you are advocating is tyranny of
> the majority.  Not on our Internet, please.

I didn't deprecate _anything_.  I'm going to give you the benefit of the
doubt and assume that you must have had a really bad day or something.*

> I have no objection to the functionality you want, but I take *strong*
> exception to having the very useful Reply-To field *hijacked* so that
> you don't need to wait for my proposal to be implemented.[1]
> 
>  > So, in the end, I think that the algorithm you mentioned is a good step
>  > in the right direction, sure.  But I think the ultimate solution is even
>  > simpler than that:
> 
> Except that it is *not* an ultimate solution, because the function of
> the Reply-To field is lost in important cases.  A new Reply-To field
> that third parties are prohibited from munging would have to be
> defined.  Why do that when we already have one?

Citation, please?  I already quoted the part of RFC 2822 that shows that
semantically speaking your assertion is incorrect.  If there is an RFC
that supersedes the definitions of RFC 2822, I'd like to see it.  At
present, I am not aware of one.  (Further, if there is additional
clarification that I've missed in my readings of RFC 2822, I'd like a
pointer to that, as well; I've already read it once today, maybe I'll
review it again later for things I missed in today's reading.)

In my (admittedly, limited in terms of global and topical coverage)
personal experience, _most_ mailing lists are poorly configured on the
extreme of users not being able to specify a reply-to at all, because
the reply-to is stripped and subsequently replaced by the mailing list
software.  Clearly, this is _bad_.  Is it wrong?  Not according to RFC
2822, because the mailing list processor is the logical origin of a
message and thus it is clear to send the header---or not---as it sees
fit.  However, what sparked this thread was a practical concern
regarding a very common usage pattern, not a concern that everything be
100% idealistic and precisely fit some standard as interpreted by random
person X.

In other words, what we're talking about is left---according to the
ambiguous text in RFC 2822---as an implementation detail of mailing list
processing software.

> Footnotes: 
> [1]  The problem of the wrong dupe being eliminated is *not* a problem
> with Reply-To, although it may be made more frequent.  It's simply the
> case that if access to the List-Post field in every message is
> desired, the mailing *cannot* do dupe elimination.  *Not* *at* *all*.
> Your use case here is broken.  Badly.

I never *said* it was a problem with reply-to.  I _did_ say that by
adopting a sane default (but able to be overrode by the sender _simply_
by using the header him/herself) value is a practical thing to do, is
useful, and fits 95% of the people's workflows, 95% of the time---maybe
more, maybe less, but I don't believe I'm terribly far outside of the
ballpark.  In _ANY_ system there is going to be exceptions, but guess
what?  That's because we are human, and no matter how pedantic or
technical we are, we're going to screw up occasionally.

If this conversation is going to degrade into slinging and retaliation
based on emotion-provoking arguments instead of grounded ones, I think
it's best that it stops here.  If you want to talk about 1984, there's a
place and time for that; if you want to overlook details, I'm sure
there's one for that, too.  I was talking about a practical matter, and
it was just a comment (regarding my MUA, which I am _well_ aware could
behave better, and I simply do _not_ have the time to make that happen
right now).  It wasn't supposed to blow up into a huge argument of
religion and who can interpret RFCs more conservatively or liberally
than the other.

	Have a better day tomorrow,*
	Mike

* My wife seems to think that I come off sarcastic in those statements.
In case that is how you read it, allow me to assure you, that is not my
intent.

-- 
Blog:  http://mike.trausch.us/blog/
Misc. Software:  http://mike.trausch.us/software/

“The greater danger for most of us lies not in setting our aim too
high and falling short; but in setting our aim too low, and achieving
our mark.” —Michelangelo