Re: [despammed] Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer <ino@despammed.com>]

prj@po.cwru.edu (Paul Jarc) writes:

>> only when starting a thread, there is no information in the To/Cc,
>
> We have to-list, to-address, header fields from group parameters,
> and message-default-mail-headers.  At least.

no.  you people always think that everybody wants separate groups for
each mailinglist and splits that way.  well, i don't.  i subscribe to
as many lists i can manage in me poor head, and i read each and every
post, but i store only the ones i need.  so i have a central mailbox
collecting everything, all splitting is done by procmail before that.

meaning i can't use any of the group parameters, even if there were
thousands of them.  so what do _i_ do?  i know, i know, "roll your
own"...

>> 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.
>
> It would be better to add a new command for that, so as not to
> disturb users of the old commands.

ok.

>> reading through a batch of emails it seems that senders are commonly
>> stored in Return-Path, Delivered-To and [...]
>
> Delivered-To is a recipient address, not sender.

sure.  what a big mistake of mine.  what i was hinting at is the fact
that there are no RFC-ified headers one can look at for envelope
information, although typical MTAs offer lots of functionality based
on envelope information.  it seems natural to let users influence and
check envelope information.   eg. i still don't know why
posting-styles doesn't reliably set my sender.  the workaround is
easy, but it takes hours of that time i didn't know i had to invest.

let's be done with this.  btw, some part of my mailing now generates
correct MFTs.

clemens