From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/46933 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: Thu, 03 Oct 2002 01:16:06 +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 1033607568 11692 127.0.0.1 (3 Oct 2002 01:12:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 3 Oct 2002 01:12:48 +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 17wuXm-00032K-00 for ; Thu, 03 Oct 2002 03:12:46 +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 17wuWj-0002M0-00; Wed, 02 Oct 2002 20:11:41 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 02 Oct 2002 20:12:22 -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 UAA01386 for ; Wed, 2 Oct 2002 20:12:06 -0500 (CDT) Original-Received: (qmail 6297 invoked by alias); 3 Oct 2002 01:11:20 -0000 Original-Received: (qmail 6292 invoked from network); 3 Oct 2002 01:11:20 -0000 Original-Received: from main.gmane.org (80.91.224.249) by gnus.org with SMTP; 3 Oct 2002 01:11:20 -0000 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17wuW0-0002xc-00 for ; Thu, 03 Oct 2002 03:10:56 +0200 Original-To: ding@gnus.org X-Injected-Via-Gmane: http://gmane.org/ Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17wuW0-0002xS-00 for ; Thu, 03 Oct 2002 03:10:56 +0200 Original-Path: ID-23066.news.dfncis.de!not-for-mail Original-Lines: 110 Original-NNTP-Posting-Host: p3e9baa94.dip.t-dialin.net Original-X-Trace: main.gmane.org 1033607456 11373 62.155.170.148 (3 Oct 2002 01:10:56 GMT) Original-X-Complaints-To: usenet@main.gmane.org Original-NNTP-Posting-Date: Thu, 3 Oct 2002 01:10:56 +0000 (UTC) User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386--freebsd) Cancel-Lock: sha1:VlZhXGet3UfZRd4cVRqpICkoCbk= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:46933 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:46933 prj@po.cwru.edu (Paul Jarc) writes: > 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. ... unless you aren't subscribed. never mind: to my astonishment ding is bold enough to let non-members post. > Anyway, this has to do > with how Gnus handles MFT in incoming messages, which is completely > separate from generating MFT for outgoing messages. yes, i think this is true (but i have the strong feeling i forgot something important...). > Why don't you add "ding@gnus.org" to message-subscribed-addresses? then i need another file or some mechanism that distinguishes between lists i'm really subscribed to and those which i can read, but maybe not post to. but i just did, messages honouring the MFT thus generated will appear on gmane, so i get to see them. i have the addresses of the lists i'm subscribed to in one place, which is also used in the filtering stage (procmail) to add a header tagging a message as coming from a list. these addresses used to be regular expressions, but it seems generally better to have the addresses spelled out. > 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 is what i proposed a few sentences later, only i called the field X-Gnus-MFT. >> 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. (i) _is_ the current behaviour! > 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. ok. > [two cases: replying and 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. only when starting a thread, there is no information in the To/Cc, so what do we put into X-Gnus-MFT? if the user doesn't split lists into separate groups, we couldn't even look at the To address of the group parameters. >> 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"). basically, yes. i'm beginning to think that this entire business could be simplified. C-c C-f C-a (init unsubscribed-mft) or C-c C-f C-m (move to mft) could have their semantics changed in that they re-generate the header value according to the current contents of To/Cc. together with editing header fields, this would be enough for me. >> 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? it would be ideal if the headers could be made trustworthy by yet unknown magic, but for me it would suffice if i at least knew their names ;) reading through a batch of emails it seems that senders are commonly stored in Return-Path, Delivered-To and maybe you can look at the leading "From_...@..." if all else fails, but regarding receivers, it's much worse. with some mail-providers, i'm forced to scan the received lines, because they are the only places i can see that darned envelope receiver. so yes, i would very much like them to be mandatory. envelope info is needed so many places, why does it have to be a mythical experience to see it? clemens