WO2005104422A1

WO2005104422A1 - Electronic message authentication process

Info

Publication number: WO2005104422A1
Application number: PCT/AU2005/000560
Authority: WO
Inventors: Sydney Gordon Low; Matthew Iain Walker
Original assignee: Alien Camel Pty Ltd
Priority date: 2004-04-23
Filing date: 2005-04-21
Publication date: 2005-11-03

Abstract

An electronic message authentication process, including providing authenticating data for a first party, authenticating a transport session with the first party on the basis of the authenticating data, receiving at least one electronic message for at least one second party from the first party during the transport session, digitally signing the electronic message using a party certificate, and sending the signed message to the second party.

Description

ELECTRONIC MESSAGE AUTHENTICATION PROCESS

The present invention relates to an electronic message authentication process, and a system for enabling authentication of received messages, such as emails.

Background

The absence of any true centralised control of the Internet, and the open nature of the protocols that support it, are characteristics that have lead to its rapid adoption, but also have given rise to considerable abuse and fraud. This is acutely illustrated in use of the network to send unsolicited messages whilst masking or "spoofing" the identity of the sender. For example, protocols, such as SMTP, that allow the transmission of emails between computers on the Internet, allow messages to be sent with headers, such as in the "from" field, that do not provide an indication as to the true location from which the emails have been sent and often do not represent a valid return address. This allows parties who send unsolicited emails, most of which are commonly referred to as "Spam", to remain fictitious and anonymous. Another significant problem is spoofing of emails so as to represent the message as coming from another party, such as a financial institution or a reputable ecommerce site, and soliciting the entry of personal information and account details. This type of spoofing scam is considerably more serious and is known as "phishing". A number of banks, such as Citigroup, Lloyds, TSB, Barclays, the Bank of America, and the ANZ Bank of Australia, have been the subject of phishing attacks where emails have been sent which appear to have come from the banks and request customer account, debit and credit card data.

A number of developments have been introduced and proposed to address the problems posed by the unsolicited and fraudulent messages currently being sent. For example, software has been developed by a number of parties to filter Spam received by email clients. The filters may be installed on a client machine, a receiving mail server (which may be maintained by an Internet service provider (ISP) or within a local area network) or major mail serving nodes within the communications backbone of the Internet. Whilst the Spam filters are successful to a certain degree, and are able to eliminate a relatively high percentage of Spam, a filter is yet to be produced that is able to eliminate all unsolicited email without also filtering valid messages.

Systems have also been developed to certify an email as being authentic or valid, primarily on the basis of authenticating or verifying the sender. Most email clients, such as Microsoft Outlook Express, Microsoft Outlook 2000 and Apple's Mail.app application, support the S/MLME (Secure/Multipurpose Internet Mail Extensions) standard which provides a protocol that enables digital signatures, certificates and encryption to be added to the MIME format. This allows senders of emails to digitally sign their emails so that they can be authenticated and verified by a receiver. This facility, however, is under utilised by users of email clients, and unfortunately is also open to abuse. The emails can be signed with a digital certificate obtained from a certification authority ("CA"), such as VeriSign Corporation. Whilst some CAs apply rigorous processes concerning determining the identity of parties requesting a digital certificate, others unfortunately do not. For example, a personal email digital certificate can be obtained from Thawte Technologies Inc (http ://www.thawte . conϊ) using a relatively simple procedure without any offline verification.

Another significant problem in sending digitally signed emails in large corporations is managing the security and safeguarding of the digital certificates. Typically, the sender of an email requires the certificate to be stored on his computer. This poses serious security issues if the computer is stolen or the certificate is improperly copied and used by another email sender. Furthermore, in many situations such as centralised call centres, many computer operators may send emails with the same email address, eg siipport@cornpanv.com. For all these emails to be digitally signed, each computer requires a copy of the digital certificate, thereby increasing the risk of certificate theft or loss.

Furthermore, the manner in which the current email clients indicate that an email has been digitally signed is by the display of a seal logo that most users either neglect, ignore or are unaware of what it represents. The seal logo needs to be clicked on by the recipient of an email to display information on the owner of the digital signature that sent the email and any certificate used when signing the email.

A number of solutions have been proposed to address phishing, such as those proposed by the Anti-Phishing Working Group (nttpV/www.antipliishing.orgX These include providing web site authentication using physical tokens (such as a smart card), using client software to verify the authenticity of web sites, and digitally signing all emails using S/MLVIE, as discussed above. For the latter approach, the digitally signed emails will be either verified by the client or a gateway using the standard processes for the S/MLVIE standard. All of these approaches suffer the difficulties discussed above, are impractical to implement or do not address the spoofing problems. Accordingly, it is desired to address this or at least provide a useful alternative.

Summary

In accordance with the present invention there is provided an electronic message authentication process, including: providing authenticating data for a first party; authenticating a transport session with said first party on the basis of said authenticating data; receiving at least one electronic message for at least one second party from said first party during said transport session; digitally signing said electronic message using a party certificate; and sending the signed message to said second party.

The present invention also provides an electronic message authentication process, including: generating a limited digital certificate for a first party, said limited certificate being valid for a limited purpose; and digitally signing an electronic message for a second party from said first party with said limited certificate and sending the signed message to said second party.

The present invention also provides a message server for performing the steps of the authentication process.

The present invention also provides a message server system for performing an electronic message authentication process, including: a message transfer module for receiving and sending electronic messages using a transport layer protocol; and an authentication module for providing authenticating data for a first party, authenticating a transport session with said first party on the basis of said authenticating data, processing at least one electronic message for at least one second party from said first party during said transport session, digitally signing said electronic message using a party certificate, and allowing the signed message to be sent to said second party.

The present invention also provides a client process, executed by a client device, including: receiving a digitally signed electronic message; and generating a certificate notification on determining said message as being signed with at least one digital certificate, said notification providing information on authenticity of the message based on data of said certificate.

The present invention also provides computer program instructions for performing said client process which can be integrated into email client or web mail software.

The present invention also provides a message provider process, including: receiving a digitally signed electronic message; and generating a certificate notification on determining said message as being signed with at least one digital certificate, said notification providing information on authenticity of the message based on data of said certificate. Brief Description of the Drawings

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

Figure 1 is a block diagram of a preferred embodiment of an email authentication system;

Figure 2 is a flow diagram of an authentication process performed by a relay server of the system;

Figure 3 is a flow diagram of a TLS session authentication process performed by the relay server;

Figure 4 is a flow diagram of a username and password generation process performed by the relay server;

Figure 5 is a flow diagram of a SMTP AUTH session authentication process performed by the relay server; Figure 6 is a flow diagram of a token generation process performed by the relay server;

Figure 7 is a flow diagram of a session token authentication process performed by the relay server;

Figure 8 is a flow diagram of a limited certificate generation process performed by the relay server; Figure 9 is a flow diagram of a certificate interface generation process performed by an email client of the system;

Figure 10 is a certificate notification generation process performed by a server of a web mail provider of the system;

Figure 11 is a screen display showing a window produced by an email client plugin of the system;

Figure 12 is another screen display produced by an email client plugin of the system; and

Figure 13 is a screen display produced using a web mail authentication module of the system. Detailed Description of the Preferred Embodiments

An electronic message authentication system, as shown in Figure 1, includes a relay server 100 that communicates with other electronic messaging servers 102 to 110 over a public communications network. The relay server 100 is able to receive messages from the servers 102 to 106 and once the messages are authenticated, digitally sign the messages and forward them onto other servers 108 to 110, so that the messages can be collected using a client device 120. For the purposes of the description below, the servers 100 to 110 are all described as being SMTP (Simple Mail Transfer Protocol) servers, and the client device, a personal computer running an email client 182, such as Microsoft Outlook or Apple Mail email software. It will of course be appreciated that the servers could be other messaging servers, such as SMS servers, and the client device 120 could be another computer device, such as a mobile phone or PDA. The communications network is therefore described as being the Internet and as using the various Internet protocols, such as SMTP, POP and IMAP and S/MEvIE. The SMTP servers 100 to 110 each include a mail transfer application 121, such as Sendmail or Microsoft Exchange, to implement SMTP. A web mail server 110 also includes web server and associated code 168 to allow the client machine 120 to access messages using an Internet browser 186. Web mail servers are used by mail providers such as Microsoft Corporation (http://www.hotmail.com and Yahoo Inc. (http://mail.yahoo.com) to offer users an email service accessible via a web browser. The relay server 100 also includes a web server 122, such as Apache (http://www.apache.org). an authentication module 140 provided by computer program instructions in languages, such as Java (http ://www.j ava. sun. com) and Perl (http://www.perl.org), and a database server 142 provided using software, such as MySQL4 (http://www.mvsql.org). which are all run on an operating system, such as the Linux OS (http ://www. linux. org), on a standard computer 150, such as a PC server (http://www.ibm.com). As will be understood by those skilled in the art, the components 121 to 142 of the server 100 can also be placed on a number of distributed computers connected by the communications network, and the processes executed by the components can also be executed at least in part by dedicated hardware circuits, eg ASICs. The SMTP server 102 of a bank and the SMTP server 104 of an airline can be used to send an email message to customers using the customer email addresses maintained in their databases. A customer is able to use the email client 182 of the computer 120 to access the email using POP or IMAP from the mail server 108 of an Internet service provider (ISP). Alternatively, the customer can use a web browser 186, such as Internet Explorer, of the computer 120 to access the email, using the hypertext transfer protocol (secure: HTTPS or standard: HTTP), from the web server 110 of a web mail provider. A service bureau is also able to use an SMTP server 106 to send an email to customers on behalf of, for example, a second bank or an auction site, such as eBay (http ://www. ebay. com) . In this case the email messages originate from the service bureau mail server 106 which sends out emails on behalf of the second bank or auction site. These messages typically contain the "from" address of the bank or auction site, however it could also contain the "from" address of the service bureau. The text of the message to be bulk emailed may be sent to the service bureau server 106 from servers 112 and 114 of the second bank and the auction site. The email addresses to be used may also be sent from the servers 112 and 114 to the service bureau server 106. Whilst the first bank and the airline can be identified using the IP addresses associated with their servers 102 and 104, the second bank and the auction site cannot be so discriminated, as email originating from the service bureau server 106 would have the IP address assigned to the server 106 in the SMTP messages transmitted. In any event, it is undesirable to rely solely on an IP address, as a person launching a phishing attack can fake the IP addresses of the originating SMTP servers if they are known and fraudulently represent themselves as another sending party, eg a bank, airline or auction site provider.

The relay server 100 under the control of the authentication module 140 executes a message authentication process generally as shown in Figure 2. When a sending party wishes to use the email relay service provided by the relay server 100, the party initially needs to be authenticated and a party digital certificate and private key obtained for the party at step 202. Whilst the party can be authenticated using an online process, normally the party would be authenticated offline using a rigorous identification validation process. This involves the sending party, such as the first and second bank, the airline or the auction site provider, establishing to the satisfaction of the operator of the relay service that they have the identity that they claim to possess. Once the identity has been validated, and the party authenticated, the relay server 100 needs to receive a digital certificate with the private key for the sending party. This party certificate can be provided by the operator of the relay service after the party is authenticated, or the sending party may already have had the certificate issued by a CA. The certificate needs to include the party's name and email address corresponding to those authenticated during the sending party authentication process 202. The digital certificate complies with the ITU-Standard X.509 for public key infrastructure and can be as specified in RFC 2459 (http ://www.ietf . or /rfc/rfc2459.txt) . Once the relay server has completed step 202 and received and stored the party certificate with the private key, then the relay server can be used for a bulk email campaign for the sending party.

To commence an email campaign, a sending mail server 102, 104 or 106 needs to establish an authenticated transport session with the relay server 100 (step 206). This is achieved by the relay server 100 executing processes of the authentication module 140 that rely on one or more of the following:

(i) A transport certificate provided to the sending server 102, 104 or 106. The transport certificate is an X.509 digital certificate used when connecting the SMTP server 102, 104, 106 to the relay server 100 using the Transport Layer Security (TLS) protocol. The transport certificate may be the party certificate or another X.509 certificate issued to the message transport party controlling the sending server 102, 104, 106 using an identification verification process similar to that (step 202) described above for the sending party obtaining the party certificate. A separate transport certificate is advantageous in situations where it is to be stored on a machine that is not as secure as what is required by the sending party for storage of the party certificate. (ii) A username and password for the message transport party for connecting the SMTP server 102, 104, 106 to the relay server 100 using the SMTP AUTH protocol.

(iii) A secret token provided to the message transport party for use in the email headers of the sent emails so that the received emails can be authenticated, as described below.

(iv) A hash process based on the content of the email excluding variable content, such as first names and last names,

(v) A virtual private network (VPN) tunnel between the sending server 102, 104, 106 and the relay server 100.

Once the relay server 100 has authenticated transport of the emails received from one of the SMTP servers 104 to 106 (step 206), the received emails for the campaign are each digitally signed at step 208. The emails are each signed with at least the party certificate. The emails may be signed by the party certificate and a limited digital certificate, as discussed below. When two certificates are used, the received email is separately signed by each certificate. Once the message is signed (step 208), the message is then sent using SMTP to the destination address at step 210. If the transport session for the emails is not authenticated at step 206, then the SMTP session with the server 104 to 106 is disconnected, and the relay server 100 does not accept any emails from the disconnected server.

When a messaging campaign commences that uses the transport certificate and TLS to authenticate the session, the sending server 102 to 106 first initiates an SMTP session with the relay server 100, as shown in Figure 3 at step 310. The TLS protocol used is as specified in RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt). The SMTP connections established during the session use TLS to send messages for the campaign to the relay server with the transport certificate. The authentication module 140 of the relay server 100 controls the TLS session (step 310) and on receipt of a request to establish a TLS session from the sending server 102 to 106 seeks to confirm the IP address of the sending SMTP server, at step 320. If the IP address is valid, then the transport certificate used to establish the TLS session is extracted (step 330) and checked to determine if it is valid (step 332). The TLS session will be determined authentic or valid if it originates from the expected sender IP address issued for the transport certificate. Also it may be necessary for the session to be established within a restricted time period. If the TLS session is considered to be valid, then all email messages received during the session are considered to be authenticated and as having actually been sent by an authenticated transport party. The authentication module then proceeds to step 340 where every message is signed using the party certificate for the sending party. The signed messages are sent by the relay server 100 to a mail server 108 or 110 for collection by customers using their client computers 120.

Alternatively the authentication module 140 of the relay server 100 can use the SMTP AUTH extension to the SMTP protocol, as specified in RFC2554 SMTP Service Extension for Authentication (http://www.ietf.org/rfc/rfc2554.txt). to authenticate the transport session. The SMTP AUTH process initially involves receiving a request (step 410) for a username and password corresponding to a "from" email address of an organisation, such as support(α),westpac.com. The request can be received from a transport party by an administrator logging onto a HTTPS web site provided by the web server 122 of the relay server 100. The site provides forms which can be submitted with the email address and organisation details in order to be provided with the username and password. The username and password is generated at step 412 and then transmitted back to the transport party over the secure HTTPS link. The transport party then configures the SMTP mail server 106 to 110 to relay messages from the particular "from" email address of the said organisation via the relay server 100 using the username and password generated at step 12. The server 106 to 110 is then able to send the username and password combination so the relay server 100 can authenticate a transport session with the server 106 to 110. Encrypted methods of SMTP AUTH, such as CRAM-MD5, can be used so the username and password are not sent in clear text and are protected from interception. When a mail campaign commences that uses SMTP AUTH, the session commences at step 510, as shown in Figure 5. The username and password for the SMTP server is processed at step 550. The SMTP AUTH username and password will only be determined authentic or valid if the connection originates from the expected sender IP address issued for the username and password combination. The combination may also need to be used within a restricted time period. If the SMTP AUTH username and password and the IP address is determined to be valid (step 552), the relay authentication module 140 proceeds (step 554) to sign the email messages using at least the party certificate and then send them to the destination address.

An alternative to TLS and SMTP AUTH to authenticate the transport session is for the authentication module 140 of the relay server 100 to instead execute a token process, as shown in Figure 6 and 7. The token process involves receiving a request (step 610) for a time limited token corresponding to a "from" email address of an organisation, such as support@westpac.com. The request can be received from a transport party by an administrator logging onto a web site provided by the web server 122 of the relay server 100. The site provides forms which can be submitted with the email address and organisation details in order to be provided with the limited token. The token is generated at step 612 and then transmitted back to the server 106 to 110 identified by the "from" address. The server 106 to 110 is then able to embed the token in the header of any email sent to the relay server 100.

When an SMTP session is established, as shown in Figure 7, the relay authentication module 140 detects the token at step 750 as being embedded in the header field of the email sent by the server 106 to 110. A check is then made to determine (step 752) whether the embedded token is valid such as comparing the expected IP address of the SMTP server against the actual IP address, and the existence of other expected header fields, and the message being received within the restricted time period, and then the token is deleted from the email message. If the token is valid, the relay authentication module 140 proceeds (step 754) to sign the message using at least the party certificate, which is then sent to the customer.

Another alternative for authenticating the transport is to create and use an authenticated and encrypted virtual private network (VPN) between the sending server 106-110 and the relay server 100 or between the networks they reside on. The VPN ensures that the IP address information of the sending server is correct and can only be used exclusively by the authentication module 140 of the relay server 100. The authentication of the VPN requires the exchange of certificates and/or username and password information and the coordination of IP address and firewall configurations in order that the authenticity of the IP addresses of received messages can be guaranteed. During a transport session, if the IP address is valid and is recognised as one that uses the VPN, the relay authentication module 140 proceeds (step 208) to sign the messages using at least the party certificate. The VPN uses dedicated switches and/or routers to essentially provide a hardware component based process used between the sender server 102 to 106 and the relay server 100 to authenticate the transport session (206)

To help a recipient of an email authenticate the email, and to assist with enhancing security for the email sent as part of a campaign, the emails can be additionally signed with a limited certificate. To obtain a limited certificate for an email campaign, a sending party first connects to the relay server 100 by using HTTPS and presents the party certificate, if not already received, or their username and password, as shown in Figure 8 (at step 802). They then undergo a verification process at step 804 where the certificate or username and password are compared to information stored for them in the authentication module 140. If this information is correct they are then authorised to create a campaign. The sending party then enters the information about the email campaign they wish to include in the limited certificate. The limited certificate corresponds to a "from" email address of a party, such as support@westpac.com. Other parts of a "from" header in a valid email from the party can also be used and validated against the limited certificate, such as the pretty name part of the "from" header. The sending or transport party logs onto a web site provided by the web server 122 of the relay server 100, and the site provides forms which can be submitted with the email address, organisation details and email campaign information in order to generate the limited certificate. Based on this information the authentication module 140 generates a limited certificate at step 806. This limited certificate is limited by conditions such as being valid for a particular sending and/or transport party, for a restricted time period, and for a specific purpose, ie a particular messaging campaign. The limited certificate complies with the ITU-T Standard X.509 for public key infrastructure and is as specified in RFC 2459 (http://www.ietf.org/rfc/rfc2459.txt).

A customer is able to use the email client 182 on the computer 20 to access the message from the mail server 108, as shown in Figure 9 (step 902). The retrieved message has the standard email headers, message body, a digital signature using the party certificate and may be another digital signature using the limited certificate. The email client is able to process the message according to S/MIME standards so as to generate the standard interface notifications, eg the seal icon, indicating that the message has been digitally signed using the party certificate. However if the customer has a plugin 184 installed on his computer, at step 904 the plugin 184 is able to detect and process the signature derived from the limited certificate (if it exists). The plugin retains information about certain known certificates and is also able to query, in real-time, certificate databases. The program instruction code of the plugin 184 causes generation (step 906) of a new window 1100, as shown in Figure 11, providing a certificate interface. The certificate interface displays information contained in the signature of the limited certificate that identifies the sender name, purpose of the email, and other authenticating information that the transport and/or sending party desires to be communicated to the recipient. Instead of a pop-up window 1100, the plugin 184 can alternatively include program instruction code to cause the email client to render an inline display 1200 containing the same information provided by the limited and party certificates when the message is opened, as shown in Figure 12. The plugin 184 can be made available to users using a number of distribution mechanisms, such as by download from particular sites, distributed disks or as an attachment to an email.

When a customer uses the HTTP browser 186 of client computer 120, to access their email using the web mail server 110, the server 110 executes a web mail certificate process, as shown in Figure 10. At step 1002, the web mail server 110 receives a message sent by the relay server 100, and uses a web mail authentication module 170 provided by the operator of the relay server 100 to detect and interpret the signature(s) (step 1004). The web mail server 100 uses the authentication module 170 to extract party information from the signing certificate(s) and add it to the body of the email, at step 1006. The email is then placed in a location and format where it can be accessed and presented to the client using the browser 186 (step 1008). The web mail authentication module 170 authenticates emails on the basis of the certificate(s) and then presents the email in HTML format as having been verified. This may be done (step 1008) by displaying a unique sender verification explanation code in the subject line for the email when the summary web page for a recipient's inbox is accessed by the client 120 or by displaying information from the signing certificate(s) in a frame 1300 surrounding the message once the message has been selected to be opened by the client 20, as shown in Figure 13.

It will be understood by those skilled in the art that the processes executed by the computer program instructions of the plugin 184, and the web mail authentication module 170 can also be executed at least in part by dedicated hardware circuits, eg ASICs or FPGAs.

The authentication system described ensures the electronic messages for a user of a client machine 120 provide identity information in a manner that cannot be fabricated by a party other than the sending and/or transport party, and allows the user receiving the messages to authenticate that those messages are from the sending party.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings. For example, the relay server 100 or operations of the authentication module 140 could be incorporated into the mail servers 102 to 106 and the operations undertaken on the relay server 100 could be distributed across a number of servers and/or a number of locations in order to provide better performance or redundancy.

Claims

CLAIMS:

1. An electronic message authentication process, including: providing authenticating data for a first party; authenticating a transport session with said first party on the basis of said authenticating data; receiving at least one electronic message for at least one second party from said first party during said transport session; digitally signing said electronic message using a party certificate; and sending the signed message to said second party.

2. An electronic message authentication process as claimed in claim 1, wherein said party certificate is for said first party or for a third party when said message is sent by said first party on behalf of said third party.

3. An electronic message authentication process as claimed in claim 1, including determining said message as being valid and from said first party, before said signing.

4. An electronic message authentication process as claimed in claim 3, wherein said determining is performed on the basis of network data for said message corresponding to data for said transport session.

5. An electronic message authentication process as claimed in claim 4, wherein said network data is a sender IP address.

6. An electronic message authentication process as claimed in claim 1, wherein the authenticating data is a digital certificate for said first party and the transport session is a Transport Layer Security (TLS) session.

7. An electronic message authentication process as claimed in claim 1, wherein the authenticating data is a username and password combination and the transport session is a SMTP AUTH session.

8. An electronic message authentication process as claimed in claim 1, including: sending a limited token to said first party as said authenticating data, said token being for said first party and for a limited time; and determining said message as being valid and from said first party, before said signing, when said message includes said token.

9. An electronic message authentication process as claimed in claim 1, including: generating a limited digital certificate for said first party or a sending party, said limited certificate being valid for a limited purpose; and digitally signing said electronic message using said limited certificate.

10. An electronic message authentication process, including: generating a limited digital certificate for a first party, said limited certificate being valid for a limited purpose; and digitally signing an electronic message for a second party from said first party with said limited certificate and sending the signed message to said second party.

11. An electronic authentication process as claimed in claim 9 or 10, wherein said limited certificate is valid for a predetermined time.

12. An electronic message authentication process as claimed in claim 9 or 10, wherein said limited purpose corresponds to the purpose of said message, and said second party is able to determine said purpose based on data of said limited certificate.

13. A message server system for performing an authentication process as claimed in any one of the preceding claims.

14. A message server system as claimed in claim 13, wherein said message server is an SMTP relay server.

15. Computer program instructions, stored on computer readable media, for performing an authentication process as claimed in any one of the preceding claims.

16. A message server system for performing an electronic message authentication process, including: a message transfer module for receiving and sending electronic messages using a transport layer protocol; and an authentication module for providing authenticating data for a first party, authenticating a transport session with said first party on the basis of said authenticating data, processing at least one electronic message for at least one second party from said first party during said transport session, digitally signing said electronic message using a party certificate, and allowing the signed message to be sent to said second party.

17. A message server system as claimed in claim 16, wherein said party certificate is for said first party or for a third party when said message is sent by said first party on behalf of said third party.

18. A message server system as claimed in claim 16, wherein authentication module determines said message as being valid and from said first party, before said signing.

19. A message server system as claimed in claim 18, wherein said authentication module determines said message as being valid and from said first party on the basis of network data for said message corresponding to data for said transport session.

20. A message server system as claimed in claim 19, wherein said network data is a sender IP address.

21. A message server system as claimed in claim 16, wherein said authentication module generates a limited digital certificate for said first party or a sending party, said limited certificate being valid for a limited purpose, and digitally signs said electronic message using said limited certificate.

22. A message server system as claimed in claim 21, wherein said limited certificate is valid for a predetermined time.

23. A message server system as claimed in claim 21, wherein said limited purpose corresponds to the purpose of said message, and said second party is able to determine said purpose based on data of said limited certificate.

24. A client process, executed by a client device, including: receiving a digitally signed electronic message; and generating a certificate notification on determining said message as being signed with at least one digital certificate, said notification providing information on authenticity of the message based on data of said certificate.

25. A client process as claimed in claim 24, wherein said at least one digital certificate includes a limited digital certificate valid for a limited purpose corresponding to the purpose of said message.

26. A client process as claimed in claim 25, wherein said limited certificate is valid for a predetermined time.

27. A client process as claimed in claim 25, wherein said at least one digital certificate further includes a party certificate for a sending party.

28. Computer program instructions, stored on computer readable storage media, for performing a client process as claimed in any one of claims 24 to 27.

29. An email client including computer program instructions as claimed in claim 28.

30. Web mail software including computer program instructions as claimed in claim 28.

31. A message provider process, including: receiving a digitally signed electronic message; and generating a certificate notification on determining said message as being signed with at least one digital certificate, said notification providing information on authenticity of the message based on data of said certificate.

32. A message provider process as claimed in claim 31, wherein said at least one digital certificate includes a limited digital certificate valid for a limited purpose corresponding to the purpose of said message.

33. A message provider process as claimed in claim 32, wherein said limited certificate is valid for a predetermined time.

34. A web mail provider system for performing a message provider process as claimed in any one of claims 31 to 33.