Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Paul Michael Reilly]

 > Could you implement this too?
 > 
 > ------- Start of forwarded message -------
 > X-Authentication-Warning: zuse.dina.kvl.dk: abraham set sender to abraham@dina.kvl.dk using -f
 > To: emacs-devel@gnu.org
 > Subject: Re: CC (was: Re: kill ring menu)
 > Organization: The Church of Emacs
 > From: Per Abrahamsen <abraham@dina.kvl.dk>
 > In-Reply-To: <rj7kmq7tbu.fsf_-_@zuse.dina.kvl.dk> (Per Abrahamsen's message
 >  of "Mon, 29 Apr 2002 11:22:13 +0200")
 > Sender: emacs-devel-admin@gnu.org
 > Date: Tue, 30 Apr 2002 12:14:36 +0200
 > 
 > Answers to multiple people:
 > 
 > - - It is Mail-Followup-To, without an "s".
 > 
 > - - It was invented by Dan Bernstein, and documented in
 >   < http://cr.yp.to/proto/replyto.html >
 > 
 > - - It is supported in Gnus from the Oort line 
 >   (i.e. what will become the next version).
 > 
 > - - Mail-Copies-To was invented by Lars Magne Ingebrigtsen for Gnus for
 >   both mail and news, and has been adopted by a large number of other
 >   news clients, but no other mail clients as far as I know.  
...
 > Here is the specification from USEFOR (the RFC 1036 replacement):
 >
 >   < http://www.mibsoftware.com/userkt/usefor/05/0060.htm >

While this is a News feature from what I can discern, I will implement
it in the Rmail reply command with the following semantics:

If either a Mail-Followup-To or Mail-Copies-To header exists in the
message being replied to AND the user has not edited the default
reply-to list at mail-send time, then the followup header(s) will be
processed and any mailboxes indicated by the header(s) will be
included in the reply.  "never" and "nobody" will be treated as
synonymous, as will "always" and "poster".

If the User edits the reply-to list, then one could argue that it is
the wish of the replier to ignore the wishes of the poster.  One
could also argue that the intent of the original poster should be
heeded but I know that if I prune a reply-to list and my mail agent
chose to send the message to someone(s) I did not explicitly bless, I
would be mightily pissed.

Would anyone care to make a case for adding custom variable support to
tailor the behavior further?  I'm inclined not to do so if only to
keep the feature simple.

Other comments?

-pmr

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Simon Josefsson]

On Fri, 3 May 2002, Paul Michael Reilly wrote:

> While this is a News feature from what I can discern, I will implement
> it in the Rmail reply command with the following semantics:
> 
> If either a Mail-Followup-To or Mail-Copies-To header exists in the
> message being replied to AND the user has not edited the default
> reply-to list at mail-send time, then the followup header(s) will be
> processed and any mailboxes indicated by the header(s) will be
> included in the reply.  "never" and "nobody" will be treated as
> synonymous, as will "always" and "poster".
> 
> If the User edits the reply-to list, then one could argue that it is
> the wish of the replier to ignore the wishes of the poster.  One
> could also argue that the intent of the original poster should be
> heeded but I know that if I prune a reply-to list and my mail agent
> chose to send the message to someone(s) I did not explicitly bless, I
> would be mightily pissed.
> 
> Would anyone care to make a case for adding custom variable support to
> tailor the behavior further?  I'm inclined not to do so if only to
> keep the feature simple.
> 
> Other comments?

Only one: What about re-using the logic and code from message.el instead 
of re-implementing it?

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Per Abrahamsen]

Paul Michael Reilly <pmr@pajato.com> writes:

> While this is a News feature from what I can discern, I will implement
> it in the Rmail reply command with the following semantics:

Mail-Followup-To is a mail feature only.  

Mail-Copies-To was intended for mail and news, but only gained
popularity for news.  Given the existence of MFT I don't think it is
important to support.

> If either a Mail-Followup-To or Mail-Copies-To header exists in the
> message being replied to AND the user has not edited the default
> reply-to list at mail-send time, then the followup header(s) will be
> processed and any mailboxes indicated by the header(s) will be
> included in the reply.  "never" and "nobody" will be treated as
> synonymous, as will "always" and "poster".

Eh, I don't know what you mean by the "default reply-to".  If it is
what is presented to the user by default in the "To" and "CC" fields
when composing a reply, I think MFT and MCT should change the "default
reply-to".

Basically, both headers only affect the behaviour of the "wide reply"
command.  If you make a wide reply to a message where Mail-Followup-To
is set, the "To" field will be set to the specified adress, and "CC"
will be empty.  If you make a wide reply to a message where
Mail-Copies-To is set, that adress will be added to the default CC,
along with any other adresses that would usually be there.  Unless the
value is never/nobody, in which case the poster will be removed from
the default CC field.

> If the User edits the reply-to list, then one could argue that it is
> the wish of the replier to ignore the wishes of the poster.

Gnus will give a warning in that case.

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Mail-Copies-To was intended for mail and news, but only gained
> popularity for news.  Given the existence of MFT I don't think it is
> important to support.

Just support it; it's not very hard.  Just use its contents [or nothing,
if the value is `nobody' or `never'] instead of Reply-To:/From: when
doing a followup, before merging with To:/CC:.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Miles Bader]

Paul Michael Reilly <pmr@pajato.com> writes:
> If either a Mail-Followup-To or Mail-Copies-To header exists in the
> message being replied to AND the user has not edited the default
> reply-to list at mail-send time, then the followup header(s) will be
> processed and any mailboxes indicated by the header(s) will be
> included in the reply.  "never" and "nobody" will be treated as
> synonymous, as will "always" and "poster".

It's a bit hard to tell from the above paragraph the actual algorithm you
intend to use, but here's what I gather is correct way to calculate
outgoing addresses for followups (the MFT parts are based on Dan
Bernstein's FAQ about MFT <http://cr.yp.to/proto/replyto.html>):

   If the message has a Mail-Followup-To: header, then
       outgoing To: <= incoming Mail-Followup-To:
       outgoing CC: <= empty
       ;; you can also optionally add an outgoing Mail-Followup-To: if
       ;; the current user is on the mailing list; it should probably just
       ;; be a copy of the incoming Mail-Followup-To: in that case.]
   else if the message has a Mail-Copies-To: header, then
       if the MCT header contains `never' or `nobody', then
           outgoing To: <= incoming To:
           outgoing CC: <= incoming CC:
       else if the MCT header contains `always' or `poster', then
           ;; this is the same as the default (no MCT/MFT) case
           outgoing To: <= incoming Reply-To:/From:
           outgoing CC: <= incoming CC: + To:
       else (the MCT header contains some addresses)
           outgoing To: <= incoming Mail-Copies-To:
           outgoing CC: <= incoming CC: + To:
   else (the message has no MFT/MCT header)
       outgoing To: <= incoming Reply-To:/From:
       outgoing CC: <= incoming CC: + To:

This is all calculated when generating the message to insert into the
reply buffer, before popping it up and letting the user type into it.
There doesn't seem to be any need to detect whether the user modified a
header or anything like that.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> Mail-Copies-To was intended for mail and news, but only gained
>> popularity for news.  Given the existence of MFT I don't think it is
>> important to support.
>
> Just support it; it's not very hard.  Just use its contents [or nothing,
> if the value is `nobody' or `never'] instead of Reply-To:/From: when
> doing a followup, before merging with To:/CC:.

That is not what it means.  If the value is not nobody/never, it
should be used _in addition to_ the content of Reply-To/From.

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

>        else (the MCT header contains some addresses)
>            outgoing To: <= incoming Mail-Copies-To:
>            outgoing CC: <= incoming CC: + To:

I'd say 

             outgoing To: <= incoming Reply-To:/From:
             outgoing CC: <= incoming CC: + To: + Mail-Copies-To:

I haven't tested it, but that is what I infer from the Gnus code.

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > Just support it; it's not very hard.  Just use its contents [or nothing,
> > if the value is `nobody' or `never'] instead of Reply-To:/From: when
> > doing a followup, before merging with To:/CC:.
> 
> That is not what it means.  If the value is not nobody/never, it
> should be used _in addition to_ the content of Reply-To/From.

OK.  Anyway, the point is the same -- it's not hard to implement.

-Miles
-- 
Run away!  Run away!

Re: [abraham@dina.kvl.dk: Re: CC (was: Re: kill ring menu)]

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> I'd say 
> 
>              outgoing To: <= incoming Reply-To:/From:
>              outgoing CC: <= incoming CC: + To: + Mail-Copies-To:
> 
> I haven't tested it, but that is what I infer from the Gnus code.

Yes, I agree (I tested it after I saw your other message).

-Miles
-- 
Fast, small, soon; pick any 2.