[patch] message.el

[patch] message.el

[Fabrice Popineau]

Hi,

Is it possible to apply the following patch :

--- message.el~ Fri Jun 09 15:36:58 2000
+++ message.el  Sat Jun 24 21:04:53 2000
@@ -3091,7 +3091,8 @@
   "Return the \"real\" user address.
 This function tries to ignore all user modifications, and
 give as trustworthy answer as possible."
-  (concat (user-login-name) "@" (system-name)))
+  (or (message-user-mail-address)
+      (concat (user-login-name) "@" (system-name))))

 (defun message-make-address ()
   "Make the address of the user."

Possibly, conditionalize it by os is windows. But currently, chances
are great that the returned value be false under windows.

-- 
Fabrice POPINEAU
------------------------
e-mail:       Fabrice.Popineau@supelec.fr  |  The difference between theory 
voice-mail:   +33 (0) 387764715            |  and practice, is that
surface-mail: Supelec, 2 rue E. Belin,     |  theoretically,
	      F-57078 Metz Cedex 3         |  there is no difference !

Re: [patch] message.el

[Florian Weimer]

Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:

> Possibly, conditionalize it by os is windows. But currently, chances
> are great that the returned value be false under windows.

Chances are great that "message-make-sender" returns a bogus address
on many systems.  In the past, Lars expressed several times that he
feels that's right, anyway.

Re: [patch] message.el

[Fabrice Popineau]

It is definitely bogus on my laptop : "Fabrice Popineau@neveryon" is
refused by the nntp server ! Or this just means that somewhere,
message-make-sender has been used in place of message-make-address (?).


-- 
Fabrice 

Re: [patch] message.el

[Lars Magne Ingebrigtsen]

Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:

> It is definitely bogus on my laptop : "Fabrice Popineau@neveryon" is
> refused by the nntp server ! Or this just means that somewhere,
> message-make-sender has been used in place of message-make-address (?).

No, this means that your setup is invalid.  (user-login-name) should
return your login name.

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

Re: message.el

[Greg Stark]

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

> Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:
> 
> > Possibly, conditionalize it by os is windows. But currently, chances
> > are great that the returned value be false under windows.
> 
> Chances are great that "message-make-sender" returns a bogus address
> on many systems.  In the past, Lars expressed several times that he
> feels that's right, anyway.

Ok, so this is a real problem now. The problem is that he's correct for NNTP.
The Sender header in NNTP is supposed to be there to help track down where the
message really came from, not to actually be a deliverable address. However
it's wrong for mail messages. In mail messages the Sender header is supposed
to be the e-mail address of the person actually sending the e-mail in cases
such as when a secretary is sending an e-mail for someone else.

This has caused problems for me a few times. Some windows software actually
uses the Sender header in preference to the From header. Also some list
processing software (brokenly imho, even if you accept the interpretation
above) try to subscribe the Sender address rather than the From address.

Probably the sender header should simply be stripped from mail messages since
there really is no consensus on how it should be used. If anything I would
suggest message check when preparing to send the message if the From header is
the same as it would be initialized. If it's been altered by the user in the
message buffer then message should ask whether to add a Sender header
indicating the actual sender.

Unfortunately this is one of those cases where news articles and mail messages
don't have precisely the same interpretation for the same header.

-- 
greg

Re: [patch] message.el

[Kai Großjohann]

Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:

> Possibly, conditionalize it by os is windows. But currently, chances
> are great that the returned value be false under windows.

IMHO, the old behavior does not make sense in any case.  It is not
possible to automatically find out what is the email address of the
sender of the current message, anyway.

The only possibility I can think of is that someone writes a message
but manually changes the From header.  (Or maybe the From header is
changed from the posting styles, or from gnus-pers.el.)  In this case,
the sender would be different from the From header, and
user-mail-address should be put into the Sender header (if set).

kai
-- 
I like BOTH kinds of music.

message.el

[Kai Grossjohann]

I hit `m' in the summary buffer, then C-c C-c the mail.  The window
configuration is not updated:  the compose buffer should be buried or
deleted, and the summary buffer window should be selected.  Or
something.

--> sgnus-0.60

tia,
        kai
--
There ain't no cure for the summer time blues.

message.el

[Kai Grossjohann]

message-default-headers doesn't quite seem to work.  I just set this
to "Bcc: grossjoh", then hit "m", and here's what I get:

,-----
| To: 
| Subject: 
| ----- text of mail follows -----
| 
| Bcc: grossjoh
`-----

Hm...  I didn't find this right away, but you will know what to do
immediately, I'm sure.

        kai
--
There ain't no cure for the summer time blues.

message.el

[Lars Magne Ingebrigtsen]

I've started working on message.el, and I now reali{s,z}e that it
should incorporate many of the things from gnus-msg.el -- like
auto-saving to a draft directory, and so on.  Since this is something
that's been introduced in September, and will be obsolete in Red, I've
decided to go ahead and rip gnus-msg.el apart right away. 

Which means that 0.58 will feature message.el, and all your Gnus
variables for customizing outgoing mail & news will be obsolete.
`gnus-reply-to-function' will become `message-reply-to-function'.
Many variables will simply disappear.

I feel positively *evil*.  Bwa-ha-ha!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen