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

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

"clemens fischer" <ino-e1f066c1@spotteswoode.de.eu.org> 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 <ino@despammed.com>
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