Re: [Evolution] Bounce/remail command

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 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]