UGH. I hit Send by accident, going for the menu bar. I hate my mouse.
Sorry for the dup.
Note, I am not subscribed to mailman-developers@python.org, so this
message may or may not get through to that list. I did CC everyone
interested so far, though (I think), in this subthread.
On Tue, 2009-10-13 at 16:03 +0900, Stephen J. Turnbull wrote:
> Reply-To set to me. Please verify that your replies are going to the
> intended place.
Indeed, Ctrl+R does reply to you.
> Michael B. Trausch writes:
> > In any case, it's off-topic, and unless others here are interested
> > in the discussion, or there's a chance that the ML config would be
> > changed, it's probably best just to drop it altogether.
>
> I'm not sure where discussion will take place. Not here, possibly
> Mailman Developers ML, most likely wiki.list.org. Drop me a line and
> I'll make sure that you're notified about the new venue. It will
> probably be Saturday or so.
I assume that since we've already gone there, that's where it'll be. I
assume I'll know shortly after I hit C-RET if I need to be subscribed
there, too...
> As long as I'm here, let me respond.
>
> > I've seen that argument before; it's fine, but the ideal situation
is
> > impossible to achieve (some form of complete consistency amongst
all
> > mailing lists globally).
>
> The draft RFC admits that. It's not a panacea, it's a path forward.
>
> The problem to date, AFAICT from the litter on the path to RFC 2822,
> is that a lot of people want a way to indicate that responses SHOULD
> go to the list (of course you can't *force* them to go to the list).
> They have insisted on coopting Reply-To and Mail-Followup-To for that
> purpose because they are existing headers that many MUAs already
> respect. This breaks their usage as defined in the RFCs, so the
> cooler heads have refused to sanction such usage. They are for the
> *author* to indicate where personal replies and public discussion,
> respectively, should be conducted.
>
> 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.
This manages to make things work 95% of the time for 95% of the people.
I know that people far less technical than myself expect the behavior
above. I don't know about ML's and whether or not they'll respect and
author-set Reply-To if one is set in the ML configuration, but I've
never tried, either; I do know that of the lists I'm on, the Bazaar ML
and one other one (don't remember right now which one) are the only two
that actually don't set Reply-To.
Now, RFC 2822 says that From, Sender and Reply-To are "originator
fields". It also says this:
When the "Reply-To:" field is present, it indicates the
mailbox(es) to which the author of the message suggests
that replies be sent.
AFAIC, _this_ author wants replies to his posts to go to a ML unless he
says otherwise. That would tie with #2 above, and it seems to me to be
a quite reasonable default.
As things currently sit, the default would seem to be "reply to me,
unless I say otherwise," which doesn't make sense in the context of an
ML. So, this is a bit of a higher-level discussion than the RFCs really
provide for. Further, RFC 2822 doesn't prohibit mailing lists from
setting Reply-To, and discussion about that would seem to me to be
splitting hairs as to where the author suggests posts go in the first
place. Your page says that it applies to the originator of the message,
but the RFC does not say that; it says that it's an originator header,
and from the POV of my Inbox, that's exactly where the mail comes from
(e.g., the message comes from human A sending message A, and then the ML
server receives message A and becomes the new origin, sending out
messages A(1), A(2), ..., A(n)).
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.
I would say that if ML software _always_ overrides reply-to, even when
the author explicitly provided one, then that is broken. And that does
leave the odd corner case of "My outbound origin is
u...@machine.example.org but I want inbound mail to go to
u...@example.org" unhandled, but I think that is such a rare case that
they would expect misdirected mails in that event.
> The intention is to fix that. I already have agreement in principle
> from the Mailman boss to implement for that list manager. I will
> provide an implementation of my algorithm that can be used in Emacs
> MUAs. I'm sure I can get VM and MH-E to adopt it, and almost sure
> Gnus will. The KDE KMail guy has expressed interest. Both seemed to
> think my proposal is actually novel, but I certainly will check the
> IETF archives in order to frame it properly in existing discussion.
>
> > On the topic of the discussion, though, what is better for all is a
> > default behavior that is correct, say, 95% of the time for 95% of
the
> > people.
>
> My algorithm gives that by default. The draft RFC gives a way for a
> mailing list to either insist on public followup or to strongly
> discourage it.
In the event of:
* user reports problem to ML
* admin asks for info (s)he knows to be sensitive
* user replies to ML
This is easily fixed by the admin explicitly setting reply-to for that
single message. However, reply-to becomes meaningless in such a
situation where admin x always sets the header (as in the odd case I
mentioned above), again because of the misdirected-reply problem.
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: Use the reply-to standard header to make it possible
for users to "do what they mean", by setting a default and using it when
a message comes in that _doesn't_ have a reply-to set on its header and
is intended to be posted to the list.
Even better, this eliminates the problem of:
I post message A without reply-to:
To: m...@example.org
From: m...@zest.trausch.us
Someone responds with message B and hits reply-all, also without
reply-to:
To: m...@zest.trausch.us
Cc: m...@example.org
From: u...@example.org
And then I don't get a message with a List-Post header _at all_. That
is one failing that your algorithm cannot fix, unless the ML sends its
second copy (and most MLs are configured not to do so, because users
find it inconvenient).
--- Mike
--
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
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
