Re: cc'ing (was Re: Mozilla goes GTK+ instead of Qt)
>>>>> "TD" == Tyson Dowd <trd@cs.mu.OZ.AU> writes:
TD> 1. Keeps discussion on the list. No more seeing requests for
TD> help and wondering if anyone else has helped them yet. No
TD> more information falling off the list. No more accidental
TD> thread jumping from private to public lists.
Here you argue to increase list traffic...
TD> 2. Stops CCs which clutter lists and increase download times
TD> (and yes, of course OTHER things can fix this -- for example
TD> you could unsubscribe or filter).
...and here you argue that increased list traffic is bad.
TD> Not according to RFC-822.
TD> Setting From is perfectly workable. Unless your ISP is
TD> broken.
Here you call upon RFC822 to support you, and elsewhere you demand
that Reply-To be clobbered, thus making it impossible for it to serve
it's RFC822 purpose.
TD> As I pointed out originally, dupe filtering is basically
TD> useless for pay-as-you-go people. But otherwise it's not a
TD> bad solution to duplicates -- but duplicates are really a
TD> small part of the problem IMHO -- I am MUCH more concerned
TD> about information that falls off the list.
I quite agree - I, too, pay for email by the byte, but I strongly
oppose Reply-To munging. Your mailer has two reply keys - group reply,
and author reply. Without Reply-To munging, their function is a
superset of what it should be (group reply may happen to target a few
more recipients, depending on how clever it is). With Reply-To
munging, their function is a *subset* of what it should be - author
reply does not reply to the author.
I personally have been bitten on several occasions by this. Not
always by forwarding deeply personal information to a larger than
intended audience, but by broadcasting mail that was not required to
be broadcast. In some cases, it's a question of list administrators
trying to boost their list volumes. From my perspective, protocol
purity dictates that Reply-To be left untouched.
m.
Reply to: