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

["clemens fischer" <ino-e1f066c1@spotteswoode.de.eu.org>]

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