From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37337 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: Request: ding subscribers' group parameter Date: Tue, 31 Jul 2001 17:57:37 -0400 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1035172770 13331 80.91.224.250 (21 Oct 2002 03:59:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:59:30 +0000 (UTC) Return-Path: Return-Path: Original-Received: (qmail 28379 invoked from network); 31 Jul 2001 21:57:38 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (261@129.22.96.25) by gnus.org with SMTP; 31 Jul 2001 21:57:38 -0000 Original-Received: (qmail 7899 invoked by uid 500); 31 Jul 2001 21:57:59 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: (Karl Kleinpaste's message of "Tue, 31 Jul 2001 17:37:27 -0400") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Original-Lines: 62 Xref: main.gmane.org gmane.emacs.gnus.general:37337 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37337 Karl Kleinpaste writes: > Gnus provides a feature explicitly designed=B9 to eliminate duplicate > copies to individuals inhabiting mailing lists. This feature works > every single time, in every single instance, if only the list > subscribers will deploy it as intended. Right. > Yet we should ignore this feature, instead in favor of Yet Another > Header. No. We should *also* support Yet Another Header, because the header field is more expressive than to-address, and that extra expressiveness can be useful. Have a look at . > There is _no reason_ for any ding subscriber /not/ to be using to-address. Someone may post a question here, but not be subscribed to the list. They might add "Mail-Followup-To: ding@gnus.org, me@here.net" to explicitly indicate that they want to receive extra copies of messages in the thread. If a list member uses to-address, then MFT will override that for this message, but further followups won't be sent to the OP unless MFT is preserved in each additional message. So, yes, this is a bit fragile, but it does more than to-address is capable of. OTOH, I think Mail-Copies-To will discourage extra copies (when you want to discourage them) without interfering with MFT. And it's automatically obeyed by everyone else's Gnus, without requiring extra configuration on their part. I can't think of any case where to-address is preferable to MCT. to-address puts the decision into the wrong hands - this preference should be expressed by the sender, not the recipient. > Instead of everyone just doing that, and the problem disappearing in > the course of a single day, You're never going to get everyone to do anything in a single day. > we now have a full-blown discussion over code changes in order to > handle non-existent failure cases in what is already the default > situation when the property is properly in use. to-address is *not* set by default. MFT and MCT *are* respected by default. > If you want to insert MFT headers, fine, but "to-address" provides > exactly the feature you're looking for on *this* list, among *this* > universe of subscribers. What about non-subscribers? > And the price of lunch says MFTs won't do a bit of good on > yahoogroups mailing lists, where Joe Random Users from all over the > planet are still using Outlook Express as packaged with Win98 which > has no awareness of MFT at all. There's nothing to be done in such cases anyway. You'll get extra copies from those people regardless of whether you send them any. paul