From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/46926 Path: main.gmane.org!not-for-mail From: "clemens fischer" Newsgroups: gmane.emacs.gnus.general Subject: Re: [despammed] Re: Why does Gnus generates Lines: header in mail? Date: 2 Oct 2002 21:44:52 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87n0pzj9db.fsf@mail.paradoxical.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1033588027 19641 127.0.0.1 (2 Oct 2002 19:47:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 2 Oct 2002 19:47:07 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17wpSb-00056f-00 for ; Wed, 02 Oct 2002 21:47:06 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17wpRC-0000UZ-00; Wed, 02 Oct 2002 14:45:38 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 02 Oct 2002 14:46:18 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id OAA00822 for ; Wed, 2 Oct 2002 14:46:03 -0500 (CDT) Original-Received: (qmail 17185 invoked by alias); 2 Oct 2002 19:45:16 -0000 Original-Received: (qmail 17180 invoked from network); 2 Oct 2002 19:45:16 -0000 Original-Received: from mailout02.sul.t-online.com (194.25.134.17) by gnus.org with SMTP; 2 Oct 2002 19:45:16 -0000 Original-Received: from fwd05.sul.t-online.de by mailout02.sul.t-online.com with smtp id 17wpQZ-0005Zf-06; Wed, 02 Oct 2002 21:44:59 +0200 Original-Received: from spotteswoode.dnsalias.org (520082050842-0001@[62.155.170.148]) by fmrl05.sul.t-online.com with esmtp id 17wpQT-15ZuCWC; Wed, 2 Oct 2002 21:44:53 +0200 Original-Received: (qmail 3068 invoked by uid 0); 2 Oct 2002 19:44:52 -0000 Original-To: ding@gnus.org, "Paul Jarc" In-Reply-To: (prj@po.cwru.edu's message of "Wed, 02 Oct 2002 12:49:05 -0400") Original-Lines: 60 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386--freebsd) X-Sender: 520082050842-0001@t-dialin.net Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:46926 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:46926 prj@po.cwru.edu (Paul Jarc) writes: > automatic MFT from a manual MFT you supplied yourself. The only way > to make the generated MFT be correct is for it not to be shown before > you send the message. well, i'm using MFT as generated by a recent Oort right now, and i had to edit the generated To, because it was wrong. gnus saw my email and ding@gnus.org, deleted my own and left me with a buffer carrying a To header to a mailinglist which i'm not subscribed to. i read ding on gmane, that's all. now gnus won't find ding@gnus in the MFT-list, so it won't generate a MFT, although i'd like it to. your statement "The only way to make the generated MFT be correct is for it not to be shown before you send the message." is extreme in that it hints in either me beeing an idiot or gnus knowing better. my position is this: show the MFT on answers in general. in most cases gnus knows enough before sending to get it right. the MFT would have to be changed if To or Cc had changed. let it be configurable: (i) generate MFT like it is now, calculated on the To/Cc and a list of subscribed email-lists, (ii) always use the MFT as set by the user. maybe we could use an additional X-Gnus-MFT header instead of the MFT itself. gnus displays and presets this header based on To/Cc. the configuration takes care of the actual MFT used. all this on replies. for starting a new thread: if X-Gnus-MFT is left blank by the user, gnus is to generate the MFT as usual, if it isn't blank, override the magic. you seem to think that it's not worth the trouble with the risk of users running misconfigured software or making errors. and i wish i had a choice. btw: i'm still not subscribed, but i don't know what will happen (is ding members-only?). only thing i know is that you will get this message, although you specifically wanted it on the list. >> this sounds reasonable on first sight, but it may well be that i >> beeing the sender of some message already know that some of these >> addresses wouldn't want a followup (copies of outgoing email needed >> locally, for example). > > Then you want to remove them from To/Cc, not just MFT. > (setq message-hierarchical-addresses > '(("list@address" "subscriber1@address" ...) > ...)) oh! i didn't know about this tweakable, thanks. it doesn't solve my problems 100%, but i'm getting closer :) >> Sender: for envelope info > > This header field is not necessarily the same as the SMTP envelope > sender address. yes. i should have written it the other way around: "for envelope info: one of Sender, Return-Path etc., checked in this order". i wish RFC-2822 had a mandatory field with envelope information in it. clemens