[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: