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

[prj@po.cwru.edu (Paul Jarc)]

Clemens Fischer <ino@despammed.com> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> 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.

I thought you were suggesting that X-Gnus-MFT would contain the same
thing that MFT would contain - i.e., the same addresses as To/Cc.
X-Gnus-Make-MFT-For would be different - it would contain only the
*subscribed* addresses from To/Cc.  Then you would know that if you
removed all those addresses from To/Cc and left only unsubscribed
addresses, no MFT would be generated.  This is more informative than a
simple copy of the initial To/Cc.

>>> 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) _is_ the current behaviour!

It's not clear.  What does (i) do when the user puts MFT into the
message manually before sending?  Anyway, I think we already have
enough configurability: if you don't want Gnus to ever generate MFT
automatically, just don't set any message-subscribed-* variables.

> 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.

> if the user doesn't split lists into separate groups, we couldn't
> even look at the To address of the group parameters.

Nor should we.  To/Cc is exactly where MFT will come from, so it's the
only place we should look to guess what MFT will be when we send the
message later.  To/Cc can come from lots of different places in turn,
but we don't care about that.

> 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.

> 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.


paul