IES990985A2 - A secure electronic mail gateway - Google Patents

Abstract

A gateway (1) is connected in a local area network (3). It interacts with a local mail server (4) and remote servers via a firewall (5) and the Internet (6). It automatically generates certificates for senders on-the-fly. It also caches third party certificates so that they are available for sending encrypted and/or signed messages to remote recipients. The gateway (1) also automatically requests third party certificates on-the-fly when required for outgoing messages.

Description

INTRODUCTION Field of the Invention The invention relates to a secure electronic mail gateway to perform operations such as cryptography operations for users.

, Prior Art Discussion Encryption involves the conversion of an original plain-text, readable message to an unreadable form known as ciphertext. There are two commonly used encryption methodologies, symmetric encryption and asymmetric encryption.

Symmetric encryption or secret key encryption is the traditional or conventional method of cryptography. It is based on both the sender and receiver of a message knowing and using the same secret key to encrypt and decrypt messages. Symmetric encryption is also used for single user encryption, for example to encrypt files on a hard drive.

In symmetric encryption, an original plain text, readable message is converted using a symmetric algorithm, for example DES, and a secret key to an unintelligible, unreadable form known as ciphertext. The output ciphertext will depend on the specific secret key being used at the time and so changing the key causes substantial changes in the produced ciphertext. The ciphertext is then transmitted to the receiver. The receiver can transform the ciphertext back into the readable plain-text message OPEN TO PUBLIC INSPECTION UNDER SECTION 28 AND PULE 23 JNL. NOifcM.........OF.&2&1232?.. t&U- ^//2 ? IE 990985 -2by using the same decryption algorithm and the same secret key that was used for encryption.

The generation, transmission and storage of keys is called key management. Since symmetric cryptography involves only secret keys (keys that must be kept secret), providing secure key management and key transport in an open environment with a large number of users is a difficult task.

A problem in symmetric encryption is the reliance on both parties exchanging and using the same secret key. If the two parties reside in two separate physical locations, it is necessary to trust a courier or some other relatively insecure transmission medium to transfer the secret key.

This problem is overcome in “Asymmetric” or “Public Key” cryptography. In Asymmetric encryption, for example RSA, each person gets a pair of keys, one called the public key and the other called a private key.

The public key is generated from the private key using a complex algorithm. The private key can't however be derived from the public key so the public key can be freely distributed while the private key is kept secret. There is no longer a need for the sender and receiver to share a secret key.

To send a confidential message, one obtains the recipient's public key and encrypt the message using it. Only the intended recipient will be able to decrypt the message since only the intended recipient should hold the associated private key needed to decrypt the message.

In addition to providing privacy, asymmetric or 'public key' cryptography can also be used for authentication by providing digital signatures. When used for authentication, as a digital signature, the key roles are reversed. The message is IE 990985 -3signed (encrypted) by the sender’s private key. Since only the sender should hold their private key, this is like a personal signature. Anyone who has the sender's public key, which should be freely distributed, is able to decrypt the message and verify that the message came from the sender.

Heretofore, the cryptographic functionality has been provided in a manner whereby the user must take an active part in the cryptographic process. Thus, many people are put off using off using cryptography as it is perceived as being too awkward.

SUMMARY OF THE INVENTION According to the invention, there is provided an electronic mail gateway system comprising:15 means for interfacing with at least two mail servers to relay messages between them, and processing means for automatically encrypting messages and decrypting messages as they are relayed, transparently to senders and recipients.

In one embodiment, the processing means comprises means for generating a certificate-on-the-fly for an outgoing message.

In one embodiment, said means comprises means for automatically performing certification authority operations.

In one embodiment, said means comprises means for using a top certification authority certificate to sign user certificates on-the-fly.

• V In one embodiment, the system further comprises a certificate database storing user 30 certificates.

IE 990985 -4In another embodiment, certificates are linked in the database in a chain-of-trust hierarchy from the top certificate down.

In one embodiment, the certificates are identified in the database by a serial number and a fingerprint code.

In one embodiment, the processing means comprises means for automatically cacheing certificates of incoming messages.

In a further embodiment, the processing means further comprises means for using cached certificates for encrypting outgoing messages.

In one embodiment, the processing means comprises means for requesting 15 certificates of intended recipients on-the-fly for automatic encryption of outgoing messages.

In one embodiment, said interfacing means comprise means for communicating in a virtual private network.

In one embodiment, the processing means comprises a security policy database and means for accessing said database to determine cryptographic operations to be performed on messages being relayed.

In one embodiment, the security policy database defines security on a user domain basis.

In one embodiment, the domains include a local domain of users in a local area network including the gateway and users of a remote network having a gateway.

IE 990985 -5Preferably, the security policy database indicates an encryption policy for each domain of always encrypting, never encrypting, or only encrypting if a recipient certificate is stored in the gateway.

In one embodiment, the security policy database defines a signing policy for each domain.

In one embodiment, the signing policies are opaque signing, clear signing, or never signing.

In a further embodiment, the processing means comprises an administrator function comprising means for switching log events on or off.

In one embodiment, the events include diagnostics, mail processing, virtual private network traffic, pending traffic, performance warnings, encryption problems, and connection problems.

In another embodiment, the processing means comprises means for permanently switching on by default security alert, error condition, start up, and shut down events.

In one embodiment, the processing means comprises a cryptographic function for processing mail between incoming and outgoing directories.

In one embodiment, the cryptographic function comprises means for distinguishing between general outgoing mail and virtual private network outgoing mail.

In another embodiment, the processing means comprises a server function for listening for new incoming and outgoing messages and for storing them.

IE 990985 -6In one embodiment, the server function uses a registry DLL to retrieve configuration details from a registry.

In one embodiment, the processing means comprises a dedicated function associated with an incoming mail directory and for sending mail to recipients.

In one embodiment, the processing means comprises a dedicated function associated with an outgoing mail directory and being programmed to connect to a remote mail server.

In a further embodiment, the processing means comprises a dedicated retry function programmed to pick up messages from directories and place them in appropriate directories to be retried.

In one embodiment, the retry function is programmed to read retry configuration details from a registry.

In one embodiment, the processing means comprises a service control manager comprising means for activating said functions.

In one embodiment, said service control manager comprises means for re-activating a failed function without affecting the other functions.

DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:IE 990985 -7Fig. 1 is an overview schematic diagram showing the context of a gateway of the invention; Fig. 2 is a flow diagram illustrating a method of operation of the gateway; Figs. 3 and 4 are flow diagrams showing paths for outgoing and incoming messages respectively; Figs. 5 to 10 are sample screen displays illustrating operation of the system.

Description of the Embodiments Referring to Fig. 1 and 2, there is shown a gateway 1. The gateway 1 operates in a virtual private network (VPN) in which there are user workstations 2, a local area network 3, a mail server 4, and a firewall system 5. The firewall system 5 provides access to the Internet 6. The gateway 1 handles electronic mail for the users in a manner to provide excellent security without the need for the users to be aware of what is happening.

Referring now to Fig. 2, an overview of some of the important functions performed by the gateway 1 is described. A process 10 is carried out by the gateway 1 communicating with a second gateway 11. For illustrative purposes, “Bob” is a user connected to the gateway 10, and “Alice” is a user connected to a remote gateway 11.

The gateway 1 initially determines in step 12 if Bob is registered. If not, it automatically generates a key pair on the fly in step 13. This results in storage in the gateway 1 of a private key 14 and a certificate 15 for Bob. They are stored in a private key database and in a separate certificate database. Step 13 involves IE 990985 -8automatically performing the formal requirements for generation of a certificate in communication with a registering authority. These are described in more detail below.

The gateway 1 then checks if there is a certificate available for the recipient, Alice, in step 16. If not, in step 17 the gateway postpones transmission of the message and the postponed message is indicated by the numeral 18. In step 19 the gateway 1 transmits a signal requesting a certificate to the intended recipient. The request is received by the remote gateway 11 (Consus2.com) in step 20 and it stores the sender’s certificate 15 locally.

In step 22 the remote gateway 11 determines if there is a certificate for the recipient (Alice) and in step 23 it generates a key pair on the fly for Alice if one is not available. Step 23 results in storage of a private key 24 and of a certificate 25 for Alice.

In step 26 the remote gateway 11 transmits the certificate to the gateway 10 and it is received by that gateway in step 27. The certificate 25 is stored in a database for recipient certificates. The postponed message 18 and the sender private key 14 are then used to sign and encrypt the message in step 28 and it is transmitted.

It will thus be appreciated that the gateway 10 generates a certificate for a sender (a local user) on-the-fly as it acts as its own certification authority. The gateway also automatically requests third party certificates from proposed recipients on-the-fly in a manner which is transparent to the sender. He or she does not need to be aware of the fact that the local network does not store the recipient’s certificate.

Also, the gateway caches third party certificates for recipients (users of the remote system 11 and other remote recipients) as they arrive. This is also performed automatically and transparently to the user. These certificates are then available IE 990985 -9whenever a local user wishes to send an electronic mail to these recipients. For a particular electronic mail message, if there is no available recipient certificate, it is requested on the fly (step 18) and is then stored in the database. All of these steps take place transparently to the local users. Thus, the flow diagram of Fig. 2 illustrates many of the important functions of the gateway in one electronic mail communication.

At installation time, a system administrator generates a top level key pair and certificate. The private keys are stored in an encrypted form on the system hard drive. Access to these keys is controlled via a password-protected token, which is required at system start-up. The gateway automatically generates a key pair and certificate for each internal mail user the first time the gateway detects an e-mail from this user. The system administrator is notified of each new user processed in this way. This allows rapid and simple deployment of the gateway with minimal intervention from the administrator. Keys are generated with sizes of 512, 1024 or 2048 bits depending on administrator preference.

As a digitally signed message is received from an external user the gateway removes the digital certificate and stores it in a database for later use. Once again the administrator is notified to enable the trusting of the received certificate (and associated CA certificates). This certificate, once trusted, is then available for use by all internal users.

When deploying a secure e-mail environment, it is desirable to propagate public key information as widely as possible. The simplest way to do this is to digitally sign outgoing messages. The gateway supports both opaque and clear signing of messages to ensure interoperation with non-S/MIME clients.

The system administrator defines the security policy to be applied to outgoing messages at a domain level. This policy defines whether outgoing messages should IE 990985 • ίοgo in the clear, signed or encrypted. Where the policy states that a message must be encrypted, a signed message will be sent to the intended recipient. This message will ask the recipient to reply with a signed e-mail to facilitate secure transfer of the message. If a signed reply is not received within an administrator-defined period the message is not delivered and the sender notified.

The gateway supports the creation of mail VPN’s (Virtual Private Networks) between sites with the gateway deployed. In this environment, the gateway systems perform automatic certificate exchange when a recipient certificate is not available.

Fig. 3 shows the outgoing message path through the gateway. The gateway encrypts and/or signs all outgoing mail coming from the local LAN depending on the security policy defined in the policy database. Outgoing messages are collected by a gateway server function 35 and are passed to an Out directory 36 where the Crypto’s sending agent 37 secures them according to the security policy defined in a security database 38. The secured messages are placed in the OutCrypto Directory 40. The Sender Out picks up the message from the OutCrypto directory 40 and tries to connect to the remote server. If the SMTP connection is successful, the message is sent to the remote SMTP server. If unsuccessful, the message is placed in a Retry directory 41.

A Retry function 42 places the message in the OutCrypto directory 36 to be retried according to the defined Retry policy.

In order to encrypt the e-mail, The gateway needs to have the message recipient’s certificate in the database. If there is no certificate available, the message is also placed in the Retry directory, while a ‘signed’ certificate request is sent to the recipient. In this case the retry executable will place the message in the Out directory 36 to be picked up by the Crypto sending agent 37, which will test for the existence of the certificate. If the certificate is in the database, the message will be placed in the OutCrypto directory 40 and a Sender Out component 43 will try to send the IE 990985 - ii message. In this diagram, the steps 44 and 45 indicate the decisions regarding certification and a PKI agent 46 performs these operations using a key database 47.

Fig. 4 shows the incoming message path through the gateway. A gateway server 50 picks up any incoming mail entering the gateway domain from the Internet and places the mail in an In directory 51. Mail in the In directory 51 is picked up and processed by the a receiving agent 52. As indicated by the decision step 53, if the incoming mail is encrypted, the PKI agent 46 decrypts the mail using the recipient’s private key (the recipient will be an internal user on the LAN). The sender’s certificate will always be included in the sender’s signature. The sender’s certificate is stored in the database and the message is verified. The message is then placed in an InCrypto directory 54 to be sent by a Senderln component55 to the message recipient. If signature verification (step 56) fails, the message is still sent on to the recipient. The message header, however, has been altered to indicate that the message was not verified. In addition, The gateway provides the ability to send an extra notification message to either the recipient and/or the administrator informing them of the verification failure. This information can be specified in the gateway GUI, as indicated by the steps 57 and 58.

The gateway comprises five executables that can be run as separate NT™ services. The service can start at boot up time. A service control manager is responsible for starting and stopping all services. If one of the services fails, the service will restart it without affecting other parts of the system. The executables include: Crypto An executable or function that uses the functionality of a crypto DLL to process mail from the incoming and outgoing directories into the InCrypto and OutCrypto directories. Incoming mail is decrypted and/or verified. Outgoing mail is encrypted and/or signed according to preferences set via the GUL Two types of outgoing mail can be distinguished, general and VPN.

IE 990985 - 12Preferences may be set for each independently. The crypto executable uses a gateway registry DLL to retrieve configuration information from the registry and a gateway message DLL for message file I/O.

Server The Server executable listens for new incoming and outgoing messages and stores the messages in the In and Out directories accordingly. The server uses the registry DLL to retrieve configuration details from the registry and the message DLL for message manipulation.

Sender In This picks messages from the InCrypto directory and connects to the local mail server. It sends message to each recipient. Senderln uses the registry DLL to retrieve configuration details from the registry and the message DLL for message manipulation.

SenderOut This picks messages from the OutCrypto directory and connects to a local Domain name server and does a DNS lookup for each message recipient. For each recipient, SenderOut connects to the remote mail server and, if successful, sends the message to each recipient. SenderOut uses the registry DLL to retrieve configuration details from the registry and the message DLL for message manipulation. SenderOut provides the functionality to work with an external ‘smart relay’. If an ISP provides this service, the message is handed over to the ‘smart relay’ to perform the necessary DNS lookups.

IE 990985 -13Retrv The Retry executable uses the registry DLL to read configuration details from the registry. According to the retry interval and frequency defined on the GUI, Retry picks up messages from the retry directory and places them in the appropriate directories to be retried. Retry is also responsible for generating notification messages.

As shown in Fig. 5, the gateway GUI presents a single, well-designed entry point to the gateway features. The GUI consists of five tabs to navigate the management windows to define and maintain a security framework for the gateway. Each tab has a consistent set of buttons and text fields. Fig. 5 shows the gateway GUI with the Network Tab enabled. The GUI has seven text fields and two check boxes related to network connections to allow them to be configured.

The gateway needs information to connect it to its surroundings, for example, the IP address of the local mail server 4. The gateway is flexible enough to permit the use of either a smart relay or a DNS server to deliver its mail. A smart relay is capable of receiving all mail from the gateway domain and delivering it to the correct address. No local MX lookups are required.

If both sending options are specified, then the smart relay is only used if the DNS server is unavailable.

The GUI can be configured to send notification messages for the following reasons □ No certificate available: Send notification messages to the Administrator and/or Sender and/or Recipient □ Delivery failure: Send notification messages to the Administrator and/or Sender IE 990985 -14□ Incoming Message Failure: Send notification messages to the Administrator and/or Recipient The gateway is a multithreaded application capable of handling up to thirty two different incoming and outgoing e-mail messages at the one time. Server threads handle incoming messages and Sender threads handle outgoing messages. Senderln sends incoming mail to the local mail server while SenderOut sends mail over the Internet to remote SMTP servers. It is recommended that the threads be set to between 10 and 32 threads depending on network traffic.

The gateway implements a time-out feature. In the gateway server this is the maximum allowable time that: □ can elapse between stages of the SMTP protocol, □ can be taken to receive IK of message data In SenderOut this is the maximum time allowed to connect to a remote SMTP server. The default value is 80 seconds. This feature ensures that threads do not wait forever on stalled connections. The default timeout is 300 seconds for the Server and 80 seconds for the Sender.

Fig. 6 shows the gateway GUI with the Security tab enabledThe gateway uses standard option buttons to provide your choice of digest and symmetric encryption algorithm used in securing the mail messages. Non MIME messages can either be passed unsecured through The gateway or returned to the sender. The gateway defines a security policy by domain name. An encryption and signing policy can be applied to a particular domain.

IE 990985 -15The three different encryption policies are: □ Always: Always encrypt mail leaving the gateway domain. If the domain is a VPN domain and the recipient's certificate is not already stored, the gateway will automatically send a certification request for the recipient to the recipient's gateway along with the sender's certificate. In this way the certification request is handled transparently from the user.

If the domain is defined as having a general security policy the gateway will automatically send a certification request to the recipient instructing them to return a signed message to the gateway domain. The sender's message will try to be re-sent according to the details entered in the Retry Count / Interval on the Network Tab.

□ If possible: Only encrypt the message if the certificate is already stored.

□ Never: Never encrypt the message.

The three different signing policies for both VPN and General Policy security are; □ Opaque: Sign messages using opaque signing. Opaque signed messages cannot be accidentally altered in transit to the recipient. This is a problem that sometimes occurs with clear signed messages causing false tampering alerts. Non-S/MIME clients cannot read opaque signed messages.

□ Clear: Sign messages using clear signing. Clear signing allows the message itself to be readable to non-S/MIME clients while a signature attachment is ignored. S/MIME clients can verify the authenticity of the sender in addition to reading the message.

IE 990985 -16□ Never: Never sign the message The General Security policy can be applied to □ All domains □ Except: All domains Except the specified domains □ Only the specified domains Fig. 7 shows the gateway GUI with the User’s Node enabled All user certificates in the gateway database are linked and shown in a ‘chain-oftrust’ certificate hierarchy. The top level Certificate Authority (CA) certificate is generated and stored for the organization when the gateway is installed. As described above, a certificate is automatically generated and stored for each internal user when they send a message through the gateway. These user certificates are signed by the top level CA certificate. When an individual certificate is selected, the individual fields in that certificate are shown in the Certificate Information box. Each certificate has an associated fingerprint code such as that illustrated. The fingerprint is used with the gateway VPN's as an out-of-band verification of certificate authenticity.

The serial number together with the fingerprint uniquely identifies the certificate in the database. The trust button allows the Administrator to trust a selected certificate. A trusted certificate is symbolized by a tick mark. The distrust button allows the Administrator to distrust a selected certificate. A distrusted certificate is symbolized by “ x”. The Delete button deletes the certificate from the database and from the trust hierarchy view.

IE 990985 -17An entity can still exist in the database after its certificate has been deleted. The compact button deletes any entities from the database that have no certificates. The Reload button refreshes the Manager's view of the trust hierarchy of certificates in the database.

Specific gateway events are logged by the NT Event Viewer Application Log.

Fig. 8 shows the gateway GUI with the Report Logging Tab enabled The Event Viewer is located in Start / Programs / Administrative Tools / Event Viewer. From within the application log in the Log menu, the gateway events can be filtered (View / Filter Events). The gateway events can be further filtered for each gateway component/module.

The gateway provides seven event categories that can be switched on/off by the Administrator. These are: □ Diagnostics: Provides very low-level implementation type messages. Used only for serious troubleshooting.

□ Mail Processing: Event messages concerning the interaction between the SMTP protocol sessions.

□ VPN Traffic: Event messages concerning VPN traffic for example, certification requests/reply’s.

□ Pending Traffic: Event messages concerning messages waiting to be sent.

□ Performance Warnings: Event messages concerning performance problems IE 990985 • 18□ Encryption Problems: Event messages concerning encryption □ Connection Problems: Event messages concerning connection The gateway provides three categories of events that are always written to the event viewer. These are: □ Security Alerts: Messages from events that compromise the security of the . gateway io □ Error Condition: High-level error handling event messages.

□ Start Up / Shut down: Event messages concerning the start up and shut down of the gateway modules.

The gateway provides the following option buttons to provide the Administrator with a convenient configuration for choosing the appropriate event categories to be written to the NT event viewer.

□ Minimum: In addition to the three event categories that are always logged, the minimum configuration consists of performance problems, encryption problems and connection problems □ Typical: In addition to the three event categories that are always logged, the typical configuration consists of VPN traffic, pending traffic, performance problems, encryption problems and connection problems.

□ Debug: All categories are checked so that every possible message is written to the event viewer.

IE 990985 -19□ Custom: Clears all the category check boxes so that the Administrator can choose the appropriate options.

The gateway supports the ability to 'plug-in' third party virus scanners.

Fig. 9 shows the gateway GUI with the Virus Scanner Tab enabled. The gateway supports virus scanners. The full path to the where the Virus Scanner executable is found, is inserted in the Directory text box.

The different options for each virus scanner are shown in the Command Line Arguments text box. The gateway provides a default set of command line switches for each virus scanner, however, these can be changed if needed, for example, if a newer version of the scanner requires it.

The gateway generates a top Certificate Authority (CA) at install time. This allows an organization to certify its internal users quickly without the need for an external CA. The information required by the gateway to generate the top CA is shown in Fig. 10. By certifying the user certificates, the top CA certificate is used to 'sign' or verify the identity of others within your LAN, which are using the gateway e-mail encryption gateway. If the top CA is deleted, the certificates signed by the CA, which are lower in the trust hierarchy, are also deleted. In the screen of Fig. 10: Organization refers to the name of your organization Organizational Unit is the name of your organizational unit or branch Country is the two-digit code representing your country The Setup dialog box shown is also used to configure the strength of the asymmetric encryption used. This is the encryption process responsible for securing all mail messages leaving the gateway domain against snooping and forgery.

IE 990985 -20The best size for the key length depends on the required security needs. The larger the key leng±, the greater the security provided, but also the slower the operations performed. When choosing the key length, consideration should also be given to the value of the data to be protected: how long it needs to be protected, and how powerful the potential threats might be. The gateway recommends using the 1024 bit RSA Key length since this provides strong encryption while still retaining acceptable processing speeds.

Signature Algorithm refers to the digest algorithm used to create a message digest of all the fields in the top gateway CA certificate. This is then used to sign all other user certificates that are generated by the gateway. The gateway currently supports the SHA-1 digest algorithm to provide this functionality. The MD2 and MD4 algorithms will be supported in future versions of the gateway.

CA Certificate Lifetime refers to the time period in which the top CA's certificate is valid. This is currently set to 5 years. User Certificate Lifetime refers to the time period in which all user certificates are valid. User certificates are certificates that are generated by The gateway and signed by the top The gateway CA Certificate. This is also currently set to 5 years. r The gateway provides the ability to increase the number of users by buying a new The gateway pack, entering the serial number and license key and clicking the add button. The Remove button removes a user pack. The Next button takes a user to the gateway GUI or Manager Screen.

. The invention is not limited to the embodiments described but may be varied in construction and detail within the scope of the claims.

Claims (5)

Claims

1. An electronic mail gateway system comprising: means for interfacing with at least two mail servers to relay messages between them, and processing means for automatically encrypting messages and decrypting messages as they are relayed, transparently to senders and recipients.

2. A system as claimed in claim 1, wherein the processing means comprises means for generating a certificate-on-the-fly for an outgoing message; and wherein said means comprises means for automatically performing certification authority operations; and wherein said means comprises means for using a top certification authority certificate to sign user certificates on-thefly; and wherein the system further comprises a certificate database storing user certificates; and wherein certificates are linked in the database in a chainof-trust hierarchy from the top certificate down; and wherein the certificates are identified in the database by a serial number and a fingerprint code.

3. A system as claimed in any preceding claim, wherein the processing means comprises means for automatically cacheing certificates of incoming messages; and wherein the processing means further comprises means for using cached certificates for encrypting outgoing messages; and wherein the processing means comprises means for requesting certificates of intended recipients on-the-fly for automatic encryption of outgoing messages; and wherein said interfacing means comprise means for communicating in a virtual private network.

4. A system as claimed in any preceding claim, wherein the processing means comprises a security policy database and means for accessing said database to IE 990985 -22determine cryptographic operations to be performed on messages being relayed; and wherein the security policy database defines security on a user domain basis; and wherein the domains include a local domain of users in a local area network including the gateway and a virtual private network including users of a remote network having a gateway; and wherein the security policy database indicates an encryption policy for each domain of always encrypting, never encrypting, or only encrypting if a recipient certificate is stored in the gateway; and wherein the security policy database defines a signing policy for each domain; and wherein the signing policies are opaque signing, clear signing, or never signing.

5. A system as claimed in any preceding claim, wherein the processing means comprises an administrator function comprising means for switching log events on or off; and wherein the events include diagnostics, mail processing, virtual private network traffic, pending traffic, performance warnings, encryption problems, and connection problems; and wherein the processing means comprises means for permanendy switching on by default security alert, error condition, start up, and shut down events.