How to detect self destructing emails? How to prevent from self destruction?
It is not possible to create a digital communication that will self-destruct after a certain amount of time (or upon sender's command). This because of the nature of the message, which once reaches the recipient' machine can be copied at will. This applies to email as well as instant messages.
Therefore any service promising you messages that self-destruct after some time (e.g. Snapchat) simply do not work.
The golden rule to remember in digital communications is that once you send a message, you have no control over it.
> any way to prevent it from self destruction?
Simply copy the message text, with full headers, and paste it into another window. (Or forward the message to another email address you control. Or start a reply quoting the original message, and save the draft. I don't know how this Gmail extension works, but if it allows this, it's dumber than I thought.)
Self-destructing emails, like email read receipts and mail services which tell you they can tell you which recipients have read your message and which have not, are at best misleading and at worse a con perpetrated on ignorant managers, executives and users who don't understand how email works.
In general, all of these schemes rely on the recipient buying into the whole process and not doing anything to subvert it. Self-destructing email either uses client extensions, where both the sender and recipient use the extension, or they rely on a 3rd party server which acts as a type of relay.
In the extension scenario, the message has additional meta-data which tells the recipient's extension to delete the message after a certain period or after it has been opened once. It will normally be necessary for the recipient to agree to allow the extension to do this. The recipient can always remove the extension or turn off this functionality, in which case the message will not be deleted unless the user explicitly tells their client to do so.
With the server scenario, the 3rd party relay will normally send a new message to the recipient which requires some sort of interaction with the 3rd party server for the recipient's client to render the contents. It could be as simple as downloading an image from the server, or requiring a request to the server to get a key to decrypt and display the message, or something more complicated. The objective is to force the recipient to use the server in order to access the message. The server can then remove either the message or access to the message based on some criteria specified by the sender.
However, the underlying problem with all of this is that if you can read the message, you can copy the message. If you can copy the message, you don't need the original and what happens to the original is irrelevant.
The issue here is that calling something like this self-destructing or self-destroying is misleading. When people hear it, they immediately picture scenes from Mission Impossible and are given the false impression that their email will no longer exist. Unfortunately, SnapChat users found out how false this assumption is the hard way when "sensitive" photos they had sent and thought would be destroyed began to show up on other web sites.
We are in the digital age and in the digital age, copies are as good as the originals. Once upon a time, copies meant reduced quality — the more something was copied, the less the quality. This is not true with digital data — the copy is as good as the original (and contrary to all those TV shows, you cannot improve the quality either — you might be able to enhance it, but you cannot improve it).
The basic protocol underlying email is very simple. It does not yet include advanced features like read receipts, self destruction, etc. Extensions for things like read receipts have been proposed and some "unofficial" support exists in some clients such as Outlook and Apple Mail. However, these are unofficial and generally, can be turned off by the recipient. If someone is not using a mail client which supports the extension, nothing will happen.
Same goes for many of those schemes that claim they can tell you when your email has been read by a recipient. Most of those solutions rely on things like clear glyph images being embedded inside the message — the glyph is actually an image with a remote URL. The remote URL is coded to identify the message it was embedded in. If the server receives a request for that URL, it is a safe bet that someone has tried to read the message. However, this completely fails if the user does not use an HTML based mail client or has disabled the automatic loading of images — many people do so for security reasons. It may also fail if the message is read off-line. It can also give false positives depending on the client. Some clients might try to improve performance by pre-fetching data, in which case the client will think the message has been read when it hasn't.
I think the goal of self-destructing email is not to erase the email, but to erase the information about who generates/sends the email. Under this idea:
Self-destructing email works if content of the email can be easily generated. If the email contains only text (e.g. "I love you!"), then the receiver can easily write it down or copy it. But with a self-destructing email, the recipient cannot tell other people that the sender has sent this message before, since the email server will have no trace of the email (unlike a normal email server). Of course the receiver can show the copied message, but other people can reply that it is too easy to fabricate by the receiver.
Self-destructing email might not work if the content of the email is hard to generate. For example, it might be hard to fabricate a photo. So when the receiver shows a photo of the sender, other people might be more likely to believe that the sender indeed has sent the photo before.
Self-destructing email will not work if the information content in the email is important by itself. For example, if you send your debit card PIN in the email, then self-destructing it makes no big difference...