Re: cc'ing (was Re: Mozilla goes GTK+ instead of Qt)
On 03-Nov-1998, Mikolaj J. Habryn <dichro-f8e2243b@eris.rcpt.to> wrote:
> >>>>> "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.
No, I argue that duplicates are bad. All information is good, but
2 copies of the same information is useless.
If you want no list traffic -- unsubscribe.
If you want infinite list traffic -- ask for spam.
The trick is to get lots of useful list traffic.
>
> 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.
Well it has more than one purpose according to RFC-822. This isn't
my fault, I didn't write it. Almost certainly there should have
been two headers -- "Reply-To:" and "List-Reply-To:".
The fact is, RFC-822 doesn't assign precendence to these possible
uses, and so saying it is the "users right" to do one thing or another
is debatable at best. All uses are equally valid in the eye of
RFC-822.
The one argument of the web page that is worthwhile is that mail
is easy to screw up, so doing one less manipulation is good.
But I don't like the way it completely ignores the costs of such
things.
>
> 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.
Actually, you need a third reply-to which is "list reply" and you
need to tell it the names of lists. Mutt has this for instance.
It auto-trims everything but list list address.
> 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.
In a perfect world yes. But sometimes the tradeoff is acceptable.
--
Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety. - Benjamin Franklin
Tyson Dowd <tyson@tyse.net> http://tyse.net
Reply to: