4 ms·

Well, duh - if you can delete, edit, and upload a NEW email clearly you can change the state of your mailbox. That's a new email though, it's not the same emai

Well, duh - if you can delete, edit, and upload a NEW email clearly you can change the state of your mailbox. That's a new email though, it's not the same email. Books are also not immutable - you can throw away a book and print a different book with the same cover. So at that level, nothing is immutable if you have full write access to it. The difference is, who has access to mutate the message? If you mutate it yourself, more power to you. It's your copy. If the SENDER can mutate it right there in your mailbox, that's a different story.

mehrdadn 9y ago
In what sense is it a "new" email? It has exactly the same headers and message body (except for whatever you choose to modify, obviously), including dates and sender and everything. It's like copying a file on top of another file and claiming the older one isn't modified, it's just a "new" file that you're copying. I mean, OK, but how is this a meaningful or useful statement? The result is pretty indistinguishable from having modified the bits of the original email in-place from the user's standpoint. If you mean it can't be mutated by anyone other than the account owner, then that would be worth clarifying I think? But even then, the same is true of, say, my Google Drive. Nobody can modify my files who hasn't received my explicit permission. So are files on Google Drive "immutable" to you?
- brongondwana 9y ago
  "modify it" - looks like a new email to me. It's going to have a different secure digest. You can argue semantics here - but the main difference is: YOU can modify the messages in your Inbox. THE SENDER can not. Unless they have write access to your mailbox and can copy things out in a client, edit them, and write them back.
  - mehrdadn 9y ago
    Regarding the "the sender" thing -- see my update above; sorry I was busy editing my comment before you posted this. Regarding the secure message digest: if that's your claim, maybe clarify that "[DKIM-]signed messages are tamper-proof"? Because not all email messages are signed. Also, I think you can still upload messages with broken signatures (not sure?) in most mailboxes, and the user won't necessarily know either (who verifies DKIM signatures manually?)... but I'd have to double-check this.
    - brongondwana 9y ago
      Yeah, probably true - I did mention our non-standard DIGEST.SHA1 (I'd like to change that algorithm at some point, though the risks are kind of overblown, particularly since we inject some randomness in the SESSIONID field that's part of the Received header added on every delivery) That said, if you tried to claim that a message was from somebody and used a tampered version, then checking the DKIM signature is something I expect would be done as part of the forensic analysis, as would checking the mail server logs. At least on our servers, you'd be able to tell from the logs that the digest changed when the new copy was uploaded - assuming you claimed something about downloading it and moving it to a new folder with your client.

mehrdadn 9y ago

In what sense is it a "new" email? It has exactly the same headers and message body (except for whatever you choose to modify, obviously), including dates and sender and everything. It's like copying a file on top of another file and claiming the older one isn't modified, it's just a "new" file that you're copying. I mean, OK, but how is this a meaningful or useful statement? The result is pretty indistinguishable from having modified the bits of the original email in-place from the user's standpoint. If you mean it can't be mutated by anyone other than the account owner, then that would be worth clarifying I think? But even then, the same is true of, say, my Google Drive. Nobody can modify my files who hasn't received my explicit permission. So are files on Google Drive "immutable" to you?

brongondwana 9y ago
"modify it" - looks like a new email to me. It's going to have a different secure digest. You can argue semantics here - but the main difference is: YOU can modify the messages in your Inbox. THE SENDER can not. Unless they have write access to your mailbox and can copy things out in a client, edit them, and write them back.
- mehrdadn 9y ago
  Regarding the "the sender" thing -- see my update above; sorry I was busy editing my comment before you posted this. Regarding the secure message digest: if that's your claim, maybe clarify that "[DKIM-]signed messages are tamper-proof"? Because not all email messages are signed. Also, I think you can still upload messages with broken signatures (not sure?) in most mailboxes, and the user won't necessarily know either (who verifies DKIM signatures manually?)... but I'd have to double-check this.
  - brongondwana 9y ago
    Yeah, probably true - I did mention our non-standard DIGEST.SHA1 (I'd like to change that algorithm at some point, though the risks are kind of overblown, particularly since we inject some randomness in the SESSIONID field that's part of the Received header added on every delivery) That said, if you tried to claim that a message was from somebody and used a tampered version, then checking the DKIM signature is something I expect would be done as part of the forensic analysis, as would checking the mail server logs. At least on our servers, you'd be able to tell from the logs that the digest changed when the new copy was uploaded - assuming you claimed something about downloading it and moving it to a new folder with your client.