From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/46928 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: [despammed] Re: Why does Gnus generates Lines: header in mail? Date: Wed, 02 Oct 2002 16:25:25 -0400 Organization: What did you have in mind? A short, blunt, human pyramid? 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 1033590382 27077 127.0.0.1 (2 Oct 2002 20:26:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 2 Oct 2002 20:26:22 +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 17wq4a-00072Q-00 for ; Wed, 02 Oct 2002 22:26:20 +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 17wq47-0000nJ-00; Wed, 02 Oct 2002 15:25:51 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 02 Oct 2002 15:26:32 -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 PAA00890 for ; Wed, 2 Oct 2002 15:26:17 -0500 (CDT) Original-Received: (qmail 18943 invoked by alias); 2 Oct 2002 20:25:31 -0000 Original-Received: (qmail 18938 invoked from network); 2 Oct 2002 20:25:31 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (@129.22.96.25) by gnus.org with SMTP; 2 Oct 2002 20:25:31 -0000 Original-Received: (qmail 11960 invoked by uid 500); 2 Oct 2002 20:25:48 -0000 Original-To: ding@gnus.org In-Reply-To: ("clemens fischer"'s message of "2 Oct 2002 21:44:52 +0200") Mail-Copies-To: nobody Mail-Followup-To: ding@gnus.org Original-Lines: 107 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:46928 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:46928 "clemens fischer" wrote: > 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. My previous message was addressed as: To: Clemens Fischer Cc: ding@gnus.org So you're saying you started to compose a reply to that message, and the initial message buffer had only: To: ding@gnus.org Is that what happened? That seems fine to me. Anyway, this has to do with how Gnus handles MFT in incoming messages, which is completely separate from generating MFT for outgoing messages. > i read ding on gmane, that's all. I don't think that matters. > now gnus won't find ding@gnus in the MFT-list, so > it won't generate a MFT, although i'd like it to. Why don't you add "ding@gnus.org" to message-subscribed-addresses? > 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. I don't see how you read that into it. I didn't mean it that way. > my position is this: show the MFT on answers in general. I just don't see the point. What information are you really looking for? If you want to know what the contents of the generated MFT will be, you can just look at To and Cc. If you want to know whether MFT will be generated at all, then that might be useful information that could be added to the initial message buffer, but it could be done in a different way that would not cause a wrong MFT to be sent. E.g., a field could be added like: X-Gnus-Make-MFT-For: ding@gnus.org This would mean that that address (which was in the initial To/Cc) would cause Gnus to generate MFT. So you would know that as long as you don't remove that address from To/Cc, Gnus will generate MFT. Then when you actually send the message, this field would be removed. It's just there for your information during the editing of the message. > 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. Neither of those does what I want. I want the current behavior: use my MFT if I add one myself; otherwise generate one based on To/Cc if I'm subscribed to one of those addresses. AFAICT, what you want is not different behavior, but just more information during message editing. So let's provide that information without changing the behavior. > 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: The behavior is supposed to be the same for both cases: MFT for outgoing messages (if autogenerated at all) is copied from To/Cc. So if X-Gnus-MFT were to be generated, it would be based on the initial To/Cc list. But that list can be set in many different ways; MFT on an incoming message is just one of them. The only interaction between incoming MFT and outgoing MFT is that the incoming MFT, if present, specifies the initial To/Cc list. > 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. That's how MFT works now (if by "blank" you mean "nonexistent"). > you seem to think that it's not worth the trouble with the risk of > users running misconfigured software or making errors. It's not a matter of misconfiguration. Adding MFT to the initial message buffer makes it easier to send a wrong MFT by accident. You could change the To/Cc list. If you do, who will change MFT to match? Gnus can't, because it's not smart enough to know whether the MFT in the buffer is what you want; it has to assume you did not make a mistake. But you could make a mistake, by forgetting to update MFT. > (is ding members-only?). I don't think so. > i wish RFC-2822 had a mandatory field with envelope information in > it. It wouldn't be trustworthy if it were set by the sender. As long as your own receiving MTA adds those fields (e.g., Return-Path and Delivered-To for qmail), does it really matter whether they're required? paul