WO2003039097A2

WO2003039097A2 - Method and device for automatic e-mail management

Info

Publication number: WO2003039097A2
Application number: PCT/DE2002/004051
Authority: WO
Inventors: Daniel Seemann; Manuela Damm; Thomas Gravel
Original assignee: Im-Brain Gmbh
Priority date: 2001-10-30
Filing date: 2002-10-30
Publication date: 2003-05-08
Also published as: WO2003039097A3; AU2002347101A1; DE10295048D2

Abstract

According to the invention, the problem of routing, in other words the allocation of an E-mail to a particular responsible person and the problem of blocking, in other words the collection of particular E-mails without a direct forwarding, which occurs with automatic E-mail management can be solved, whereby the server performs contents analysis, even an associative and semantic contents analysis on incoming and/or outgoing E-mails.

Description

Method and device for automatic email management

Technical field of the invention

The invention relates to a method and a device for automatic email management. In particular, the invention relates to a method and a device for server-side and platform-independent routing, blocking and categorizing and / or classifying emails. The method can be designed to be self-learning and / or teachable.

Background of the Invention

So far, it is common for authorities, companies and other institutions that receive a large number of e-mails with different inquiries on different topics and problems every day, all or at least the majority of the incoming e-mails via only a few e-mail addresses (so-called collective addresses, hereinafter also referred to as "work addresses"), whereby the addresses are usually structured as follows: presse@xyz.com, support@xyz.de, info@ip-de.com, federal chancellor @ bundesregierung.de etc.

The following problems exist when handling large amounts of email:

The recipients are often unable to respond to all e-mails promptly and appropriately, for example, professionally and / or organizationally, and can, for example, answer important inquiries quickly. In many companies the procedure is such that the e-mails arriving at a collective address are sorted "by hand" as in a post office, whereby the e-mails must be read by employees, who then read the content of the respective e-mail try to send the email to the right person using an email client, or to filter out and delete unwanted emails (spam). This method is time consuming and expensive and ad absurdum the advantages of electronic mail traffic.

With the function of the so-called "Autoreply" with the assignment of a ticket number (processing number), the processing of an e-mail request is carried out by any employee without taking into account the specific expertise.

When responding to an e-mail received via a collective address, the personal e-mail address of the sender, e.g. john.smith@dpma.de, although the sender or his company / authority / institution do not want this for various reasons. For example, a company / authority / institution would only like to have a manageable and therefore controllable number of "communication interfaces" such as post office, telephone exchange and e-mail center. For its part, the specialist consultant would like to be protected from direct contact via email. For this reason, only the general address, such as e.g. info@dpma.de, but many email servers do not allow this. It should be noted at this point that in this application the terminology used in the technical field in question followed and under an email server or an email client not a physical machine (computer), but rather a virtual machine is understood.

If it is possible to set a uniform sender address on the part of the e-mail server, the problem arises that possible queries by the sender of the original e-mail to the answer of a clerk are difficult to arrive at the collective e-mail address again are assigned to the same clerk, so that in particular in companies and the like. high e-mail volume, a clerk should answer a query without already being familiar with the initial question and the answer of his colleague. It is currently not possible to filter outgoing emails for information that should not be sent or at least not forwarded to any person.

Blocking unwanted advertising emails (spam) is currently insufficient.

To at least partially solve the problems mentioned, it is known to search for an email client in the text of an email, the so-called email body, for so-called "regular expressions" and then to search for the respective email according to predefined filter rules, based on the regular expressions, either sorted into different folders in the e-mail client or sorted on the e-mail server by a certain clerk, whereby certain actions can then be carried out according to defined workflows (see e.g. US 6,282,565 B1 or US 6,182,059 B1).

The methods described in US Pat. No. 6,182,059 B1 and US Pat. No. 6,282,565 B1 are methods based on fixed rules that work directly with workflow management software and only allow action-based action or case-based reactions.

US Pat. No. 6,052,709 B1 describes a method which allows advertising mails (spam) to be learned via an address, part of an email text being removed and alert signals being set, to which other email servers can then react. This method does not allow a semantic analysis of the entire email text and possibly also the attachments, blocking of emails or processing the reaction of the addressee.

US Pat. No. 6,091,724 B1 describes a process for the so-called "forwarding" (forwarding) of emails to a clerk, but this does not anonymize an outgoing email (one from the clerk to the sender of the original email). Mail sent reply) and also no blocking of emails. General change in the setting of the email sender address in the email client resolves.

Known solutions have the following disadvantages:

high personnel costs with manual sorting; the "distribution know-how" lies with a few people; in the case of manual distribution of e-mails arriving via a collective address, the quality of the distribution depends heavily on the competence of the distributor; forwarding generally loses the ability to reply directly to the original sender; The automated solutions that concern automatic e-mail management in local networks are always "client-heavy" solutions that only work when the computer on which the respective client is installed is in operation and with the is connected to the local network, which leads to problems and processing bottlenecks if a local email server forwards emails to a local email client, but the employee serving the email client concerned is ill or on vacation, for example without this being communicated to the email server; The known filter rules are based on so-called "regular expressions" (English: "regular expressions"), which in this application are understood to be terms according to RFC 1801 and RFC 3028. The RFCs mentioned are available on the Internet at http://www.faqs.org/rfcs/rfc1801.html or http://www.faqs.org/rfcs/rfc3028.html (for definition see also Showalter, Sieve : A Mail Filtering Language). The two sources mentioned are hereby expressly made the full disclosure content of this application by citation. This allows e-mails containing a specific ("regular") expression (a specific string) to be sorted into specific folders, but general filter rules are difficult to define with regular expressions, and the intelligent rule design is very know-how- intensive, especially when in a changing system environment (for the definition of the term "system environment" see Niklas Luhmann: Social Systems - floor plan of a general theory, Suhrkamp, 2000) also the

Change language and thus the regular expressions for the same context; resharpening the rules and regular expressions requires considerable effort

Know-how and is time-consuming and therefore costly; the change of the sender's email address on the part of the

Email clients (i.e. in the email software, such as the program with the

Trade name "Microsoft Outlook") is ignored by some email servers, e.g. from t-oniine; When searching with regular expressions, content to be found is sometimes not found simply because it is simply expressed in a different concept.

So far, there is no satisfactory solution to the problems mentioned

Disclosure of the invention

The invention is based on the object of specifying a method and a device for automatic email management which do not have the problems mentioned. In particular, the following should be solved: the problem of routing, i.e. the assignment of an email to a specific clerk, and the problem of blocking, i.e. the collection of certain emails, especially unwanted emails, without forwarding them directly, but especially also without filtering them in such a way that e-mails classified as "undesired" are deleted directly, because it has been shown that important e-mails are always deleted due to incorrect classifications.

To solve the problems mentioned, the invention proposes a method and a device in which a content analysis, namely an associative (ie taking synonyms into account) and semantic content analysis of the incoming and / or outgoing emails is carried out on the server side. The invention advantageously allows for the optional implementation of all aspects through the interaction of

Mail server independence,

Routing of emails, semantic categorization of the email, server-side sender anonymization,

Block emails,

Semantic classification of email and automatic semantic learning

simple, fast and automatic email management, even with the largest amounts of email.

Platform and mail server independence means that the proposed solution is independent of the respective operating system (usually called "platform" such as the operating system "Windows NT") and independent of the platform-specific software of the e-mail server (such as "Microsoft Exchange Server ") of the e-mail recipient can be operated. The servers exchange e-mails via SMTP or eSMTP via TCP / IP. This exchange can also be based on another protocol.

Routing e-mails means forwarding the original e-mail to an e-mail server, if the recipients and / or sender addresses change, depending on the content of the e-mail. Both recipient and sender notice no change in the email.

Semantic categorization means assigning texts to previously defined categories. The method according to the invention learns to assign by training with exercise texts that were previously categorized by hand.

Server-side sender anonymization means that the sender address is replaced by a definable address using the solution according to the invention. After the intervention, the email complies with the RFC standards described on the website with the address ftp://ftp.isi.edu/innotes/rfc2026.txt, or in RFC 2026 itself, which is hereby expressly made the disclosure content of the present application by citation.

Blocking e-mails means holding the e-mails for a user without transporting them to the user's mailbox. These emails are unsolicited advertising emails (spam). The user can view this at any time and also receive it on request.

Semantic classification of the email means the content analysis of the content and the sorting of the emails into a class. The semantic classification is taught and learned in a similar way to the semantic categorization.

The automatic semantic learning takes place in the solution according to the invention on the basis of texts or also e-mails that were previously categorized or classified by hand.

The solution according to the invention has the following advantages, among others:

Personnel costs are reduced because emails no longer have to be sorted and forwarded “by hand”;

response times are reduced;

the fast and correct delivery of an email request to the email address of the responsible clerk is ensured;

the solution is platform and mail server independent;

Evaluation of the processing and response times of the rout email address owners are possible;

Virus scanners are easy to integrate; it is possible to block executable and possibly dangerous content such as components with JavaScript or ActiveX;

HTML can be blocked in e-mails;

it is possible to block advertising emails;

protecting employees from sexual harassment is possible;

the method according to the invention can be used in both directions, i.e. Both incoming and outgoing emails can be examined for content. For example, outgoing e-mails are examined for confidential information and incoming e-mails are sorted according to subject areas or on the basis of advertising e-mails.

Brief description of the drawing

Fig. 1 shows schematically the normal course of the transport of an email according to the prior art.

Fig. 2 shows schematically the course of the transport of an email using the invention.

3 shows a detailed flowchart of the sequence of the method according to the invention when categorizing or classifying e-mails without the preparation, without the reaction of the recipient and without the re-learning.

FIG. 4 shows a detailed flow diagram of the sequence of the method according to the invention when blocking advertising emails or emails with confidential information without the preparation, without the reaction of the recipient and without learning. Description of preferred implementations

In the following two exemplary embodiments of a method according to the invention are described purely by way of example and not by way of limitation.

In the following and in the drawing are the words / abbreviations

MUA for "mail user agent". This agent (a virtual machine or a program) is required to read, write and send e-mails.

MTA for "mail transport agent". MTAs are the e-mail servers that pass on the e-mails on the destination and on the sender side. They access DNS servers (domain name servers) to read out the MX records (mail exchange records), which indicate which MTA is responsible for which domain. The MTAs exchange the e-mails via SMTP or eSMTP via TCP / IP.

MDA for "mail delivery agent". On the target side, the MDA is responsible for receiving and forwarding to the recipient client.

im-brain for the method and

im-brain MTA for the mail transport agent trained according to the invention.

Fig. 1 shows the normal course of a transport of an email. The sender sends the email to the MUA. The latter then forwards the email to the MTA.

The email is then sent to the MTA, which, according to the MX record, is responsible for the domain on the DNS server. In this way, the email reaches the MDA Recipient domain. The latter then forwards the email directly to the recipient or to the MUA.

The reply takes the same route, only in reverse order.

2 shows the course of the transport using the invention:

The email goes from the sender to the MTA via the MUA. The MTA asks the DNS server which MTA is responsible for the domain. The MX record in the DNS records that the im-brain MTA is responsible for the domain. The email is sent to the im-brain MTA via SMTP / eSMTP. This semantically analyzes the text for the content and thus categorizes / classifies it. Then the advertising emails (spam) are filtered out and the emails sorted according to their thematic concerns to the right clerk. Sorting is an exchange of the target address and the provision of the information required for further processing. The modified e-mail then arrives at the "real" target MTA. The e-mail then arrives via the MDA at MUA and finally at the clerk.

The response passes from the MUA back to the im-brain MTA via the MTA. This creates the original destination email address (anonymization of outgoing emails) and then returns this email to the MTA of the sender. There, the email is returned to the sender's MUA via the MDA.

When blocking, the email is not passed on to the MTA, but stored by the im-brain MTA until either the recipient or an authorized person has viewed and reacted to this email or a predefinable time in days (e.g. 21 Days) has expired. The email will then be deleted. The reaction of the recipient or an authorized person, for example an administrator, is not shown in FIGS. 1-4. The invention learns with the reaction of the recipient or the authorized person. A more detailed description of email routing / email classifying and email categorizing according to the invention

The following scenario is given:

A sender writes an email from example.user@strato.de to info@dmba.de.

1. The email is written by the sender and given to the MTA of his domain or provider (e.g. post.strato.de).

2. This MTA asks the DNS server which MTA is entered as MX for the recipient domain. This entry points to the IP address of the imbrain MTA.

3. The im-brain MTA accepts the email. The im-brain MTA uses the SMTP commands or eSMTP commands specified in the RFCs.

4. The e-mail is stored in the inbox (inbox), which advantageously enables the e-mail to be reconstructed in the event of any hardware-related malfunctions, e.g. Power outages is guaranteed.

5. The im-brain MTA determines whether the email is a request to the collective address (here info@dbma.de). If the email is an email to another address, it will be passed on without any further changes to the forwarding (referred to as outbox in the purely schematic and non-limiting drawing).

6. The im-brain MTA determines whether it is an initial request or a question about an answer. Depending on the result of this determination, the procedure is different:

It is an initial request: 1. An analysis module reads the e-mail from the directory and passes it on to the semantic categorization or semantic classification and at the same time to the categorization / classification by means of regular expressions. During the analysis, the attachments (attachments or files) can optionally be taken into account.

2. The analysis module offsets both analyzes and then determines on the basis of the determined category or class which receiving address or clerk should receive this request. The clerk's email address is inserted in the email instead of the "real" (i.e. original) recipient address (info@dbma.de).

3. According to the invention, this sorting or classification / categorization is learned and recorded automatically as correct (by storing in a memory which is accessible to the in-brain MTA and is not shown here), in which a header field with a unique identifier (e.g. an identification number and a date with time). An entry is made in a database, the so-called mapping database (called mapping DB in the drawing), from which it can be seen which clerk was sent which email.

4. Then this modified e-mail is sent to the outbox, from where it is sent to the identified recipient in the usual way, e.g. to the clerk determined as responsible.

It is a question of an answer:

1. When analyzing the email based on the unique identifier in the header field of the email, the im-brain MTA notices that it is a question of an answer.

2. The email is processed in the same way as for the first request. However, it is no longer categorized / classified again. 3. The recipient address is changed based on the data stored by the im-brain-MTA to the email address of the person who gave the answer to the first request.

4. The processing is saved in the mapping database in the same way as for the first request.

5. Then this modified email is passed on.

Forwarding to the "real" MTA (routing)

1. The emails are forwarded to the "real" MTA via SMTP / eSMTP.

2. The MTA forwards this to the MUA via the MDA.

Response of the clerk to an inquiry

1. The clerk answers the email with the email client he uses or with CRM software (customer relation management software).

2. The email then goes to the MTA of its domain.

3. This forwards the email directly to the im-brain MTA via SMTP / eSMTP.

4. The im-brain MTA accepts these and places them in a home directory.

5. The im-brain MTA learns the answer and the request for later processing. In addition, it saves the answer to this request by the respective clerk for any queries.

6. The im-brain MTA restores the "real" receiving address or collective address (anonymizing, here info@dbma.de). The email will be passed on.

Forwarding to the MTA of the original sender:

1. The emails are forwarded to the sender MTA (here "post.strato.de") via SMTP / eSMTP.

2. The MTA forwards this to the MUA via the MDA.

Forwarding incorrectly routed / categorized / classified email

1. The clerk determines that the email cannot be answered in a qualified manner.

2. The clerk forwards this email via email client or CRM software to a fictitious email address (forwarding). According to the invention, this e-mail address is defined as a "forwarding address". It must be outside the clerk's domain.

3. This email then goes from the MTA of the clerk to the im-brain MTA.

4. When analyzing, the im-brain MTA notices that it is a forwarded email.

5. The original email is restored based on the stored information and re-categorized / classified.

6. The email is sorted into the next most relevant category / class that does not correspond to the "old", wrong category / class and / or the "wrong" clerk. 7. This new categorization / classification is saved and relearned.

8. The clerk e-mail address is registered in the e-mail and the e-mail is passed on to the "real" MTA.

9. The contents of the e-mails that have been sorted incorrectly can be assessed at a later point in time by an authorized person and, if necessary, deleted, re-categorized / classified.

Re-learning of incorrectly routed / categorized / classified emails

1. An authorized person (administrator) is shown the incorrectly routed / categorized / classified texts and the sorted category / class or clerk email address.

2. He decides which category / class / email address this text should be sorted into in the future. He has the opportunity to consult with the clerk so that the price agent problem is minimized and quality control takes place.

3. This re-learning can also be automated.

4. Reading through improves the accuracy of the categorization / classification.

More precise description of the blocking of confidential information and advertising emails (spam) by means of the invention for incoming and outgoing emails:

A sender writes an email from example.user@strato.de to tg@dmba.de. 1. The email is written by the sender and handed over to the MTA of his domain or provider (eg post.strato.de)

2. This asks the DNS server which MTA is entered as MX for the recipient domain. This entry points to the IP address of the im-brain MTA.

4. The email is stored in the inbox, which ensures that it can be reconstructed.

5. The im-brain MTA determines whether the email is a request to the monitored email address (here tg@dbma.de).

If the email is an email to another address, it will be passed on without any further changes to the forwarding.

6. The invention determines whether it is a first request or a query for an answer

Analyze and block the email

1. An analysis module reads the email from the directory and passes it on to the semantic categorization or semantic classification and at the same time to the categorization / classification using regular expressions. The attachments (attachments or files) can also be taken into account in the analysis.

2. The analysis module offsets both analyzes and then determines on the basis of the class determined whether the email remains in the invention or can be passed on as unobjectionable.

3. The email can optionally also have a tag (a freely definable string as a sorting aid for email clients such as Microsoft Outlook) in the subject (Subject) can be provided. This tag is only set if it is an email that is considered an advertising email or email with confidential content.

4. Furthermore, the email can also be duplicated for a third person if the content of the email meets one of the two criteria.

5. The possibly modified e-mail is then passed on to the transfer

Forwarding to the "real" MTA (incoming email)

1. The emails are forwarded to the recipient MTA via SMTP / eSMTP.

2. The MTA forwards this to the MUA via the MDA.

Forwarding to the sender of the original email (outgoing email)

2. The MTA forwards this to the MUA via the MDA.

Response of the recipient to blocked emails

1. The recipient (or an authorized person) can receive a time-controlled e-mail with a list of the blocked e-mails, a so-called "digest", in which he can then react to this blocking.

2. The recipient can confirm each email individually, or treat all emails equally. If the recipient still wants to receive an e-mail, he shows it to the invention and then immediately receives it unchanged. 3. If the recipient confirms the correctness of this blocking, the email will be deleted.

On / Nachlemen

1. The method according to the invention learns through the reactions of the recipient (or an authorized person).

2. The recipient can subsequently change, rearrange or delete the learned texts.

3. The recipient can also learn and re-learn the invention by email.

Important phases of the invention are described below for the method described.

Preparation (training phase)

Specification of the collective addresses (work addresses), the clerk addresses (routing addresses), the e-mail addresses of the users who are to receive protection against advertising emails and the specification of the e-mail addresses of the users, their e-mail Traffic to be monitored for strictly confidential information.

The im-brain MTA is taught with historical email content, digital sample texts and information to be protected.

The texts are sorted into the individual categories / classes and thus announced to the im-brain MTA.

Setting regular expressions which are intended to assist the invention in analyzing the contents of the emails in the semantic analysis. The clerk email addresses (routing addresses) are sorted into the individual categories / classes.

The addresses to which duplicates of the emails may be sent will be announced in the brain MTA.

The tags are defined that may appear in the subject of the emails.

business

1. An email will be accepted.

2. The receiving email address is examined to determine whether it is a "work address" or an email address to be monitored.

3. The appropriate processing is called according to the flowchart described above.

4. The emails arrive modified / unmodified at the "real" MTA

5. The user replies to the requests. / The user processes the digest. / The user forwards the email.

6. The invention processes the user's reaction.

7. The invention passes the email on to the sender.

relearning

According to the invention, the im-brain MTA can be sharpened and retrained at any time with categorized / classified emails or other digital texts. For this categorized / classified e-mails or other digital texts have to be entered into the brain MTA or the regular expressions have to be changed.

Within the scope of the inventive concept, numerous modifications and developments are possible which are disclosed to the person skilled in the art in the technical field in question without inventive intervention by this application and which are hereby expressly designated as belonging to the invention.

Claims

claims

1. A method for automatic email management, in particular for server-side and platform-independent routes, blocking, classifying and / or categorizing emails and their attachments, characterized in that an incoming or outgoing email automatically a semantic analysis is subjected.

2. The method according to claim 1, characterized in that server-side and platform-independent emails with executable content or only the executable content of emails themselves, such as content with JavaScript or ActiveX and / or HTML, are blocked.

3. The method according to claim 1 or 2, characterized in that it is self-learning.

4. The method according to any one of claims 1 to 3, characterized in that it is automatically determined whether an e-mail to be routed, classified, categorized was a query for an answer or whether it is a first request.

5. The method according to claim 4, characterized in that in the case of a first request, the email is stored in an input directory on the hard disk; an analysis module takes the e-mails from this directory and transfers them to a module for automatic semantic categorization / classification and for categorization / classification by regular expressions, whereupon the recipient address is changed on the basis of the category / class, in which one of the routing addresses instead of the input address (Collective address) this so-called mapping is entered in a database and the email is then forwarded to the "real" email server (MTA) via SMTP / eSMTP.

6. The method according to claim 4 or 5, characterized in that in the case of a query for an answer based on the database entries, the routing address is determined, which wrote the answer to the previous question, and the email is forwarded to this address ; the routing address is entered as the recipient address and the email is then forwarded to the "real" email server (MTA) via SMTP / eSMTP.

7. The method according to any one of claims 4 to 6, characterized in that in the event that an email has been incorrectly routed, classified, categorized, the recipient forwards the incorrectly routed, classified, categorized email to a fictitious one E-mail address outside his own domain, with which this e-mail then leaves the local MTA and leads to the invention; the invention receives this email and produces the original email on the basis of a database and analyzes it again semantically and with regular expressions and thus categorizes / classifies it, the email then being assigned to the next most relevant class / category and / or clerk; the text and the incorrectly sorted category are recorded so that the administrator can initiate the learning process later.

8. The method according to any one of claims 1 to 7, characterized by a preparation phase (training phase) in which the following process steps are carried out:

Indication of the recipient's email address to be processed by the procedure;

-, the procedure is learned with existing categorized / classified e-mail texts and / or other digitized texts;

In addition, regular expressions are determined that should lead to certain categorization / classification. So-called clerk email addresses (routing addresses) are assigned to the learned categories / classes, to which the categorized / classified email is delivered in whole or in part during routing.

9. The method according to any one of claims 1 to 8, characterized by an operating phase in which the following method steps are carried out:

Receiving an email (via SMTP / eSMTP, or another protocol)

Examination of the receiving e-mail address, whether this is a "work address" or an e-mail address to be monitored;

Calling up the appropriate processing according to the flowchart described above;

Sending the emails modified / unmodified to the "real" MTA;

Reply of the recipient to the requests / processing of the digest by the recipient / forwarding of the email by the recipient;

Processing the response of the recipient;

Forward the email to the sender.

10. The method according to any one of claims 1 to 9, characterized in that an additional analysis of incoming and / or outgoing is carried out automatically using a set of rules with regular expressions.

11. Device for automatic email management, in particular for server-side and platform-independent routing, blocking, classifying and / or categorizing emails and their attachments, characterized in that a computer system is provided with a number of components and for execution of a method according to one of claims 1 to 10.