US20130238726A1 - Method And System Of Transferring Electronic Messages - Google Patents
Method And System Of Transferring Electronic Messages Download PDFInfo
- Publication number
- US20130238726A1 US20130238726A1 US13/761,740 US201313761740A US2013238726A1 US 20130238726 A1 US20130238726 A1 US 20130238726A1 US 201313761740 A US201313761740 A US 201313761740A US 2013238726 A1 US2013238726 A1 US 2013238726A1
- Authority
- US
- United States
- Prior art keywords
- recipient
- sender
- server
- local
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H04L51/12—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/212—Monitoring or handling of messages using filtering or selective blocking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
Definitions
- the invention relates to a method and system of transferring electronic messages via telecommunication network, and more specifically to a method and system of delivering internet electronic messages (e-mails), comprising the step of creating a message by a sender and the step of authorizing the sender by the sender authorization server.
- internet electronic messages e-mails
- Server denotes a program, a computer system or a device electronically connected with other servers and accepting commands for providing specific services by sending responses, such as file server, database server, and in particular mail server.
- Mail Server or “Mail Transfer Agent” (MTA) denotes a server providing services of transferring electronic messages.
- MTAs are programs Sendmail, Postfix, or MS6 Exchange Server.
- SMS Simple Mail Transfer Protocol
- POP3 Post Office Protocol version 3
- IMAP Internet Message Access Protocol
- MUA Mail User Agent
- e-mail client is a program enabling user to create, write, send and receive e-mails.
- MUA connects with MTA using SMTP and after establishing connection sends messages to MTA.
- MUA connects with MTA using e.g. POP3 or IMAP protocol and downloads messages.
- Exemplary MUAs are local applications such as Mozilla Thunderbird or MS® Outlook Express®, server applications such as Berkeley Mail, Heirloom mailx or pine, or applications controlled by means of web browsers (e.g. MS® Explorer®, Mozilla Firefox®) such as Hotmail or Gmail generally referred to as “webmail”.
- DNS Domain Name System
- IP numeric form
- DNS stores information about Mail Transfer Agent(s) of a given internet domain (e.g. uprp.pl).
- FQDA Full Qualified Domain Address
- Applet denotes a software component constructed in a manner allowing it to be embedded in a web page and subsequently downloaded and executed in the context of a web browser of a computer system, in particular digitally signed and implementing Java, Flash or ActiveX technology and Cookies system.
- Server or “server side script” denotes a software component executed by remote web server, on the basis of an information provided by user by means of a web browser, in particular digitally signed and implementing PHP, ASP, Borland Enterprise Server, etc. technology.
- Reception of SPAM messages is presently out of control of the recipient, which at best (e.g. using appropriate filtering software) bears the costs of SPAM delivery, especially while accessing the net via dial-up connection.
- Transmission of SPAM also consumes resources of mail servers intermediating in this process.
- Mail servers receiving e-mails from any mail sending servers are called “open relay” servers and commonly such servers are not handled by other servers, because with a high' probability it may be assumed that the e-mails sent by such servers are SPAM messages.
- open relay server attempts to send a message, a recipient's server is able to determine its address and check whether this server is listed on the public list of “open relay” servers.
- Such lists are managed for example by the “MAPS” Organization (http://www.mail-abuse.com), which also administers lists of RBL servers (Realtime Blackhole List—list of servers spreading SPAM messages) and DUL servers (Dial-Up User List—list of servers connected via switched lines, from which servers SPAM messages are sent directly to recipient's servers).
- RBL servers Realtime Blackhole List—list of servers spreading SPAM messages
- DUL servers Dialog-Up User List—list of servers connected via switched lines, from which servers SPAM messages are sent directly to recipient's servers.
- Additional method used in connection with the one described above is a method in which receiving server accepts only e-mails for which the address of the sender corresponds to the address of the sending server.
- a sender is able to send messages only by means of the server being capable to authorize sender's identity.
- a sender authorization server is a server of a sender mail box or any other server connected with such a server, and a comparison of the sender address with the address of the sending server may consist in checking whether a domain part of sender FQDA address corresponds to a domain part of the sending server address.
- FIG. 1 schematically illustrates typical system of transferring e-mails between sender's local computer system 1 and recipient's local computer system 4 by means of or through sender's mail server 2 and recipient's mail server 3
- FIG. 4 individual steps of transferring the message.
- particular computer systems 1 - 4 are located remotely to each other and interconnected by means of a network employing TCP/IP protocol.
- a local sender's mail user agent 11 is installed on the senders computer system 1 (such as sender's personal computer, laptop, etc.), while a local recipient's mail user agent 41 is installed on the recipient's computer system 14 .
- an e-mail message is created by the sender with usage of mail user agent 11 .
- an e-mail includes also among other things a FQDA address of at least one recipient and a FQDA address of the sender.
- local mail user agent 11 makes an attempt to login to a sender's server 2 , on which the sender has its e-mail account.
- the login process is realized with using a SMTP AUTH mechanism as well as user name and passwords provided by the sender, which data are usually stored in encoded form by a local MUA 11 of the sender. If login process is performed correctly, sender's MUA 11 sends created e-mail message to a sender's server 2 and, if there is no more messages to send, interrupts connection with sender's server.
- the sender's server 2 translates FQDA addresses of each of the recipients indicated in the message, and using DNS mechanism determines recipient's server 3 of each specified recipient.
- sending server 2 connects then with a server of a given recipient 3 .
- each server making a connection with recipient's server 3 shall be rather recognized as “sending server” instead of “sender's server”, as its identity has not be yet verified.
- the sending server 2 indicates the sender of the message (using for example “MAIL FROM” command).
- a recipient's server 3 If a domain part of a FQDA address does not match a domain part of the address of the sending server 2 , a recipient's server 3 returns error reply informing about an error and refuses to accept the message. In the opposite instance, a recipient's server 3 returns OK reply enabling the sending server 2 to inform (for example using “RCPT TO” command) about the data of the recipient of the message, and, if a given receiving server 3 is suitable for the given recipient, to send messages and to disconnect.
- Step Server Command (1) R: 220BBN-UNIX.ARPA Simple Mail Transfer Service Ready (2) S: HELO HOST1.USC-ISIF.ARPA (3) R: 250 BBN-UNIX.ARPA (4) S: MAIL FROM: ⁇ Smith@USC-ISIF.ARPA> (5) R: 250 OK (6) S: RCPT TP: ⁇ Jones@BBN-UNIX.ARPA> (7) R: 250 OK (8) S: DATA (9) R: 354 Start mail input; end with ⁇ CRLF>. ⁇ CRLF> (10) S: This is a test mail... S: Blah blah blah.... S: . (11) R: 250 OK (12) S: QUIT (13) R: 221 BBN-UNIX.ARPA Service closing transmissions channel
- the sending server identified itself in step ( 2 ), and its domain part (USC-ISIF.ARPA) corresponds to domain part of the sender's address which was provided in step ( 4 ). It is of course one of the simplest systems of verification of the sender's server, as well as the sender itself. In the prior art methods of transferring of electronic message, data identifying the sender and/or recipient and/or the address of the sending server is contained most often in the message itself or follows from the actual IP address of the sending server or hitherto existing former history of transmission of the message.
- the last step of a process of sending a message is its delivering to s a recipient's local mail user agent 41 , residing in recipient's local computer system 4 .
- a recipient's local mail user agents logs in to a recipient's server 3 and, after passing through a logging procedure, the MUA downloads e-mail messages stored on the recipient's server.
- the above discussed steps of a process of transferring electronic messages are carried out with using SMTP protocol, whereas during the steps illustrated on FIG. 4 c POP3 or IMAP protocols are used.
- European patent specification EP 1 575 228 discloses a method and apparatus for reducing e-mail spam and virus distribution in a communications network by authenticating the origin of e-mail messages.
- the described method includes receiving at the sender's server a query to determine whether an e-mail message was sent be an indicated (in this message) user; checking logged data at the sender's server to determine whether the e-mail message in fact corresponds to a message sent from the sender's server, and responding to said query to authenticate the e-mail message origin.
- message needs to be transferred three times: firstly between sender's local mail user agent 11 residing on sender's personal computer 1 and sender's mail server 2 ; secondly between sending mail server 2 and recipient's mail server 3 : and for the third time between a recipient's server 3 and a recipient's local mail user agent 41 .
- common e-mail messages still grows larger in terms of a size of data that needs to be sent, what results among other things from a message format (e.g. HTML or formatted text), but mainly from a size and a number of additional files attached to e-mails (attachments).
- the aim of the invention is to provide a method and system of transferring electronic messages via telecommunication network, and particularly a method and system of transferring internet electronic messages (e-mails), which would cause a decrease in a network traffic load, wherein the implementation of the solutions according to the invention might be able to be gradually introduced to the existing environments of transferring messages (in other words the invention should feature backward compatibility in relation to existing systems).
- the aim of the invention is also providing a method and system of transferring electronic messages, which would provide considerably limitation of activity of entities responsible for spreading SPAM Messages.
- the invention relates to a method of transferring electronic messages via telecommunication network, comprising the steps of:
- said sender authorization server is a server of the sender mail box (sender's MTA).
- Sender's MTA This enables to employ known solutions, such as “POP” before “SMTP” or “SMTP AUTH” services described above. It is of course possible to use other network servers capable of confirming the identity of the remote sender.
- step (b) of authorizing said authorization request of intention of sending a message to a specified at least one recipient by the sender authorization server involves registration of said authorization request. Registration may be saved in logs or database of the authorization server, any other server connected to sender authorization server or even recipient's server.
- Said authorization request of intention of sending a message to a specified at least one recipient being send in said step (a) preferably comprises at least address of said at least one recipient and optionally at least one additional parameter chosen among others from the address of the sender, signature or the subject of the message, date and time of creating or sending the message and/or lists of attachments of the message.
- Said authorization of intention of sending a message to specified at least one recipient by the sender authorization server performed in step (b) is preferably valid within a predefined period and/or invalidated after step (c).
- the method according to the invention may after step (b) comprise additional step of sending by sender authorization server to the sender an authorization confirmation of intention of sending the message to at least one recipient. This allows the sender to send the message using a known method if sender authorization server does not confirm authorisation e.g. because it does employ the method of the present invention.
- the method may prior step (c) comprise additional step of sending by a recipient's server to sender authorization server an authorization query about the intention of sending the message to this recipient. This query may also be sent to a server appropriate to authorize given recipient, e.g. in an attempt to send to the recipient's server a message from open relay server or DUL listed server.
- the method according to the invention may comprise additional step of sending authorization server to recipient's mail server information about authorization of an intention to send a message to this recipient. After receiving such a message, recipient's server is ready to accept a message delivered from a specified sender.
- the method according to the invention may comprise an additional step of sending by recipient's local mail server to recipient authorization server a message informing about the IP address of the recipient's local mail server.
- recipient authorization server that is a server with which sending servers connects in order to send a message addressed to a given recipient, may transfer the message directly to recipient's local MTA operating on his local computer system.
- IP address information message is preferably send whenever IP address of recipient's local computer changes. In case recipient's local MAT is offline, recipient authorization server may obviously receive messages operating as recipient's remote MTA.
- step (c) the method comprises an additional step of sending by the recipient authorization server to sender authosiation server or sender's local mail server a message informing about the IP address of the recipient's local mail server. Therefore authorized e-mail may be delivered directly to recipient's local mail server.
- identity of sender authorization server and/or identity of recipient authorization server is confirmed by appropriate certificate, such as certificate issued by Verisign® (http://www.verisign.com) or ThawteTTM (http://www.thawte.com).
- authorization request of intention of sending a message to a specified at least one recipient is itself an electronic message.
- a modification of an e-mail system might comprise e.g. an extension of SMTP protocol with additional commands (e.g. AUTR for authorization request, ROAD in order to inform about recipient's local server, etc.), or comprise appropriate configuration of mail servers.
- the invention relates to a method of transferring Internet e-mails comprising the steps of creating a first e-mail by a sender and authorizing the sender by the sender's mail server, which further comprises the steps of:
- a prior art commonly used systems of transferring e-mails they are transferred between mail servers using a peer to peer (P2P) architecture, however transfer of messages between MTAs and local computers of e-mail users is supported by client-server architecture.
- P2P peer to peer
- the method of the invention enables to supplement or overlay the whole system of e-mail transfer with the P2P architecture, reducing network overload, increasing privacy and safety of e-mail transmission and reducing SPAM distribution which shall be explained later. Additionally, the method of the invention features backward compatibility over known systems of e-mails transfer and transparency of usage for end users.
- authorization request confirmation is itself an electronic message and is transferred by recipient's local mail server to sender's local mail server via outgoing mail server of a specified recipient and sender's incoming mail server.
- servers distributing SPAM in particular zombie computers, are not usually configured to receive messages (otherwise they would be vulnerable to be blocked by traffic of servers of organizations fighting against SPAM distribution).
- authorization request confirmation is transferred by recipient's local mail server directly to sender's local mail server.
- the channel may be active as long as these addresses unequivocally points to local computers of sender and recipient. Otherwise sender's local mail server may automatically send subsequent authorization request through sender's mail server to recipient's mail server, where from it shall be received by recipient's local mail server in order to establish the P2P channel again.
- recipient's local mail server sends to the sender's local mail server authorization request confirmation whenever the recipient's local mail server IP address changes.
- the P2P e-mail channel is maintained between local mail servers since each one of them knows IP address of its partner. If only address of one of them changes, e.g. due to breaking of internet connection and dynamic assignation of a new address from available pool of IP addresses, change of localization, Internet Service Provider, etc., than the local mail server immediately informs the counterpart about this fact and establishes P2P channel again.
- the P2P channel would be broken only if both of these systems changed their IP addresses in the same time or remained offline for longer period of time.
- Additional parameters of authorization request described above are preferably chosen from sender's cryptographic public-key (encrypting), an information promoting P2P transfer and/or text of the first electronic message created by the sender, while said additional parameters of said authorization request confirmation are chosen from recipient's cryptographic public-key (encrypting), acceptable types and sizes of attachments, acceptable size and/or other parameters of the first electronic message that are acceptable by the recipient.
- Encrypting and decrypting keys allow establishing encrypted P2P channel between local computer systems of sender and recipient, such as symmetric or more preferably asymmetric TLS (Transport Layer Security) channel, operating on TCP layer, in which encryption of data streams is performed by means of two public keys and decryption by means of private keys, each one of which is known only to sender and recipient.
- TLS Transport Layer Security
- the additional information may serve for promotion of the method according to the present invention, e.g. by encouraging installation of P2P enabled local mail server or mail user agent, implementing the method of the invention.
- the method involves more than one exchange of an authorization request and corresponding authorization request confirmation between sender's local mail server and recipient local mail server in order to negotiate the form of the first electronic message that is acceptable by recipient's local mail server.
- sender's local mail server and/or recipient's local mail server has a form of an application operating in between local mail user agent and remote mail server.
- the application may operate e.g. as a SMTP server bound to port 23 and POP3 server bound to port 80 of sender's/recipient's local computer system (localhost, IP 127.0.0.1) and after appropriate configuration of mail user agent by indicating that localhost shall serve both as the incoming and outgoing mail server and after appropriate configuration of the application itself by indicating actual remote mail servers for incoming and outgoing e-mails, intercept messages that are sent or received.
- the application may transparently supplement the first e-mail created by sender with authorization request or temporarily save locally the first e-mail creating new authorization request, and than send it as e-mail to recipient having a similar application which appropriately interprets authorization request and sends authorization request confirmation back to sender.
- the application may operate on a different port (e.g. 272 ) and use dedicated protocol (other than SMTP) for P2P transmission according to the invention.
- a different port e.g. 272
- dedicated protocol other than SMTP
- sender's local mail server and/or recipient's local mail server may be integrated with local mail user agent.
- e-mail client is enabled with incorporated mechanisms of sending and receiving authorization requests and confirmations or establishing P2P channels right after its installation.
- local mail user agent may be operated via a web browser (webmail) and sender's local mail server and/or recipient's local mail server may have a form of an applet installed on a sender's local computer system and/or recipient's local computer system and operated via a web browser and/or via local mail user agent.
- web browser webmail
- sender's local mail server and/or recipient's local mail server may have a form of an applet installed on a sender's local computer system and/or recipient's local computer system and operated via a web browser and/or via local mail user agent.
- Applets operating as local mail servers may be implemented e.g. in Java and ensure direct connection between sender's and recipient's local computer systems.
- Said steps (a) to (c) of each variant of the method of the present invention are advantageously performed if the volume of the message exceeds a predefined threshold. Therefore small messages (e.g. smaller that 4 MB) may be still transferred using commonly used system of e-mail transmission.
- the invention also relates to a system of transferring electronic messages via telecommunication network, in particular a system of transferring internet electronic messages (e-mails), which operates according to any variant of the method described above.
- the invention relates to a computer-readable storage medium containing executable instructions for a system of transferring electronic messages via telecommunication network, in particular for a system of transferring internet electronic messages (e-mails), wherein said executable instructions comprise an execution of steps of any variant of the method described above.
- FIG. 1 shows a typical prior art system of transferring electronic messages via computer network
- FIG. 2 shows a typical system of transferring electronic messages via computer network which is known from the prior art, but in which a method according to the invention is employed;
- FIG. 3 shows another exemplary system of transferring electronic messages according to the present invention
- FIGS. 4 a, 4 b and 4 c show particular steps of a method of transferring electronic messages which is known from the prior art
- FIGS. 5 a and 5 b show particular steps of an exemplary method of transferring electronic messages according to the invention, a first step of a connection session shown in FIG. 5 a, and a local mail user agent establishing a connection with a recipient's server 3 and sending a command identifying the message sender in FIG. 5 b;
- FIG. 6 shows particular steps of another exemplary method of transferring electronic messages according to the invention.
- FIG. 7 shows another exemplary system of transferring electronic messages according to the present invention.
- FIG. 8 shows yet another exemplary system of transferring electronic messages according to the invention used for webmail user agents
- FIG. 9 shows particular steps of an exemplary method of transferring electronic messages according to the invention which substantially corresponds to the system depicted in FIG. 7 ;
- FIG. 10 shows particular steps of another exemplary method of transferring electronic messages according to the invention which substantially corresponds to the system shown in FIG. 8 .
- server sends a request “a server sends a query”, “a server responds”
- computer servers and in particular internet mail servers, communicate in this way as defined for SMTP protocol in RFC 821, RFC 2821 and RFC 1869 normalization standards, which are therefore included into this description by reference.
- a communication process with a mail server may also be realized in this way manually manner using appropriate software, such as telnet application.
- FIGS. 2 and 5 schematically shows an exemplary implementation of the invention.
- the first step of connection session shown in FIG. 5 a is creating an e-mail message by the sender.
- a local mail user agent 11 logs in to a sender's server 2 , where the sender possesses his mail account.
- the local MUA 11 sends to the sender's MTA 2 , instead of the created message, a request for registration of intended operation of transfer which comprises sender's address, recipient's address and the size of a message.
- the registration request may of course contains also other parameters such as date and time data, the subject of a message, lists of attachments, etc.
- a local MUA 11 receives a communication confirming registration of the request in a register 5 of the server 2 and disconnects.
- sender's server 2 is not capable to handle a method according to the invention, it shall reject a registration request for intended transferring operation thus giving a local mail user agent 11 a signal to send the message using known method as depicted in FIGS. 1 and 4 .
- a local mail user agent 11 establishes a connection with a recipient's server 3 and sends a command (in case of SMTP protocol—“MAIL FROM” command) identifying the message sender.
- a command in case of SMTP protocol—“MAIL FROM” command
- the recipient's server 3 refuses to accept the message in case of not handling a method of the invention. Otherwise it sends to the mail server 2 corresponding to the sender's address a request about registration of intended transferring operation. If sender's server 2 is not capable to handle a registration mechanism according to the method of the invention, it generates an error reply.
- the lack of the registration of intended transferring operation in register 5 of the server 2 means an attempt to send a message anonymously or an attempt to send a message after a predetermined period of time of storing the registration in registers 5 of the server 2 , amounting e.g. one minute. In each of these cases, the recipient's server 3 denies accepting a message.
- a message is accepted by the recipient's server 3 only if the intention of transferring a message for the recipient for which this server is designated has been registered by the sender's server 2 .
- the recipient's server 3 may also invalidate registration in the register 5 of the sender's server 2 , thus preventing possibility of receiving the same message again.
- FIGS. 3 and 6 Another exemplary implementation of the invention is schematically illustrated in FIGS. 3 and 6 .
- e-mail clients of the sender 11 and the recipient 41 are configured in such a way that in both cases local computer systems of the sender 1 and the recipient 4 (so called localhosts with IP address 127.0.0.1) serve as incoming mail servers (POP3) as well as outgoing mail servers (SMTP).
- POP3 incoming mail servers
- STP outgoing mail servers
- On the sender's local computer system 1 there is a program 12 installed, which operates in background and provides services of sender's local mail server, by sending and receiving e-mails transferred from and to MUA 11 .
- Similar program 42 on the recipient's local computer system 4 sends and receives e-mails transferred from and to MUA 41 .
- the recipient's local mail server 42 is responsible for sending to recipient authorization server 3 a communications informing about its factual IP address.
- recipient authorization server 3 a communications informing about its factual IP address.
- a recipient's local computer system 4 is commonly connected with the Internet via dynamic connection or temporary connection (for example by Dial Up switched line connection), this address may frequently change.
- the sender After creating a message using local e-mail client 11 , the sender executes “Send” command available from a toolbar of mail user agent 11 , and the message is sent to senders local mail server 11 , which subsequently logs in to sender authorization server 2 a . After passing through logging procedure, the sender's local server 12 sends to the sender authorization server 2 a an authorization request of intended operation of transferring a message. The sender authorization server 2 a establishes a connection with the recipient authorization server 3 a .
- the recipient authorization server 3 closes transmission channel.
- the recipient authorization server 3 a gives to the sender authorization server 2 a information about the address of the recipient's local server 4 , and the sender authorization server 2 a forwards this information to the sender's local server 12 .
- the last step consists in transferring the message by the sender's local mail server 12 to the recipient's local mail server 42 and closing transmission channel.
- the message may naturally be transferred between the sender's local server 12 and the recipient's local server 42 in parts in dependence of possibilities of setting up the transmission channel.
- the e-mail is transferred to the recipient's local MUA 41 directly way or after executing by the recipient “Receive” command available from MUA 41 toolbar. In order to transfer an electronic message according to this implementation of invention, only one communication session is required.
- the final recipient's server is of course the recipient's local mail server 42 .
- the recipient authorization server may naturally receive messages acting as the final recipient's server (similarly as described in relation to FIGS. 2 and 5 ).
- FIGS. 7 and 9 schematically depicts another exemplary implementation of the invention.
- settings of e-mail clients of the sender 11 and recipient 41 indicate that the local computer systems of the sender 1 and the recipient 4 (localhosts) are both incoming mail servers (POP3) as well as outgoing mail servers (SMTP).
- POP3 incoming mail servers
- SMTP outgoing mail servers
- Program 12 provides services of sender's local mail server, which sends (SMTP) and receives (POP3/IMAP) electronic mail transferred from and to the mail user agent 11 .
- Similar background operating program 42 installed on the recipient's local computer system 4 provides services of recipient's local mail server by sending and receiving e-mails transferred from and to the MUA 41 .
- the configuration settings of local mail servers 12 and 42 the actual outgoing and incoming mail servers for mail accounts of the sender and the recipient are indicated.
- local computer systems of the sender 1 and the recipient 4 are connected with the Internet via dynamic connection or temporary connection (for example by Dial Up switched line connection), in a result of which their IP addresses may frequently change.
- the first step of a connection session shown in FIG. 9 involves creation of suitable first e-mail by the sender with use of a local MUA 11 including typing the e-mail content, indication of the e-mail address of its recipient or recipients, stating the subject of the message, attaching additional files, etc.
- the sender executes “Send” command from the toolbar of the mail user agent 11 , and the application 11 sends the first message in a sense to itself and more precisely to a local mail server 12 .
- the local mail server 12 records received first message for its later use.
- the local mail server 12 checks in its registers whether they contain the IP address of the local computer system 4 corresponding to e-mail address of the recipient and whether the recipient is able to handle the method of the invention.
- the address shall be stored in the registers if the communication channel of P2P connection between the sender and the recipient has been correctly constituted previously.
- the IP address might also have been introduced to these registers manually by the sender.
- the senders local mail server 12 attempts to send the first message via P2P connection through port 272 (particularly using encrypted channel) directly to the recipient's local mail server 42 . If the IP address of the recipient's computer system is not known or, despite the address being known, transferring of the first message was not successful, then the sender's local mail server 12 creates the second electronic message comprising an authorization request of intention of sending a message to a given recipient.
- the request includes IP address of the sender's computer system 1 , the sender's address, e-mail address of the recipient, the content of the first message and optionally the other parameters, such as a list of types and sizes of the attachments that are to be sent together with the first message.
- the sender's local mail server 12 sends the second authorization message to the outgoing mail server 2 , on which the sender has his e-mail account.
- the sender Before sending the message, the sender must gain authorization of his MTA 2 , for example with use of SMTP AUTH or “POP3 before SMTP” mechanism, and in a case of incorrect passing through the authorization procedure, the sender's server refuses connection.
- the sender's server 2 sends via SMTP protocol ( FIG. 7 ) an authorization communication to the recipient's MTA 3 , on which the recipient has his e-mail account.
- the message shall in turn be received by the recipient's local mail server 42 via POP3 or IMAP protocols.
- POP3 the recipient's local mail server 42 may connect periodically, for example every 2 minutes (in dependence on given configuration settings thereof), to the recipient's server 3 in order to determine whether there are any new messages, particularly any new authorization messages.
- an authorization message shall be received from the recipient's MTA 3 by his mail user agent 41 as a common e-mail message.
- an authorization confirmation shall obviously not be send, and the sender's local server 12 shall send after predetermined period of time, in dependence on its configuration settings, the first actual e-mail message using the known method of transferring e-mail messages (cf. FIG. 4 a ).
- the recipient's mail server 42 is capable to handle a method of the invention, in the next step it may determine whether the parameters of the first message are conforming to its default configuration settings or configuration settings defined by the recipient. It may for example determine whether the attachments, that the sender intends to send, agree as to the type of the attachments that are accepted by the recipient, etc.
- the recipient's local mail server sends via P2P channel (particularly via encrypted P2P channel) directly to the sender's local mail server a confirmation of the reception of an authorization request, comprising acceptable parameters of the first message. If the parameters are not acceptable by the recipient, then the sender may negotiate them by sending another third message and so forth, up to obtaining acceptance of a form of the first electronic message given by the recipient's local mail server.
- the final step includes sending the first message by the sender's local server 12 via channel P2P (particularly via P2P encrypted channel) directly to the recipient's local server 42 and ending the connection.
- a message may also be forwarded between the sender's local server 12 and the recipient's local server 42 in fragments in dependence of possibilities of setting up the connection between them.
- the message is transferred to the recipient's local mail user agent 41 in a direct way or after executing by the recipient “Receive” command available from a toolbar of mail user agent 41 .
- FIGS. 8 and 10 schematically illustrate another exemplary implementation of the invention that may be employed in e-mail clients handled by means of web browsers, such as Hotmail or Gmail, generally referred to as “webmail”.
- the sender connects via a web browser 13 with the sender's mail server 3 using HTTP protocol or cryptographic secure HTTPS protocol, and after correct logging on he gets access to his mail program 11 a, operating as a server-side script on the sender's mail server (MTA) 2 .
- the e-mail program 11 a being locally controlled by means of sender's web browser 13 , during the first connection requests sender to install the applet 12 a on the sender's local computer system 1 .
- the applet 12 a shall act as sender's local mail server functionally integrated with the e-mail program 11 a.
- Similar applet 42 a in communication with the e-mail program 42 a is installed on the recipient's local computer system 4 .
- the sender creates the first e-mail and confirms requests to send it to a given recipient or set of recipients.
- the e-mail program 11 a checks whether the recipient having a given e-mail address is able to handle a method of transfer according to the invention and whether IP address of the recipient's local computer system 4 is known. If so, the mail user agent 11 a sends to the sender's local mail server 12 a an instruction to send the first message via P2P channel directly to the recipient's local mail server 42 a . In a case of lack of such information relative to the recipient, the mail user agent 11 a creates and sends an authorization request to the recipient's mail server 3 .
- the recipient's mail server 3 does not handle P2P transmission according to the invention, it shall not appropriately interpret an authorization request. However the request may still be handled by the recipient's local mail server 42 (cf. FIGS. 7 and 9 ). In any case if it is not served, the sender's mail user agent 11 a shall send the first message to the recipient according to a known method after some time.
- recipient's mail user agent 41 a cooperates with the recipient's mail server 3 .
- the recipient's mail user agent 41 a locally controlled by means of the recipient's web browser 43 obtains information about the IP address of the recipient's local system 4 , which information is forwarded together with authorization request confirmation to the sender's mail user agent 11 a, in order to establish P2P channel between local servers 12 a and 42 a for transferring the first message.
- the second authorization message may also be obviously created and sent by the sender's applet 12 a (instead of servlet 11 a ), and received by the sender's applet 42 a (instead of servlet 41 a ), capable of handling a method of the invention, and appropriately integrated with e-mail web browser controlled programs of the sender 11 a and the recipient 41 a.
- a local mail server being integrated with a local mail user agent, either in a form of an application ( 12 , 42 ) operating between local mail user agent ( 11 , 41 ) and remote MTA ( 2 , 3 ) or in a form of an applet ( 12 a, 42 a ) installed on a local computer system and integrated with a remote mail program ( 11 a , 41 a ) and controlled by means of an web browser, may be used for sending and receiving messages. Thanks to backward compatibility of a method of P2P transmission according to the invention, it does not matter at all whether a recipient is capable to handle innovative P2P transmission system, as nevertheless a message shall reach him in a typical manner.
- a local mail server is equipped with appropriate mechanisms known from the prior art, enabling for proper communication through specified ports SMTP and POP3/IMAP with mail servers and on a specified port MAILP2P with other local mail servers without any difficulties resulting from operation on computer systems using firewalls, such as for example MSTM′ Windows firewall.
- firewalls such as for example MSTM′ Windows firewall.
- Configuration settings and characteristics of a local mail server handling a method according to the present invention may particularly comprise the following instructions, which for example may be assigned to all or only to selected e-mail addresses of mail users and/or may be dependent on the action effected by the user in response to a communication from his mail server:
- the first message itself may also comprise additional parameters added for example in the subject field, options, or in the content, the parameters may for example determine the mode of transfer: standard via SMTP and POP3/IMAP protocols, or via P2P channel, P2P cryptographic channel, etc.
- any of the inventive methods were described in a given order. It should be however understood that in alternative realization examples of the invention, the steps may be carried out in different order than the one described. Additionally, the described methods may be realized by means of hardware components and/or may be embedded in sequences of machine processed instructions, which may be used to enforce its execution by a machine, such as a general purpose processor or a dedicated processor or logical circuits programmed with use of such instructions. Such machine processed instructions may be stored on one or a number of machine readable carriers, such as CD-ROM, DVD discs or other optical disks, floppy disks, ROM, RAM, EPROM or EEPROM memories, smart cards or optical cards, and/or other types of machine readable carriers suitable for storing electronic instructions.
- machine readable carriers such as CD-ROM, DVD discs or other optical disks, floppy disks, ROM, RAM, EPROM or EEPROM memories, smart cards or optical cards, and/or other types of machine readable carriers suitable for storing electronic instructions.
- applications and/or software components which may be executed on one or on some number of computers, for carrying out the above described methods.
- applications and/or software components which may be executed on one or on some number of computers, for carrying out the above described methods.
- the methods according to the invention may be implemented by appropriate combination of hardware and software elements.
- presented embodiments of the invention relate to internet e-mails, the persons skilled in the art shall be aware that the invention may also be employed for transferring electronic messages in any other transferring system.
Abstract
The invention relates to a method and system of transferring internet electronic messages (e-mails). The method comprises the steps of creating a first e-mail by sender's mail user agent (11) and authorizing the sender by sender's mail server (2). To reduce network traffic and limit activities of entities responsible of transferring SPAM the method further comprises the steps of (a) sending an authorization request, in one embodiment in a form a of a second e-mail comprising IP address of sender's local computer system (1), to a sender authorization sever, which in one embodiment is recipient's local mail server (42); (b) authorizing said local computer system (4); (c) accepting the first e-mail by recipient's server, which in one embodiment is recipient's local mail server (42), if said authorization request of intention of sending the first e-mail to this recipient was authorized by the sender authorization server.
Description
- This application is a continuation of U.S. patent application No. 12/669,675, filed 19 Jan. 2010, which was a National Stage of PCT International application no. PCT/PL2008/000055, filed 24 Jul. 2008, which claimed priority in Polish patent application no. P.385076, filed Apr. 30, 2008 and Polish patent application no. P.382998, filed Jul. 25, 2007, the contents all of which are hereby incorporated by reference.
- The invention relates to a method and system of transferring electronic messages via telecommunication network, and more specifically to a method and system of delivering internet electronic messages (e-mails), comprising the step of creating a message by a sender and the step of authorizing the sender by the sender authorization server.
- Terms used in this specification have their defined or commonly accepted and used meanings that is quoted below:
- “Server” denotes a program, a computer system or a device electronically connected with other servers and accepting commands for providing specific services by sending responses, such as file server, database server, and in particular mail server.
- “Mail Server” or “Mail Transfer Agent” (MTA) denotes a server providing services of transferring electronic messages. Exemplary MTAs are programs Sendmail, Postfix, or MS6 Exchange Server.
- “Simple Mail Transfer Protocol” (SMTP) is a communication protocol defining transfer of electronic messages across the Internet.
- “Post Office Protocol version 3” (“POP3”) is a communication protocol to retrieve electronic messages from a remote server.
- “Internet Message Access Protocol” (IMAP) is a communication protocol contemplated to remedy some shortcomings of the POP3 protocol.
- “Mail User Agent” (MUA) or “e-mail client” is a program enabling user to create, write, send and receive e-mails. In case of sending, MUA connects with MTA using SMTP and after establishing connection sends messages to MTA. In case of receiving, MUA connects with MTA using e.g. POP3 or IMAP protocol and downloads messages. Exemplary MUAs are local applications such as Mozilla Thunderbird or MS® Outlook Express®, server applications such as Berkeley Mail, Heirloom mailx or pine, or applications controlled by means of web browsers (e.g. MS® Explorer®, Mozilla Firefox®) such as Hotmail or Gmail generally referred to as “webmail”.
- “Domain Name System” (DNS) is a system of servers and a communication protocols ensuring translation of internet addresses between mnemonic form (e.g.www.uprp.pl) and numeric (IP) form (e.g. 217.17.45.3) used by internet servers. Further, DNS stores information about Mail Transfer Agent(s) of a given internet domain (e.g. uprp.pl).
- “Fully Qualified Domain Address” (FQDA) is a string forming the Internet e-mail address comprising the local part, commonly denoting the user, symbol “@” and the domain part, commonly denoting internet domain in which the e-mail account of the user is located.
- “Applet” denotes a software component constructed in a manner allowing it to be embedded in a web page and subsequently downloaded and executed in the context of a web browser of a computer system, in particular digitally signed and implementing Java, Flash or ActiveX technology and Cookies system.
- “Servlet” or “server side script” denotes a software component executed by remote web server, on the basis of an information provided by user by means of a web browser, in particular digitally signed and implementing PHP, ASP, Borland Enterprise Server, etc. technology.
- In the past, servers transferring electronic messages accepted it from any sending server which was essential as the network connections were unreliable. If a given Sending server could not connect with the server of the recipient, it could at least pass over the message to any other relay server located closer to the recipient. This system however proven to be vulnerable to abuses from entities sending out unsolicited messages (SPAM) such as Unsolicited Commercial E-mail (UCE) or Unsolicited Bulk E-mail (UBE), which are illegal in many countries.
- Reception of SPAM messages is presently out of control of the recipient, which at best (e.g. using appropriate filtering software) bears the costs of SPAM delivery, especially while accessing the net via dial-up connection. Transmission of SPAM also consumes resources of mail servers intermediating in this process. Mail servers receiving e-mails from any mail sending servers are called “open relay” servers and commonly such servers are not handled by other servers, because with a high' probability it may be assumed that the e-mails sent by such servers are SPAM messages. When open relay server attempts to send a message, a recipient's server is able to determine its address and check whether this server is listed on the public list of “open relay” servers. Such lists are managed for example by the “MAPS” Organization (http://www.mail-abuse.com), which also administers lists of RBL servers (Realtime Blackhole List—list of servers spreading SPAM messages) and DUL servers (Dial-Up User List—list of servers connected via switched lines, from which servers SPAM messages are sent directly to recipient's servers).
- Commonly used technique for protection against SPAM messages involves appropriate configuration of sending server in such a way that sender has to be authorized before sending a mail. Thanks to this solution, only mails from senders that may log on to the mail sending server and whose identity is in this way confirmed by this server, shall be transferred further to the addresses of receiving servers designated in the messages. In case of an electronic mail, such type of service is called as SMTP AUTH and is defined in RFC 2554 (Request For Comment) normalization standard.
- Additional method used in connection with the one described above is a method in which receiving server accepts only e-mails for which the address of the sender corresponds to the address of the sending server. In other words, a sender is able to send messages only by means of the server being capable to authorize sender's identity. In practice, a sender authorization server is a server of a sender mail box or any other server connected with such a server, and a comparison of the sender address with the address of the sending server may consist in checking whether a domain part of sender FQDA address corresponds to a domain part of the sending server address.
- Particular steps of a typical, prior art method of transferring e-mail messages between sender's mail user agent and recipient's mail user agent, employing both techniques described above are illustrated below with reference to
FIGS. 1 and 4 .FIG. 1 schematically illustrates typical system of transferring e-mails between sender'slocal computer system 1 and recipient'slocal computer system 4 by means of or through sender'smail server 2 and recipient's mail server 3, while FIG. 4—individual steps of transferring the message. Usually, particular computer systems 1-4 are located remotely to each other and interconnected by means of a network employing TCP/IP protocol. A local sender'smail user agent 11 is installed on the senders computer system 1 (such as sender's personal computer, laptop, etc.), while a local recipient'smail user agent 41 is installed on the recipient's computer system 14. - As shown in
FIG. 4 a, in the first step an e-mail message is created by the sender with usage ofmail user agent 11. Except for its subject matter, an e-mail includes also among other things a FQDA address of at least one recipient and a FQDA address of the sender. Subsequently, localmail user agent 11 makes an attempt to login to a sender'sserver 2, on which the sender has its e-mail account. The login process is realized with using a SMTP AUTH mechanism as well as user name and passwords provided by the sender, which data are usually stored in encoded form by alocal MUA 11 of the sender. If login process is performed correctly, sender's MUA 11 sends created e-mail message to a sender'sserver 2 and, if there is no more messages to send, interrupts connection with sender's server. - In the next step, which is not shown in
FIG. 4 , the sender'sserver 2 translates FQDA addresses of each of the recipients indicated in the message, and using DNS mechanism determines recipient's server 3 of each specified recipient. As shown inFIG. 4 b, sendingserver 2 connects then with a server of a given recipient 3. At the present step of sending a message, each server making a connection with recipient's server 3 shall be rather recognized as “sending server” instead of “sender's server”, as its identity has not be yet verified. After establishing a connection, the sendingserver 2 indicates the sender of the message (using for example “MAIL FROM” command). If a domain part of a FQDA address does not match a domain part of the address of the sendingserver 2, a recipient's server 3 returns error reply informing about an error and refuses to accept the message. In the opposite instance, a recipient's server 3 returns OK reply enabling the sendingserver 2 to inform (for example using “RCPT TO” command) about the data of the recipient of the message, and, if a given receiving server 3 is suitable for the given recipient, to send messages and to disconnect. - An exemplary session of connection between the sending
server 2 and the recipient's server 3 shown inFIG. 4 b is presented below, where “R” denotes commands and replies send by the recipient's server and “S” denotes commands send by the sending server: -
Step Server Command (1) R: 220BBN-UNIX.ARPA Simple Mail Transfer Service Ready (2) S: HELO HOST1.USC-ISIF.ARPA (3) R: 250 BBN-UNIX.ARPA (4) S: MAIL FROM:<Smith@USC-ISIF.ARPA> (5) R: 250 OK (6) S: RCPT TP:<Jones@BBN-UNIX.ARPA> (7) R: 250 OK (8) S: DATA (9) R: 354 Start mail input; end with <CRLF>.<CRLF> (10) S: This is a test mail... S: Blah blah blah.... S: . (11) R: 250 OK (12) S: QUIT (13) R: 221 BBN-UNIX.ARPA Service closing transmissions channel - As shown, the sending server identified itself in step (2), and its domain part (USC-ISIF.ARPA) corresponds to domain part of the sender's address which was provided in step (4). It is of course one of the simplest systems of verification of the sender's server, as well as the sender itself. In the prior art methods of transferring of electronic message, data identifying the sender and/or recipient and/or the address of the sending server is contained most often in the message itself or follows from the actual IP address of the sending server or hitherto existing former history of transmission of the message.
- The last step of a process of sending a message is its delivering to s a recipient's local
mail user agent 41, residing in recipient'slocal computer system 4. As shown inFIG. 4 c, a recipient's local mail user agents logs in to a recipient's server 3 and, after passing through a logging procedure, the MUA downloads e-mail messages stored on the recipient's server. The above discussed steps of a process of transferring electronic messages, as illustrated onFIGS. 4 a and 4 b, are carried out with using SMTP protocol, whereas during the steps illustrated onFIG. 4 c POP3 or IMAP protocols are used. - European
patent specification EP 1 575 228 discloses a method and apparatus for reducing e-mail spam and virus distribution in a communications network by authenticating the origin of e-mail messages. The described method includes receiving at the sender's server a query to determine whether an e-mail message was sent be an indicated (in this message) user; checking logged data at the sender's server to determine whether the e-mail message in fact corresponds to a message sent from the sender's server, and responding to said query to authenticate the e-mail message origin. - The term “known method” or “known method of transferring the message” as used in this specification, denotes a process of sending messages according to any known and used prior art method, and particularly according to the method illustrated by
FIGS. 1 and 4 . - Using known methods of sending electronic messages, message needs to be transferred three times: firstly between sender's local
mail user agent 11 residing on sender'spersonal computer 1 and sender'smail server 2; secondly between sendingmail server 2 and recipient's mail server 3: and for the third time between a recipient's server 3 and a recipient's localmail user agent 41. On the other side, common e-mail messages still grows larger in terms of a size of data that needs to be sent, what results among other things from a message format (e.g. HTML or formatted text), but mainly from a size and a number of additional files attached to e-mails (attachments). In case where the sender is located in a place near the recipient but his mail server is in a remote location, known methods generate a considerable load in network traffic. Let us consider the sender having an e-mail account handled by a server in Warsaw, Poland, who is on a business travel in Beijing, from where using mail user agent residing on his personal laptop computer he intends to send a message to a contractor being also in Beijing, whose server is installed in Chicago. The message shall be sent for the first time to the sender's server in Poland, then from Poland to Chicago and eventually back again to the recipient's in Beijing. - The aim of the invention is to provide a method and system of transferring electronic messages via telecommunication network, and particularly a method and system of transferring internet electronic messages (e-mails), which would cause a decrease in a network traffic load, wherein the implementation of the solutions according to the invention might be able to be gradually introduced to the existing environments of transferring messages (in other words the invention should feature backward compatibility in relation to existing systems). The aim of the invention is also providing a method and system of transferring electronic messages, which would provide considerably limitation of activity of entities responsible for spreading SPAM Messages.
- The invention relates to a method of transferring electronic messages via telecommunication network, comprising the steps of:
- (a) sending an authorization request of intention of sending a message to a specified at least one recipient to a sender authorization server;
- (b) authorizing said authorization request of intention of sending a message to a specified at least one recipient by the sender authorization server; and
- (c) accepting said message to a specified at least one recipient by the server of this recipient if said authorization request of intention of sending a message to this recipient was authorized by the sender authorization server.
- Preferably said sender authorization server is a server of the sender mail box (sender's MTA). This enables to employ known solutions, such as “POP” before “SMTP” or “SMTP AUTH” services described above. It is of course possible to use other network servers capable of confirming the identity of the remote sender.
- Preferably said step (b) of authorizing said authorization request of intention of sending a message to a specified at least one recipient by the sender authorization server involves registration of said authorization request. Registration may be saved in logs or database of the authorization server, any other server connected to sender authorization server or even recipient's server.
- Said authorization request of intention of sending a message to a specified at least one recipient being send in said step (a) preferably comprises at least address of said at least one recipient and optionally at least one additional parameter chosen among others from the address of the sender, signature or the subject of the message, date and time of creating or sending the message and/or lists of attachments of the message.
- Said authorization of intention of sending a message to specified at least one recipient by the sender authorization server performed in step (b) is preferably valid within a predefined period and/or invalidated after step (c).
- The method according to the invention may after step (b) comprise additional step of sending by sender authorization server to the sender an authorization confirmation of intention of sending the message to at least one recipient. This allows the sender to send the message using a known method if sender authorization server does not confirm authorisation e.g. because it does employ the method of the present invention. Moreover, the method may prior step (c) comprise additional step of sending by a recipient's server to sender authorization server an authorization query about the intention of sending the message to this recipient. This query may also be sent to a server appropriate to authorize given recipient, e.g. in an attempt to send to the recipient's server a message from open relay server or DUL listed server. Also, after step (b) the method according to the invention may comprise additional step of sending authorization server to recipient's mail server information about authorization of an intention to send a message to this recipient. After receiving such a message, recipient's server is ready to accept a message delivered from a specified sender.
- Further the method according to the invention may comprise an additional step of sending by recipient's local mail server to recipient authorization server a message informing about the IP address of the recipient's local mail server. Thanks to that recipient authorization server, that is a server with which sending servers connects in order to send a message addressed to a given recipient, may transfer the message directly to recipient's local MTA operating on his local computer system. IP address information message is preferably send whenever IP address of recipient's local computer changes. In case recipient's local MAT is offline, recipient authorization server may obviously receive messages operating as recipient's remote MTA.
- Especially in this case, it is advantageous if before step (c) the method comprises an additional step of sending by the recipient authorization server to sender authosiation server or sender's local mail server a message informing about the IP address of the recipient's local mail server. Therefore authorized e-mail may be delivered directly to recipient's local mail server.
- Preferably identity of sender authorization server and/or identity of recipient authorization server is confirmed by appropriate certificate, such as certificate issued by Verisign® (http://www.verisign.com) or ThawteT™ (http://www.thawte.com).
- Preferably authorization request of intention of sending a message to a specified at least one recipient is itself an electronic message. This allows employing a method of the invention in known system of transferring e-mails with no need of their substantial modification. Such a modification of an e-mail system might comprise e.g. an extension of SMTP protocol with additional commands (e.g. AUTR for authorization request, ROAD in order to inform about recipient's local server, etc.), or comprise appropriate configuration of mail servers.
- In particular, the invention relates to a method of transferring Internet e-mails comprising the steps of creating a first e-mail by a sender and authorizing the sender by the sender's mail server, which further comprises the steps of:
- (a) creating and sending a second e-mail comprising an authorization request of intention of sending a message to a specified at least one recipient to a sender authorization server;
- (b) authorizing said authorization request of intention of sending a message to a specified at least one recipient by the sender authorization server; and
- (c) accepting said message to a specified at least one recipient by the server of this recipient, if said authorization request of intention of sending a message to this recipient was authorized by the sender authorization server, wherein
the sender authorization server is a recipient's local mail server; the authorization request contained in the second electronic message comprises at least IP address of the sender's local computer system and recipient e-mail address and optionally at least one additional parameter, and the second electronic message is transferred by senders local mail server to remote sender's mail server, then to at least one mail server of specified at least one recipient and eventually it is received by the recipient's local mail server; where authorizing by the sender authorization server said authorization request of intention of sending a message to a specified at least one recipient comprises creating and sending by recipient's local mail server to sender's local mail server an authorization request confirmation which comprises at least IP address of recipient's local computer system and optionally at least one additional parameter; and a method comprises an additional step of sending the first electronic message by sender's local mail server to at least one local mail server of specified at least one recipient. - In a prior art commonly used systems of transferring e-mails, they are transferred between mail servers using a peer to peer (P2P) architecture, however transfer of messages between MTAs and local computers of e-mail users is supported by client-server architecture. The method of the invention enables to supplement or overlay the whole system of e-mail transfer with the P2P architecture, reducing network overload, increasing privacy and safety of e-mail transmission and reducing SPAM distribution which shall be explained later. Additionally, the method of the invention features backward compatibility over known systems of e-mails transfer and transparency of usage for end users.
- Although explanations below relates mainly to transfer of e-mails between sender's local mail server and recipient's local mail server, it is obvious that such notation depends only on the function (sending or receiving) performed by given server during a given stage of transfer, and both of them shall advantageously perform both of these functions.
- Preferably said authorization request confirmation is itself an electronic message and is transferred by recipient's local mail server to sender's local mail server via outgoing mail server of a specified recipient and sender's incoming mail server.
- Thanks to that not only sender is verified by sending authorization request but also recipient who sends authorization request confirmation back to sender. Furthermore servers distributing SPAM, in particular zombie computers, are not usually configured to receive messages (otherwise they would be vulnerable to be blocked by traffic of servers of organizations fighting against SPAM distribution).
- Alternatively said authorization request confirmation is transferred by recipient's local mail server directly to sender's local mail server.
- This allows establishing P2P channel to send and receive message between sender and recipient and vice versa instantly on the basis of IP address of a sender's local computer provided in authorization request e-mail and IP address of recipient's local computer system provided in authorization request confirmation e-mail. The channel may be active as long as these addresses unequivocally points to local computers of sender and recipient. Otherwise sender's local mail server may automatically send subsequent authorization request through sender's mail server to recipient's mail server, where from it shall be received by recipient's local mail server in order to establish the P2P channel again.
- It is however advantageous if recipient's local mail server sends to the sender's local mail server authorization request confirmation whenever the recipient's local mail server IP address changes.
- Thanks to that the P2P e-mail channel is maintained between local mail servers since each one of them knows IP address of its partner. If only address of one of them changes, e.g. due to breaking of internet connection and dynamic assignation of a new address from available pool of IP addresses, change of localization, Internet Service Provider, etc., than the local mail server immediately informs the counterpart about this fact and establishes P2P channel again. The P2P channel would be broken only if both of these systems changed their IP addresses in the same time or remained offline for longer period of time.
- Additional parameters of authorization request described above are preferably chosen from sender's cryptographic public-key (encrypting), an information promoting P2P transfer and/or text of the first electronic message created by the sender, while said additional parameters of said authorization request confirmation are chosen from recipient's cryptographic public-key (encrypting), acceptable types and sizes of attachments, acceptable size and/or other parameters of the first electronic message that are acceptable by the recipient.
- Encrypting and decrypting keys allow establishing encrypted P2P channel between local computer systems of sender and recipient, such as symmetric or more preferably asymmetric TLS (Transport Layer Security) channel, operating on TCP layer, in which encryption of data streams is performed by means of two public keys and decryption by means of private keys, each one of which is known only to sender and recipient.
- Furthermore it is possible e.g. to send text of the first e-mail created by sender along with authorization request using known e-mail transfer system, while attachments of the first e-mail shall be delivered later after establishing P2P channel. If recipient does not use the P2P transfer method, the additional information may serve for promotion of the method according to the present invention, e.g. by encouraging installation of P2P enabled local mail server or mail user agent, implementing the method of the invention.
- Preferably prior the step of sending the first electronic message, the method involves more than one exchange of an authorization request and corresponding authorization request confirmation between sender's local mail server and recipient local mail server in order to negotiate the form of the first electronic message that is acceptable by recipient's local mail server.
- Preferably sender's local mail server and/or recipient's local mail server has a form of an application operating in between local mail user agent and remote mail server.
- The application may operate e.g. as a SMTP server bound to port 23 and POP3 server bound to port 80 of sender's/recipient's local computer system (localhost, IP 127.0.0.1) and after appropriate configuration of mail user agent by indicating that localhost shall serve both as the incoming and outgoing mail server and after appropriate configuration of the application itself by indicating actual remote mail servers for incoming and outgoing e-mails, intercept messages that are sent or received. In particular the application may transparently supplement the first e-mail created by sender with authorization request or temporarily save locally the first e-mail creating new authorization request, and than send it as e-mail to recipient having a similar application which appropriately interprets authorization request and sends authorization request confirmation back to sender.
- Moreover the application may operate on a different port (e.g. 272) and use dedicated protocol (other than SMTP) for P2P transmission according to the invention.
- Alternatively or additionally sender's local mail server and/or recipient's local mail server may be integrated with local mail user agent.
- In this case e-mail client is enabled with incorporated mechanisms of sending and receiving authorization requests and confirmations or establishing P2P channels right after its installation.
- In yet another embodiment local mail user agent may be operated via a web browser (webmail) and sender's local mail server and/or recipient's local mail server may have a form of an applet installed on a sender's local computer system and/or recipient's local computer system and operated via a web browser and/or via local mail user agent.
- This enables to employ the invention in webmail systems. Applets operating as local mail servers may be implemented e.g. in Java and ensure direct connection between sender's and recipient's local computer systems.
- Said steps (a) to (c) of each variant of the method of the present invention are advantageously performed if the volume of the message exceeds a predefined threshold. Therefore small messages (e.g. smaller that 4 MB) may be still transferred using commonly used system of e-mail transmission.
- The invention also relates to a system of transferring electronic messages via telecommunication network, in particular a system of transferring internet electronic messages (e-mails), which operates according to any variant of the method described above.
- Furthermore the invention relates to a computer-readable storage medium containing executable instructions for a system of transferring electronic messages via telecommunication network, in particular for a system of transferring internet electronic messages (e-mails), wherein said executable instructions comprise an execution of steps of any variant of the method described above.
- The invention is shown in its advantageous exemplary embodiments with reference to the drawings, in which:
-
FIG. 1 shows a typical prior art system of transferring electronic messages via computer network; -
FIG. 2 shows a typical system of transferring electronic messages via computer network which is known from the prior art, but in which a method according to the invention is employed; -
FIG. 3 shows another exemplary system of transferring electronic messages according to the present invention; -
FIGS. 4 a, 4 b and 4 c show particular steps of a method of transferring electronic messages which is known from the prior art; -
FIGS. 5 a and 5 b show particular steps of an exemplary method of transferring electronic messages according to the invention, a first step of a connection session shown inFIG. 5 a, and a local mail user agent establishing a connection with a recipient's server 3 and sending a command identifying the message sender inFIG. 5 b; -
FIG. 6 shows particular steps of another exemplary method of transferring electronic messages according to the invention; -
FIG. 7 shows another exemplary system of transferring electronic messages according to the present invention; -
FIG. 8 shows yet another exemplary system of transferring electronic messages according to the invention used for webmail user agents; -
FIG. 9 shows particular steps of an exemplary method of transferring electronic messages according to the invention which substantially corresponds to the system depicted inFIG. 7 ; and -
FIG. 10 shows particular steps of another exemplary method of transferring electronic messages according to the invention which substantially corresponds to the system shown inFIG. 8 . - In systems of transferring electronic messages shown in
FIGS. 1-3 , 7 and 8 particular steps of transferring messages between individual computer systems and servers are indicated by thick arrows representing transfer of electronic messages and thin curved arrows representing transferring auxiliary control communications (commands, queries, authorization messages, confirmation replies, etc.). It should be understood however that each step of transferring a message has usually a form of some kind of dialogue comprising mutual exchanging of communicates between servers. Though in the description a simplified terminology is used (e.g. “server sends a request”, “a server sends a query”, “a server responds”), for the persons skilled in the art it is obvious that computer servers, and in particular internet mail servers, communicate in this way as defined for SMTP protocol in RFC 821, RFC 2821 and RFC 1869 normalization standards, which are therefore included into this description by reference. A communication process with a mail server may also be realized in this way manually manner using appropriate software, such as telnet application. -
FIGS. 2 and 5 schematically shows an exemplary implementation of the invention. Similarly as in the case of the known method (seeFIGS. 1 , 4 and background art part of the specification), the first step of connection session shown inFIG. 5 a is creating an e-mail message by the sender. Subsequently, a localmail user agent 11 logs in to a sender'sserver 2, where the sender possesses his mail account. - In case of correct passing through logging procedure, the
local MUA 11 sends to the sender'sMTA 2, instead of the created message, a request for registration of intended operation of transfer which comprises sender's address, recipient's address and the size of a message. The registration request may of course contains also other parameters such as date and time data, the subject of a message, lists of attachments, etc. In a response, alocal MUA 11 receives a communication confirming registration of the request in aregister 5 of theserver 2 and disconnects. It is obvious that in a case when sender'sserver 2 is not capable to handle a method according to the invention, it shall reject a registration request for intended transferring operation thus giving a localmail user agent 11 a signal to send the message using known method as depicted inFIGS. 1 and 4 . - In subsequent connection session shown in
FIG. 5 b, a localmail user agent 11 establishes a connection with a recipient's server 3 and sends a command (in case of SMTP protocol—“MAIL FROM” command) identifying the message sender. As an address of the sending server, i.e. acomputer system 1, where the localmail user agent 11 resides, does not correspond with the sender address, the recipient's server 3 refuses to accept the message in case of not handling a method of the invention. Otherwise it sends to themail server 2 corresponding to the sender's address a request about registration of intended transferring operation. If sender'sserver 2 is not capable to handle a registration mechanism according to the method of the invention, it generates an error reply. The lack of the registration of intended transferring operation inregister 5 of theserver 2 means an attempt to send a message anonymously or an attempt to send a message after a predetermined period of time of storing the registration inregisters 5 of theserver 2, amounting e.g. one minute. In each of these cases, the recipient's server 3 denies accepting a message. - A message is accepted by the recipient's server 3 only if the intention of transferring a message for the recipient for which this server is designated has been registered by the sender's
server 2. After receiving a message, the recipient's server 3 may also invalidate registration in theregister 5 of the sender'sserver 2, thus preventing possibility of receiving the same message again. After all the messages have been sent to a given recipient's server 3 it closes transmission channel. Transferring messages to a recipient's local mail user agent is realized in a manner analogous to the one presented inFIG. 4 c. - By using the method described above, it is thus necessary only to transfer e-mail only twice: for the first time between a sender's
MUA 11 and recipient's MTA 3 and for the second time between recipient's MTA 3 and a recipient'sMUA 41. - Another exemplary implementation of the invention is schematically illustrated in
FIGS. 3 and 6 . In this embodiment, e-mail clients of thesender 11 and therecipient 41 are configured in such a way that in both cases local computer systems of thesender 1 and the recipient 4 (so called localhosts with IP address 127.0.0.1) serve as incoming mail servers (POP3) as well as outgoing mail servers (SMTP). On the sender'slocal computer system 1, there is aprogram 12 installed, which operates in background and provides services of sender's local mail server, by sending and receiving e-mails transferred from and toMUA 11.Similar program 42 on the recipient'slocal computer system 4 sends and receives e-mails transferred from and toMUA 41. - Additionally, the recipient's
local mail server 42 is responsible for sending torecipient authorization server 3 a communications informing about its factual IP address. As a recipient'slocal computer system 4 is commonly connected with the Internet via dynamic connection or temporary connection (for example by Dial Up switched line connection), this address may frequently change. - After creating a message using
local e-mail client 11, the sender executes “Send” command available from a toolbar ofmail user agent 11, and the message is sent to senderslocal mail server 11, which subsequently logs in tosender authorization server 2 a. After passing through logging procedure, the sender'slocal server 12 sends to thesender authorization server 2 a an authorization request of intended operation of transferring a message. Thesender authorization server 2 a establishes a connection with therecipient authorization server 3 a. If the address of the sender does not correspond to the address of thesender authorization server 2 a or the sender authorization server is not authorized to send messages from the senders whose domain part of FQDA address corresponds to the address of theserver 2 a, then the recipient authorization server 3 closes transmission channel. - In the opposite situation, the
recipient authorization server 3 a gives to thesender authorization server 2 a information about the address of the recipient'slocal server 4, and thesender authorization server 2 a forwards this information to the sender'slocal server 12. - The last step consists in transferring the message by the sender's
local mail server 12 to the recipient'slocal mail server 42 and closing transmission channel. The message may naturally be transferred between the sender'slocal server 12 and the recipient'slocal server 42 in parts in dependence of possibilities of setting up the transmission channel. From the recipient'slocal mail server 42, the e-mail is transferred to the recipient'slocal MUA 41 directly way or after executing by the recipient “Receive” command available fromMUA 41 toolbar. In order to transfer an electronic message according to this implementation of invention, only one communication session is required. - It is obvious that in this case there are in a way two sender's servers present, that is the sender's
local mail server 12 and thesender authorization server 2 a, as well as two recipient's servers, that is therecipient authorization server 3 a and the recipient'slocal mail server 42. For the invention point of view, the final recipient's server is of course the recipient'slocal mail server 42. In case the recipient'slocal mail server 42 is unavailable, the recipient authorization server may naturally receive messages acting as the final recipient's server (similarly as described in relation toFIGS. 2 and 5 ). -
FIGS. 7 and 9 schematically depicts another exemplary implementation of the invention. In this configuration, settings of e-mail clients of thesender 11 andrecipient 41, indicate that the local computer systems of thesender 1 and the recipient 4 (localhosts) are both incoming mail servers (POP3) as well as outgoing mail servers (SMTP). On the recipient'slocal computer system 1, there is abackground operating program 12, which is bound to ports 23 (SMTP), 80 (POP3) and 272 (new MAILP2P protocol) of the IP address of the local computer system.Program 12 provides services of sender's local mail server, which sends (SMTP) and receives (POP3/IMAP) electronic mail transferred from and to themail user agent 11. Similarbackground operating program 42 installed on the recipient'slocal computer system 4 provides services of recipient's local mail server by sending and receiving e-mails transferred from and to theMUA 41. In the configuration settings oflocal mail servers sender 1 and therecipient 4 are connected with the Internet via dynamic connection or temporary connection (for example by Dial Up switched line connection), in a result of which their IP addresses may frequently change. - Similarly as in a case of the known method of transferring a message, the first step of a connection session shown in
FIG. 9 involves creation of suitable first e-mail by the sender with use of alocal MUA 11 including typing the e-mail content, indication of the e-mail address of its recipient or recipients, stating the subject of the message, attaching additional files, etc. After message creation, the sender executes “Send” command from the toolbar of themail user agent 11, and theapplication 11 sends the first message in a sense to itself and more precisely to alocal mail server 12. Thelocal mail server 12 records received first message for its later use. - In the next step, the
local mail server 12 checks in its registers whether they contain the IP address of thelocal computer system 4 corresponding to e-mail address of the recipient and whether the recipient is able to handle the method of the invention. The address shall be stored in the registers if the communication channel of P2P connection between the sender and the recipient has been correctly constituted previously. The IP address might also have been introduced to these registers manually by the sender. - If the recipient's IP address and optionally the other parameters identifying the recipient are Known, then the senders
local mail server 12 attempts to send the first message via P2P connection through port 272 (particularly using encrypted channel) directly to the recipient'slocal mail server 42. If the IP address of the recipient's computer system is not known or, despite the address being known, transferring of the first message was not successful, then the sender'slocal mail server 12 creates the second electronic message comprising an authorization request of intention of sending a message to a given recipient. The request includes IP address of the sender'scomputer system 1, the sender's address, e-mail address of the recipient, the content of the first message and optionally the other parameters, such as a list of types and sizes of the attachments that are to be sent together with the first message. - In subsequent step, the sender's
local mail server 12 sends the second authorization message to theoutgoing mail server 2, on which the sender has his e-mail account. Before sending the message, the sender must gain authorization of hisMTA 2, for example with use of SMTP AUTH or “POP3 before SMTP” mechanism, and in a case of incorrect passing through the authorization procedure, the sender's server refuses connection. In the next step, the sender'sserver 2 sends via SMTP protocol (FIG. 7 ) an authorization communication to the recipient's MTA 3, on which the recipient has his e-mail account. From the recipient's server 3, the message shall in turn be received by the recipient'slocal mail server 42 via POP3 or IMAP protocols. In the first case (POP3), the recipient'slocal mail server 42 may connect periodically, for example every 2 minutes (in dependence on given configuration settings thereof), to the recipient's server 3 in order to determine whether there are any new messages, particularly any new authorization messages. - Obviously if the sender does not have a local mail server, an authorization message shall be received from the recipient's MTA 3 by his
mail user agent 41 as a common e-mail message. In such a case, an authorization confirmation shall obviously not be send, and the sender'slocal server 12 shall send after predetermined period of time, in dependence on its configuration settings, the first actual e-mail message using the known method of transferring e-mail messages (cf.FIG. 4 a). If however, the recipient'smail server 42 is capable to handle a method of the invention, in the next step it may determine whether the parameters of the first message are conforming to its default configuration settings or configuration settings defined by the recipient. It may for example determine whether the attachments, that the sender intends to send, agree as to the type of the attachments that are accepted by the recipient, etc. - In the next step, the recipient's local mail server sends via P2P channel (particularly via encrypted P2P channel) directly to the sender's local mail server a confirmation of the reception of an authorization request, comprising acceptable parameters of the first message. If the parameters are not acceptable by the recipient, then the sender may negotiate them by sending another third message and so forth, up to obtaining acceptance of a form of the first electronic message given by the recipient's local mail server.
- The final step includes sending the first message by the sender's
local server 12 via channel P2P (particularly via P2P encrypted channel) directly to the recipient'slocal server 42 and ending the connection. Obviously a message may also be forwarded between the sender'slocal server 12 and the recipient'slocal server 42 in fragments in dependence of possibilities of setting up the connection between them. From the recipient'slocal mail server 42, the message is transferred to the recipient's localmail user agent 41 in a direct way or after executing by the recipient “Receive” command available from a toolbar ofmail user agent 41. - In order to send the first substantial electronic message according to this implementation of the invention, there is one connection session required.
-
FIGS. 8 and 10 schematically illustrate another exemplary implementation of the invention that may be employed in e-mail clients handled by means of web browsers, such as Hotmail or Gmail, generally referred to as “webmail”. In the first step, the sender connects via aweb browser 13 with the sender's mail server 3 using HTTP protocol or cryptographic secure HTTPS protocol, and after correct logging on he gets access to hismail program 11 a, operating as a server-side script on the sender's mail server (MTA) 2. Thee-mail program 11 a, being locally controlled by means of sender'sweb browser 13, during the first connection requests sender to install theapplet 12 a on the sender'slocal computer system 1. Theapplet 12 a shall act as sender's local mail server functionally integrated with thee-mail program 11 a. -
Similar applet 42 a in communication with thee-mail program 42 a is installed on the recipient'slocal computer system 4. - Next, the sender creates the first e-mail and confirms requests to send it to a given recipient or set of recipients. The
e-mail program 11 a checks whether the recipient having a given e-mail address is able to handle a method of transfer according to the invention and whether IP address of the recipient'slocal computer system 4 is known. If so, themail user agent 11 a sends to the sender'slocal mail server 12 a an instruction to send the first message via P2P channel directly to the recipient'slocal mail server 42 a. In a case of lack of such information relative to the recipient, themail user agent 11 a creates and sends an authorization request to the recipient's mail server 3. If the recipient's mail server 3 does not handle P2P transmission according to the invention, it shall not appropriately interpret an authorization request. However the request may still be handled by the recipient's local mail server 42 (cf.FIGS. 7 and 9 ). In any case if it is not served, the sender'smail user agent 11 a shall send the first message to the recipient according to a known method after some time. - On the other hand in the system and method shown in
FIGS. 8 and 10 , recipient's mail user agent 41 a cooperates with the recipient's mail server 3. After the recipient logs in to his mail server 3, the recipient's mail user agent 41 a, locally controlled by means of the recipient's web browser 43 obtains information about the IP address of the recipient'slocal system 4, which information is forwarded together with authorization request confirmation to the sender'smail user agent 11 a, in order to establish P2P channel betweenlocal servers - The second authorization message may also be obviously created and sent by the sender's
applet 12 a(instead ofservlet 11 a), and received by the sender'sapplet 42 a (instead of servlet 41 a), capable of handling a method of the invention, and appropriately integrated with e-mail web browser controlled programs of thesender 11 a and the recipient 41 a. - It is obvious that all the methods of transferring e-mail messages may be mutually connected. In other words, a local mail server being integrated with a local mail user agent, either in a form of an application (12, 42) operating between local mail user agent (11, 41) and remote MTA (2, 3) or in a form of an applet (12 a, 42 a) installed on a local computer system and integrated with a remote mail program (11 a, 41 a) and controlled by means of an web browser, may be used for sending and receiving messages. Thanks to backward compatibility of a method of P2P transmission according to the invention, it does not matter at all whether a recipient is capable to handle innovative P2P transmission system, as nevertheless a message shall reach him in a typical manner.
- According to the invention a local mail server is equipped with appropriate mechanisms known from the prior art, enabling for proper communication through specified ports SMTP and POP3/IMAP with mail servers and on a specified port MAILP2P with other local mail servers without any difficulties resulting from operation on computer systems using firewalls, such as for example MSTM′ Windows firewall. During a connection with Internet, it is thus possible, without infringing rules ensuring obtaining proper security level, to provide services to user with private, virtual or public IP address, using any possible NAT (network address translation) and PAT (port address translation) configurations that are usually used in firewall settings.
- Configuration settings and characteristics of a local mail server handling a method according to the present invention may particularly comprise the following instructions, which for example may be assigned to all or only to selected e-mail addresses of mail users and/or may be dependent on the action effected by the user in response to a communication from his mail server:
-
- automatically send authorization request confirmation or ask user beforehand;
- send authorization request confirmation via P2P channel or via SMTP and POP3/IMAP channel;
- always send the first message via P2P channel if it is only possible;
- send information about a change of owned IP address to every authorized recipient;
- do not accept or accept attachments of the specified types and sizes;
- always create encrypted P2P channel or create encrypted channel on sender's request;
- download the first message fragmentarily if a connection was been interrupted; and many others.
- Moreover, the first message itself may also comprise additional parameters added for example in the subject field, options, or in the content, the parameters may for example determine the mode of transfer: standard via SMTP and POP3/IMAP protocols, or via P2P channel, P2P cryptographic channel, etc.
- The above embodiments of the invention relate and discuss a transmission process between one sender and one recipient has been ed. It is however obvious that a message may be sent using a method according to the invention from one sender to many recipients.
- Further, the particular steps of any of the inventive methods were described in a given order. It should be however understood that in alternative realization examples of the invention, the steps may be carried out in different order than the one described. Additionally, the described methods may be realized by means of hardware components and/or may be embedded in sequences of machine processed instructions, which may be used to enforce its execution by a machine, such as a general purpose processor or a dedicated processor or logical circuits programmed with use of such instructions. Such machine processed instructions may be stored on one or a number of machine readable carriers, such as CD-ROM, DVD discs or other optical disks, floppy disks, ROM, RAM, EPROM or EEPROM memories, smart cards or optical cards, and/or other types of machine readable carriers suitable for storing electronic instructions. For example, according to some exemplary embodiments of the invention, there are provided applications and/or software components, which may be executed on one or on some number of computers, for carrying out the above described methods. For instance, according to particular exemplary embodiments of the invention, there may be many software components configured to execution thereof on various hardware devices. Alternatively, the methods according to the invention may be implemented by appropriate combination of hardware and software elements. Although presented embodiments of the invention relate to internet e-mails, the persons skilled in the art shall be aware that the invention may also be employed for transferring electronic messages in any other transferring system.
- In this way, on the basis of the above described exemplary embodiments of the invention, the innovative methods, systems and software products for transferring messages has been presented and discussed. The present description indicates some exemplary realizations, including implementations of solutions according to the present invention, wherein the persons skilled in the art shall certainly notice that it is easily to develop many modifications and variants of the presented embodiments, which should also be considered as belonging to the scope of the invention. Thus only the content of the patent claims may be regarded as a proper definition of the invention.
Claims (13)
1. A method of transferring electronic messages via telecommunication network, in particular a method of transferring internet electronic messages (e-mails), comprising the step of creating a first electronic message by a sender, characterized in that, it comprises the steps of
(a) creating and sending using a known method of transferring electronic messages a second electronic message to a recipient's mail server (3, 3 a, 42, 42 a), said second electronic message comprising an authorization request of intention of sending said first electronic message to said recipient;
(b) determination of whether said authorization request of intention of sending said first electronic message is authorized by said recipient's mail server (3, 3 a, 42, 42 a) by authorization request confirmation; and
(c) establishing direct P2P channel between the sender's local computer system (1) and the recipient's mail server (3, 3 a, 42, 42 a) and accepting said first electronic message by the recipient's mail server (3, 3 a, 42, 42 a) through said direct P2P channel, if said authorization request of intention of sending said first electronic message to this recipient was authorized by the recipient's mail server (3, 3 a, 42, 42 a); or
(d) sending using a known method of transferring electronic messages said first electronic message to the recipient's mail server (3, 3 a, 42, 42 a).
2. The method of transferring electronic messages according to claim 1 , characterized in that, authorization of said authorization request by the recipient's mail server (3, 3 a, 42, 42 a) involves registration of said authorization request.
3. The method of transferring electronic messages according to claim 1 , characterized in that, said authorization request comprises at least IP address of sender's local computer system and optionally at least one additional parameter chosen among others from the address of the sender, signature or the subject of said first electronic message, date and time of creating or sending and/or lists of attachments of said first electronic message, sender's cryptographic public-key (encrypting), an information promoting P2P transfer and/or text of said first electronic message, while said additional parameters of said authorization request confirmation are chosen from recipient's cryptographic public-key (encrypting), acceptable types and sizes of attachments, acceptable size and/or other parameters of the first electronic message that are acceptable by the recipient.
4. The method of transferring electronic messages according to claim 1 , characterized in that, said authorization of said authorization request performed by the recipient's mail server (3, 3 a, 42, 42 a) is valid within a predefined period and/or invalidated after step (c).
5. The method of transferring electronic messages according to claim 1 , characterized in that, said authorization request confirmation is transferred by the recipient's local mail server (42, 42 a) directly via P2P channel to the sender's local mail server (12, 12 a).
6. The method of transferring electronic messages according to claim 1 , characterized in that, recipient's local mail server (42, 42 a) sends to the sender's local mail server (12, 12 a) said authorization request confirmation whenever the recipient's local mail server (12, 12 a) IP address changes.
7. The method of transferring electronic messages according to claim 1 , characterized in that, before the step (c) of sending the first electronic message via direct P2P channel it comprises more than one exchange of an authorization request and corresponding authorization request confirmation between sender's local mail server (12, 12 a) and recipient's mail server (3, 3 a, 42, 42 a) in order to negotiate the form of the first electronic message that is acceptable by recipient's mail server (3, 3 a, 42, 42 a).
8. The method of transferring electronic messages according to claim 1 , characterized in that, said sender's local mail server (12) and/or said recipient's local mail server (42) has a form of an application operating between local mail user agent (11, 41) and remote mail server (2, 3).
9. The method of transferring electronic messages according to claim 1 , characterized in that, said sender's local mail server (12) and/or recipient's local mail server (42) is(are) integrated with local mail user agent (11, 41).
10. The method of transferring electronic messages according to claim 1 , characterized in that, said local mail user agent (11 a, 41 a) is operated via a web browser (webmail) (13, 43) and said sender's local mail server (12 a) and/or recipient's local mail server (42 a) has a form of an applet installed on a sender's local computer system (1) and/or recipient's local computer system (4) and operated via a web browser (13, 43) and/or via local mail user agent (11 a, 41 a).
11. The method of transferring electronic messages according to claim 1 , characterized in that, said steps (a) to (c) are performed if the volume of the message exceeds a predefined threshold.
12. A system of transferring electronic messages via telecommunication network, in particular a system of transferring internet e-mails, characterized in that, it operates according to the method defined in any of previous claims.
13. A computer-readable storage medium containing executable instructions for a system of transferring electronic messages via telecommunication network, in particular for a system of transferring internet electronic messages (e-mails), characterized in that, said executable instructions comprise an execution of steps of the method defined in any of previous claims.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/761,740 US20130238726A1 (en) | 2007-07-25 | 2013-02-07 | Method And System Of Transferring Electronic Messages |
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PL382998A PL382998A1 (en) | 2007-07-25 | 2007-07-25 | The manner and system for sending of e-mails |
PLP.382998 | 2007-07-25 | ||
PLP.385076 | 2008-04-30 | ||
PL385076A PL385076A1 (en) | 2008-04-30 | 2008-04-30 | Method and system of electronic messages transmission |
PCT/PL2008/000055 WO2009014464A1 (en) | 2007-07-25 | 2008-07-24 | A method and system of transferring electronic messages |
US66967510A | 2010-01-19 | 2010-01-19 | |
US13/761,740 US20130238726A1 (en) | 2007-07-25 | 2013-02-07 | Method And System Of Transferring Electronic Messages |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/PL2008/000055 Continuation WO2009014464A1 (en) | 2007-07-25 | 2008-07-24 | A method and system of transferring electronic messages |
US66967510A Continuation | 2007-07-25 | 2010-01-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130238726A1 true US20130238726A1 (en) | 2013-09-12 |
Family
ID=39941909
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/669,675 Expired - Fee Related US8387120B2 (en) | 2007-07-25 | 2008-07-24 | Method and system of transferring electronic messages |
US13/761,740 Abandoned US20130238726A1 (en) | 2007-07-25 | 2013-02-07 | Method And System Of Transferring Electronic Messages |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/669,675 Expired - Fee Related US8387120B2 (en) | 2007-07-25 | 2008-07-24 | Method and system of transferring electronic messages |
Country Status (5)
Country | Link |
---|---|
US (2) | US8387120B2 (en) |
EP (1) | EP2174456B1 (en) |
AT (1) | ATE511280T1 (en) |
PL (1) | PL2174456T3 (en) |
WO (1) | WO2009014464A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120296989A1 (en) * | 2010-11-15 | 2012-11-22 | Nhn Corporation | File transmission management system and file transmission management method for supporting file transmission in mobile messaging service |
US20140297722A1 (en) * | 2011-11-04 | 2014-10-02 | Zte Corporation | Media message sending method, device and system |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5120405B2 (en) * | 2010-03-25 | 2013-01-16 | ブラザー工業株式会社 | E-mail communication apparatus and computer program |
US10200325B2 (en) * | 2010-04-30 | 2019-02-05 | Shazzle Llc | System and method of delivering confidential electronic files |
PL394944A1 (en) | 2011-05-19 | 2012-12-03 | Szymon Lukaszyk | The method and system of sending electronic messages using the instant communication protocol |
US9176949B2 (en) * | 2011-07-06 | 2015-11-03 | Altamira Technologies Corporation | Systems and methods for sentence comparison and sentence-based search |
CN105284178B (en) * | 2013-06-10 | 2019-04-12 | 苹果公司 | Configure wireless accessory device |
JP7188046B2 (en) * | 2018-12-14 | 2022-12-13 | 富士フイルムビジネスイノベーション株式会社 | Communication system, communication device, communication system program and communication program |
US11496423B2 (en) | 2019-11-20 | 2022-11-08 | Centurylink Intellectual Property Llc | Platform-agnostic message relay service for outbound messages |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020052855A1 (en) * | 2000-11-01 | 2002-05-02 | Mark Landesmann | System and method for granting deposit-contingent e-mailing rights |
US20020104026A1 (en) * | 2001-01-29 | 2002-08-01 | Robert Barra | Method and apparatus for providing a service to transfer messages over a communications network |
US20030009698A1 (en) * | 2001-05-30 | 2003-01-09 | Cascadezone, Inc. | Spam avenger |
US20040064511A1 (en) * | 2002-08-29 | 2004-04-01 | Abdel-Aziz Mohamed M. | Peer-to-peer email messaging |
US20050081051A1 (en) * | 2003-10-09 | 2005-04-14 | International Business Machines Corporation | Mitigating self-propagating e-mail viruses |
US20080046814A1 (en) * | 2002-02-15 | 2008-02-21 | Microsoft Corporation | System and method for generating structured documents in a non-linear manner |
US20080052400A1 (en) * | 2004-05-28 | 2008-02-28 | Christian Ekberg | Communications Method and Apparatus, Database Information Retrieval Method and Apparatus |
US20080126856A1 (en) * | 2006-08-18 | 2008-05-29 | Microsoft Corporation | Configuration replication for system recovery and migration |
US20090144380A1 (en) * | 2007-11-21 | 2009-06-04 | Kallman William R | Peer-to-peer email |
US20090157829A1 (en) * | 2007-12-14 | 2009-06-18 | Electronics And Telecommunications Research Institute | Peer-to-peer service system and method using e-mail service |
Family Cites Families (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6393465B2 (en) * | 1997-11-25 | 2002-05-21 | Nixmail Corporation | Junk electronic mail detector and eliminator |
US6321267B1 (en) * | 1999-11-23 | 2001-11-20 | Escom Corporation | Method and apparatus for filtering junk email |
US6691156B1 (en) * | 2000-03-10 | 2004-02-10 | International Business Machines Corporation | Method for restricting delivery of unsolicited E-mail |
AU2001265407A1 (en) | 2000-05-31 | 2001-12-11 | Snip, Llc | Method and system for instant messaging |
US20030020026A1 (en) * | 2001-07-26 | 2003-01-30 | Chao-Hui Huang | Method of detecting pattern defects of a conductive layer in a test key area |
US7039949B2 (en) | 2001-12-10 | 2006-05-02 | Brian Ross Cartmell | Method and system for blocking unwanted communications |
US20030200267A1 (en) | 2002-04-22 | 2003-10-23 | Garrigues James F. | Email management system |
AU2003278421A1 (en) | 2002-06-19 | 2004-01-06 | Joseph C. Benowitz | Technology enhanced communication authorization system |
EP1387249B1 (en) * | 2002-07-31 | 2019-03-13 | Texas Instruments Incorporated | RISC processor having a stack and register architecture |
US6824539B2 (en) * | 2002-08-02 | 2004-11-30 | Storz Endoskop Produktions Gmbh | Touchscreen controlling medical equipment from multiple manufacturers |
EP1427210B1 (en) * | 2002-12-04 | 2006-08-16 | Irdeto Access B.V. | Terminal, data distribution system comprising such a terminal and method of re-transmitting digital data |
US20040243847A1 (en) | 2003-03-03 | 2004-12-02 | Way Gregory G. | Method for rejecting SPAM email and for authenticating source addresses in email servers |
US7320020B2 (en) * | 2003-04-17 | 2008-01-15 | The Go Daddy Group, Inc. | Mail server probability spam filter |
US20040221016A1 (en) * | 2003-05-01 | 2004-11-04 | Hatch James A. | Method and apparatus for preventing transmission of unwanted email |
US20040236838A1 (en) | 2003-05-24 | 2004-11-25 | Safe E Messaging, Llc | Method and code for authenticating electronic messages |
US20040249897A1 (en) | 2003-06-09 | 2004-12-09 | Espinosa Claudia Leticia | Method, system and apparatus for rejecting unauthorized or SPAM e-mail messages |
ITRM20030353A1 (en) | 2003-07-17 | 2005-01-18 | Diego Angelo Tomaselli | METHOD FOR ANTI-SPAM MANAGEMENT OF E-MAIL MESSAGES. |
US20050020413A1 (en) * | 2003-07-25 | 2005-01-27 | Rudell Elliot A. | Power unit for jumping rope-with timer circuit |
WO2005031586A1 (en) | 2003-09-26 | 2005-04-07 | Trusted Delivery Pty Ltd | Method and system for delivering electronic messages using a trusted delivery system |
US7752440B2 (en) | 2004-03-09 | 2010-07-06 | Alcatel-Lucent Usa Inc. | Method and apparatus for reducing e-mail spam and virus distribution in a communications network by authenticating the origin of e-mail messages |
US20050204133A1 (en) | 2004-03-09 | 2005-09-15 | Robert LaLonde | Reduction in unwanted e-mail (spam) through the use of portable unique utilization of public key infrastructure (PKI) |
US20050256959A1 (en) | 2004-04-13 | 2005-11-17 | Magnus Svensson | Method of and system for multimedia messaging system interoperability |
US7945954B2 (en) * | 2004-09-07 | 2011-05-17 | Coueignoux Philippe J M | Controlling electronic messages |
US20090222450A1 (en) | 2005-05-16 | 2009-09-03 | Ron Zigelman | System and a method for transferring email file attachments over a telecommunication network using a peer-to-peer connection |
US20090044006A1 (en) | 2005-05-31 | 2009-02-12 | Shim Dongho | System for blocking spam mail and method of the same |
US7814313B2 (en) * | 2005-06-29 | 2010-10-12 | Nokia Corporation | System, terminal, network entity, method and computer program product for authorizing communication message |
US7607014B2 (en) * | 2005-06-30 | 2009-10-20 | Hewlett-Packard Development Company, L.P. | Authenticating maintenance access to an electronics unit via wireless communication |
-
2008
- 2008-07-24 EP EP08793965A patent/EP2174456B1/en not_active Not-in-force
- 2008-07-24 WO PCT/PL2008/000055 patent/WO2009014464A1/en active Application Filing
- 2008-07-24 US US12/669,675 patent/US8387120B2/en not_active Expired - Fee Related
- 2008-07-24 PL PL08793965T patent/PL2174456T3/en unknown
- 2008-07-24 AT AT08793965T patent/ATE511280T1/en not_active IP Right Cessation
-
2013
- 2013-02-07 US US13/761,740 patent/US20130238726A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020052855A1 (en) * | 2000-11-01 | 2002-05-02 | Mark Landesmann | System and method for granting deposit-contingent e-mailing rights |
US20020104026A1 (en) * | 2001-01-29 | 2002-08-01 | Robert Barra | Method and apparatus for providing a service to transfer messages over a communications network |
US20030009698A1 (en) * | 2001-05-30 | 2003-01-09 | Cascadezone, Inc. | Spam avenger |
US20080046814A1 (en) * | 2002-02-15 | 2008-02-21 | Microsoft Corporation | System and method for generating structured documents in a non-linear manner |
US20040064511A1 (en) * | 2002-08-29 | 2004-04-01 | Abdel-Aziz Mohamed M. | Peer-to-peer email messaging |
US20050081051A1 (en) * | 2003-10-09 | 2005-04-14 | International Business Machines Corporation | Mitigating self-propagating e-mail viruses |
US20080052400A1 (en) * | 2004-05-28 | 2008-02-28 | Christian Ekberg | Communications Method and Apparatus, Database Information Retrieval Method and Apparatus |
US20080126856A1 (en) * | 2006-08-18 | 2008-05-29 | Microsoft Corporation | Configuration replication for system recovery and migration |
US20090144380A1 (en) * | 2007-11-21 | 2009-06-04 | Kallman William R | Peer-to-peer email |
US20090157829A1 (en) * | 2007-12-14 | 2009-06-18 | Electronics And Telecommunications Research Institute | Peer-to-peer service system and method using e-mail service |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120296989A1 (en) * | 2010-11-15 | 2012-11-22 | Nhn Corporation | File transmission management system and file transmission management method for supporting file transmission in mobile messaging service |
US20140297722A1 (en) * | 2011-11-04 | 2014-10-02 | Zte Corporation | Media message sending method, device and system |
Also Published As
Publication number | Publication date |
---|---|
PL2174456T3 (en) | 2011-10-31 |
EP2174456A1 (en) | 2010-04-14 |
US8387120B2 (en) | 2013-02-26 |
US20100211783A1 (en) | 2010-08-19 |
ATE511280T1 (en) | 2011-06-15 |
WO2009014464A4 (en) | 2009-03-12 |
EP2174456B1 (en) | 2011-05-25 |
WO2009014464A1 (en) | 2009-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20130238726A1 (en) | Method And System Of Transferring Electronic Messages | |
US8032750B2 (en) | Method for establishing a secure e-mail communication channel between a sender and a recipient | |
US7673004B1 (en) | Method and apparatus for secure IM communications using an IM module | |
US8595814B2 (en) | TLS encryption in a managed e-mail service environment | |
US8327157B2 (en) | Secure encrypted email server | |
Gellens et al. | Message submission for mail | |
Lyon et al. | Sender ID: Authenticating e-mail | |
EP1701494B1 (en) | Determining a correspondent server having compatible secure e-mail technology | |
US20170078104A1 (en) | Secure instant messaging system | |
DE602005000121T2 (en) | Method and apparatus for reducing e-mail spam and spreading viruses in a communication network by authenticating the origin of e-mail messages | |
US20050235041A1 (en) | Public/Private/Invitation Email Address Based Secure Anti-Spam Email Protocol | |
WO2004063870A2 (en) | System and method for dynamic data security operations | |
US7636848B2 (en) | Method, system, network and computer program product for securing administrative transactions over a network | |
Malatras et al. | Technical recommendations for improving security of email communications | |
US20140089441A1 (en) | Method And System Of Transferring Electronic Messages Using An Instant Messaging Protocol | |
Holst-Christensen et al. | Security issues in SMTP-based email systems | |
WO2009028955A2 (en) | Secure exchange of messages | |
RU2008135759A (en) | SYSTEM AND METHOD FOR TRANSFER OF DOCUMENTS AND DOCUMENT MANAGEMENT | |
Gellens et al. | RFC 6409: Message Submission for Mail | |
AU2005236499B2 (en) | Electronic message authentication process | |
EP1788771A1 (en) | System and method for handling electronic messages | |
WO2005104422A1 (en) | Electronic message authentication process | |
Lyon et al. | RFC 4406: Sender ID: Authenticating E-Mail | |
AU2005242194A1 (en) | A trusted electronic messaging system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |