At 4:12 PM +0100 2003/10/23, Tom Thomson wrote:
Some lists are designed to anonymise
the originator of the message; the design of such a list will be broken
instantly by a decision not to munge the Reply-To header.
Those lists are very uncommon, and are not the audience that is
being addressed by the previously mentioned page. If you want to set
up an anonymizing list, then obviously you would have some additional
requirements that you would need to meet.
For many lists,
the most commonly intended reply action is to send the reply to the list
without a second copy to the originator: as the most common action, it
should be achievable with a single mouse-click or key-stroke
In an ideal world, that would be easily achievable.
This is not an ideal world.
- and almost
all the MUAs out there will not allow you to do that if the list software
doesn't munge the Reply-To header.
So we break something for many users for whom there is no
alternative, simply to make it easier for other users to do the
"default" action, and for whom if they don't want the default action
they're usually also screwed?
This sounds like an extremely brain-damaged idea.
For other lists the most commonly
required reply action is a reply to the list moderator - again, Reply-To
header munging is required to make this the default action of most MUAs.
Again, not the most common type of list, and for which the
previously quoted page is not attempting to address.
Each list has its own requirements, the standardised message of
RFC2822 is not adequate to cover all these requirements without header
munging.
Agreed -- you can't use header munging to conform to the issues
and requirements of all mailing lists, especially not with all MUAs
(since many are severely broken).
Therefore, you should make no attempt to use header munging for
this purpose.
What I want out of an MUA is to be able to chose between reply to
originator, reply to list, reply to list with copy to originator, reply to
list with copy to cc reipients of the original message, .... quite a few
options.
Get a better MUA. Don't try to fix this problem within the mailing
list.
The headers provided by RFC2822 are not adequate to permit an MUA
to offer all these options in a simple and straightforward usable manner.
Sounds like you need to write an RFC to detail all these issues
and lay out the suggestions for MUA authors.
So I think this list would probably be improved
by adding the munging
That's assuming that no one on the list (currently or in the
future) is/will be using an MUA that is known to be severely broken,
in such a way that they are completely unable to reply to any message
other than what is specified in the "Reply-To:" header.
Not a valid assumption.
- biut I don't think it's worth arguing about;
Then why are we having this argument?
what I
do think is worth arguing about is someone claiming that as a general
principal such munging should not be done: the RFCs make no attenmpt to
dictate to me (or anyone else) what features I should put into applications
I supply to my users, and I don't like to see Chip claiming they do and
neither do I like to see Brad quoting him as if he were holy writ.
His page hasn't been updated to make reference to the latest
RFCs, but then it doesn't really need to. The issues with regards to
the broken MUAs haven't changed, and many sites are still running the
same ten-year old software that was at the heart of the problem
originally, which lead to Chip writing that page.
If the problem hasn't changed, it doesn't make a whole lot of
sense to try to update the description of the problem, or
recommendations on how to avoid tickling the problem and making it
even worse.
I make reference to this page because it's the best collection
I've seen yet for the various problems and the ways to deal with them.
Would you prefer that I write all this up as an RFC and really
set things in stone?
--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg