Why does Gnus generates Lines: header in mail?

Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

How about this patch?

The Lines: header seems to be deprecated even for news in RFC1036bis.

Also, shouldn't Gnus generate the In-Reply-To header in the message
buffer when you press R or F?  The References: header is generated.
Possibly neither should be generated though (and people that want to
see it can use `message-generate-headers-first').  Opinions?

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.252
diff -u -p -u -w -r6.252 message.el
--- message.el	2002/09/26 02:21:37	6.252
+++ message.el	2002/09/29 14:44:22
@@ -206,11 +206,11 @@ header, remove it from this list."
   :type '(repeat sexp))
 
 (defcustom message-required-mail-headers
-  '(From Subject Date (optional . In-Reply-To) Message-ID Lines
+  '(From Subject Date (optional . In-Reply-To) Message-ID
 	 (optional . User-Agent))
   "*Headers to be generated or prompted for when mailing a message.
 It is recommended that From, Date, To, Subject and Message-ID be
-included.  Organization, Lines and User-Agent are optional."
+included.  Organization and User-Agent are optional."
   :group 'message-mail
   :group 'message-headers
   :type '(repeat sexp))

Re: Why does Gnus generates Lines: header in mail?

[Karl Kleinpaste]

Simon Josefsson <jas@extundo.com> writes:
> How about this patch?
> The Lines: header seems to be deprecated even for news in RFC1036bis.

Why do you want to get rid of it?  What purpose does removal of a
feature serve?

I find line count to be very useful in *Summary* because it gives me a
sense of how much babbling someone has done, and I also score up or
down on line count in some groups.

I always felt that the deprecation of Lines was due merely to Henry
Spencer's (and perhaps Geoff Collyer's) personal bias against it, for
which I have no explanation.

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Karl Kleinpaste <karl@charcoal.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> How about this patch?
>> The Lines: header seems to be deprecated even for news in RFC1036bis.
>
> Why do you want to get rid of it?  What purpose does removal of a
> feature serve?

Well, what purpose does having a Lines: header serve?  It is not a
standard mail header so its presence should probably be justified.

> I find line count to be very useful in *Summary* because it gives me a
> sense of how much babbling someone has done, and I also score up or
> down on line count in some groups.

Does this feature depend on the sender sending a Lines: header?  Most
MUAs don't send the Lines: header, and I still get this number in the
summary buffers.  See my original mail which didn't include a Lines:
header.

> I always felt that the deprecation of Lines was due merely to Henry
> Spencer's (and perhaps Geoff Collyer's) personal bias against it, for
> which I have no explanation.

I'm not saying we should change it for news, only mail.  A possible
explanation for why it should be removed could be to compare the
merits of the Content-Length: mail header, but I don't know enough
about news to tell if the same argument applies.

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Also, shouldn't Gnus generate the In-Reply-To header in the message
> buffer when you press R or F?  The References: header is generated.
> Possibly neither should be generated though (and people that want to
> see it can use `message-generate-headers-first').  Opinions?

IIUC, the In-Reply-To header contains a pointer to just one message,
whereas the References header contains pointers to many messages.
With the multiple messages, Gnus can fill gaps in the threading.  I
like the filling-gaps feature.

Unless I misunderstood something, I vote for keeping References.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Also, shouldn't Gnus generate the In-Reply-To header in the message
>> buffer when you press R or F?  The References: header is generated.
>> Possibly neither should be generated though (and people that want to
>> see it can use `message-generate-headers-first').  Opinions?
>
> IIUC, the In-Reply-To header contains a pointer to just one message,
> whereas the References header contains pointers to many messages.
> With the multiple messages, Gnus can fill gaps in the threading.  I
> like the filling-gaps feature.
>
> Unless I misunderstood something, I vote for keeping References.

I wasn't clear -- I wanted to remove Lines: completely for mail, but
the In-Reply-To/References question was only if they were to be
displayed in the message buffer by default.  Currently, References: is
shown in the message buffer when you press F but In-Reply-To: is not,
which is rather confusing.  Both headers will be present in the sent
message.  I wanted to make the behaviour the same, either both
In-Reply-To and References: are shown when you press F or they are not
shown.  They should both still be added to outgoing mail, of course.

The reason is that I often have a habit of pressing R or F and then
removing the References: line and change Subject in order to start a
new thread.  This won't work well since In-Reply-To: is automatically
added when the message is sent though.  Either both headers should be
shown by default, or none and I will have to use
`message-generate-headers-first'.

I vote for not showing References: by default.  People that care about
the header (very few I think) can frob m-g-h-f.  What do you think?

Re: Why does Gnus generates Lines: header in mail?

[Karl Kleinpaste]

Simon Josefsson <jas@extundo.com> writes:
> Well, what purpose does having a Lines: header serve?  It is not a
> standard mail header so its presence should probably be justified.

As opposed to Mail-Copies-To, X-Face, or X-Hashcash...?

> Does this feature depend on the sender sending a Lines: header?  Most
> MUAs don't send the Lines: header, and I still get this number in the
> summary buffers.  See my original mail which didn't include a Lines:
> header.

If Lines were no longer generated locally, then it won't appear in
one's Gcc'd copies.

I just see no reason for dismantling behavior which causes no
difficulty and which has the potential to be useful.

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Karl Kleinpaste <karl@charcoal.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> Well, what purpose does having a Lines: header serve?  It is not a
>> standard mail header so its presence should probably be justified.
>
> As opposed to Mail-Copies-To, X-Face, or X-Hashcash...?

X-* is blessed by the standard to contain experimental stuff, so I
don't see a problem there.  Mail-Copies-To has value and even
interoperates fairly well.  If Lines: has value, I won't continue
argue it should be removed, but I haven't understood where that value
is.

>> Does this feature depend on the sender sending a Lines: header?  Most
>> MUAs don't send the Lines: header, and I still get this number in the
>> summary buffers.  See my original mail which didn't include a Lines:
>> header.
>
> If Lines were no longer generated locally, then it won't appear in
> one's Gcc'd copies.

What problems are caused by this?  Does any writable backend depend on
the Lines: header being generated by Gnus?  I have disabled Lines: and
GCC:ed mail to a nnml, nnfolder and nnimap and it this does not seem
to cause any problems.  Nnml and nnfolder adds Lines: if it does not
exists, so the header do appear in GCC'd copies.  I only wanted to
change this in message, not in the backends.

> I just see no reason for dismantling behavior which causes no
> difficulty and which has the potential to be useful.

OK.  Since it is possible to customize, perhaps that is enough.

Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery]

Karl Kleinpaste <karl@charcoal.com> writes:

> Why do you want to get rid of it?  What purpose does removal of a
> feature serve?

It saves pointless work and a small amount of article size, and it makes
it less likely that news readers will get confused by incorrect Lines
headers.  The header is completely, 100% worthless.

> I find line count to be very useful in *Summary* because it gives me a
> sense of how much babbling someone has done, and I also score up or
> down on line count in some groups.

All that information comes from the overview data, which is guaranteed to
be correct.  There's no such guarantee for the Lines header, and you'll
still be able to do all these things without that header.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why does Gnus generates Lines: header in mail?

[Michael Cook]

Russ Allbery <rra@stanford.edu> writes:

> The header is completely, 100% worthless.

i think the original intention was that you could get an indication
of how big the article is without having to examine the body.

m.

Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery]

Michael Cook <michael@waxrat.com> writes:
> Russ Allbery <rra@stanford.edu> writes:

>> The header is completely, 100% worthless.

> i think the original intention was that you could get an indication
> of how big the article is without having to examine the body.

Yes, but this was completely obsoleted by overview, which does the same
thing.  (Lines is a purely Usenet thing; it was never an e-mail thing that
I've ever heard apart from some e-mail clients picking it up from Usenet.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> I wasn't clear -- I wanted to remove Lines: completely for mail, but
> the In-Reply-To/References question was only if they were to be
> displayed in the message buffer by default.  Currently, References: is
> shown in the message buffer when you press F but In-Reply-To: is not,
> which is rather confusing.  Both headers will be present in the sent
> message.  I wanted to make the behaviour the same, either both
> In-Reply-To and References: are shown when you press F or they are not
> shown.  They should both still be added to outgoing mail, of course.

Ah, sorry for my misunderstanding.

Yes, I also have users who find the header confusing.  But I think
that showing References was done on purpose: sometimes the header can
get long, then users can delete part of it.

But maybe these days the References header is shortened
automatically, so that this is not an argument any more.

Let's generate References on sending, too.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Jorgen Schaefer]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Let's generate References on sending, too.

I'd prefer to really see *all* non-default headers I'm including
in my message when pressing F... That way, I can edit or remove
them if I want to. It's not really nice to the user to do a lot of
behind-the-stage-magic...

Greetings,
        -- Jorgen

-- 
((email . "forcer@forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Jorgen Schaefer <forcer@forcix.cx> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> Let's generate References on sending, too.
>
> I'd prefer to really see *all* non-default headers I'm including
> in my message when pressing F... That way, I can edit or remove
> them if I want to. It's not really nice to the user to do a lot of
> behind-the-stage-magic...

Then you want to frob `message-generate-headers-first'.  Is this OK,
or do you still want to see all headers by default?  I think most
people don't have or want to see the cruft.

Re: Why does Gnus generates Lines: header in mail?

[Jorgen Schaefer]

Simon Josefsson <jas@extundo.com> writes:

> Jorgen Schaefer <forcer@forcix.cx> writes:
> 
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >
> >> Let's generate References on sending, too.
> >
> > I'd prefer to really see *all* non-default headers I'm including
> > in my message when pressing F... That way, I can edit or remove
> > them if I want to. It's not really nice to the user to do a lot of
> > behind-the-stage-magic...
> 
> Then you want to frob `message-generate-headers-first'.  Is this OK,
> or do you still want to see all headers by default?  I think most
> people don't have or want to see the cruft.

Sounds good to me. I didn't know about that variable :) Thanks!

Then it really doesn't make sense to have a seperate case for
References...

Greetings,
        -- Jorgen

-- 
((email . "forcer@forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))

Re: Why does Gnus generates Lines: header in mail?

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Sun, 29 Sep 2002
| X-* is blessed by the standard to contain experimental stuff, so I don't
| see a problem there.  Mail-Copies-To has value and even interoperates
| fairly well.  If Lines: has value, I won't continue argue it should be
| removed, but I haven't understood where that value is.

The purpose of Lines is quite simple: it gives a ballpark estimate as to
the size of a message, thus allowing the client the ability not to download
messages that exceed a particular size.

For example, POP does not have a mechanism by which it can determine the
size of messages.  But it can get all the headers.  A POP client can grab
the headers of all messages, check the Lines headers for each, and skip any
messages that exceed a user-defined threshold.  This is useful, for
example, if you happen to be a travelling sales engineer currently
somewhere in India using a cellular/gsm phone at 9600 baud to download your
mail but don't want the 150MB PowerPoint presentations that your manager
sent out to everyone, at least not until you get back to your office and a
T1.  I am not making this up.  I have an SE who routinely does this.

On the Usenet side of things, Gnus Agent uses Lines headers the same way,
to determine if a message qualifies as "long" and does not automatically
retrieve articles that exceed the "long" threshold.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> For example, POP does not have a mechanism by which it can determine the
> size of messages.  But it can get all the headers.  A POP client can
> grab the headers of all messages, check the Lines headers for each, and
> skip any messages that exceed a user-defined threshold.  This is useful,
> for example, if you happen to be a travelling sales engineer currently
> somewhere in India using a cellular/gsm phone at 9600 baud to download
> your mail but don't want the 150MB PowerPoint presentations that your
> manager sent out to everyone, at least not until you get back to your
> office and a T1.  I am not making this up.  I have an SE who routinely
> does this.

Do enough mail clients generate accurate Lines headers to make this
worthwhile?

> On the Usenet side of things, Gnus Agent uses Lines headers the same way,
> to determine if a message qualifies as "long" and does not automatically
> retrieve articles that exceed the "long" threshold.

It shouldn't.  It should be using overview for that information.  A huge
percentage of Lines headers in Usenet articles are simply completely wrong
(such as only counting half of a multipart/alternative, or being
calculated prior to signature appending, or simply being completely
unrelated to reality).  This is why USEFOR is going to remove the header
completely for Usenet; for Usenet, it's worthless.

Overview is required to include a line count.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why does Gnus generates Lines: header in mail?

[greg andruk]

Stainless Steel Rat wrote:

> For example, POP does not have a mechanism by which it can determine the
> size of messages.

??? In POP3, LIST returns the size of each message, and STAT returns the 
total for the inbox.

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Simon Josefsson <jas@extundo.com>  on Sun, 29 Sep 2002
> | X-* is blessed by the standard to contain experimental stuff, so I don't
> | see a problem there.  Mail-Copies-To has value and even interoperates
> | fairly well.  If Lines: has value, I won't continue argue it should be
> | removed, but I haven't understood where that value is.
>
> The purpose of Lines is quite simple: it gives a ballpark estimate as to
> the size of a message, thus allowing the client the ability not to download
> messages that exceed a particular size.

But it can't be used reliably since very few MUAs generate it.

> For example, POP does not have a mechanism by which it can determine the
> size of messages.

POP3 has.

> But it can get all the headers.  A POP client can grab the headers
> of all messages, check the Lines headers for each, and skip any
> messages that exceed a user-defined threshold.  This is useful, for
> example, if you happen to be a travelling sales engineer currently
> somewhere in India using a cellular/gsm phone at 9600 baud to
> download your mail but don't want the 150MB PowerPoint presentations
> that your manager sent out to everyone, at least not until you get
> back to your office and a T1.  I am not making this up.  I have an
> SE who routinely does this.

Is the manager who send 150MB powerpoint presentations using Gnus?  I
strongly doubt Outlook sends a Lines: header in mail.

> On the Usenet side of things, Gnus Agent uses Lines headers the same way,
> to determine if a message qualifies as "long" and does not automatically
> retrieve articles that exceed the "long" threshold.

No, the agent is using NOV information.

Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

Simon Josefsson <jas@extundo.com> writes:

> Then you want to frob `message-generate-headers-first'.  Is this OK,
> or do you still want to see all headers by default?  I think most
> people don't have or want to see the cruft.

i have message-generate-headers-first set, but i don't get to see
_all_ headers.  i would like to be able to see every header generated
on my behalf, customizable using a list in this header, for example.

clemens

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Clemens Fischer <ino@despammed.com> writes:

> i have message-generate-headers-first set, but i don't get to see
> _all_ headers.  i would like to be able to see every header generated
> on my behalf, customizable using a list in this header, for example.

Yes, allowing message-generate-headers-first to be a list is a good
idea.  Any takers?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Clemens Fischer <ino@despammed.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Then you want to frob `message-generate-headers-first'.  Is this OK,
>> or do you still want to see all headers by default?  I think most
>> people don't have or want to see the cruft.
>
> i have message-generate-headers-first set, but i don't get to see
> _all_ headers.

Which headers aren't shown?

> i would like to be able to see every header generated on my behalf,
> customizable using a list in this header, for example.

I like Kai's suggestion of making the variable be a list of headers to
generate (nil and t would still be valid choices).

Re: Why does Gnus generates Lines: header in mail?

[Stainless Steel Rat]

* Russ Allbery <rra@stanford.edu>  on Sun, 29 Sep 2002
| Do enough mail clients generate accurate Lines headers to make this
| worthwhile?

I do not know.  I suppose that depends on the definition of "enough".

| It shouldn't.  It should be using overview for that information.

Overview is a feature of the NNTP client specifications.  Not all news
readers use NNTP.  For example, a reader looking at a local spool can only
get the Lines count from a header field or by grabbing the article in its
entirety and counting.

YMMV.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Why does Gnus generates Lines: header in mail?

[Stainless Steel Rat]

* greg andruk <gja@meowing.net>  on Sun, 29 Sep 2002
| ??? In POP3, LIST returns the size of each message, and STAT returns the
| total for the inbox.

Y'know, you are correct.  I had forgotten that.

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

Simon Josefsson <jas@extundo.com> writes:

> Clemens Fischer <ino@despammed.com> writes:
>
>> i have message-generate-headers-first set, but i don't get to see
>> _all_ headers.
>
> Which headers aren't shown?

the Mail-Followup-To header is of the most important to me.  i have
all the settings in my setup to generate it, yet it seems it is
generated _after_ editing the message.  as this header is very
important, i let qmail generate one, too, but it wouldn't if it saw
one when handed the message.

i know there are headers which making doesn't make sense before the
message is sent, but when replying or fup'ing, there's set of headers
with a fixed meaning in the context, and those should be shown.

then the references:  i get to see them, but when i actually compose a
message, i do not want to see them.

configuring all this as a simple list is good, and if i can have them
in a certain order and with certain faces, i'll be happy.

clemens

Re: Why does Gnus generates Lines: header in mail?

[Josh Huber]

Clemens Fischer <ino@despammed.com> writes:

> the Mail-Followup-To header is of the most important to me.  i have
> all the settings in my setup to generate it, yet it seems it is
> generated _after_ editing the message.  as this header is very
> important, i let qmail generate one, too, but it wouldn't if it saw
> one when handed the message.

MFT is *supposed* to be generated at send-time.  It's based on the
actual recipients of the message, not the recipients when you happened
to create the followup.

http://cr.yp.to/proto/replyto.html

-- 
Josh Huber

Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Russ Allbery <rra@stanford.edu>  on Sun, 29 Sep 2002

> | It shouldn't.  It should be using overview for that information.

> Overview is a feature of the NNTP client specifications.  Not all news
> readers use NNTP.

This is, for all intents and purposes, no longer true.

> For example, a reader looking at a local spool

Essentially no one does this any more.  There may be one or two people who
are doing this out of a sense of nostalgia, but using NNTP to localhost is
faster, more reliable, and offers considerably more features.  And you
have the ability to do that already if you have the news in the first
place, unless you're just faking a local spool using a suck utility (and
why you'd do that rather than just use an off-line reader, which does
basically the same thing but a lot more reliably and with better control,
escapes me).

It's utterly pointless to do try to use the local spool unless you're
doing it for the same reason that you'd be programming on a Commodore 64
or porting gcc to a PDP-11.  Even the hard-line old Unix clients are
starting to drop support for reading from a local spool.

Not to mention that roughly 10% of the Lines headers seen in the wild on
Usenet are completely wrong.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why does Gnus generates Lines: header in mail?

[Stainless Steel Rat]

* Russ Allbery <rra@stanford.edu>  on Mon, 30 Sep 2002
| Not to mention that roughly 10% of the Lines headers seen in the wild on
| Usenet are completely wrong.

Let's just say that I do not agree with this being a valid reason for
deprecating it or eliminating it entirely.  Everything else, sure.  This,
no.

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.
       That and five bucks will get you a small coffee at Starbucks.

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Russ Allbery <rra@stanford.edu>  on Mon, 30 Sep 2002
> | Not to mention that roughly 10% of the Lines headers seen in the wild on
> | Usenet are completely wrong.
>
> Let's just say that I do not agree with this being a valid reason for
> deprecating it or eliminating it entirely.  Everything else, sure.  This,
> no.

As I wanted to remove the header for mail only, and not news which was
discussed here, are there still any objections to applying the patch?

Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Russ Allbery <rra@stanford.edu>  on Mon, 30 Sep 2002

> | Not to mention that roughly 10% of the Lines headers seen in the wild on
> | Usenet are completely wrong.

> Let's just say that I do not agree with this being a valid reason for
> deprecating it or eliminating it entirely.  Everything else, sure.  This,
> no.

The line of argument went like this on USEFOR, and I think the argument is
valid:

We looked around to see where Lines headers come from.  We found that many
of them are created by clients or the original server, that many servers
pass them on unchanged, and that some servers always replace them locally.
We also found that essentially no one enforces their accuracy (although
they may be replaced locally).

We thought about how to write up a specification for the Lines header
compatible with existing practice, and in order to make it useful, we
would have to mandate that each server generate its own and store it in
the article.  Generation of headers by the server is nasty; Xref already
requires special-case code in the news server, and adding another header
requires more special-case code.  Plus it means that there's more of the
article that may mutate as it passes around the net, which is bad except
where it's unavoidable (like Path and Xref).

So then we started looking at whether it really was worth fixing.  The
information is completely redundant with information in overview, which on
most servers is accurate whereas the header is not guaranteed to be.  We
then looked at the Lines headers in the wild, and found that they were
frequently so wildly inaccurate as to be worthless for any sort of
filtering; no property at all can be reliably assumed about an article
based on its Lines header.

So standardization of the header seemed pointless; it would just add
additional redundant information, when we could encourage people to use
overview or count lines themselves if they really want that information
and can't use NNTP.  Anyone using the header right now already is having
problems, due to the frequent inaccuracy of the header.  The current
existing practice was such a disaster that a lot of work would have to be
done to make the header reliable, and that effort seemed wasted.

We then considered just leaving it alone and not mentioning it at all, but
the disadvantage of that is that without any sort of clear statement,
people assume all sorts of cargo-cult things about the Lines header just
like they do now.  The reason why the current practice is such a mess is
because lots of different software authors have assumed lots of different
things about what the header even means.  So leaving the situation without
any documentation would just continue the confusion, and part of the goal
of standardization is to clean up areas like that.

So we made the decision to formally deprecate it and recommend that people
just stop supporting it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

Josh Huber <huber@alum.wpi.edu> writes:

> MFT is *supposed* to be generated at send-time.  It's based on the
> actual recipients of the message, not the recipients when you happened
> to create the followup.

you mean this differs after i edited it.  and i think i would like to
be able to set this value.  eg. i use a qmail-followup-to file to
generate the MFT from the recipients.  qmail automatically compares
the addresses in To and Cc to a list of emails in this file and
generates the MFT if one of them appears in that list, but _with all
values_ in To and Cc.

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).  whatever: i simply want to be able to edit
that header, or leave it alone, or let it be generated automatically,
and i don't see why i shouldn't mention it when you asked.

here's the list of headers i'd like to see.

From:
Subject:
Date:
Message-ID:
Sender:              for envelope info
In-Reply-To:
Mail-Followup-To:
Mail-Copies-To:
Content-Type:        to see what characterset/language the OP expects

Path:
Lines:               if it is "correct enough"
Reply-To:

X-headers            these are in case i want to complain
X-Complaints-To:
X-Report-Spam:
NNTP-Posting-Date:
User-Agent:


clemens

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Clemens Fischer <ino@despammed.com> writes:

> you mean this differs after i edited it.  and i think i would like to
> be able to set this value.  eg. i use a qmail-followup-to file to
> generate the MFT from the recipients.  qmail automatically compares
> the addresses in To and Cc to a list of emails in this file and
> generates the MFT if one of them appears in that list, but _with all
> values_ in To and Cc.

Gnus generates an MFT header which contains all To/Cc/From address,
minus the following:

- addresses that were excluded in the MFT header of the original
  message you're following up to
- message-subscribed-addresses and/or message-subscribed-address-file,
  message-subscribed-address-functions,
  gnus-parameter-subscribed-alist, and possibly other variables

I presume that this is the behavior you really want, so...

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> I like Kai's suggestion of making the variable be a list of headers to
> generate (nil and t would still be valid choices).

It was Clement's suggestion :-)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Kai Großjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> It was Clement's suggestion :-)

Clemens', of course.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Why does Gnus generates Lines: header in mail?

[Josh Huber]

Clemens Fischer <ino@despammed.com> writes:

> you mean this differs after i edited it.  and i think i would like
> to be able to set this value.  eg. i use a qmail-followup-to file to
> generate the MFT from the recipients.  qmail automatically compares
> the addresses in To and Cc to a list of emails in this file and
> generates the MFT if one of them appears in that list, but _with all
> values_ in To and Cc.

This is exactly what Gnus does.

> 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).  whatever: i simply want to be able to edit
> that header, or leave it alone, or let it be generated automatically,
> and i don't see why i shouldn't mention it when you asked.

And, this is also what Gnus does.  Gnus will not overwrite a MFT
header which is already present in the message buffer.

If you want to generate one for editing, use C-c C-f C-a
(message-gen-unsubscribed-mft)

If you want to specify what addresses are "subscribed" you have many
options (of course, this is gnus after all :)

message-subscribed-address-file - A file containing addresses the user is subscribed to.
message-subscribed-address-functions - Specifies functions for determining list subscription.
message-subscribed-addresses   - Specifies a list of addresses the user is subscribed to.
message-subscribed-regexps     - Specifies a list of addresses the user is subscribed to.

If this is not flexible enough for you, please say how you would like
it changed...

-- 
Josh Huber

Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

Josh Huber <huber@alum.wpi.edu> writes:

> And, this is also what Gnus does.  Gnus will not overwrite a MFT
> header which is already present in the message buffer.
>
> If you want to generate one for editing, use C-c C-f C-a
> (message-gen-unsubscribed-mft)
>
> If you want to specify what addresses are "subscribed" you have many
> options (of course, this is gnus after all :)
>
> message-subscribed-address-file
> message-subscribed-address-functions
> message-subscribed-addresses
> message-subscribed-regexps

ok, i've experimented with the above, but never saw a correct MFT in
my outgoing messages.  what worries me more is kai's statement about
gnus generating the MFT minus the entries in m-s-*, specifically
message-subscribed-address-file.  did i get this really wrong?

i have now compiled a file qmailmftfile used in the uppercase
environment variable of the same name for qmail, and this file is also
set as the value for m-s-a-file.  there's one complete, fully
qualified email address per line of this file, which contains nothing
else and no holes.  is this correct?

> If this is not flexible enough for you, please say how you would like
> it changed...

i'm not sure, it even seems overkill.  at first i thought i could
simply use the regular expressions describing the subscribed addresses
i had used for mutt, so this one, big regex was the value of
m-s-regexps.  then, after checking the code, i also used m-s-addresses
and finally added the file.  i'm not using the regexes anymore.

clemens

Re: Why does Gnus generates Lines: header in mail?

[Dan Christensen]

Simon Josefsson <jas@extundo.com> writes:

> Clemens Fischer <ino@despammed.com> writes:
>
>> i would like to be able to see every header generated on my behalf,
>> customizable using a list in this header, for example.
>
> I like [Clemens'] suggestion of making the variable be a list of headers to
> generate (nil and t would still be valid choices).

How about making 'most a valid choice too:  this could generate all
headers except those listed in message-deletable-headers.  Since those
change when you send the message, what you see isn't really accurate
anyways, so I expect many people would like this option.

Dan

-- 
Dan Christensen
jdc@uwo.ca

Re: Why does Gnus generates Lines: header in mail?

[Per Abrahamsen]

Karl Kleinpaste <karl@charcoal.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> Well, what purpose does having a Lines: header serve?  It is not a
>> standard mail header so its presence should probably be justified.
>
> As opposed to Mail-Copies-To, X-Face, or X-Hashcash...?

They are not generated by default.

I don't think anyone object to the user being able to ask for a Lines
header to be generated, it is the default that is open to discussion.

Re: Why does Gnus generates Lines: header in mail?

[Paul Jarc]

Clemens Fischer <ino@despammed.com> wrote:
> you mean this differs after i edited it.  and i think i would like to
> be able to set this value.  eg. i use a qmail-followup-to file to
> generate the MFT from the recipients.  qmail automatically compares
> the addresses in To and Cc to a list of emails in this file and
> generates the MFT if one of them appears in that list, but _with all
> values_ in To and Cc.

Gnus does the same.  But suppose MFT were shown in the message buffer
before you sent the message.  Also suppose that you change the To/Cc
fields.  Now you probably want MFT to be changed as well.  But MFT
won't be regenereated, because there's no way to distinguish this old,
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.

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

> Sender:              for envelope info

This header field is not necessarily the same as the SMTP envelope
sender address.


paul

Re: Why does Gnus generates Lines: header in mail?

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Gnus generates an MFT header which contains all To/Cc/From address,
> minus the following:
>
> - addresses that were excluded in the MFT header of the original
>   message you're following up to

Actually, if the original message had MFT, then that list is used for
the new message's initial To/Cc list.  Then the new MFT contains all
the new To/Cc addresses.

> - message-subscribed-addresses and/or message-subscribed-address-file,
>   message-subscribed-address-functions,
>   gnus-parameter-subscribed-alist, and possibly other variables

Those aren't excluded from MFT.  They're used to determine whether to
generate MFT at all.


paul

Re: Why does Gnus generates Lines: header in mail?

[Paul Jarc]

Clemens Fischer <ino@despammed.com> wrote:
> ok, i've experimented with the above, but never saw a correct MFT in
> my outgoing messages.

This message of yours had no MFT.  Can you post the configuration you
had at the time?

I have this in my .emacs:
(setq message-subscribed-regexps (gnus-find-subscribed-addresses))
But message-subscribed-regexps was nil just now.  Do I have to start
Gnus before g-f-s-a will work?

> what worries me more is kai's statement about gnus generating the
> MFT minus the entries in m-s-*, specifically
> message-subscribed-address-file.  did i get this really wrong?

No, Kai did.

> i have now compiled a file qmailmftfile used in the uppercase
> environment variable of the same name for qmail, and this file is also
> set as the value for m-s-a-file.  there's one complete, fully
> qualified email address per line of this file, which contains nothing
> else and no holes.  is this correct?

Yes.

> at first i thought i could simply use the regular expressions
> describing the subscribed addresses i had used for mutt, so this
> one, big regex was the value of m-s-regexps.

That variable's value should be a list, even if there is only one
regexp in the list.


paul

Re: Why does Gnus generates Lines: header in mail?

[Reiner Steib]

On Tue, Oct 01 2002, Clemens Fischer wrote:

> here's the list of headers i'd like to see.
[...]
> Content-Type:        to see what characterset/language the OP expects

This depends on both, the characters in the cited text and the ones
*you* enter. I doesn't make any sense to see it while composing a
message. If you want to see the CT used for sending, you'd better use
`mml-preview' (C-u C-c RET P):

,----[ C-h f mml-preview RET ]
| mml-preview is an interactive compiled Lisp function in `mml'.
| (mml-preview &optional RAW)
| 
| Display current buffer with Gnus, in a new buffer.
| If RAW, don't highlight the article.
`----

> Path:

Why? Doesn't make any sense for me.

> Reply-To:

Useless if empty (or equal to From:). Use `C-c C-f C-r' (or <menu-bar>
<Field> <Reply-To>) to insert it.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

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

[clemens fischer]

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

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

[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

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

[Clemens Fischer]

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

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

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

mail-followup-to, was Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

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

> This message of yours had no MFT.  Can you post the configuration you
> had at the time?

(setq ;message-subscribed-address-file "/var/spott/mailinglists"
      message-subscribed-address-file "/var/qmail/control/qmailmftfile"
      ;; !!!! throws stringp error on posting?  M-x toggle-debug-on-error
      ;message-subscribed-regexps '(
      ;	"beta-test"
      ;	"bitchx"
      ;	"bsd-questions"
      ;	"fetchmail-friends"
      ;	"freebsd-gnats-submit"
      ;	"freebsd-jobs"
      ;	"webreference-update-text"
      ;)
      message-subscribed-addresses '(
	      "cryptlib@mbsks.franken.de"
	      "info@dgob.de"
	      "w3m-dev-en@mi.med.tohoku.ac.jp"
	      )
      ;message-subscribed-address-functions nil ; '(gnus-find-subscribed-addresses)
      message-use-mail-followup-to 'use ; 'ask
      message-make-forward-subject-function
      '(message-forward-subject-fwd) ; -or- message-forward-subject-author-subject
      message-wash-forwarded-subjects t
      message-forward-before-signature nil
      ;message-wide-reply-confirm-recipients t
)

the number of entries in the lists is much higher, and i had
overlooked message-subscribed-regexps beeing a list of regexex, but
this variable was commented out anyway.  note that ding@gnus.org
wasn't in qmailfmtfile until today, so i must check this some other
way.  btw, i'm not sure how to check if valid MFTs are generated!

clemens

Re: Why does Gnus generates Lines: header in mail?

[Clemens Fischer]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> `mml-preview' (C-u C-c RET P):

"volltreffer!" == "bingo!"  next think i'll try this to check MFT!

>> Path:
>
> Why? Doesn't make any sense for me.
>
>> Reply-To:

i want to see and set the envelope.

clemens

Re: mail-followup-to, was Re: Why does Gnus generates Lines: header in mail?

[Paul Jarc]

Clemens Fischer <ino@despammed.com> wrote:
> note that ding@gnus.org wasn't in qmailfmtfile until today

Ok, then it makes sense that your past messages had no MFT.  But this
message still has no MFT.  (I'm assuming you want to set MFT for the
ding list; do you?)  Ah - you're posting via NNTP on gmane, right?  So
there is no To/Cc field containing "ding@gnus.org", so no MFT will be
generated.  If you send messages via mail instead (regardless of how
you read them), and if you have the ding address in your mft file,
then Gnus should produce MFT.


paul

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

[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

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

[Clemens Fischer]

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

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

[Paul Jarc]

Clemens Fischer <ino@despammed.com> wrote:
> 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 wasn't assuming that.  E.g., you could use a posting style like
this: ("big-multilist-group" ("To" (whatever-you-like)))
whatever-you-like can be function that looks at any information
available and returns the address that is appropriate right now.  It
doesn't have to give the same address for the same group every time.
I'm sure the same effect could be achieved in other ways too.

> 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'm not sure, because I don't quite understand your setup.  If
procmail does all the splitting before you read your mail, how is it
all in one group?

> btw, some part of my mailing now generates correct MFTs.

This message still didn't have any.


paul

Re: Why does Gnus generates Lines: header in mail?

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> X-* is blessed by the standard to contain experimental stuff,

X-headers are no longer part of RFC 2822.  Intially, I thought this
was silly, but it makes sense (think of X-No-Archive etc.).

Re: Why does Gnus generates Lines: header in mail?

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> X-* is blessed by the standard to contain experimental stuff,
>
> X-headers are no longer part of RFC 2822.  Intially, I thought this
> was silly, but it makes sense (think of X-No-Archive etc.).

Ouch.  I find it somewhat disappointing that this isn't even mentioned
in 2822, as 822 says that X- will never be used by standards and is a
protected namespace.  This breaks backwards compatibility.  Sigh.

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

[Clemens Fischer]

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

> I'm not sure, because I don't quite understand your setup.  If
> procmail does all the splitting before you read your mail, how is it
> all in one group?

procmail filters out junk.  useful messages go into that one special
main folder.

>> btw, some part of my mailing now generates correct MFTs.
>
> This message still didn't have any.

you had guessed that one already:  i read ding on gmane.

clemens

Re: Why does Gnus generates Lines: header in mail?

[Reiner Steib]

On Thu, Oct 03 2002, Clemens Fischer wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
[...]
>>> Path:
>>
>> Why? Doesn't make any sense for me.
>>
>>> Reply-To:
[re-inserted my text:]
>> Useless if empty (or equal to From:). Use `C-c C-f C-r' (or <menu-bar>
>> <Field> <Reply-To>) to insert it.

> i want to see and set the envelope.

I don't understand what this has to do with "Reply-To:" or "Path:".

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

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

[Paul Jarc]

Clemens Fischer <ino@despammed.com> wrote:
> procmail filters out junk.  useful messages go into that one special
> main folder.

Ok, then ISTR there may be a way to select a particular posting style
when you start a new message.  But I don't remember how.

>>> btw, some part of my mailing now generates correct MFTs.
>>
>> This message still didn't have any.
>
> you had guessed that one already:  i read ding on gmane.

How you read doesn't matter.  How you post does.  If you post via
mail, everything can still exactly work as if you were subscribed to
the mailing list, assuming gmane preserves the original From, To, Cc,
and MFT fields.  If you post via news, then ding@gnus.org won't be in
your To/Cc, so MFT can't be generated automatically (at least not by
the existing code), but you could add it manually if you like.  Or you
could use "Mail-Copies-To: nobody" if you want to discourage Cc's to
your address.

But if you post via news, you'll be ignoring the MFT on messages you
reply to: your message will go only to the list, even if MFT specifies
additional addresses or directs the thread to a different list.  Maybe
gmane shouldn't allow posting, since AFAICS it can't be done right.


paul

Re: Why does Gnus generates Lines: header in mail?

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Ouch.  I find it somewhat disappointing that this isn't even mentioned
> in 2822, as 822 says that X- will never be used by standards and is a
> protected namespace.  This breaks backwards compatibility.  Sigh.

The problem is that many people interpreted it the other way, that any
non-standard headers *must* start with an "X-".  Combined the promise
above, it made it impossible to standardize experimental headers.

Re: Why does Gnus generates Lines: header in mail?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> The Lines: header seems to be deprecated even for news in RFC1036bis.

My conclusion from reading this thread is that it should probably be
removed for news as well, so I did that, too.

> Also, shouldn't Gnus generate the In-Reply-To header in the message
> buffer when you press R or F?  The References: header is generated.
> Possibly neither should be generated though (and people that want to
> see it can use `message-generate-headers-first').  Opinions?

And I've now made References be generated upon sending by default.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Why does Gnus generates Lines: header in mail?

[Romain FRANCOISE]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> And I've now made References be generated upon sending by default.

Hm, a funny side-effect of this change is that (apparently) messages
sent via the Agent queue (e.g. unplugged) don't have References in them
when they're delivered; effectively breaking threads if the subject
changes (with a mailing-list manager that puts article numbers in the
subject, for example).

-- 
Romain FRANCOISE <romain@orebokech.com> | When we were kids, we hated
it's a miracle -- http://orebokech.com/ | things our parents did.

Re: Why does Gnus generates Lines: header in mail?

[Lars Magne Ingebrigtsen]

Romain FRANCOISE <romain@orebokech.com> writes:

> Hm, a funny side-effect of this change is that (apparently) messages
> sent via the Agent queue (e.g. unplugged) don't have References in them
> when they're delivered; effectively breaking threads if the subject
> changes (with a mailing-list manager that puts article numbers in the
> subject, for example).

What's the value of your `message-required-news-headers' variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

No References header when using drafts (was: Why does Gnus generates Lines: header in mail?)

[Reiner Steib]

On Sun, Dec 29 2002, Lars Magne Ingebrigtsen wrote:

> Simon Josefsson <jas@extundo.com> writes:
[...]
>> Also, shouldn't Gnus generate the In-Reply-To header in the message
>> buffer when you press R or F?  The References: header is generated.
>> Possibly neither should be generated though (and people that want to
>> see it can use `message-generate-headers-first').  Opinions?
>
> And I've now made References be generated upon sending by default.

,----
| 2002-12-29  Lars Magne Ingebrigtsen  <larsi@gnus.org>
[...]
| 	* message.el (message-required-news-headers): Removed Lines.
| 	(message-reply): Don't insert References first.
| 	(message-followup): Ditto.
| 	(message-make-references): New function.
| 	(message-followup): Set message-reply-headers before generating
| 	the buffer stuff.
`----

It seems to me that this change leads to bug: When I save a reply to
drafts and send it later, the References header gets lost.

The drafts file doesn't contain the References header.  See article
<v94r8v8l6k.fsf@theotp5.physik.uni-ulm.de> in gmane.test.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> It seems to me that this change leads to bug: When I save a reply to
> drafts and send it later, the References header gets lost.

Try updating from CVS again and see whether the problem has been
fixed by the latest changes...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Reiner Steib]

On Mon, Dec 30 2002, Lars Magne Ingebrigtsen wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>
>> It seems to me that this change leads to bug: When I save a reply to
>> drafts and send it later, the References header gets lost.
>
> Try updating from CVS again and see whether the problem has been
> fixed by the latest changes...

cvs up -dP (Mon Dec 30 22:49:20 CET 2002)

No luck, see <http://article.gmane.org/gmane.test/412>.  Maybe it
works when you don't exit Emacs, so that the buffer with the original
article (" *Original Article gnus.ding*") is still alive.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Why does Gnus generates Lines: header in mail?

[Romain FRANCOISE]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What's the value of your `message-required-news-headers' variable?

It's

(From Newsgroups Subject Date Message-ID
      (optional . Organization)
      (optional . References)
      (optional . User-Agent))

but now that I think about it, the messages were all coming from a
draft, then sent unplugged, then sent when I plugged again, so this is
probably the same bug as Reiner had.  I'll update and see if it happens
again.

-- 
Romain FRANCOISE <romain@orebokech.com> | This is a man's man's man's
it's a miracle -- http://orebokech.com/ | world. --James Brown

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> No luck, see <http://article.gmane.org/gmane.test/412>.  Maybe it
> works when you don't exit Emacs, so that the buffer with the original
> article (" *Original Article gnus.ding*") is still alive.

Oh, I see now.  I wasn't thinking clearly.

Yes, that's a major problem that I didn't consider.  When saving to
the drafts buffer, the References header has to be stored there.
Hmm.

Ok, how about this -- installing a file-write hook that generates the
References header, so that it exists if the message buffer is written
to a file.  Any other headers that should also be generated then?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Reiner Steib]

On Mon, Dec 30 2002, Lars Magne Ingebrigtsen wrote:

> Yes, that's a major problem that I didn't consider.  When saving to
> the drafts buffer, the References header has to be stored there.
> Hmm.
>
> Ok, how about this -- installing a file-write hook that generates the
> References header, so that it exists if the message buffer is written
> to a file.  Any other headers that should also be generated then?

Maybe In-Reply-To (for mail)?

BTW, Simon suggested
<ilu8z1k28u6.fsf@h28n1c1o299.bredband.skanova.com>:

| [...] people that want to see it can use
| `message-generate-headers-first'

Would it be difficult allow a list of headers that should be generated
first?  E.g. I don't like to have "Date:" generated first, but it's
okay for me if References, MID, ... are generated first.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: No References header when using drafts

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ok, how about this -- installing a file-write hook that generates the
> References header, so that it exists if the message buffer is written
> to a file.  Any other headers that should also be generated then?

With this, you don't need X-Draft-From anymore: you can just generate
all the headers at the time of writing the file.

-- 
Ambibibentists unite!

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> Maybe In-Reply-To (for mail)?

Yup.

> Would it be difficult allow a list of headers that should be generated
> first?  E.g. I don't like to have "Date:" generated first, but it's
> okay for me if References, MID, ... are generated first.

That would probably also be nice...  I'll let that value also be
allowed to be a list of headers.

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> With this, you don't need X-Draft-From anymore: you can just generate
> all the headers at the time of writing the file.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Ok; I've now made the rather sweeping changes that allows References
and draft headers be generated on draft buffer save.  So let's see
how that goes...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Simon Josefsson]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Ok, how about this -- installing a file-write hook that generates the
>> References header, so that it exists if the message buffer is written
>> to a file.  Any other headers that should also be generated then?
>
> With this, you don't need X-Draft-From anymore: you can just generate
> all the headers at the time of writing the file.

Doesn't X-Draft-From influence e.g. posting styles, which in turn
could influence e.g. which SMTP server is eventually used?

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

>> With this, you don't need X-Draft-From anymore: you can just generate
>> all the headers at the time of writing the file.
>
> Doesn't X-Draft-From influence e.g. posting styles, which in turn
> could influence e.g. which SMTP server is eventually used?

Hm...  It's possible that people have written posting styles that
depend on X-Draft-From, but it seems kinda unlikely.  The information
available there is much more easily accessible from the
`gnus-newsgroup-name' variable, I'd have thought.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>>> With this, you don't need X-Draft-From anymore: you can just generate
>>> all the headers at the time of writing the file.
>>
>> Doesn't X-Draft-From influence e.g. posting styles, which in turn
>> could influence e.g. which SMTP server is eventually used?
>
> Hm...  It's possible that people have written posting styles that
> depend on X-Draft-From, but it seems kinda unlikely.  The information
> available there is much more easily accessible from the
> `gnus-newsgroup-name' variable, I'd have thought.

Yes, but isn't the gnus-newsgroup-name initialized from the
X-Draft-From header when you edit a draft?  I assumed that was what it
was there for, but I probably never looked at the code.

Re: No References header when using drafts

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Yes, but isn't the gnus-newsgroup-name initialized from the
> X-Draft-From header when you edit a draft?

Oh, sure, but in that case the X-Draft-Header is in the buffer.  It's
generated when you save the buffer to the draft group.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No References header when using drafts

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Doesn't X-Draft-From influence e.g. posting styles, which in turn
> could influence e.g. which SMTP server is eventually used?

Well, the headers that they generate could be generated on saving.
But you're right about the variables.  That's not so easy.

-- 
Ambibibentists unite!

Re: No References header when using drafts

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Yes, but isn't the gnus-newsgroup-name initialized from the
>> X-Draft-From header when you edit a draft?
>
> Oh, sure, but in that case the X-Draft-Header is in the buffer.  It's
> generated when you save the buffer to the draft group.

Simon was responding to my suggestion of removing X-Draft-From...

It was not a good suggestion.
-- 
Ambibibentists unite!

References Header (Re: Why does Gnus generates Lines: header in mail?)

[Mark Thomas]

On Sun, 29 Dec 2002, larsi@gnus.org wrote:

> And I've now made References be generated upon sending by default.

Is there any way to get the old behavior?

I know I can set message-generate-headers-first to t (or to
'("References")) to see the References-header's value, but sometimes I
delete it (because I'm being "bad" and using "followup" when maybe I
should be using "new mail"), and I'd like it to stay deleted.

Cheers,

-Mark

Re: References Header (Re: Why does Gnus generates Lines: header in mail?)

[Lars Magne Ingebrigtsen]

Mark Thomas <swoon@bellatlantic.net> writes:

> I know I can set message-generate-headers-first to t (or to
> '("References")) to see the References-header's value, but sometimes I
> delete it (because I'm being "bad" and using "followup" when maybe I
> should be using "new mail"), and I'd like it to stay deleted.

Oh.  Hm.  Message actually has no mechanism for recognizing that
you've removed one of the headers that it usually generates.  For
instance, if you have Organization as a required header, and generate
the headers first, Message will just re-insert the Organization
header.  On the other hand, if you edit the Organization header,
Message won't touch the header.

The same goes for References now that's it's a more normal header.

Hm.  I don't see any easy solution.  Message could keep track of
which headers that were inserted upon group entry, and not try to
generate any of them if they are removed?  But that would create
problems if you delete the From header (generated, say, by a posting
style), meaning to let Message auto-generate the default From header.

*ponder*

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: References Header

[Reiner Steib]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Mon, Jan 06 2003, Mark Thomas wrote:

> On Sun, 29 Dec 2002, larsi@gnus.org wrote:
>
>> And I've now made References be generated upon sending by default.
>
> Is there any way to get the old behavior?
>
> I know I can set message-generate-headers-first to t (or to
> '("References")) to see the References-header's value, 

Shouldn't it be '(References)?

BTW, here's a patch, allowing to customize the variable as a list:

--8<---------------cut here---------------start------------->8---
2003-01-07  Reiner Steib  <Reiner.Steib@gmx.de>

	* message.el (message-generate-headers-first): Added customization
	if variable is a list.

--8<---------------cut here---------------end--------------->8---


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message.message-generate-headers-first.patch --]
[-- Type: text/x-patch, Size: 519 bytes --]

--- message.el.~6.283.~	Tue Jan  7 12:20:10 2003
+++ message.el	Tue Jan  7 12:55:33 2003
@@ -690,7 +690,9 @@
 are to be deleted and then re-generated before sending, so this variable
 will not have a visible effect for those headers."
   :group 'message-headers
-  :type 'boolean)
+  :type '(choice (const :tag "None" nil)
+                 (const :tag "All" t)
+                 (repeat (sexp :tag "Header"))))
 
 (defcustom message-setup-hook nil
   "Normal hook, run each time a new outgoing message is initialized.

[-- Attachment #3: Type: text/plain, Size: 116 bytes --]


Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: References Header (Re: Why does Gnus generates Lines: header in mail?)

[Mark Thomas]

On Tue, 07 Jan 2003, larsi@gnus.org wrote:

> Mark Thomas <swoon@bellatlantic.net> writes:
> 
>> I know I can set message-generate-headers-first to t (or to
>> '("References")) to see the References-header's value, but
>> sometimes I delete it (because I'm being "bad" and using "followup"
>> when maybe I should be using "new mail"), and I'd like it to stay
>> deleted.
> 
> Hm.  I don't see any easy solution.

I admit I get the unwanted References header when when I'm abusing
Gnus, and since you indicate getting the previous behavior will not be
easy, I'll just need to change my behavior.  If I find that I cannot,
I'll edit message-required-mail-headers in my ~/.gnus.

Thanks, Lars.

-Mark

Re: References Header (Re: Why does Gnus generates Lines: header in mail?)

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Oh.  Hm.  Message actually has no mechanism for recognizing that
> you've removed one of the headers that it usually generates.  For
> instance, if you have Organization as a required header, and generate
> the headers first, Message will just re-insert the Organization
> header.  On the other hand, if you edit the Organization header,
> Message won't touch the header.
>
> The same goes for References now that's it's a more normal header.

Gnus (or Message, rather) could delete headers where the value is
empty.

WDYT?
-- 
Ambibibentists unite!

Re: References Header

[Lars Magne Ingebrigtsen]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> 	* message.el (message-generate-headers-first): Added customization
> 	if variable is a list.

Thanks for the patch; I've applied it to Oort Gnus v0.11 (i. e., CVS).

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: References Header (Re: Why does Gnus generates Lines: header in mail?)

[Lars Magne Ingebrigtsen]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Gnus (or Message, rather) could delete headers where the value is
> empty.

Message now considers empty headers and missing headers to be the
same thing.  For instance, if you leave From empty, Message will
generate it.

*ponder*  Aha!  But I could make Message not generate the headers
that are optional if they are empty.  This would apply to References
in particular.  Yes, I think I'll do that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen