Gateway device, communication system and program

Abstract

The gateway device comprises a domain evaluation means for evaluating the creditworthiness of a source domain according to the email sending and receiving history for each source domain, a domain creditworthiness holding means for holding source domain creditworthiness data according to the creditworthiness of the source domain determined by the domain evaluation means, a destination creditworthiness holding means for holding destination address creditworthiness data according to the disclosure level of the destination email address within the organization, an extraction means for extracting the source domain name of the email and the destination email address within the organization from the header of the received email, and a calculation means for calculating received email creditworthiness data of the received email according to the source domain creditworthiness data held in the domain creditworthiness holding means corresponding to the domain name extracted by the extraction means and the destination address creditworthiness data corresponding to the destination email address within the organization extracted by the extraction means, and the domain evaluation means evaluates the creditworthiness of the source domain using any two or more of the number of sends, the number of receives, the thread average, and the transaction period indicating the period during which emails are exchanged.

Description

[Technical field]

[0001] The present invention relates to a gateway device, a communication system, and a program that improve the accuracy in determining the validity of received e-mail. [Background technology]

[0002] In recent years, there has been an increase in damage caused by fraudulent emails, such as emails disguised as executives of targeted companies, which cause harm to recipients. In particular, when a person employed by the company is disguised as the sender, serious damage can occur. Known sender domain authentication technologies such as SPF authentication, DKIM, and DMARC are technologies for detecting fraudulent emails. These sender domain authentication technologies require the registration of the sender domain and IP address, so there is a problem that the domains that can be authenticated are limited to registered domains. In addition, if the sender domain or IP address is changed, or if the registered information is not changed in a timely manner, there is a problem that authentication will not be possible. Patent Document 1 adopts a method of collecting whitelists from multiple mail servers and distributing the integrated data to a mail server to check the sender mail server using the latest appropriate sender information.

[0003] The fundamental reason why it is difficult to verify the legitimacy of emails is that information about the legitimate mail servers of each organization is not made public. SPF authentication was intended to solve this problem by having each organization register its legitimate mail server, but there are problems such as the fact that registration changes may not be made properly when the mail server is changed, and when an attacker registers a similar domain and sets SPF authentication, the email may appear to the recipient to be legitimate. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-27510 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, the sender's email address in the email header can be forged by the sender (the attacker), and the sender can also add the sending server's IP address to the header. Furthermore, the IP address of the sending server may change due to a system reboot or configuration change. For this reason, it is not sufficient to simply determine the legitimacy of an email based on the sender's email address, the sending server's IP address, and the like. An object of the present invention is to improve the accuracy in determining the legitimacy of received email. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems, the gateway device of the present invention comprises: a domain evaluation means for evaluating the creditworthiness of a sender domain according to the sending and receiving history of email for each sender domain; a domain creditworthiness holding means for holding the creditworthiness data of the sender domain according to the creditworthiness of the sender domain determined by the domain evaluation means; a destination creditworthiness holding means for holding the creditworthiness data of the destination address according to the disclosure level of the destination email address within the organization; an extraction means for extracting the sender domain name of the email and the destination email address within the organization from the header of the received email; and a calculation means for calculating received email creditworthiness data of the received email according to the creditworthiness data of the sender domain held in the domain creditworthiness holding means corresponding to the domain name extracted by the extraction means and the creditworthiness data of the destination address corresponding to the destination email address within the organization extracted by the extraction means, wherein the domain evaluation means evaluates the creditworthiness of the sender domain using any two or more of the number of transmissions, the number of receptions, the thread average, and the transaction period indicating the period during which emails are exchanged.

[0007] Another gateway device according to the present invention is characterized in that it comprises a storage means for storing a domain name of a trusted sender and an IP address of a sending mail server; an extraction means for extracting the domain name of the sender email address of the email and the IP address of the sending mail server from the header of a received email; a confirmation means for sending a confirmation email to the sender email address of the email to confirm the sending of the email when the domain name of the sender email address of the email extracted by the extraction means is registered in the storage means and the IP address of the sender mail server of the email does not match the IP address corresponding to the domain name of the sender email address of the email stored in the storage means; and a delivery means for delivering the received email when a response is received to the confirmation email.

[0008] Another gateway device according to the present invention is characterized in that it comprises: a regular domain name holding means for holding a domain name of a regular domain; an extraction means for extracting from the header of a received email the domain name of the sender email address of the email and the domain name of the sender server described in the Received header; a confirmation means for sending a confirmation email to the sender email address of the received email to confirm the sending of the email if the domain name of the sender server extracted by the extraction means is registered in the regular domain name holding means and does not match the domain name of the sender server described in the extracted Received header; and a delivery means for delivering the received email when there is a response to the confirmation email. Effect of the Invention

[0009] In the gateway device of the present invention, the domain evaluation means evaluates the creditworthiness of the sending domain using any two or more of the number of sends, the number of receives, the thread average, and the transaction period indicating the period during which emails are exchanged, and the calculation means calculates received email creditworthiness data for the received email based on the sending domain creditworthiness data stored in the domain creditworthiness storage means corresponding to the domain name extracted by the extraction means and the destination address creditworthiness data corresponding to the destination email address within the organization extracted by the extraction means, thereby improving the accuracy in determining the legitimacy of received email. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram showing an example of the arrangement of a communication system according to a first embodiment. [Diagram 2] FIG. 4 is a block diagram showing an example of the configuration of a determination server. [Diagram 3] FIG. 13 is a diagram showing an example of a public email address table. [Figure 4] FIG. 13 is a diagram showing an example of a credit evaluation criteria table. [Diagram 5] FIG. 13 is a diagram showing an example of an internal email information table. [Figure 6] FIG. 13 is a diagram showing an example of an organization basic information table. [Figure 7] FIG. 13 is a diagram showing an example of a mail server information table. [Figure 8] FIG. 13 is a diagram showing an example of a blacklist table. [Figure 9] 10 is a flowchart showing an example of a process of a determination server when receiving an email. [Figure 10] FIG. 13 is a diagram showing an example of an email header. [Figure 11] FIG. 13 is a diagram showing an example of an email header. [Figure 12] FIG. 13 is a diagram showing an example of a header added by a determination unit. [Figure 13] FIG. 13 is a diagram showing an example of a header added by a determination unit. [Figure 14] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of a user terminal. [Figure 15]FIG. 13 is a diagram showing an example of a management screen displayed on a management terminal. [Figure 16] FIG. 13 is a diagram showing an example of a canonical domain list. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described, however, the present invention is not limited thereto and can be modified as appropriate within the scope of the technical concept of the present invention. (Embodiment 1) <Communication system configuration> FIG. 1 is a block diagram showing an example of the configuration of a communication system according to the first embodiment. This communication system includes a determination server 10 that can communicate via a network 1 such as the Internet, a receiving server 20 that receives e-mail, and a sending server 30 that sends e-mail. The determination server 10 operates as a gateway device that determines received e-mail for the receiving server 20. This communication system also includes a Web server 40 that provides Web services, an administrator terminal 50 used by an administrator of the communication system, and a user terminal 60 used by a user to send and receive e-mail. The determination server 10 to the user terminal 60 are provided for each organization to be managed, such as within a company or for each department. In addition, a plurality of user terminals 60 are provided since they are used by a plurality of users. In addition, FIG. 1 shows a case where the receiving server 20, the sending server 30, and the Web server 40 are provided separately from the determination server 10, but some of these may be provided within the determination server 10. In addition, this communication system also includes an information aggregation server 90 that aggregates data accumulated in the determination servers 10 provided for each of a plurality of organizations.

[0012] This communication system also includes transmitting terminals 70 and 74 that transmit emails to the receiving server 20 and the like, and transmitting servers 71 and 75. The transmitting terminal 70 and the transmitting server 71 are assumed to be terminals used for transmitting legitimate emails, and the transmitting terminal 74 and the transmitting server 75 are assumed to be terminals used for transmitting fraudulent emails. Depending on the configuration of network 1, the forwarding of e-mail sent from a remote sending server is generally carried out via multiple sending servers (SMTP servers), and in the following explanation, for convenience, the sending server that ultimately sends the e-mail to the external network 1 is referred to as the exit server.

[0013] Email from the sending server 71 is sent to the external network 1 via the exit server 72. Depending on the network configuration within the organization, the use of a hosting service, etc., other sending servers may be present between the sending server 71 and the exit server 72. In this case, a Received header is added to the email when it is transferred between the sending servers. Furthermore, mail from the transmission server 75 is transmitted to the external network 1 via the exit server 76. The transmission terminal 74 and the transmission server 75 may be configured as one device, or the transmission terminal 74, the transmission server 75, and the exit server 76 may be configured as the same device. Although it is assumed that the sending terminal 70 and the sending server 71 are installed outside the organization, when sending an e-mail to a destination within the organization, they may be installed within the organization. This communication system also includes a DNS server 81 that manages the correspondence between IP addresses and domain names.

[0014] The user terminal 60 is configured with an information processing device such as a personal computer or a mobile information terminal, and includes a mail client 61 and a display unit 62. The mail client 61 includes a display plug-in 611 that displays on the display unit 62 a display corresponding to mail credibility data indicating the credibility of the sender that is added to the header of the mail by the determination server 10, as described later.

[0015] FIG. 2 is a block diagram showing an example of the configuration of the determination server 10. As shown in FIG. This determination server 10 comprises a history analysis unit 11 that evaluates trustworthiness based on the reception history data of the receiving server 20 and the transmission history data of the transmitting server 30, a determination unit 12 that performs determination of emails received via the network 1, and a data storage unit 13 that stores various data. This determination server 10 also operates as a gateway device (or a proxy server) that determines the legitimacy of emails received via the network 1 and supplies them to the receiving server 20 when predetermined conditions are met.

[0016] 3 to 8, various tables used for judgment in the judgment unit 12 are held in the data holding unit 13. Furthermore, the quarantine area or the hold area of ​​the data holding unit 13 stores emails that have been "quarantined" or "held" as a result of judgment by the judgment unit 12. FIG. 3 is a diagram showing an example of the public email address table 101 stored in the data storage unit 13. As shown in FIG. This public email address table 101 stores destination address credibility data according to the disclosure level of the destination address. That is, the public email address table 101 stores destination address credibility data according to whether the destination address is a public address, a limited public address, or a private address. Specifically, the public email address table 101 stores, for example, for a destination address, "info," "contact," or "sales" as public information addresses, and destination address credibility data indicating "destination address credibility," in association with the destination address. This destination address credibility data is set in advance by, for example, an administrator of the communication system (administrator within the organization), etc.

[0017] Here, a public address refers to an email address that anyone can freely obtain via the Internet, such as an email address listed on a company's homepage or an email address published on an information disclosure page of a public institution. A limited public address is, for example, an email address that is not published on the Internet, but is communicated to other companies as an email address necessary for carrying out business. Generally, a mailing list address is often used. A private address refers to an email address that is not disclosed to the public or communicated to other companies.

[0018] Specifically, as shown in Fig. 3, for email addresses (public addresses) published on the organization's website, etc., the destination address credibility is evaluated as low, and the value of the destination address credibility data is lowered. For email addresses that are published in a limited manner (limited public addresses: for example, "sales" and "0.5" in the case of Fig. 3), the destination address credibility is evaluated as higher than that of public addresses. For email addresses that are not included in the published email address table 101, the destination address credibility data is evaluated as "1". The information in the published email address table 101 is set as an initial setting, for example, when the communication system starts operating, but the settings may be changed as appropriate from the administrator terminal 50, for example.

[0019] FIG. 4 is a diagram showing an example of the credit evaluation criteria table 102 stored in the data storage unit 13. As shown in FIG. This creditworthiness evaluation criteria table 102 is a table that specifies the "email creditworthiness data" (described below) that corresponds to a "creditworthiness rank" and the corresponding creditworthiness rank. This creditworthiness evaluation criteria table specifies the "creditworthiness rank" that corresponds to each "email creditworthiness data" separated by a predetermined threshold value. Details of the operation according to the creditworthiness rank will be described later. The values ​​of the threshold values ​​("70" and "30" in the case of FIG. 4) can be set appropriately.

[0020] <Whitelist> 5 to 7 are diagrams showing examples of tables included in a "white list" stored in the data storage unit 13 for evaluating the trustworthiness of the sender of an email. FIG. 5 is a diagram showing an example of the intra-office mail information table 103 of the whitelist. In this internal mail information table 103, for known organizations such as within a company, affiliated companies, and existing business partners, for which the route between the host name or IP address of the transmission server 71 and the exit server 72 is clearly known, for example, "organization name," "domain," "source host name (host name of the transmission server 71)," "source IP address (IP address of the transmission server 71)," "exit server name (host name of the exit server 72)," "exit server IP address (IP address of the exit server 72)," and "route" indicating the number of routes from the transmission server to the exit server are stored in association with each other. Note that when the host names and IP addresses of the transmission server 71 and the exit server 72 are associated one-to-one with each other in the DNS server 81, it is possible to register either one of them, but it is preferable to register both of them for the transmission server 71, since the IP address may change.

[0021] Each sending server that forwards the mail adds to the header of the mail as needed a Received header that includes the host name and IP address of the server that received the mail and the host name and IP address of the sending server. The "route" in the above-mentioned internal mail information table 103 is a number indicating the number of routes between the Received header added by the sending server 71 included in the header of the mail and the Received header added by the exit server 72, as described later. For example, in the case of X Co., Ltd. in the first row of Fig. 5, the number of routes in the header of a regular mail is 3, as shown in Fig. 10. If multiple domains exist in the same organization, each piece of information is stored in association with each domain, as shown in Fig. 5. In the example of Fig. 5, there are multiple source transmission servers 71, but only one exit server 72. In addition, for affiliated companies, business partners, etc., similar information is stored for each affiliated company, business partner, etc. These pieces of information are set as initial settings when the communication system starts operating, but the settings may be changed as appropriate from, for example, the administrator terminal 50. For known organizations, such as those within the company, affiliated companies, and existing business partners, where the host name or IP address of the sending server 71 and the route to the exit server 72 are clearly known, the information is registered in the internal mail information table 103, and the legitimacy of received mail is judged based on this table, thereby improving the reliability of the legitimacy judgment.

[0022] FIG. 6 is a diagram showing an example of the organization basic information table 104 of the whitelist. In this organization basic information table 104, for known communication partners (organizations), the "organization name," "domain," "address," "phone number," "number of emails sent," "number of emails received," the average value of a series of emails sent and received (thread) ("thread average"), the "transaction period" with the organization, and "organization credit data" (described below) are stored in association with each other. Note that the "number of emails sent" is the total number of emails sent by the sending server 30 to the organization, the "number of emails received" is the total number of emails received by the receiving server 20 from the organization, and the "transaction period" is the number of days since the first email received by the receiving server 20.

[0023] The "organization name", "domain", "address", and "telephone number" in the organization basic information table 104 are set as initial settings when the operation of the communication system is started, but the settings may be changed as appropriate from, for example, the administrator terminal 50. Also, the "address" and "telephone number" do not necessarily have to be set. The “number of transmissions”, “number of receptions”, “thread average”, and “transaction period” in the organization basic information table 104 are calculated by the history analysis unit 11 from the reception history of the receiving server 20 and the transmission history of the transmitting server 30 . Furthermore, the evaluation of the "organization credit data" is calculated by the evaluation means in the history analysis unit 11 using the number of transmissions, number of receptions, thread average, and trading period, as described below. Since the number of transmissions, number of receptions, thread average, and trading period change daily, they are updated daily. Based on these updates, the organization credit data evaluation is also updated daily by the history analysis unit 11.

[0024] The evaluation of the organizational credit data is obtained, for example, by the following calculation formula, but the calculation formula may be appropriately changed according to the actual situation of email sending and receiving, the accuracy of the required determination, etc. The evaluation means in the history analysis unit 11 evaluates the "organizational credit" based on the actual email sending and receiving history data from the past, and calculates the "organizational credit data" from data such as "number of sent emails", "number of received emails", "thread average", and "transaction period". Specifically, for example, when the state where the number of sent emails: 500, the number of received emails: 500, the thread average: 10, and the transaction period: 365 days is regarded as the organizational credit data 100, the following calculation formula is obtained. Organizational credit data = MIN(25×(number of sent emails / 500), 25) + MIN(25×(number of received emails / 500), 25) + MIN(25×(thread average / 10), 25) + MIN(25×(transaction period / 365), 25) Here, MIN(A, B) is a function that becomes B when A≧B and becomes A when A<B. For example, in the case of Company A registered in the first row of the organizational credit basic information table 104 in Figure 6, the number of sent emails is 201, the number of received emails is 254, the thread average is 23.4, and the transaction period is 1023 days. Substituting these values into the above formula, Organizational credit data = MIN(25×(201 / 500), 25) + MIN(25×(254 / 500), 25) + MIN(25×(23.4 / 10), 25) + MIN(25×(1023 / 365), 25) = 10.05 + 12.7 + 25 + 25 = 72.75 It becomes like this. In addition, the credit of the sender domain may be evaluated using any two or more of the number of sent emails, the number of received emails, the thread average, and the transaction period indicating the period during which email exchanges are taking place. Data such as the number of sent emails, the number of received emails, the thread average, and the transaction period are generally managed within the organization. By using these data for evaluation, it is possible to evaluate the credit of the sender domain only with the data within the organization without the need for external evaluation, etc.

[0025] <Email Trust Data Calculation> Furthermore, the judgment unit 12 calculates email credibility data for each email received via the network 1. The following formula can be used to calculate this email credibility data, but the formula may be changed as appropriate depending on the actual state of email transmission and reception, the accuracy of the required judgment, etc. Email credibility data = recipient email address credibility data × organization credibility data That is, in this embodiment, the credibility of each email is calculated by multiplying the "destination email address credibility data" in Figure 3, which corresponds to the destination email address of the received email, and the "organization credibility data" in Figure 6, which corresponds to the organization from which the email was sent.

[0026] FIG. 7 is a diagram showing an example of the mail server information table 105 of the whitelist. In this mail server information table 105, for known communication partners (organizations), the "organization name", the IP address of the transmission server 71, and the host name of the transmission server 71 are stored in association with each other. The host name to be registered in the mail server information table 105 is extracted by the history analysis unit 11 from the Received header of the mail received by the receiving server 20. The history analysis unit 11 registers all the extracted data in the mail server information table 105.

[0027] <Blacklist> FIG. 8 is a diagram showing an example of the blacklist table 106 held in the data holding unit 13. As shown in FIG. In this blacklist table 106, the "IP address" and "host name" of the sending server that sent the spoofed email are registered. When the communication system starts operating, an empty blacklist table 106 is created as an initial setting. If the determination unit 12 determines that a received email is fraudulent during operation of the communication system, the IP address and host name of the sending server of the email are registered in the blacklist.

[0028] <Operation overview> In the communication system of this embodiment, rather than simply determining whether or not to deliver an email based on the sender's email address, the sending server's IP address, etc., as in the conventional system, the system combines the following four processes, broadly speaking, to improve the accuracy of determining the legitimacy of received email. What makes it difficult to determine the legitimacy of received emails is that the hostname and IP address of the legitimate sender's email server are not made public, making it unclear whether the email was sent from a legitimate email server. 1. Evaluating email credibility based on the organization's past email sending and receiving history data 2. Determining the route of an email sent from an internal sender (a known organization whose route is clearly understood) 3. Check the sender of the email (It is not possible to simply check the sender of an email, but rather to check it strictly on a case-by-case basis.) 4. If the source address (From:) is a legitimate address, check whether the source address (From: and ReceivedFrom:) match In this embodiment, an example in which all four of the above processes are implemented will be described, but it is also possible to implement any one of the processes or a combination of any two or three of the processes. By implementing at least one of the processes, it is possible to improve the accuracy of determining the validity of received email.

[0029] <Actions when receiving email> FIG. 9 is a flowchart showing an example of a process of the determination server when receiving an email. When an e-mail is received via the network 1, the determination unit 12 of the determination server 10 starts the process of FIG. The determination unit 12 receives an email in S11, and then extracts the IP address of the sender's email server, the host name of the sender's email server, and the sender's email address from the header of the received email in S12.

[0030] In S13, the judgment unit 12 judges whether the domain of the sender's email address matches the domain registered in the internal email information table 103, and if it matches, in S14, it judges whether the sender host name, sender IP address, exit server name, exit server IP address, and route in the header of the received email match each piece of information registered in the internal email information table 103. If there is a match, in S15, the judgment unit 12 sets the email credibility data to full marks (e.g., 100), and adds information indicating a message displaying the data and the credibility data corresponding to the data (e.g., an "X-Hantei" header) to the header of the received email, as shown in Figure 12(A), and delivers the email to the receiving server 20, and ends the processing of Figure 9. The information added to the "X-Hantei" header is not limited to this example, and may be, for example, only the trustworthiness data or only information indicating the trustworthiness data. When a mail client 61 receives an email containing such an "X-Hantei" header from receiving server 20, display plug-in 611 causes display unit 62 to display display 621 corresponding to the "X-Hantei" header, as shown in FIG. 13, for example.

[0031] On the other hand, in S14, if any of the sender host name, sender IP address, exit server name, exit server IP address, or route in the header of the received email differs from the information registered in the internal email information table 103, the email is an email that disguises itself as an internal sender, so in S16, the judgment unit 12 stores the email in a quarantine area of ​​the data storage unit 13, and if it is not registered in the blacklist, it registers it, and the processing of Figure 9 is terminated. For example, even if the sender email address in the email header (the email address in the envelope From) is within the organization, if the sender host name and sender IP address are different, the email was not sent by the legitimate sending server 71, but is a spoofed email sent from sending server 75 that is disguised as a sender.

[0032] FIG. 10 is a diagram showing an example of a "Received" header 201 that is added to a recipient's email by each mail server on the transfer path until it reaches the determination server when the email is sent by a sender within a legitimate organization. Figure 11 shows an example of the "Recieived" header that is added to the recipient's email by each mail server along the forwarding path until it reaches the judgment server when the sender of the forged email sends an email with the same "Recieived" header as a genuine email added for the purpose of forgery. In this example, the sender of the forged email (e.g., terminal device 74) adds a "Received" header 202 similar to that of a genuine email for the purpose of forgery, but also adds a forwarding history 203 from the actual sender, the sending terminal 74, to the exit server 76. If you receive such an email, you may not be able to distinguish it from a legitimate email just by checking the sender's hostname and IP address in the header. However, when a forged "Recieived" header 202 is added, a forwarding history 203 from the sending terminal 74, which is the actual sender, to the exit server 76 is added, and the number of routes to the actual exit server 76 increases, so that, as in this embodiment, by comparing the number of routes with the routes (number of routes) registered in the in-house mail information table 103, it is possible to determine that the mail is fraudulent, and improve the accuracy of determining the legitimacy of the received mail. In the case of Fig. 11, the determination unit 12 makes a determination based on the number of routes between the "Recieived" header last added by the exit server and the "Recieived" header added (or forged) by the first sending server.

[0033] In S13, if the domain of the sender's email address does not match the domain registered in the internal email information table 103, the judgment unit 12 judges in S17 whether the host name or IP address of the sender's email address of the received email is registered in the blacklist table 106. If it is registered, the determination unit 12 stores the email in a quarantine area of ​​the data storage unit 13 in S18, and if it is not registered in the blacklist, it registers it and ends the process of FIG.

[0034] If the host name or IP address of the sender's email address is not registered in the blacklist table 106, the determination unit 12 determines in S19 whether or not the domain of the sender's email address is registered in the organization basic information table 104. If registered, the determination unit 12 determines in S20 whether or not the IP address of the sender's email server matches an IP address registered in the email server information table 105. If there is a match, in S21, the judgment unit 12 sets the email credit data to the organization credit data registered in the organization basic information table 104, as shown in Figures 12(B) and 12(C), adds information indicating the data (e.g., an ``X-Hantei'' header) to the header of the received email, and transfers it to the receiving server 20, and terminates the processing of Figure 9. When a mail client 61 receives an email containing such an "X-Hantei" header from receiving server 20, display plug-in 611 causes display unit 62 to display display 622 or display 623 according to the data in the "X-Hantei" header, as shown in FIG. 14, for example, depending on the data in the "X-Hantei" header.

[0035] In S19, if the domain of the sender's email address is not registered in the whitelist's organization basic information table 104, there is no added credibility data based on the past sent and received email history data that evaluates the email's credibility, and since this is the first email from the sending organization, etc., the judgment unit 12 stores the email in a holding area of ​​the data storage unit 13 in S22 and terminates the processing of Figure 9.

[0036] As described below, when the email stored in the hold area of ​​the data storage unit 13 is released from the hold state by an operation from the administrator terminal 50, it is transferred to the receiving server 20 and becomes viewable from the user terminal 60. At this time, the determination unit 12 sets the email credibility data to "-1", indicating that it is a first email, and adds information indicating the data (for example, an "X-Hantei" header) to the header of the email, as shown in Fig. 13. When a display plug-in 611 of a mail client 61 receives a mail including such an "X-Hantei" header from a receiving server 20, the display plug-in 611 displays a display 624 on the display unit 62 in accordance with the "X-Hantei" header, as shown in FIG. 14, for example.

[0037] In S20, if the domain of the sender's email address is registered in the whitelist's organization basic information table 104 but the IP address of the sender's email server does not match the IP address registered in the email server information table 105, the judgment unit 12 instructs the sending server 30 to send a confirmation email to the email address of the sender of the email in S23. This confirmation email may contain, for example, a quoted portion of the received email and link information to a confirmation address on the Web server 40. Note that instead of link information to a confirmation address on the Web server 40, a message requesting the other party to reply to the confirmation email may also be included. S23 is executed when an email is sent from an organization registered in the whitelist, but the IP address of the sending server is different from the IP address registered in the mail server information table 105, and it is not clear whether the email is a spoofed email or the system configuration of the sender has changed, etc. For this reason, the determination unit 12 sends a confirmation email to the email address that is the sender of the email.

[0038] In S24, the determination unit 12 determines whether or not the other party has accessed the Web server 40 in response to the link information in the confirmation email sent in S23 and confirmed the sending of the email. When it is confirmed by a notification from the Web server 40 or the like that the other party has confirmed the sending of the email, in S25 the determination unit 12 adds information indicating the data (for example, the "X-Hantei" header) to the header of the received email, transfers it to the receiving server 20, changes and registers the IP address and host name of the sender of the email in the email server information table 105, and ends the process in FIG. 9.

[0039] If it is not possible to confirm that the other party has confirmed the sending of the email within the specified period, then in S26, the judgment unit 12 stores the received email in a quarantine area of ​​the data storage unit 13, registers the sender's IP address and host name in the blacklist table 106 in correspondence with the organization name identified as the sender of the email, and terminates the processing of Figure 9.

[0040] (Modification) In addition, even if it is the first time you have received an email from the sending organization (domain), it is possible to detect some spoofed emails by sending a confirmation email. When classifying spoofed emails from attackers, there are two types of disguise methods. (1) A spoofed email with a From domain name that exactly matches a legitimate domain name (2) Forged emails with a From domain name that resembles a legitimate domain name In the case of a spoofed email (1): The From domain name in the email header is the same as a legitimate domain name, and in this case, if you reply to the email, the reply email will not reach the attacker, but will reach the legitimate organization, since the destination is a legitimate domain name. For this reason, it is used in one-shot attacks, such as attacks in which a device is infected with malware just by clicking on a URL. Furthermore, since the appearance is identical to a legitimate domain name, it is unlikely that the target of the attack will detect it. In the case of a spoofed email (2): The From domain name in the email header resembles a legitimate domain name, and in this case, when you reply to the email, the destination is different from the legitimate domain name, so the reply email does not reach the legitimate organization but reaches the attacker, allowing for a time-consuming attack by exchanging emails to gain the victim's trust. However, since the domain name of the exchanged emails is only similar but different from the legitimate domain name, there is a high possibility that the attack will be discovered by the target.

[0041] In the case of (2) above, sending a confirmation email would mean falling into the attacker's trap, so no reply email should be sent. Here, in the case of a forged email in the case of (1), if we look at the Received header, if the From domain name matches the domain name of the hostname in the Received header, it is unclear whether the email itself is genuine or not. However, if the From domain name does not match the domain name of the hostname in the Received header, it is possible to discover the authenticity of the email by sending a confirmation email to the From domain name. In other words, in the case of receiving a "forged email with a From domain name that exactly matches a legitimate domain name as described above in (1)" for the first time (a case of receiving a spoofed email using a legitimate domain name that is not registered on the whitelist), since the forged email uses a legitimate domain, the confirmation email will be delivered to the deceived legitimate recipient, and the forgery will be discovered.

[0042] In the processing of FIG. 9, in S19, if the domain of the sender's email address is not registered in the whitelist's organization basic information table 104, there is no addition of credibility data based on the past sent and received email history data that evaluates the email's credibility, and since this is the first email from the sending organization, etc., the judgment unit 12 stores the email in a holding area of ​​the data storage unit 13 in S22 and terminates the processing. On the other hand, if the domain of the sender's email address is not registered in the organization basic information table 104 of the whitelist in S19, the following process may be performed. (A1) Determine whether the From domain name matches any of the domains registered in the authorized domain list (Figure 16). As a result of the determination in (A2) and (A1), if the domain name in "From" is registered in the authorized domain list and the domain in "From" matches the domain in the "Received" header, the email is stored in a holding area of ​​the data storage unit 13 in S22. (A3) If the domain name of "From" is registered in the authorized domain list, and the domain of "From" does not match the domain of the "Received" header, a confirmation email is sent to the email address of "From". If a response to the confirmation email is received, the email is stored in a reserve area of ​​the data storage unit 13 in S22 as a legitimate email sent from the "From" domain. If no response to the confirmation email is received, the process of S26 is executed to register the IP address and host name of "Received" in a blacklist and quarantine the email as an email disguised as an email from the "From" domain. If it is determined in steps (A4) and (A1) that the domain name in the "From" field is not registered in the authorized domain list, the mail is stored in a reserve area of ​​the data storage unit 13 in step S22. The legitimate domain list indicates a list 107, which is prepared in advance from a government domain list, public information of listed companies, etc., as shown in FIG.

[0043] <Operation of the administrator terminal 50> In addition to the maintenance and management of the various tables described above, the administrator terminal 50 is also capable of checking and managing the status of the mail stored in the data storage unit 13 in S22 described above. Specifically, using a Web browser on the administrator terminal 50 , a screen for managing emails stored in the quarantine area and the reserve area of ​​the data storage unit 13 by the determination server 10 via the Web server 40 can be accessed. In response to a request from the administrator terminal 50 via the Web server 40, the determination server 10 generates HTML data for displaying a management screen, and supplies the HTML data to the administrator terminal 50 via the Web server 40. In response to the supplied HTML data, the administrator terminal 50 displays, for example, a management screen 55 shown in FIG. This management screen 55 displays a list of displays 551 each having a sender email address display area 551a, a subject display area 551b, a data display area 551c, a delivery instruction button 551d, and a deletion instruction button 551e for each email stored in the quarantine area and the hold area of ​​the data storage unit 13, and an email body display area 552 in which the body of the selected email is displayed. The operator of the administrator terminal 50 selects whether to deliver or delete the email based on a comprehensive judgment based on the reliability data, the sender email address, and the email body, and instructs the corresponding delivery instruction button 551d or deletion instruction button 551e. This allows the operator of the administrator terminal 50 to check the contents of the email stored in the hold area, and if there are no problems, change the status to, for example, "deliverable." In response to this change in status, the determination server 10 delivers the email to the receiving server 20. The operator of the administrator terminal 50 can check the contents of email stored in the quarantine area and delete it, or can forward it to a specific address by pressing a delivery instruction button. In the above explanation, emails to be quarantined or held are stored in the quarantine area or holding area of ​​the data holding unit 13, but emails associated with information such as a quarantine flag or holding flag may be stored in the data holding unit 13, and the emails that have been quarantined or held may be identified based on the information of each flag, etc.

[0044] As described above, in this embodiment, emails determined to be fraudulent are quarantined without being forwarded to the receiving server 20, and emails that cannot be determined to be fraudulent or not are forwarded to the receiving server 20 with information indicating the trustworthiness of the email added, allowing the recipient of the email (the user of the user terminal 60) to determine the trustworthiness of the received email, thereby improving the accuracy of determining the legitimacy of the received email. In addition, the accuracy can be further improved by sending a confirmation email to suspicious emails. Furthermore, for example, simply by adding information indicating the credibility of the above-mentioned email to the email to be forwarded to the receiving server 20, the recipient of the email (the user of the user terminal 60) can determine the credibility of the received email, thereby improving the accuracy in determining the legitimacy of the received email. In addition, in this embodiment, by performing route determination when the email is sent from a known organization whose host name and IP address of the sending server 71 within the company, an affiliated company, an existing business partner, etc., and the route to the exit server 72 are accurately known, the accuracy in determining the legitimacy of received email can be improved.

[0045] The determination unit 12 transmits the information described in the blacklist table 106 of Fig. 8 to the information aggregation server 90. A determination server 10 is provided for each organization, but the blacklist information aggregated in the information aggregation server 90 may be provided to the determination server 10 of another organization according to requests, permission conditions, etc. In this case, the determination server 10 is provided with a function for registering the provided blacklist. By using the blacklist table of another organization to register and manage the blacklist table 106, the blacklist table 106 can be refined, thereby reducing the workload. [Explanation of symbols]

[0046] 1...network, 10...judgment server, 11...history analysis unit, 12...judgment unit, 13...data storage unit, 20...receiving server, 30...transmitting server, 40...web server, 50...administrator terminal, 60...user terminal, 61, mail client, 611...display plug-in, 62...display unit, 70, 74...transmitting terminal, 71, 75...external transmitting server, 72, 76...exit server, 81...DNS server, 90...information aggregation server

Claims

1. A domain evaluation means for evaluating the credibility of a sender domain according to an email sending / receiving history for each sender domain; a domain credibility storage means for storing source domain credibility data according to the source domain credibility determined by the domain evaluation means; a destination credibility holding means for holding destination address credibility data according to the disclosure level of the destination email address within the organization; an extraction means for extracting a domain name of a sender of the email and a destination email address within the organization from a header of the received email; a calculation means for calculating received email credibility data of the received email in accordance with the credibility data of a sender domain stored in the domain credibility storage means corresponding to the domain name extracted by the extraction means and the credibility data of a destination address corresponding to the destination email address within the organization extracted by the extraction means, The domain evaluation means includes: Evaluate the credibility of the sending domain using two or more of the following: number of sends, number of receives, thread average, and transaction period, which indicates the period of time that emails have been exchanged; A gateway device comprising:

2. The destination credit rating storage means The trust data is stored according to whether the destination email address within the organization is a public address, a limited public address, or a private address. A gateway device comprising:

3. The extraction means extracts the domain name of the sender email address and the IP address of the sender email server from the header of the received email, A storage means for storing a domain name of a reliable sender and an IP address of a sender mail server; a confirmation means for transmitting a confirmation email to the sender email address of the email, when the domain name of the sender email address of the email extracted by the extraction means is registered in the storage means and the IP address of the sender email server of the email does not match the IP address corresponding to the domain name of the sender email address of the email stored in the storage means, to confirm the sending of the email; a delivery means for delivering the received email when there is a response to the confirmation email; 2. The gateway device according to claim 1, further comprising:

4. The extraction means extracts, from the header of the received email, the domain name of the sender email address of the email and the domain name of the sender server described in the Received header, A legitimate domain name holding means for holding a domain name of a legitimate domain; a confirmation means for transmitting a confirmation email to a sender email address of the received email, to confirm the sending of the email, when the domain name of the sender server extracted by the extraction means is registered in the regular domain name storage means and does not match the domain name of the sender server described in the extracted Received header; a distribution means for distributing the received email when there is a response to the confirmation email; 2. The gateway device according to claim 1, further comprising:

5. A legitimate domain name holding means for holding a domain name of a legitimate domain is provided, The extraction means extracts, from the header of the received email, the domain name of the sender email address of the email and the domain name of the sender server described in the Received header, the confirmation means, when the domain name of the sending server extracted by the extraction means is registered in the regular domain name holding means and does not match the domain name of the sending server described in the extracted Received header, sends a confirmation email to the sending email address of the received email, to confirm the sending of the email; The delivery means delivers the received email when there is a response to the confirmation email.

4. The gateway device according to claim 3.

6. a delivery means for delivering an email to which the received email credibility data calculated by the calculation means has been added; 2. The gateway device according to claim 1, further comprising:

7. A gateway device according to any one of claims 1 to 6, A receiving server that receives emails; A communication system comprising:

8. On the computer, The trust of each sending domain is evaluated using two or more of the number of emails sent, the number of emails received, the thread average, and the transaction period indicating the period during which emails are exchanged; Extracting the domain name of the sender of the email and the destination email address within the organization from the header of the received email, determining a recipient address credibility data of the received email according to a disclosure level of the recipient email address corresponding to the extracted domain name and a sender domain credibility data according to the credibility of the sender domain; A computer program comprising:

Images