message.el

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.

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

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

[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