[pmmail-list] A better explaination of the bug with PMMAIL attachments

[Kris Sorem Sr]

My reply to message from David Azarewicz sent on
Sun, 23 Sep 2001 13:40:11 -0700 (PDT). You wrote:

>What happened to customer service here?  A customer (several in fact) reported a 
>bug in which PMMail doesn't do what it is supposed to do.  What place do any of 
>these *opinions* about how a customer should use the product have here?

Customer service involves making the product work as advertised.
Customers, in general, do not buy a tool in order to coerce the
manufacturer to redesign it to fit their particular needs. Rather, a
customer buys a tool for how it is designed to effectively meet their
needs. Find a need and fill it. Every tool (software is no exemption) has
an *appropriate* and *inappropriate* way to be used. I've voiced an
opinion that PMMail _should not_ provide the means to *inappropriately*
use the forwarding function. But since it does, the function should be
corrected to work properly. That is customer service.

>  The fact 
>that a customer (several in fact) wants to use a product in a certain way is reason 
>enough to make the product work that way.  If a customer wants to forward a 
>message without opening the attachments, then fine, let him/her do it.  If a customer 
>wants to forward a message without even opening it, then fine, let him/her do it.  It is 
>really irrelevant as to whether you, or anyone else, thinks that is a good idea. The 
>customer may have a very good and legitimate reason for doing that.  There is no 
>way that you, or anyone else, can determine what is "competent" or "proper" for >the customer.

I disagree with the premise. For some reason, software is treated
differently than other tools that people use. Would you apply this
argument to any other tool? If the tool does not effectively meet the
customer's needs, they are free to find a new tool that does. The
manufacturer is under no obligation to redesign its tool to allow for it
to be used in an *inappropriate* way. In some cases, this could create
injury and/or liability to the manufacturer.

>
>As an example, I may have already read the message some time before, and >now I  want to forward it.  Why should I have to read it *again*?  (I may even have >re-set the read flag. A perfectly legitimate operation provided in the pop-up menu.) 

Not a very efficient way to use the tool, IMO. I still believe it would
appropriate to open the message to verify it is the message you wish to
forward to someone else.

> As for the 
>attachments, the example of how I found the bug 3 years ago still applies.  I was 
>distributing binary license files.  These files cannot and should not be opened by >the e-mail client. But it was correct to distribute them by forwarding the e-mail >message.

In response to the above example only. First, IMO, each binary license
file should have had a unique name and that unique name registered to a
single customer. No data corruption. No statement is made about why the
binary license was not sent directly to the customer. Forwarding in fact
provides the recipient with the information that the license actually came
from another source via you which seems to defeat the reason why it needed
to come from your address. Based upon the information provided, there are
more appropriate ways to resend the license other than forwarding. If it
needed to come from your address, the license attachment could have been
saved with a unique name, a personalize message created and the binary
license attached to it. No data corruption. The entire message with
license attachment could have been attached to a personalize message. No
data corruption.

>In this case I did open the messages but I did not open the attachments, and the 
>wrong attachments got sent.  Bouncing the messages was inappropriate because 
>the header needed to show me as the sender.

Apparently, the attachments were not saved either. In the case of PMMail,
if the MIME-encoded binary license attachment was to be left untouched,
bouncing it would do that. Since it needed to come from your address,
attaching the entire message to a newly formed message would do that. But
forwarding the message does not. Since the attachment(s) do not need to be
decoded in order to forward them, PMMail's implementation of forwarding
should be corrected to parse the MIME-encoded attachment(s) and not
decode.

>
>I think we need to revisit the question:  Are computers supposed to make human's 
>lives easier by conforming to how humans want to work, or are humans supposed >to make computer's/programmer's lives easier by conforming to how computers >work?

The answer lies in between. Apply it to any other tool you use.

--
JMO, 
/s/~Kris
-------------------------------+------------------------------------------