WO2005117372A1 - Procede, format de protocole et systeme de communication mobile de courriers electroniques - Google Patents

Procede, format de protocole et systeme de communication mobile de courriers electroniques Download PDF

Info

Publication number
WO2005117372A1
WO2005117372A1 PCT/NO2005/000175 NO2005000175W WO2005117372A1 WO 2005117372 A1 WO2005117372 A1 WO 2005117372A1 NO 2005000175 W NO2005000175 W NO 2005000175W WO 2005117372 A1 WO2005117372 A1 WO 2005117372A1
Authority
WO
WIPO (PCT)
Prior art keywords
email
message
messages
server
mail
Prior art date
Application number
PCT/NO2005/000175
Other languages
English (en)
Inventor
Thanh Van Do
Jon-Finngard Moe
Eivind Sivertsen
Original Assignee
Telenor Asa
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telenor Asa filed Critical Telenor Asa
Publication of WO2005117372A1 publication Critical patent/WO2005117372A1/fr

Links

Classifications

    • 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
    • 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/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the fields of mobile communication and Internet mail, and in particular relates to a method, protocol and system for transferring emails to and from a mobile device.
  • the problems that arise are due to the protocols creating excessive message exchange between client and server and unnecessary overhead in different parts of the email. This creates problems in a communication channel of limited bandwidth.
  • too complex representations of the emails create problems for the presentation on a display screen of limited size and resolution.
  • Other problems are due to unsupported presentation formats.
  • a mobile terminal has normally both limited processing power and capacity for storing programs.
  • Email clients are often of a complex nature, which are heavy to implement on a mobile client with limited capabilities.
  • strict firewall configurations may create problems for mobile access.
  • There has been attempts on creating more efficient solutions for mobile mail access e.g. by employing VPN channels between the server and the client, or by introducing an additional Web/WAP mail server handling the traffic between the email server and the client.
  • these solutions create problems on their own.
  • Another object is to provide a system and protocol by which the emails can be properly presented on a display screen of limited size.
  • Still another object is to provide a system and protocol that is less demanding as to processing power and storage capabilities in the mobile client.
  • the invention consists of a method for mobile email communication between an email server with POP/IMAP/SMTP interfaces and a mobile terminal with an email client with a SOAP interface through an email services server with POP/IMAP/SMTP interfaces, as well as a SOAP interface, said method including: sending SOAP message requests from the mobile terminal to the email services server, containing predefined method calls having as parameter a XML protocol format message, converting the requests in the email service server into standard email messages, and sending said standard email messages to the email server and vice versa .
  • the invention consists of an email communication protocol format for messages to be transferred to and from an mobile terminal, including: a ⁇ Headers> element containing a limited set of information relevant for a user of the mobile terminal, a ⁇ Flags> element mapped directly from the IMAP specification, a ⁇ Body> element of N ⁇ text/plain"-MIME type without alternative representations.
  • the invention consists of a system for mobile email communication, said sytem including: an email server with POP/IMAP/SMTP interfaces, a mobile terminal with an email client with a SOAP interface, an email services server with POP/IMAP/SMTP interfaces, as well as a first SOAP interface, said email services server being arranged to interpret XML protocol format message requests from the mobile terminal received on said first SOAP interface, convert said message requests into POP/IMAP/SMTP format messages, send the converted messages to the email server, convert the result into SOAP messages and send the SOAP messages too the mobile client.
  • Figure 1 is showing the current mail system architecture (prior art)
  • Figure 2 is showing the relationship between an SMTP mail object and a Internet Message Format message (prior art)
  • Figure 3 is showing an SMTP - envelope (prior art) .
  • Figure 4 is showing examples of email structures (prior art) .
  • FIG. 5 is showing a VPN solution (prior art)
  • Figure 6 is showing a Web/WAP Mail overall architecture (prior art) .
  • Figure 7 is showing a proposed new solution with straightforward SMTP, POP, IMAP mapping to XML Web Service,
  • Figure 8 is showing an alternative new solution with the XML Web Service taking use of XMTP
  • Figure 9 is illustrating the solution of the invention sending an e-mail using XMMAP
  • Figure 10 shows the inventive email Web Service Architecture using XMMAP
  • Figure 11 is showing the messaging occurring between participating components when sending an e-mail using XMMAP
  • Figure 12 shows the Web Service Interfaces
  • Figure 13 shows a Web Service Enterprise model.
  • the current mail communication systems consist of two main components, email Server and email Client. They are both compositions of several elements that are making use of several communication protocols, as well as internal service elements. Examples of protocols are SMTP (Simple Mail Transfer Protocol) [4], IMAP (Internet Message Access Protocol) [5] and POP (Post Office Protocol) [6] .
  • SMTP Simple Mail Transfer Protocol
  • IMAP Internet Message Access Protocol
  • POP Post Office Protocol
  • the user interacts with the UI (User Interface), which allows her to compose an email.
  • the UI will hand over the message to the MUA (Mail User Agent) that will establish an SMTP session with the remote MSA (Mail submission Agent) to expedite the mail.
  • the MSA can do pre-specified adaptations to the message to comply with the SMTP-IMF standards [7] .
  • LDA Local Delivery Agent
  • MTA Message Transfer Agent
  • An SMTP mail object contains an envelope and content.
  • the SMTP envelope is sent as a series of SMTP protocol units.
  • It consists of an originator address (to which error reports should be directed) ; one or more recipient addresses and optional protocol extension material.
  • the SMTP content is sent in the SMTP DATA protocol unit and has two parts: the headers and the body. If the content conforms to other contemporary standards, the headers form a collection of field/value pairs structured according to the Internet Message Format; the body, if structured, is defined according to MIME (Multipurpose Internet Mail Extensions) .
  • MIME Multipurpose Internet Mail Extensions
  • SMTP Envelope - excessive message transfers This is an example of a typical "SMTP Envelope" for sending a normal e-mail to two recipients. It's worth noting the excessive message transfers:
  • IMF Internet Message Format
  • MIME Multipurpose Internet Mail Extensions
  • the IMF representation of an email is quite efficient, and does not introduce any overhead of significance. This makes IMF a good starting point when trying to represent emails adapted for mobile terminals.
  • the problem with IMF is not the format itself, but how it is used.
  • An email usually contains a lot of information enclosed in headers. Most of this information is not relevant to the end user. This information may include a list of mail servers the message has visited on its way to its destination, and several so called ⁇ X-headers"l . This information is usually not presented in the user-agents and introduces a significant amount of overhead when sending email headers to mobile agents .
  • X-headers are custom headers for providing extra information about the email. Typically added by user agents, virus and spam-scanners. for ⁇ jonfinng@stud.ntnu.no>; Sat, 3 Apr 2004 15:37:45 +0200 (CEST)
  • Thread-Topic Paper MWCN 2004 final version thread-index: AcQXAvMvvLDODbn9SeSq5/2eImqLIQCfUkcw
  • FILETIME [BA45C760 : 01C41980] MIME-Version: 1.0
  • the headers marked in bold are the headers usually presented in a user-agent because they contain the information most relevant to the end user.
  • the size of the header-element of this email shrinks from 2351 to 323 bytes, significantly reducing this emails total size. Hence, for mobile terminals with limited bandwidth and client-functionality, only a minimal set of headers should be transferred.
  • a MIME email's content is organized in two dispositions: INLINE and ATTACHMENT.
  • the parts marked as INLINE will usually be shown in the mail client when opening the email for reading.
  • the INLINE content parts are encoded as text.
  • the parts marked as ATTACHMENT consist of binary data, and must be opened in an external application or through a plug-in in the mail reader able to interpret that specific attachment.
  • the different parts of the message are separated by custom defined "boundaries".
  • the first header element included in this cut tells us that this is a MIME message, and that the mail reader must support MIME to understand this message.
  • the base content type is marked as "multipart/mixed” as in this message.
  • the first bodypart is of type "text/plain” and represents the text in this message. Parameters tells us that the bodypart has charset iso-8859.
  • the second part of the message is an attached picture with content type "image/pjpeg" . In this part, the filename and encoding are supplied as parameters.
  • MIME messages also support nested content, and so called “multipart/alternative" body parts (among many other content types) .
  • a "multipart/alternative" message holds different presentation of the same data in different formats, allowing the client or user to choose which format that is best suited for presentation.
  • Figure 4 shows some examples of how email may be organized in different bodyparts .
  • MIME is a good and much needed extension to ordinary mail.
  • the access and manipulation of emails stored in the Message Store are enabled by an Access Agent, which implements protocols such as IMAP (Internet Message Access Protocol) or POP (Post Office Protocol) .
  • the client application will contain either an IMAP client or a POP client (or both) for the retrieval of emails and mailbox operations.
  • IMAP Internet Message Access Protocol
  • POP Post Office Protocol
  • the client application will contain either an IMAP client or a POP client (or both) for the retrieval of emails and mailbox operations.
  • This comes in addition to the software required for sending out mail using SMTP.
  • the clients and server are on an Intranet protected by a corporate firewall, which prevents access to the email server from outside this network. This is done to protect the server from outside attacks and hacker attempts, as well as for stopping unwanted relaying activity, which may include spamming.
  • users are getting more and more mobile and want to access their email accounts also when not being on the corporate intranet. This introduces a conflict interest between security and availability.
  • a VPN client establishes a secured channel from the remote computer through the Internet and across the firewall to the corporate intranet.
  • the client is hence logically connected to the intranet and the user can use a normal email client to access his email using standard protocols.
  • the unstable wireless link may introduce problems to the VPN session.
  • Sporadic mail access by the mobile user is not suitable because of long setup time and possible VPN connection timeout .
  • Mobile phones may not have sufficient storage for all the mails .
  • Mobile phones may not have processing and storage capabilities to host both a SMTP client and an IMAP/POP client .
  • Mobile phones have much more limited User Interface capabilities, i.e. small display, limited navigation facility, and small and limited keypad.
  • a Web/WAP mail Server is now introduced. It is usually resides in the DMZ (De- Militarized Zone) between the Internet and the corporate intranet.
  • the Web-application server synchronizes with the corporate mail server behind the firewall for the retrieval and sending of mail. Actually, this server contains a Web application with same core elements as an email client. Both implementations use SMTP and IMAP/POP for communication with the email server. The user can access her mails using a WWW-browser.
  • the main advantage of this solution is that a mobile user needs nothing more than a WWW-browser to access her email. No additional functionality is required on a mobile phone, The mobile phone can access the user' s email account on the webmail server either directly using an HTML/xHTML browser or via WAP using a WML browser. It is worth noting that this alternative applies also for pure web mail services like hotmail, yahoo, online, etc.
  • the mails are not stored on the mobile phones but on the Web/WAP Mail server. To read the same mail twice, the user has to access the Web/WAP server again. This due to the relaxed HTML/WML-standard for which it is difficult to parse out the actual information contents from presentation wrapping.
  • the reading of mail may be time consuming and less flexible since the web/WAP pages are generated dynamically on the fly for each access. Caching on the mobile device is difficult and requires much storage capacity, again due to the excessive amount of presentation data supplied together with the information content.
  • This invention consists of two elements:
  • An architecture based on XMMAP that enables the mobile user to access, send and manipulate her mails stored in a mail server residing in the user's corporate intranet.
  • XMMAP XML Mobile Email Access Protocol
  • the XML Web Service concept is found most suitable due to the ubiquity of the World Wide Web and the ability to traverse firewalls using SOAP (Simple Object Access Protocol) [2] .
  • SOAP Simple Object Access Protocol
  • the most straightforward solution is to expose the whole SMTP and IMAP/POP as Web Services as shown in Figure 7.
  • Each SMTP and IMAP/POP command is mapped to a Web Service method.
  • each SMTP or IMAP/POP command is encapsulated in a SOAP message and transported to the WS client.
  • the WS client To access and retrieve mails, the WS client must be capable of understanding the SMTP/IMAP/POP commands and communicating properly with the email Server. It must therefore be equipped both with a MUA (Mail User Agent) with full SMTP support as well as an IMAP/POP client. This functionality is put on top of the SOAP engine.
  • MUA Mail User Agent
  • IMAP and SMTP are not pure request-response protocols. They also include the possibility of server-originated messages. If full compliance with SMTP and POP/IMAP should be achieved, the clients must be able to listen for method invocations from the server. In this case server originated method invocation implies a full Web Service implementation on the client. This is infeasible due to limited processing and storage capacity on mobile terminals. They do not have a static internet address, and the connection is frequently shut down. In other words, mobile phones were not designed to work as servers.
  • XMTP XML MIME Transformation Protocol
  • XMTP contains no functionality beyond the IMF message mapping. This means that when using XMTP, all message exchanges and overhead must remain as in the previous approach. XMTP may in itself introduce some amount of overhead due to the XML-tags .
  • XMMAP XML Mobile Email Access Protocol
  • XMMAP XMMAP
  • MTA MTA
  • IMAP/POP Access Agent
  • SMTP-IMF/XMTP representation format
  • XMMAP utilizes the strength of XML to simplify parsing of the received information.
  • the terminal can use an XML-parser for retrieving the information from the XMMAP-message as well as for constructing new XML documents.
  • XMMAP introduces a new concept of messaging. While traditional protocols rely on frequent message transfers with well-defined operations, XMMAP is more flexible, making it possible to do most operations in one exchange.
  • XMMAP is in its basic form a representation of an entire mail account, spanning everything from login credentials to flags in a specific message. This makes it possible to use sub-parts of the XMMAP-format for representing different parts of a mail account for different purposes. This is especially useful when utilizing XMMAP for invoking methods on the mail server. When invoking a method, only the relevant subparts of the formats are sent, thus avoiding unnecessary overhead.
  • XMMAP is a representation of an entire mail account. This section holds a brief description of the format including several examples. We begin straight at the point by giving an example of how the most important part of an account, a single message itself, is represented in XMMAP :
  • the format is very much self-explanatory as it contains elements from the mentioned known protocols (SMTP, XMTP, P0P3 and IMAP) .
  • XMMAP maps perfectly into a standard SMTP- IMF message, with or without MIME extensions, and vice versa.
  • an XMMAP-message supplies the essential information given by both P0P3 and IMAP mail access protocols.
  • the ⁇ Message> element is the root of a MIME/RFC2822 message.
  • a ⁇ Message> element contains ⁇ BoxNumber>, ⁇ Headers>, ⁇ Flags>, ⁇ Body> and ⁇ Attachments> elements.
  • a ⁇ BoxNumber> represents the message's number in a mailbox.
  • the actual mailbox may be given as parameter when not implicit from surrounding context.
  • ⁇ Headers> element contains standard RFC 2822-headers with localo names representing the header names. Parameters are represented by child elements.
  • the ⁇ Flags> element supplies the current flags of an email as child elements.
  • the set flags are transmitted and the tag holds the value "1".
  • a value of "1" meanso that the flag should be set, and "0" means that the flag should be unset.
  • the flags are mapped directly from the IMAP specification.
  • ⁇ Body> element The body element contains the body of the email message.s The current character set is given as a parameter. If no parameter is given N us-ascii'' is assumed as in SMTP-IMF. The content of the ⁇ Body> element is always represented as "text/plain"-MIME type. If the original message supplies optional ways of representing the message, all but oneo alternative are stripped from the message by the SMTP- >XMMAP gateway. If the body is only represented in for example "text/html", the HTML-tags are stripped. The results after stripping are supplied as "text/plain”. This is done to reduce the amount of data to transmit, as well5 as supplying the data in a format as simple as possible for use with mobile terminals .
  • the representation alternatives can be supplied and the corresponding MIME types given as parameters to the ⁇ Body> element. If the client cannot represent a body part,o an error message will be supplied and shown to the user.
  • Attachments-element Only relevant if the message contains attachments. These are supplied within the Attachments-element. Each attachment is contained within an Attachment-element.
  • the MIME type and encoding is given as attributes. Encoding may be omitted, base64 is then assumed.
  • an ⁇ Attachment> element contains ⁇ Filename>, ⁇ Size> and ⁇ Content> elements, containing the filename, size of the file and binary encoded data, respectively.
  • Attachments may be large, and in many cases the user is not interested in downloading these, but only receive the message-text and attachment-description.
  • the ⁇ Content> element may be left empty ( ⁇ Content/>) . Even if the ⁇ Content> element is empty, the user receives information about the filetype, filename and size of the file. From that information the user can decide whether he wants to download the attachments later or not.
  • the Account element represents an entire mail account with all its meta-information as well as content.
  • the account contains ⁇ Mailboxes>-elements .
  • Account elements can also include login credentials. This can be ⁇ UserName>, ⁇ PassWord>, ⁇ Protocol> and ⁇ Port>.
  • the ⁇ Account> element is necessary only when logging on to an account, and when receiving a list of available mailboxes from the server.
  • An account may contain one or more mailboxes; these are listed within the Mailboxes-element-tag as MailBox- elements .
  • IMAP and POP have functionality that gives you this information without needing to download all messages.
  • the Mailbox-element in the XMMAP-format offers information usually provided by POP and IMAP.
  • the element can also hold full representation of Mailboxes with content.
  • ⁇ BoxName>, ⁇ Unread>, ⁇ Total>, ⁇ Messages> and ⁇ Mailboxes> are sub elements of a Mailbox-element.
  • ⁇ BoxName>, ⁇ Unread> and ⁇ Total> contains the name of the mailbox, the number of unread messages in it and the total number of messages respectively.
  • the Messages-element can contain one or more of the messages of this folder. It can also be left as an empty tag if this information is not wanted in the current request.
  • a Mailboxes-element within a MaiIBox-element contains sub-mailboxes ofthe current mailbox ifsuch exists.
  • the XMMAP data format is useful for representing an account in a minimalist way, and may also be well suited for storage purposes.
  • the data format lacks the coupling to specific methods related to mobile mail access. This coupling is achieved by defining SOAP - methods using XMMAP messages as parameters.
  • a session is established by the Web Service. It is recommended that this session is a SOAP session, but may also be based on underlying protocols such as HTTP.
  • the Web Service also manages a connection to the mailserver related to each session. The session fetches a previously stored profile, or creates a new one. The profile, among other information, holds custom adaptation properties for the mobile terminal used in this session.
  • loginProfileXMMAP uses a pre stored profile
  • loginMobileTermXMMAP takes more input parameters which are needed for creating a new profile for present and future use. These parameters are typically related to the mobile terminal as screen size and maximum number of colors supported. These parameters are not a part of the XMMAP- message itself.
  • the response of an invocation of these methods is a session- and profile ID in addition the XMMAP-message (see example below) .
  • the XMMAP message is a list of the mailboxes in the requested account. Request message example:
  • This method retrieves the mailboxes from an account when already logged in.
  • the message exchange is quite similar to the login-methods. The request can however be stripped down to ⁇ Account /> or completely omitted since the user is already logged in, and the account information is stored within the session.
  • This is the message for retrieving mail message content.
  • the request message must provide the name of the mailbox and message number (s) . Note that the content of the eventual attachments are not initially sent, but only the information describing them. The user can then choose to download them later using the "getAttachmentsAsXMMAP" method.
  • This method can be invoked to get the content of an attachment.
  • the client will have received a description of the attachment (s) from a call to the getMessagesAsXMMAP method, and uses the attachment number (s) to identify which attachment (s) within which message (s) it wants. Only the attachment (s) will be returned, the body content is omitted.
  • IMAP/POP server The method returns nothing, except from error messages if something goes wrong. Note: setting the DELETED flag with setFlags marks the message as deleted, but keeps it in the mailbox. For permanent deletion, see the delete method.
  • This SOAP method marks a message as deleted, or deletes it permanently (also called expunging) from the IMAP/POP server. Whether or not to expunge is given as a parameter to the method call. The default is not to expunge. The method returns nothing, except from error messages if something goes wrong. Request message example:
  • the Web Service sends the final message to the users "sent" box and marks messages as "Answered” in the current mailbox if the message is a reply (given by a ⁇ ReplyNumber' element together with the headers) .
  • Setting several ⁇ To>, ⁇ Cc> or ⁇ Bcc> headers in the request message adds multiple recipients in XMMAP. These headers are parsed by the Web Service and converted to SMTP on its outgoing interface.
  • a RFC2822 compliant message are also created by the Web Service from the information received before it is sent to its final destination by SMTP (see Figure 11 is showing the messaging occurring between participating components when sending an e-mail using XMMAP) .
  • the server needs no more information than the session id.
  • the logout call is a SOAP message with empty body.
  • the methods briefly described here is only a limited subset of the most important methods that can be implemented by coupling SOAP and XMMAP for email access on mobile terminals. There is in principle no limitation in what additional methods that may be implemented.
  • the XMMAP format is flexible, and can be extended by new elements in any part of the format if found convenient. There is no fixed order in how the current messages are sent after the user has logged in. When defining new methods, this principle should be followed in order to keep every message independent from both previous and succeeding messages.
  • FIG. 10 shows our architecture, and its different software layers and interfaces.
  • the Web Service Client (WS Client) needs support for SOAP and J2ME [3] as with the other proposed solutions.
  • the client this solution only needs a Mail User Agent (MUA) capable of XML document creation and parsing, as well as for sending and receiving XMMAP messages.
  • UUA Mail User Agent
  • Every operation on the client does only require one XMMAP message sent to the web service, and one message in return.
  • the WS Engine interprets the message client request, does the required communication with the IMAP/POP/SMTP server, 2005/117372 32
  • Figure 11 shows the interaction between some of the components from Figure 10 when a mobile client sends an e- mail using the web service. We see how the SMTP interaction is stripped down to one message for the client.
  • the web service will adapt the mail messages for mobile terminals like cellphones and PDA's. This is achieved by removing unnecessary email headers. Alternative representations on the same content (e.g. both plain text and HTML representations of the message body) is reduced to one. Attachments are by default kept back until the user specifically asks to get them. These actions keep the amount of data transmitted and the number of message exchanges to a minimum.
  • Session management for all interfaces and related active connections .
  • Content adaptation This includes everything from tag and attachment stripping to picture resizing.
  • Interfaces Provide necessary interfaces (see Interfaces section) .
  • the XML Web Service should provide these interfaces:
  • the XML Web Service will do the necessary communication with the MSA/MTA when sending email. In order to make this work, it has to do all communication with the MTA using the SMTP protocol.
  • POP/IMAP interfaces Necessary for retrieving mail, and manipulation mail account. Should also have TSL/SSL support .
  • SOAP/XMMAP interface This interface is used for communication with the client, and is thoroughly described in this document.
  • SOAP interfaces One or more interfaces for communication with other XML Web Services. Examples of may be special content filtering services as spam and virus filters .
  • the XML Web Service should have a fast connection to all interfaces so there will be minimal delays in web service- to-mail server communication. All interfaces should provide support for encrypted communication using SSL/TLS.
  • the content is automatically adapted to fit the terminal by using information sent by the client software about display dimensions and color support etc. Unnecessary information is stripped away by the web service before replying to the client .
  • Session timeout is a problem when working with services requiring authentication. Especially when accessing the Internet via a GPRS network, the GPRS/Internet gateways tend to have a short timeout periods. Reestablishment after a timeout often implies assignment of a different IP address, making all session on higher layers invalid. This problem is solved when using SOAP sessions, ensuring session mobility.
  • This invention does impose more requirements on mobile phones in terms of processing and storage capabilities.
  • SOAP and XML introduces overhead itself, eating much of the savings gained when using XMMAP.
  • this will require extra processing capacity on the client. This may potentially imply slow access on clients.
  • the XMMAP request XML-document may get unnecessary large. For example when only needing to send a mail ID, additional XML-tags are also sent according to the XMMAP standard.
  • Mail retrieval may be slow, since this very much depends on the connection to the remote mail server, which may be slow itself. As long as the connection to the mail server actually is faster than the one to the client, caching is possible. This may be caching of messages when fetching headers, and/or attachments when retrieving the messages. The content will then be preprocessed and ready for transfer when the potential request for it arrives.
  • the e-mail web service can also be configured to work as an MTA, allowing forwarding of e-mails between different instances of the web service.
  • the web service is not limited to mobile devices, any device with internet access and an XMMAP/SOAP capable client can access it.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système, un procédé et un protocole de transfert de messages vers et à partir d'un terminal mobile d'un serveur de messagerie électronique. Les courriers électroniques sont transférés au moyen d'un serveur de service de messagerie électronique équipé d'une interface SOAP vers le terminal mobile et d'interfaces POP/IMAP/SMTP communes vers le serveur de messagerie électronique.
PCT/NO2005/000175 2004-05-28 2005-05-27 Procede, format de protocole et systeme de communication mobile de courriers electroniques WO2005117372A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO20042233A NO323223B1 (no) 2004-05-28 2004-05-28 Et system, en fremgangsmate og protokoll for mobil e-post-kommunikasjon
NO20042233 2004-05-28

Publications (1)

Publication Number Publication Date
WO2005117372A1 true WO2005117372A1 (fr) 2005-12-08

Family

ID=34969647

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NO2005/000175 WO2005117372A1 (fr) 2004-05-28 2005-05-27 Procede, format de protocole et systeme de communication mobile de courriers electroniques

Country Status (2)

Country Link
NO (1) NO323223B1 (fr)
WO (1) WO2005117372A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2144408A1 (fr) 2008-07-09 2010-01-13 Research in Motion Limited Optimisation de la livraison de messages de courrier électronique contenant des versions alternatives de contenu
CN104718728A (zh) * 2012-05-31 2015-06-17 Streamwide公司 应要求投递电子邮件的方法,电子邮件服务器以及实施所述方法的电脑程序

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020116465A1 (en) * 2001-02-19 2002-08-22 Samsung Electronics Co., Ltd. System and method for providing multimedia electronic mail service in a portable terminal
US20030028606A1 (en) * 2001-07-31 2003-02-06 Chris Koopmans Service-based compression of content within a network communication system
EP1284570A2 (fr) * 2001-08-13 2003-02-19 Research In Motion Limited Système et procédé permettant de transferer des informations chiffrées dans un dispositif de communication de données mobile à partir d'un système hôte
US20030158902A1 (en) * 2001-10-31 2003-08-21 Dotan Volach Multimedia instant communication system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020116465A1 (en) * 2001-02-19 2002-08-22 Samsung Electronics Co., Ltd. System and method for providing multimedia electronic mail service in a portable terminal
US20030028606A1 (en) * 2001-07-31 2003-02-06 Chris Koopmans Service-based compression of content within a network communication system
EP1284570A2 (fr) * 2001-08-13 2003-02-19 Research In Motion Limited Système et procédé permettant de transferer des informations chiffrées dans un dispositif de communication de données mobile à partir d'un système hôte
US20030158902A1 (en) * 2001-10-31 2003-08-21 Dotan Volach Multimedia instant communication system and method

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BORDEN J: "XML MIME Transformation Protocol (XMTP)", 6 April 2004 (2004-04-06), pages 1 - 4, XP002342219, Retrieved from the Internet <URL:http://web.archive.org/web/20040406050718/http://www.openhealth.org/documents/xmtp.htm> [retrieved on 20050818] *
CRISPIN M: "Internet Message Access Protocol - version 4rev1, RFC 2060", IETF, REQUEST FOR COMMENTS, December 1996 (1996-12-01), XP002122132 *
MOE J-F ET AL: "Adapting Email Functionality for Mobile Terminals", PROCEEDINGS OF IFIP INTERNATIONAL CONFERENCE ON INTELLIGENCE IN COMMUNICATION SYSTEMS, INTELLCOMM 2004, 23 November 2004 (2004-11-23), Berlin, Germany, pages 199 - 206, XP008051312 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2144408A1 (fr) 2008-07-09 2010-01-13 Research in Motion Limited Optimisation de la livraison de messages de courrier électronique contenant des versions alternatives de contenu
US8862673B2 (en) 2008-07-09 2014-10-14 Blackberry Limited Optimizing the delivery of email messages containing alternative versions of content
CN104718728A (zh) * 2012-05-31 2015-06-17 Streamwide公司 应要求投递电子邮件的方法,电子邮件服务器以及实施所述方法的电脑程序
EP2856708B1 (fr) * 2012-05-31 2017-04-26 Streamwide Procédés de délivrance de courriels à la demande, serveurs de courriels et programmes d'ordinateur mettant en oeuvre de tels procédés

Also Published As

Publication number Publication date
NO20042233D0 (no) 2004-05-28
NO323223B1 (no) 2007-01-29
NO20042233L (no) 2005-11-29

Similar Documents

Publication Publication Date Title
US9961042B2 (en) Universal mobile device messaging
US20060095511A1 (en) Messaging protocol
US20030193951A1 (en) Method, apparatus and system for processing multimedia messages
US8611936B2 (en) Display of secure messages on a mobile communication device
US20080294729A1 (en) Email object for open mobile alliance data synchronization usage
CA2567315A1 (fr) Protocole de messagerie pour traiter des messages avec des pieces jointes
EP1469643B1 (fr) Dispositif et procédé pour faire suivre des courriers électroniques
WO1999014909A1 (fr) Systeme de messagerie
WO2011103748A1 (fr) Procédé et terminal de communication mobile pour la gestion de courriers électroniques
KR100472441B1 (ko) 인터넷 메일장치의 선택된 전자메일 수신방법
JP2009169866A (ja) 電子メールクライアントおよびその制御方法ならびにコンピュータプログラム
WO2005117372A1 (fr) Procede, format de protocole et systeme de communication mobile de courriers electroniques
EP1305725B1 (fr) Systeme de compte de messagerie instantanee
KR20030055817A (ko) 메일 헤더 정보를 이용하여 선택적으로 메일을수신/삭제하는 메일 관리 방법 및 메일 클라이언트 단말기
JP2007011879A (ja) 電子メール配信方法および電子メール配信システム
JP5255915B2 (ja) メール送信処理方法及び通信端末装置
Moe et al. Adapting email functionality for mobile terminals
DO VAN THANH et al. Reading emails on mobile phones
KR100453936B1 (ko) 다중수신 확인이 가능한 전자우편시스템 및 이의 방법
JP2005182543A (ja) 電子メールシステム
Sivertsen et al. ENABLING MOBILE EMAIL ACCESS WITH XML WEB SERVICES
Karnouskos et al. Active electronic mail
LEGGIO et al. An analysis of instant messaging and e-mail access protocol behavior in wireless environment
Van Thanh et al. Email access via mobile phone
Healy et al. Unified Internet Messaging

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase