[Mailman-Developers] Reply-To munging considered *carefully*
Michael B. Trausch
mbt at zest.trausch.us
Wed Oct 14 00:56:59 CEST 2009
Note, I am not subscribed to mailman-developers at 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:
>
> 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.
--
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
More information about the Mailman-Developers
mailing list