Subject: Bouncing mail (fwd)

From: Billy Barron <[email-masked]>
Date: Wed, 5 May 1993 08:43:04 -0500

In reply to Mike Brudenell's message:
>
>Elm has a "bounce message" feature that works along these lines:
>
>This would be useful in situations such as our Advisory/Help Desk mail drop,
>where someone redistributes messages to suitable staff to be dealt with.
>Without "bounce" the answering member of staff has to firkle around saving the
>message to a file, starting a new message, reading in the old message, etc.,
>etc..
>
That's funny, I just use "forward".

>Is "bounce" deliberately omitted as part of Pine design philosohpy?  Or is it up
>for negotiation with the development team? ;-)
>
I've considered "bounce" to be a disfeature.  People (including myself)
hit things like reply or group reply expecting them to go to the person
who did the bounce.  I forget about Elm bounce works, but in RiceMail,
the person who does the bouncing can add text at the top of the message
making it every more confusing....  I think "bounce" causes way more
confusion than good.  The *only* case where I think "bounce" is a good thing
is in the hands of a mailing list moderator....

I hope that "bounce" continues to be omitted in PINE.
 
-- 
Billy Barron,  Information Services Manager, Univ of Texas at Dallas
[email-masked]

---

From: Terry Gray <[email-masked]>
Date: Wed, 5 May 1993 07:28:56 -0700 (PDT)

We originally omitted bounce from Pine for exactly the reasons Billy
points out: bounce (or "remail") is *dangerous* and has caused
considerable embarrassment over the years to unsuspecting recipients who
inadvertently reply to the original poster.  This can be especially 
nasty if the original poster is sending via a LISTSERV where the Reply-To: 
is set to the entire list.  (I've even been bitten, and I *know* better!)

However, as Mike points out, bounce has a legitimate use, especially for 
mailing list and news group moderation.

Our plan is to provide Bounce, but *only* in Old-Growth (power-user) mode. 

I hope this will be viewed as an acceptable compromise.

-teg

---

From: [email-masked] (Jeff Hayward)
Date: Wed, 5 May 93 10:27:16 CDT

Billy Barron writes:

... And postmasters, and people-managers, and...

It's fine if you want to keep pine 'idiot-proof'.  It's a very fine
tool for novices and intermediate skill level users.  Bounce is very
important in *this* users life though, and is why I use Elm.  Some
(even most) folks can be trusted with bounce, especially if it's a
disable-by-default feature.
--
Jeff Hayward

---

From: "A. Hilborne" <[email-masked]>
Date: Wed, 5 May 1993 16:42:46 +0100 (BST)

> disable-by-default feature.

Many people, including myself, would like a few additional features in
Pine.  Usually the small "additional set" is slightly different from
person to person.

If all these changes are put in, even into "old-growth" mode, then one of
the fundamental design points of Pine (a simple mailer, with a simple
on-line manual) will have been lost.  What do the keepers of the "one true
Pine" have to say? 

--
Andrew M. Hilborne                        [email-masked]
Computing Service                    Tel: +44 91 222 8226 (direct)
University of Newcastle upon Tyne, UK.    +44 91 222 8039 (Comp Service office)

---

From: Terry Gray <[email-masked]>
Date: Wed, 5 May 1993 10:08:51 -0700 (PDT)

> on-line manual) will have been lost.  What do the keepers of the "one true

OK, I'll bite. :)

The *theory*, *hope*, and *intent* behind "old-growth" mode was that we 
could retain the "simple mailer" virtues of Pine for most users, but also 
accommodate creaping featurism in a way that didn't undermine the 
original design goal.  

Whether the old-growth approach will actually achieve that goal remains 
to be seen, but there are lots of things we'd like to add to meet local 
needs, and it's clear that there is world-wide interest in many of these 
enhancements.

One of the things we have just been discussing amongst ourselves is
related: We have some options that are configurable by separate variables
in .pinerc. (There will be more! :) And we have some that are "lumped"
together under the feature-level "old-growth".  (More of those coming,
too.) The issue is whether to lean more to the individual options or more
to the lumped options. 

Example: many have asked for a way to turn off confirmations.  This has
led to the idea of a "reckless" (or perhaps "clear-cut"?) mode beyond
"old-growth" where there would be no confirmations, even for irreversable
actions.  Alternatively, it has been suggested that even novices should
have the option of being reckless.  I actually don't agree with the latter
view, having seen what happens to support costs when you make razor blades
easily available to the infirm and inexperienced, but the general issue is
quite valid: to what extent should "old-growth" features be individually
enabled vs. lumped. 

Other examples of power-user features include: bounce, piping to a Unix
cmd, aggregate operations, more complex searching, being able to enter a
msg number without the "J", etc... 

The global .pinerc provides a way to establish a baseline config for a
site, but we don't want to get to the point where there is a big business
opportunity for those wishing to provide personal pine configuration
support.  :)

Comments welcome, as always.

-teg

---

From: "A. Hilborne" <[email-masked]>
Date: Thu, 6 May 1993 09:13:00 +0100 (BST)

On Wed, 5 May 1993, Terry Gray wrote:

> OK, I'll bite. :)
> ..
> ..
> 
> Other examples of power-user features include: bounce, piping to a Unix cmd
                                                         ********************

There will never be agreement about all these possible features.  I
believe myself that a Unix mailer that doesn't allow everyone to pipe to a
command is seriously disenfranchising the user because s/he can't have
easy access to the powerfull Unix tools...

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 13 May 1993 16:39:48 -0700 (PDT)

On the old-growth mode:
     Seems like things that change the behavior of existing
  commands should have separate options in the .pinerc and not be
  lumped in to old-growth mode.  An example of this would be
  turning off the confirmation questions (only silly for some users). 

    Additions to Pine, like adding the bounce command, the pipe
  command, MIME style forwarding, additional information displays
  etc. can be lumped together. The main reason to relegate these to
  old-growth mode is so the novice user will not be confronted by
  more commands than they can make sense of. 

On the bounce command:
    Seems like there's several things the bounce command can be used for:
    - resending a message that didn't make it because of an incorrect address
    - management of a mailing list
    - others??
  
  Resending a returned message currently involves pulling it out of sent-mail
  and sending it on.  When this is done the original sender and the
  "re-sender" are the same.  Maybe the resend command can be added with 
  a confirmation question (or even prohibition) if the original sender and the
  "re-sender" are different.

LL

---

From: [email-masked] (James Ralston Crawford)
Date: Thu, 13 May 1993 21:14:32 -0400 (EDT)

>   - management of a mailing list

	Rerouting messages that were sent to the "wrong" person.  If I
([y]) receive a message from user [x] that really is more appropriate
for user [z], I want to change:

[x] -> [y]

	...to:

[x] -> [z]

	Using forward is unacceptable, because it instead produces:

[x] -> [y] -> [z]

	I don't often have cause to do something like this, but when I
do, "bounce" is about the only thing that does it effectively.

James

-- 
James Ralston Crawford \ System Administrator (cislabs) \ Co-AS (BEH)
[email-masked] \ [email-masked] \ [email-masked]
"Computer, you and I need to have a little talk."  - O'Brien, ST:DS9

---

From: Jeff Hayward <[email-masked]>
Date: Fri, 14 May 93 10:01:16 CDT

James Ralston Crawford writes:
  	Rerouting messages that were sent to the "wrong" person.  If I
  ([y]) receive a message from user [x] that really is more appropriate
  for user [z], I want to change:

This is in fact quite common.  There are a growing number of people
who read mail from a generic address mailbox and direct it to the
appropriate party (some Postmaster mail, user help desk, "general
info", "email receptionist", customer service, etc.)  "Bounce" really
is the best for these cases.
-- 
Jeff Hayward