Re: [Evolution] Bounce/remail command

["Jeffrey P. Lanza" <jpl alumni unh edu>]

On Thu, 20 Apr 2000, Dan Winship wrote:

> There are "Reply" and "Reply To All" buttons that do the obvious
> things. If you reply to a text message, it quotes it with "> "s. If
> you reply to an HTML message, it does the appropriate HTML quoting.
> (Is there a standard for that?) If you reply to a more complicated
> message, it will try to quote the parts you might be replying to and
> omit the rest. If you reply to a multipart/alternative, it will put
> your preferred part into the composer, and you only reply to that
> part. (If you have configured it to send multipart/alternative text,
> then it will regenerate the other part(s) from your composed reply,
> not from the original.)

  All of this sounds good, except I'd like the option to always reply to
everything as ASCII text.  I don't want anything to do with transmitting
HTML messages, but I want them to be readable when I get them.

> There is a "Forward" button. It will forward as a message/rfc822
> attachment. There should be some way to forward and edit something (so
> you can forward someone a message but edit out the secret bits, etc).
> I think the clean way to do this is to be able to edit the attached
> message (in which case we have to deal with the multipart/alternative
> splitting issue again). An alternative approach would be to have a
> "pre-MIME style" forwarding command that gives the user a draft
> containing the original message inline, with some sort of
> "---Forwarded message" boundaries.

  I'd also like the option to forward inline, as you suggest.  I don't
care if the default option is forwarding as an attachment as long as I can
change that default.

[snip more stuff on forwarding]

> There will be a "resend/bounce/remail" command. While "Resend" is the
> RFC-appropriate name for this operation, it may be worthwhile to come
> up with a name which more clearly states its intended purpose.
> ("Bounce" is no good: it implies "return to sender".) Regardless, the
> command will not be placed in an easy-to-find location. I think
> probably when you resend something, it will appear in the composer
> read-only, and all you can do is enter recipients. (I haven't seen
> anyone make a plausible argument for the use of "resend" that involved
> editing the message, and doing it this way also makes it harder for
> confused people to try to use it when they mean something else.)

  I don't think the command should be "hard to find", but it would be
acceptable to make it unavailable by default.  This is how it's handled in
Pine (one has to enter setup and explicitly turn "bounce" on) and would
address your concerns about "confused people".
  Also, I agree that one needn't be able to edit a message before
redirecting it.  I was going to argue that one should be free to do so,
but the more I think about it, the less that seems like a good idea.

> Does anything think any of this is horribly horribly wrong, or that
> there are other "get mail from your inbox to someone else's inbox"
> sorts of operations that are not covered by this?

  The only part I find horribly wrong is the attitude some folks are
showing towards the resend command.  I'll agree that it's not for everyone
and should only be available to advanced users, but it does have it's uses
and it should be there for those that need it.

-Jeffrey

--------------------------------------------------------------------------
                 Jeffrey P. Lanza <jpl alumni unh edu>
Computer Science Department             ResNet Second-Level Support
Engineering and Physical Sciences       Computing and Information Services
University of New Hampshire             603-862-4242, questions unh edu