Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Aha! | 7 comments | Create New Account
Click here to return to the 'Aha!' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Aha!
Authored by: joestalin on May 19, '02 04:21:08PM

That's a clever workaround. Thanks. I admit I'm also mystified as to how non-deletability is a feature, but I can live with this for the time being.



[ Reply to This | # ]
Aha! (Altering e-mail is problematic.)
Authored by: marcinjeske on May 20, '02 02:57:50AM

You ask how the inability to delete parts of an e-mail message is a design feature and not a bug. Portability is definitely one of the key reasons.

Many people do still follow the traditional model of connecting to a mail server, downloading all their new mail to their computer, and managing it locally. Being able to edit existing e-mail messages wouldn't really be a problem for them.

However, for the use of the more advanced features of the IMAP and POP protocols, which allow multiple e-mail clients to connect and access a shared store of messages on the server, the lack of this feature would be a major headache. Right now, each message on a mail server gets a globally unique identifier. Therefore, when IMAP clients synchronize with servers, they just need to provide such an identifier to retrieve a message. Now, if one of those clients were to delete a part of an e-mail message, how would you reconcile that with the rest of the system. The IMAP mail server wouldn't let the client update the message on the server... that's not how the protocol works.

Even if it did, should other clients which access the server retain the old copy or the new copy of the message? What about if multiple people (or multiple autonomous bots) access the same messages? They may not agree with your editorial policy, and it may disrupt their use of the messages. What about if multiple clients all change the message while disconnected? There will be several different versions of the message, and no way to resolve which one is which or which one should be the official one.

What about if you need to prove you sent or received a specific message... right now, it's existence on a server (assuming you don't run it and haven't currupted the admins) is pretty good evidence that it was sent. If you can make changes to it... well.

What I think you really want is to avoid caching it locally. That means it will not get downloaded to you computer. In Mail.app, you can set up message caching option by account in the Account Options pane. Simple instruct Mail.app to not cache attachments.

Perhaps Apple could address your concern in the future with a "Un-Cache" command of some sort.

If you truly want to remove an attachment from existence, your only option is to delete the message which it is a part of. The above advice of redirecting the message is a good way of retaining the text of the message.



[ Reply to This | # ]