Gnus and the Sender: field

Gnus and the Sender: field

[Aaron D. Ball]

I just read question 2.15 of the Gnus FAQ, and found myself rather
annoyed with the answer.  While I agree that address munging is a poor
idea, there are other reasons one might not want the Sender: field to
be present: for example, when one is writing in a role that has an
email address other than the one constructed from the host and
username one happens to be logged in to, as when I write a
work-related email from home or vice versa.

RFC 2822 says this:

   If the originator of the message can be indicated by a single
   mailbox and the author and transmitter are identical, the "Sender:"
   field SHOULD NOT be used.  Otherwise, both fields SHOULD appear.

It appears that Gnus is interpreting "the author and transmitter are
identical" to mean "the From: address coincides with
user-login-name@system-name".  I claim that it makes more sense to
interpret this as "the author and transmitter are the same person",
and that Gnus should respect the user's judgment as to what goes in
the Sender: header, since it doesn't know anything at all about
whether or two email addresses describe the same person.


I am subscribed to the list for the time being, so there is no need to
CC me on replies.  I will happily discuss the particular situations in
which this bothers me, but I didn't want to confuse the issue by
introducing them initially: to me, this is not about solving
particular problems, but rather about the basic requirement that Gnus
trust the user and do what he or she wants.

Re: Gnus and the Sender: field

[Stainless Steel Rat]

* adb@bdi.com (Aaron D. Ball)  on Thu, 30 May 2002
| and that Gnus should respect the user's judgment as to what goes in
| the Sender: header, since it doesn't know anything at all about
| whether or two email addresses describe the same person.

I pointed out something a couple of weeks ago when this went around.  I
will point it out again: the vast majority of users have no clue what they
are doing.  They have no idea that headers other than From, To and Subject
even exist, and many do not fill in Subject headers, a MUST in RFC
2822.  Heck, most have never heard of RFCs in general.

Gnus cannot and should not trust the user by default.  The user must prove
to Gnus that he is neither ignorant nor incompetent.

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

Re: Gnus and the Sender: field

[Matt Armstrong]

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

> Gnus cannot and should not trust the user by default.  The user must
> prove to Gnus that he is neither ignorant nor incompetent.

You could argue that simply using Gnus in the first place is
sufficient proof of these facts.  ;-)

-- 
Don't send mail to Harmon.Landers@hole.lickey.com
The address is there for spammers to harvest.

Re: Gnus and the Sender: field

[Paul Jarc]

adb@bdi.com (Aaron D. Ball) wrote:
> It appears that Gnus is interpreting "the author and transmitter are
> identical" to mean "the From: address coincides with
> user-login-name@system-name".  I claim that it makes more sense to
> interpret this as "the author and transmitter are the same person",

Many agree with you; check the archives for a recent discussion.  You
can make Gnus stop adding Sender like this:
(add-to-list 'message-syntax-checks '(sender . disabled))

> I am subscribed to the list for the time being, so there is no need to
> CC me on replies.

You can express that via the Mail-Followup-To field so that MUAs can
automatically remove you from the recipient list for followups.
<URL:http://cr.yp.to/proto/replyto.html>
If your Gnus has the message-subscribed-address-functions variable,
you can make it add MFT automatically:
(setq message-subscribed-address-functions '(gnus-find-subscribed-addresses))
(add-to-list gnus-parameters '("ding" (subscribed . t)))


paul