KR20030052582A - Method for recovering electronic mail message and computer readable medium storing thereof - Google Patents

Abstract

PURPOSE: A method for recovering an E-mail and a recording medium capable of being read by a computer including the same are provided to recover an E-mail as the original state although the E-mail or an E-mail box including the E-mail is deleted or damaged. CONSTITUTION: If a user selects a disk drive having recovery data(S100), an FAT(File Allocation Table) and a directory entry are searched. A recovery is executed using information of a file, which remains in a directory entry, and contents of a file in an actual data sector through a directory scan operation(S200). A cluster scan operation is executed(S300). A deleted E-mail is extracted using a file header and a message header through an analysis of a message file format being used according to E-mail clients(S400). When the user reads the message, the message is decoded with respect to an encoded character string. Thus, a MINE decoding is executed(S500). The message is recovered, displayed through a computer monitor(S600).

Description

METHOD FOR RECOVERING ELECTRONIC MAIL MESSAGE AND COMPUTER READABLE MEDIUM STORING THEREOF}

The present invention relates to a method for recovering an e-mail message and a computer-readable recording medium storing the same, and more particularly, to recovering an e-mail deleted or damaged in an e-mail box to its original state, and a method for recovering an e-mail message. A storage computer readable recording medium.

In general, Internet e-mail (hereinafter referred to as e-mail) refers to an act of sending or receiving an electronic letter to the other party through the Internet environment, and a system that enables the use of such e-mail is called an Internet e-mail system.

The advantages of e-mail are easy to use, fast, and low cost, so it is widely used in domestic and foreign work or personal work, and the use of e-mail can be transmitted and received anywhere in the world.

However, due to problems such as the capacity of the system that can hold the e-mail message, the received e-mail is generally arranged, the user can delete the e-mail that must be stored unintentionally and empty the trash. With this in mind, in order to prevent accidental deletion of emails, email client programs such as Outlook Express, Netscape Mail, Eudora Mail, etc. There is a function called Deleted E-mail Box.

However, depending on the option of the e-mail client program, you can delete the deleted e-mail box when the program is terminated. If a certain amount is filled, the e-mail box is deleted by emptying the deleted e-mail box.

The problem is that there is no way to read the deleted e-mail anymore.

Accordingly, the present invention has been made in an effort to solve the above-mentioned problems, and an object of the present invention is to solve the above problems even if the e-mail message is deleted or damaged or if the e-mail box including the e-mail message is damaged or deleted. The present invention provides a method for recovering an e-mail message that can be recovered with an e-mail message.

Another object of the present invention is to provide a computer-readable recording medium storing the above-described method for recovering an e-mail message.

1 is a diagram for describing a driver structure of a general hard disk.

2 is a flowchart illustrating a method for recovering an e-mail message according to an embodiment of the present invention.

3 is a flowchart illustrating a directory scan operation according to an embodiment of the present invention.

4 is a view for explaining an example of an e-mail box list detected after the directory scan operation according to FIG. 3.

5 is a flowchart illustrating a cluster scan operation according to an embodiment of the present invention.

FIG. 6 is a diagram for explaining an example of an e-mail box list detected after the cluster scan operation according to FIG. 5.

7 is a flowchart illustrating a message format analysis operation according to an embodiment of the present invention.

8A and 8B are diagrams for explaining a file header and a message header of a DBX file, respectively.

9 is a flowchart illustrating a binary file decoding operation according to an embodiment of the present invention.

10 is a diagram for explaining a header structure of an Internet e-mail.

E-mail message recovery method according to one feature for realizing the above object of the present invention,

(a) recovering one or more e-mail boxes deleted or damaged in the disk drive through a directory scan operation and a cluster scan operation as a specific disk drive is selected according to a user's operation to recover an e-mail message;

(b) recovering one or more e-mail messages through an e-mail message format analysis operation and a binary file decoding operation within the recovered e-mail box; And

(c) storing the one or more e-mail messages recovered in step (b).

Here, the directory scanning operation of step (a) may include (a-11) setting the number of scans of a directory existing in the disk drive; (a-12) analyzing the signature of the file to be recovered; (a-13) checking whether the file is an e-mail file based on the analyzed signature; (a-14) registering as an e-mail list when the e-mail is checked in step (a-13); (a-15) When it is checked that it is not an e-mail in step (a-13) and the current count value after step (a-14) is less than or equal to the number of scans set in step (a-11). Checking whether or not; (a-16) If it is checked in step (a-15) that the current count value is less than or equal to the set number of scans, increasing the count value to reset the current count value and feeding back to the step (a-13). ; And (a-17) if it is checked in step (a-15) that the current count value is larger than the set number of scans, performing the cluster scan operation.

In addition, the cluster scan operation of step (a) may include (a-21) setting a total number of clusters present in the disk drive; (a-22) analyzing the signature of the file to be recovered; (a-23) checking whether the file is an e-mail file based on the analyzed signature; (a-24) analyzing the file size if it is checked as an e-mail file in step (a-23); (a-25) registering to an e-mail list based on the analyzed file size; (a-26) When it is checked in the step (a-23) that it is not an e-mail file, and after the step (a-25), the current count value is smaller than or equal to the count set in the step (a-21). Checking whether or not; (a-27) If it is checked in step (a-26) that the current count value is less than or equal to the count set in step (a-1), the count value is increased to set the current count value and the step (a-26) is performed. Feedback to 22); And (a-28) if it is checked in step (a-26) that the current count value is greater than the count set in step (a-21), the step (b) is preferably performed.

In addition, the operation of analyzing the e-mail message format of step (b) may include (b-11) setting the file size to a count value; (b-12) checking whether the e-mail message is an e-mail message by checking a start record of the e-mail message; (b-13) registering the e-mail message in the message list if it is checked in step (b-12); (b-14) checking if the e-mail message is not the same as the e-mail message in step (b-12) and if the current count value is less than or equal to the set count value following the step (b-13); (b-15) If it is checked in step (b-14) that the current count value is less than or equal to the set count value, the current count value is increased to reset the current count value, and the feedback is returned to the step (b-12). Making; And (b-16) if it is checked in step (b-14) that the current count value is larger than the set count value, performing step (c).

In addition, the binary file decoding operation of the step (b) comprises the steps of (b-21) analyzing the mime pattern; (b-22) if it is checked uuencode based on the mime pattern analyzed in step (b-21), performing uuencode decoding; (b-23) performing BinHex decoding when BinHex is checked based on the mime pattern analyzed in step (b-21); (b-24) performing Basse64 decoding when Basse64 is checked based on the mime pattern analyzed in step (b-21); And (b-25) performing QuotedPrintable decoding when it is checked as QuotedPrintable based on the mime pattern analyzed in step (b-21).

In addition, a computer-readable recording medium storing an e-mail message recovery method according to one feature for achieving the above object of the present invention,

(a) recovering one or more e-mail boxes deleted or damaged in the disk drive through a directory scan operation and a cluster scan operation as a specific disk drive is selected according to a user's operation to recover an e-mail message;

(b) recovering one or more e-mail messages through an e-mail message format analysis operation and a binary file decoding operation within the recovered e-mail box; And

(c) storing the one or more e-mail messages recovered in step (b).

According to a computer-readable recording medium storing such an e-mail message recovery method, even if an e-mail DB file is erased simply by a deleted e-mail message file or a virus or format, the actual contents of the e-mail DB file are stored on the hard disk. If you are in, you can restore the e-mail DB file to read the e-mail first.

Then, embodiments will be described so that those skilled in the art can easily implement the present invention.

FIG. 1 is a diagram for explaining a driver structure of a general hard disk. In particular, an example of the structure of a hard disk having two drivers will be described.

Referring to FIG. 1, data sectors store actual contents according to file storage, FAT1 and FAT2 store cluster information of a file and fragmented information of a file, and directory entries include name, size, date, etc., which are basic information of a file. Save it.

When a file is deleted according to the general process, only some information of the file is deleted from the FAT (File Allocation Table) and the directory entry, and the actual data contents stored in the data sector are not deleted. .

In the present invention, the above-described characteristics are used to recover an e-mail message.

2 is a flowchart illustrating an e-mail message recovery method according to an embodiment of the present invention.

Referring to FIG. 2, first, as a disk drive containing data to be recovered is selected by a user's operation (step S100), a FAT and a directory entry are searched as shown in FIG. As shown in FIG. 1, in general, a Windows OS stores file system information such as file size and initial cluster number in a directory entry, data position information in a FAT, and data itself in a data area.

Subsequently, a directory scan operation is performed using the information of the file remaining in the directory entry (root directory in FIG. 1) and the contents of the file in the actual data sector (step S200).

Then, a cluster scan operation is performed (step S300). That is, when data is corrupted by a virus or quick format, generally only contents of a master boot record (MBR), a boot sector, a FAT, a directory entry (or a root directory), and the like are damaged. Since the contents of the actual data in the sector are mostly intact, the contents of the files in the actual data sector can be analyzed and recovered automatically.

In particular, step S200 and step S300 may be referred to as a series of techniques for recovering deleted e-mail box files from the hard disk (e-mail box file recovery) among a plurality of e-mail boxes provided by a plurality of e-mail clients. The above-mentioned e-mail box file recovery is a technique for searching an e-mail box files by searching the hard disk when the e-mail box itself is erased on the hard disk due to a virus or a format, which will be described in detail with reference to FIGS. 3 and 5. do.

Then, the deleted e-mail message is extracted using the file header and the message header by analyzing the message file format used for each e-mail client (step S400).

Subsequently, the decoding process (binary file decoding) is performed on the encoded character string when the message is viewed or stored in the received message. In the example of the present invention, MIME decoding is performed (step S500).

In particular, the reason for performing the above-described mine decoding is as follows.

As the use of the Internet increased, the necessity of exchanging documents created by general programs, word processors, spreadsheets, and other applications emerged. These files use 8 bits, unlike text having 7 bits in length. It is called.

In addition, as the internationalization of the Internet is promoted, text characters consisting of characters of countries other than US-ASCII are represented by using the eighth most significant bit (MSB), and thus 8-bit transmission is required.

Mine decoding is performed because 8bit characters or binary files must be encoded and decoded again to 8bit in order to be safely delivered without being cut by the MSB by SMTP.

In particular, the steps S400 and S500 are techniques for recovering a message from a recovered e-mail box and extracting the message into an * .EML file, which can be referred to as an e-mail message recovery, which will be described in detail with reference to FIGS. 7 and 9. This is explained in

The message is then displayed on the computer monitor and the message is stored (step S600).

As described above, according to the present invention, first, as a disk drive is selected according to a user's operation, a plurality of e-mail boxes provided by a plurality of e-mail clients are restored through directory scan and cluster scan, and the recovered electronic You can recover email messages through a series of operations that perform message format analysis and binary decoding to recover email messages that have actually been deleted within the mailbox, even if the email box is deleted, You can recover deleted email messages within a deleted email box.

3 is a flowchart illustrating a directory scan operation according to an exemplary embodiment of the present invention. In particular, step S200 of FIG. 2 will be described in more detail.

2 and 3, as the hard disk to be recovered is selected (step S100), first, the total number of directories that can be scanned is set as the current count value based on the directory entry count value existing on the hard disk ( Step S210).

Next, after analyzing the signature of the file using the directory entry information (step S220), it is checked whether the file is an e-mail file (step S230).

If it is checked in step S230 that the e-mail file is checked, information on the root directory area and directory entry is retrieved to create a deleted e-mail box list and then registered in the e-mail list (step S240). Here, "recovery" registers the data of the cluster (a logical division unit of the hard disk) on the hard disk in the form of a virtual file using directory entry information (cluster location, file name, file size, etc.). Say that. Once registered in the list in the form of a virtual file, the contents of the file can be retrieved. That is, in the case of an erased file, the file is processed as a virtual file because it cannot be operated in the form of a general file.

If it is checked in step S230 that it is not an e-mail file, and after step S240, it is checked whether the current count value is less than or equal to the set count (step S250).

If it is checked in step S250 that the current count value is greater than the set count, the flow advances to step S300. If the current count value is checked to be less than or equal to the count set in step S210, the count is incremented by one and set to the current count value. After that, the process feeds back to step S220 (step S260).

As described above, the e-mail recovery program according to the present invention searches the information of the root directory area and the directory entry to create a deleted e-mail box list. For example, in Windows OS, if the file name is longer than eight characters or mixed case, long file name information is also stored.

When the OS deletes an email box file, it only deletes the first character of the short file name, not the actual name information of the long file name. Thus, the first character of a file and folder is deleted and marked with a shop notation (#), or even if a file with long file name information is deleted, it can be restored to its original e-mail box name.

4 is a view for explaining an example of an e-mail box list detected after the directory scan operation according to FIG. 3.

Referring to FIG. 4, with the end of the directory search of FIG. 3 described above, an item type of an e-mail box is displayed in the left window of the monitor of the user computer, and a list of directories and files for the item is displayed in the right window. Displayed with detailed information.

FIG. 5 is a flowchart illustrating a cluster scan operation according to an embodiment of the present invention. In particular, step S300 of FIG. 2 will be described in more detail.

Referring to FIG. 5, first, a count value is set by searching for the total number of clusters present in the hard disk (step S310).

Next, after analyzing the signature of the file using the cluster head data located at the head of the cluster (step S320), it is checked whether or not it is an e-mail file (step S330). In this case, the recovery means the data of the cluster (or logical division unit of the hard disk) on the hard disk using the directory entry information, that is, the location of the cluster, the file name, the file size, and the like. To register a list in the form. Since directory entry information is not available here, the file size and file name are calculated by analyzing the cluster data. As such, when the list is registered in the form of a virtual file, the contents of the file can be retrieved. In other words, if an erased file cannot be manipulated in the form of a normal file, it is treated as a virtual file.

If it is checked in step S330 that it is not an e-mail file, and after step S350, it is checked whether the current count value is less than or equal to the set count (step S360).

If it is checked in step S360 that the current count value is greater than the set count, the process proceeds to step S400. If it is checked that the current count value is less than or equal to the set count, the count is increased by one to set the current count value, and then the process goes to step S320. Feedback (step S370).

On the other hand, most e-mail clients require a lot of time and effort because the format of the file is not public and must be inferred and tested.

That is, because different e-mail message formats are used in different e-mail clients, the embodiment of the present invention describes only the widely used Outlook Express 5.0.

The e-mail message used in Outlook Express 5.0 is a file whose extension is * .DBX, as shown in FIG. 5, and includes a file header indicating information on the e-mail box file and a message indicating each message information. It consists of a header.

The file format of Outlook Express is the same principle as restoring files on the hard disk. E-mail messages that are not actually deleted from the e-mail box can be recovered using the file header alone. Since the e-mail message information has been deleted, the entire e-mail box can be analyzed by byte to recover.

Then, how to recover the deleted or deleted e-mail message in the restored e-mail box will be described in detail with reference to the accompanying drawings.

7 is a flowchart illustrating a message format analysis operation according to an embodiment of the present invention. In particular, step S400 of FIG. 2 will be described in more detail.

Referring to FIG. 7, first, a file size to be restored is set to a count value (step S410). Here, the case where there is only one file to be restored is explained as an example.

Then, it is determined whether it is a start record of an e-mail message (step S420).

Then, it is checked whether or not it is an e-mail message (step S430). If it is checked as an e-mail message, the message recovery operation by the file header and the message header and the message recovery operation by the file search in bytes are performed in the e-mail box. Recovers the e-mail message and registers it in the message list (step S440). That is, as in the case of registering the list in the form of a virtual file using the cluster data, only the portion corresponding to the e-mail message is extracted from the virtual file and registered in the message list. Say that. In conclusion, recovery refers to getting data from a specific location (cluster) on the hard disk.

Then, as in the above step S430, in order to check whether or not the Internet e-mail to know the structure of the Internet e-mail, the structure of the Internet e-mail is shown in FIG.

FIG. 10 is a diagram for explaining the header structure of an Internet e-mail. In case of a deleted message, it is determined whether the header structure of the Internet e-mail has the above-described header structure of the Internet e-mail.

Next, referring to FIG. 10 described above, message recovery by byte-based analysis will be described in detail.

(1) In general, an Internet text message consists of a header and a body, and consists of one or more lines of text. The header and body are separated by a combination of a carriage return (CR) and a line feed (LF). This is done through a NULL line consisting of only CRLF). Here, each line ends with a combination of a carriage return (CR) and a line feed (LF) (CRLF), except for the header, the maximum length of each line has a maximum of 76 characters. If you look at the header, sometimes a line is more than 76 characters long. It can't be infinitely long, and if you think about one line up to 256 characters long, there's no problem with header handling. This is not a limitation of the e-mail itself, but also a limitation of SMTP or POP.

According to the structure of FIG. 10 described above, the end of the header is a time at which the NULL line appears. In other words, the header is considered until the first NULL line.

Then, the configuration of the header field will be described in more detail.

Each field in the header consists of the following format: <field name>: <field contents> CRLF. Where <field name> is not case sensitive. In some cases, you might want to write the contents of a field on multiple lines to make it easier for the reader to read, or because of other constraints. In this case, a linear white space character (LWSP Char.) Is inserted at the beginning of the line to indicate that it is a continuous field. In addition, the character corresponding to the space character LWSP may include a space, a tab, and the like.

For example, all four header fields below are identical: CRLF is also recognized as part of the LWSP character. When multiple lines of field contents are unfolded, LWSP characters are treated as a single SPACE character. Characters like backspace are not treated as whitespace and are a bit dangerous.

_{-------------------------------------------------- --------------------------------------------------}

_{To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN}

_{To: "Joe & J. Harvey" <ddd @ Org>,}

_{JJV @ BBN}

_{To: "Joe & J. Harvey"}

_{<ddd @ Org>, JJV}

_@BBN

_{To: "Joe &}

_{J. Harvey "<ddd @ Org>, JJV @ BBN}

_{-------------------------------------------------- --------------------------------------------------}

Thus, when processing a header, if the first character is SPACE or TAB, it can be determined that it follows the header of the previous line. Usually, most systems simply put one TAB, but in some cases multiple SPACEs can be entered.

1) Date / Time related header field: "Date" header field

grammar)

_{-------------------------------------------------- --------------------------------------------------}

_{"Date:" date-time}

_{date-time: = [day ","] date time}

_{day: = "Mon" / "Tue" / "wed" / "Thu" / "Fri" / "Sat" / "Sun"}

_{date: = 1or2Digit month 2Digit}

_{month: = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun"}

_{/ "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"}

_{time: = hour zone}

_{hour: = 2Digit ":" 2Digit [":" 2Digit]}

_{zone: = "UT" / "GMT"; Universal time}

_{/ "EST" / "EDT"; Eastern}

_{/ "CST" / "CDT"; Central}

_{/ "MST" / "MDT"; Mountain}

_{/ "PST" / "PDT"; Pacific}

_{/ 1 Alpha; Military}

_{/ ("+" / "-") 4Digit; Local Difference}

_{-------------------------------------------------- --------------------------------------------------}

Yes)

Mon, 11 Oct 1999 16:17:24 +0900

This field is usually filled in by the MTA.

2) Header Fields for Path Tracking

Return-Path: route-addr

Received: ...

...

Herein, the "Return-Path" header field designates an e-mail box (id @ host format) to which a message is returned when a message transmission fails, and an e-mail box and an address may be specified in various ways.

Also, if you look at the actual message source in the "Received" header field, it can be seen that there are several header fields. This field is automatically added by the MTA to keep track of which intermediate path an email was sent through. Normally, when setting up the MTA, if there are more than one "Received" headers, the e-mail is often looped or treated as undeliverable.

3) Header field containing information about the sender

_{-------------------------------------------------- --------------------------------------------------}

_{From: mailbox}

_{Sender: address}

_{Reply-To: address}

_{-------------------------------------------------- --------------------------------------------------}

In this case, the "From" header field is used to write the sender's name in the envelope, and indicates an e-mail box of the sender of the message.

Also, the "Sender" header field is used to indicate who actually sent the message, as we can ask someone to bring it to the post office even if we write it.

Also, the "Reply-To" header field is the address of the person to whom the message is to be replied, and may be set differently depending on the case. In general, the same address as the From address is used. If the above fields are set, do not refer to From when sending a reply. If the above fields are not set, the reply will be sent by referring to From.

4) Header field for the receiver

_{-------------------------------------------------- --------------------------------------------------}

_{To: address}

_{cc: address}

_{bcc: address}

_{-------------------------------------------------- --------------------------------------------------}

Here, the "To" header field specifies the address of the person (s) to receive the message. You can specify multiple people or create groups. The recipient specified in this field is called the "primary receiver".

In addition, the "cc" field may also specify the person (s) to receive the message. The recipients specified here are called "sub-recipients" and are usually labeled "references."

In addition, the above-mentioned "bcc" field is called "sub-recipient" and is usually denoted "bcc".

5) Other header fields

_{-------------------------------------------------- --------------------------------------------------}

_{Subject: text}

_{Messeage-ID: msg-id}

_{In-Reply-To: msg-id}

_{-------------------------------------------------- --------------------------------------------------}

Here, the "Subject" header field is a field for writing a message subject, and the "Message-ID" header field is usually the current time (calculated in seconds from midnight January 1, 1970 to the present time). , A combination of the MTA's IP address, etc.

6) Extended / Custom Header Fields

Normally, header fields beginning with "X-" mean extended header fields, not fields defined by the RFC as standard. Among them, "X-Priority" and "X-Mailer" are widely used.

7) Addressing

When specifying a general domain name, there are no restrictions, but when specifying a direct IP address, use square brackets ([,]) as in [10.0.3.19].

In addition, as an addressing method that can be actually used from From, To, etc., it is possible to directly specify an e-mail box, such as Neuman @ BBN-TENEXA, and to modify an e-mail box, such as Alfred Neuman <Neuman@BBN.TENEXA>. How to Use Characters Together, "George, Ted" <Shared@Group.Arpanet>, How to Use Quotes, Wilt. (the Stilt) There are ways to use annotations, such as Chamberlain@NBA.US (same as Wilt.Chamberlain@NBA.US).

In addition, group designation is also possible as follows.

_{-------------------------------------------------- --------------------------------------------------}

_{Gourments: Pompous Person <WhoZiWhatZit @ Cordon-Blue>,}

_{Childs@WGBH.Boston, Galloping Gourmet @}

_{ANT.Down-Under (Australian National Television),}

_{Cheapie @ Discount-Liqours;}

_{Cruisers: Port @ portugal, Jones @ EA ;,}

_{Another@Somewhere.SomeOrg}

_{-------------------------------------------------- --------------------------------------------------}

On the other hand, the use of parentheses is defined in the header field content as follows.

_{-------------------------------------------------- --------------------------------------------------}

_{(,): Parentheses are used to add comments.}

_{:,; Colons and semicolons are used to indicate groups when addressing To and Cc.}

_{<,>: Both angle brackets are used to indicate addressing or routing paths.}

_{[,]: Square brackets are used to specify an IP address directly.}

_{-------------------------------------------------- --------------------------------------------------}

In the above, the procedure of analyzing the header of the e-mail message and registering it in the e-mail list in order to recover the deleted e-mail message and register it in the e-mail list has been described.

On the other hand, if it is checked in the case of non-e-mail message in step S430, and it is checked whether the current count value is less than or equal to the set count following step S440 (step S450).

If it is checked in step S450 that the current count value is less than or equal to the set count, the count is increased by 1 to set the current count value, then fed back to step S420 (step S460), and the current count value is checked to be greater than the set count. The process proceeds to step S500.

Of course, the above embodiment has been described assuming that there is only one file to be restored, but if there are a plurality of files to be restored, the size of each file is set to a count value, and a message is restored to the recovery and message list within the set count value. It is obvious to repeat the registration process.

On the other hand, in the e-mail recovery program according to the present invention to perform a decoding process for the encoded string when the message view or message storage for the received message further performs a binary file decoding operation, a detailed description thereof will be described below Describe.

In other words, STD 10 / RFC 821 states that data transmitted via SMTP is 7-bit ASCII data with the upper bit set to '0', which is suitable for sending English text messages, but not for non-English or non-text data. Not suitable for In order to overcome this limitation, as shown in FIG. 9, an approach using MIME (Multipurpose Internet Mail Extension), which is extended to be used for various purposes, may be used. Here, mime was developed in RFC 2045 to RFC 2049 to specify a mechanism for encoding text and binary data into 7-bit ASCII as defined in RFC 822 to enable the transfer of different types of files via Internet e-mail. Protocol.

This MIME type consists of two parts, one of which is a main type and the other of which is a sub type. The main type tells you what kind of file you want to handle: Text, Video, Application, Image, Audio, Multipart, Message. There are seven subtypes that specify a particular file type or application in the main type. For example, 'image / gif' means the file is a GIF graphic.

Next, a procedure for recovering a mail message through a binary file decoding operation will be described in more detail with reference to the accompanying drawings.

FIG. 9 is a flowchart illustrating a binary file decoding operation according to an embodiment of the present invention. In particular, FIG. 2 will be described in more detail with reference to step S500, and a flowchart for explaining mime decoding.

Referring to FIG. 9, first, a mime pattern is analyzed (step S510).

Subsequently, it is checked whether it is 'uuencode' based on the mime pattern analyzed in step S510 (step S520), and when it is checked as 'uuencode', uuencode decoding is performed (step S525). In other words, uuencode, which is widely used in Unix or DOS, has a header and a taylor, and characters other than the header and taylor are excluded from decoding. The header starts with 'begin' and consists of the octal mode and the original file name.

The encoded body ends with a line with whitespace and contains a data line called 'end'. The 64 characters used in the encoding are:

_{-------------------------------------------------- --------------------------------------------------}

_{'! "# $% &' () * +,-. / 0123456789:; <=>? @ ABCDEFGHIJKLMNOPQRSTUVWXYZ [^ _}

_{-------------------------------------------------- --------------------------------------------------}

The principle of 'uuencode' is that dividing 3 pairs of 8 bits into 4 bits is the same as 'Basse64', but adding 32 (space code) to map the values to the ASCII areas that can be represented as characters as above. . That is, the encoded character value itself depends on the ASCII code value, and there are characters that do not correspond to other code systems.

The first one encoded character of each line of the encoded body indicates the number of bytes of the remaining characters of the line, and the last extra handling is also controlled by this character. 'Uuencode' is not recommended for email, but traditionally Commonly used in newsgroups.

If it is checked in step S520 that it is not 'uuencode', it is checked whether it is 'BinHex' (step S530), and if it is checked, 'BinHex', decoding is performed (step S535). BinHex is an encoding scheme designed to transmit binary data having a special file structure of a Macintosh system. Macintosh files are divided into parts called resource folks and data folks.

Herein, a data folk constitutes data of an actual file, and a resource folk includes information related to icons, variables, and program segments related to the Macintosh system OS.

However, 'BinHex' contains characters that can be distorted according to the system, like 'uuencode' described above. The method is recommended.

This is because only the data folk needed for the recipient is a personal computer system or a UNIX system user can be easily extracted, and both file components are available even if the recipient uses a Macintosh system. . BinHex is also proposed as a standard for MIME by RFC1741, but cannot guarantee safety. The above Request For Comments (RFC) is an official document related to Internet technology published by the Internet Engineering Task Force (IETF), which means that it is intended as a remedy for the method that has been written so far, and that it is not recommended to use it in the future. It is implicated.

If it is checked in step S530 that it is not 'BinHex', it is checked whether it is 'Basse64' (step S540), and if it is checked, 'Basse64', Basse64 decoding is performed (step S545).

More specifically, 'Basse64' refers to a code system according to RFC 1113, and refers to a MIME encoding method that converts 8-bit data by 6 bits, matching each 6 bit to a specific code value, including EBCDIC or ASCII. It uses 'International Alphabet IA5' expressed on the platform and uses 64 characters and "=" which is a code that performs a special function as shown below.

_{-------------------------------------------------- --------------------------------------------------}

_{ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 + /}

_{-------------------------------------------------- --------------------------------------------------}

In addition, each character is given a code-independent value, which does not alter the characteristics of the system.

The principle of the Basse64 encoding described above is as follows. That is, the 64 alphabetic characters that are used in any system are values in the order of '0' to '63' regardless of the ASCII code order. That is, these 8 characters represent three 8-bit values (3 bytes) as four characters each representing a 6-bit value. In other words, three 8-bits are divided into four 6-bits, which are encoded in correspondence with the characters with the corresponding values. The "=" symbol at the end of the encoded statement is used to fill in the last part of the bit string to allocate 6 bits and represent the remaining 6-bit values.

Therefore, it can be seen that in any system, the bit strings can be mapped to values that are not related to code order.

If it is checked in step S540 that it is not 'Basse64', it is checked whether it is 'Quoted Printable' (hereinafter referred to as QP) (step S550), and if it is checked as Quoted Printable, Quoted Printable decoding is performed (step S555). .

More specifically, the principle of QP is to encode using the special symbol "=" and the hexadecimal code of the character. For example, QP encoding the character "M nchen" is equivalent to "M = FCnchen".

However, using QP encoding in Hangul e-mail can increase the transmission capacity by up to three times. For example, when using QP encoding for "to go", "= B0 = A1 = B3 = AA = B4 = D9". Becomes Therefore, QP encoding is an inefficient encoding method for Korean e-mail.

As described above, according to the present invention, the deleted e-mail box file can be recovered from the hard disk, and the e-mail message can be recovered from the restored e-mail box.

Although the above has been described with reference to a preferred embodiment of the present invention, those skilled in the art will be able to variously modify and change the present invention without departing from the spirit and scope of the invention as set forth in the claims below. It will be appreciated.

As described above, the e-mail message recovery program provided according to the present invention deletes only the information part of the e-mail even if the e-mail is deleted, and deletes the data by using the e-mail DB file on the actual hard disk since the data remains. You can recover an email. Also, even if the e-mail DB file is deleted not only by a deleted file but also by a virus or format, if the actual contents of the e-mail DB file remain on the hard disk, the e-mail DB file can be recovered first to read the e-mail. Can be recovered.

In addition, the e-mail message recovery program provided according to the present invention can be usefully used not only for the general user, but also for corporations or government agencies such as criminal investigation, tax, audit.

Claims (10)

(a) recovering one or more e-mail boxes deleted or damaged in the disk drive through a directory scan operation and a cluster scan operation as a specific disk drive is selected according to a user's operation to recover an e-mail message; (b) recovering one or more e-mail messages through an e-mail message format analysis operation and a binary file decoding operation within the recovered e-mail box; And (c) storing the one or more email messages recovered in step (b) E-mail message recovery method comprising a. The method of claim 1, wherein the directory scan operation of step (a) comprises: (a-11) setting the number of scans of directories existing in the disk drive; (a-12) analyzing the signature of the file to be recovered; (a-13) checking whether the file is an e-mail file based on the analyzed signature; (a-14) registering as an e-mail list when the e-mail is checked in step (a-13); (a-15) When it is checked that it is not an e-mail in step (a-13) and the current count value after step (a-14) is less than or equal to the number of scans set in step (a-11). Checking whether or not; (a-16) If it is checked in step (a-15) that the current count value is less than or equal to the set number of scans, increasing the count value to reset the current count value and feeding back to the step (a-13). ; And (a-17) if it is checked in step (a-15) that the current count value is greater than the set number of scans, performing the cluster scan operation. The method of claim 1, wherein the cluster scan operation of step (a) comprises: (a-21) setting a total number of clusters present in the disk drive; (a-22) analyzing the signature of the file to be recovered; (a-23) checking whether the file is an e-mail file based on the analyzed signature; (a-24) analyzing the file size if it is checked as an e-mail file in step (a-23); (a-25) registering to an e-mail list based on the analyzed file size; (a-26) If it is checked in the step (a-23) that it is not an e-mail file, and following the step (a-25), the current count value is less than or equal to the count set in the step (a-21). Checking whether or not; (a-27) If it is checked in step (a-26) that the current count value is less than or equal to the count set in step (a-1), the count value is increased to set the current count value and the step (a-26) is performed. Feedback to 22); And (a-28) if it is checked in step (a-26) that the current count value is larger than the count set in the step (a-21), the step of performing the step (b) How to recover mail messages. The method of claim 1, wherein the step of analyzing the email message format of step (b) comprises: (b-11) setting the file size to a count value; (b-12) checking whether the e-mail message is an e-mail message by checking a start record of the e-mail message; (b-13) registering the e-mail message in the message list if it is checked in step (b-12); (b-14) checking if the e-mail message is not the same as the e-mail message in step (b-12) and if the current count value is less than or equal to the set count value following the step (b-13); (b-15) If it is checked in step (b-14) that the current count value is less than or equal to the set count value, the current count value is increased to reset the current count value, and the feedback is returned to the step (b-12). Making; And (b-16) if it is checked in step (b-14) that the current count value is larger than the set count value, performing step (c). The binary file decoding operation of claim 1, wherein (b-21) analyzing the mime pattern; (b-22) performing uuencode decoding when it is checked as uuencode based on the mime pattern analyzed in step (b-21); (b-23) performing BinHex decoding when BinHex is checked based on the mime pattern analyzed in step (b-21); (b-24) performing Basse64 decoding when it is checked as Basse64 based on the mime pattern analyzed in step (b-21); And (b-25) if it is checked as QuotedPrintable based on the mime pattern analyzed in step (b-21), performing a QuotedPrintable decoding. . (a) recovering one or more e-mail boxes deleted or damaged in the disk drive through a directory scan operation and a cluster scan operation as a specific disk drive is selected according to a user's operation to recover an e-mail message; (b) recovering one or more e-mail messages through an e-mail message format analysis operation and a binary file decoding operation within the recovered e-mail box; And (c) storing the one or more email messages recovered in step (b) A computer-readable recording medium storing an e-mail message recovery method comprising a. The method of claim 6, wherein the directory scan operation of step (a) comprises: (a-11) setting the number of scans of directories existing in the disk drive; (a-12) analyzing the signature of the file to be recovered; (a-13) checking whether the file is an e-mail file based on the analyzed signature; (a-14) registering as an e-mail list when the e-mail is checked in step (a-13); (a-15) When it is checked that it is not an e-mail in step (a-13) and the current count value after step (a-14) is less than or equal to the number of scans set in step (a-11). Checking whether or not; (a-16) If it is checked in step (a-15) that the current count value is less than or equal to the set number of scans, increasing the count value to reset the current count value and feeding back to the step (a-13). ; And (a-17) if it is checked in step (a-15) that the current count value is greater than the set number of scans, performing the cluster scan operation. Computer-readable recording medium. The method of claim 6, wherein the cluster scan operation of step (a) comprises: (a-21) setting a total number of clusters present in the disk drive; (a-22) analyzing the signature of the file to be recovered; (a-23) checking whether the file is an e-mail file based on the analyzed signature; (a-24) analyzing the file size if it is checked as an e-mail file in step (a-23); (a-25) registering to an e-mail list based on the analyzed file size; (a-26) When it is checked in the step (a-23) that it is not an e-mail file, and after the step (a-25), the current count value is smaller than or equal to the count set in the step (a-21). Checking whether or not; (a-27) If it is checked in step (a-26) that the current count value is less than or equal to the count set in step (a-1), the count value is increased to set the current count value and the step (a- Feedback to 22); And (a-28) if it is checked in step (a-26) that the current count value is larger than the count set in the step (a-21), the step of performing the step (b) A computer-readable recording medium storing a method for recovering mail messages. The method of claim 6, wherein the step of analyzing the e-mail message format of step (b) comprises: (b-11) setting the file size to a count value; (b-12) checking whether the e-mail message is an e-mail message by checking a start record of the e-mail message; (b-13) registering the e-mail message in the message list if it is checked in step (b-12); (b-14) checking whether the current count value is less than or equal to the set count value in the case of not being an e-mail message in step (b-12) and following step (b-13). (b-15) If it is checked in step (b-14) that the current count value is less than or equal to the set count value, the current count value is increased to reset the current count value, and the feedback is returned to the step (b-12). Making; And (b-16) if it is checked in step (b-14) that the current count value is greater than the set count value, performing the step (c). Computer-readable recording medium. The binary file decoding operation of claim 6, wherein (b-21) analyzing the mime pattern; (b-22) performing uuencode decoding when it is checked as uuencode based on the mime pattern analyzed in step (b-21); (b-23) performing BinHex decoding when BinHex is checked based on the mime pattern analyzed in step (b-21); (b-24) performing Basse64 decoding when it is checked as Basse64 based on the mime pattern analyzed in step (b-21); And (b-25) if it is checked as QuotedPrintable based on the mime pattern analyzed in step (b-21), performing a QuotedPrintable decoding. The computer-readable recording medium storing the data.