it is worth noting that in fig1 to 9 , dotted boxes are used for optional components which may or may not be used , or may be replaced with other components altogether . new components may also be added . dotted arrows indicate a set of possibilities . referring to fig1 and 2 , the email authentication system of the present invention authenticates emails ( headers , text body , attachment ( s ), etc .) between a sender station 2 and a recipient station 14 via a mail server 16 . in fig1 , a sender mail server and a recipient mail server are the same mail server 16 , while in fig2 , the sender mail server 18 and the recipient mail server 20 are separate from each other . the system comprises a database 3 separate from the sender station 2 , for storage of sender - related data . the sender related data comprises a public key and a private key for each sender . the private key is kept inaccessible to each sender . therefore , the sender does not know his private key . the sender station 2 may be a typical desktop workstation , a server , or any other suitable device from which an email can be sent . the sender station 2 can run any operating system ( ex . : windows ®, macos ®, linux ®, etc .) and any email client application typically used to retrieve / read / send email ( e . g . eudora ®, outlook ®, outlook express ®, netscape ®, etc .). a sender module 4 , such as an email client plug - in , is integrated in the sender station 2 and interfaces with the sender &# 39 ; s existing email client application . other configurations may also be possible , with the use of other software than an email client plug - in . for example , the sender module 4 may be an email application on its own . the sender module 4 is activated when the sender attempts to send an email that is to be signed to the recipient station 14 . the sender module 4 generates an email signing request ( as depicted by arrow 10 ), prior to transmission of the email to the recipient station 14 . a signing module 6 separate from the sender station 2 and connectable to the database 3 , receives the email signing request 10 . the signing module may be integrated in an authentication server 8 . therefore , the sender module 4 contacts the authentication server 8 and conducts proper client identification handshake routine with the authentication server 8 , and , having been successfully identified as a legitimate sender , the sender module 4 sends the email to be signed to the authentication server 8 . as will be later described , the sender module 4 may then receive a signature from the authentication server 8 . a combining module 12 connectable to the signing module 6 then combines the signature to the outgoing email , thereby obtaining a signed email , and lets the signed email be sent as it may usually through the existing mail servers ( smtp servers ). the combining module 12 may be integrated in the sender station or in the authentication server 8 ( shown in fig4 ). in the case where the outgoing smtp server configured in the sender &# 39 ; s email application is the authentication server 8 instead of being the existing sender mail server 18 , a send request for an email ( e . g . when the sender presses a send button of the email application ) may automatically generate the email signing request 10 . therefore , the email signing request 10 may be the transmission of the email to the authentication server 8 . for example , authentication of the sender with the authentication server 8 may be provided based on existing authentication methods between the sender and the sender &# 39 ; s original mail server . as previously mentioned , the authentication server 8 is connectable to the sender station 2 . the authentication server 8 is typically a server , a series of servers or a network with a complex server configuration running a robust and secure operating system , or a network configuration of such operating systems , capable of handling high network traffic ( e . g . linux ®, solaris ®, aix ®, etc .). the signing module 6 receives the email signing request 10 from the sender module 4 . the authentication server 8 conducts the appropriate identification handshake in order to identify that the sender has the right to have his email signed , and , once this is determined to be true , the signing module 6 retrieves the sender &# 39 ; s private key , produces a signature as a function of the private key found in the database 3 in association with the sender , and returns the signature to the combining module 12 . the combining module 12 combines the signature with the email and then sends the signed email to the recipient station 14 via the sender mail server 18 . the sender mail server 18 is likely to remain unchanged by the integration of the authentication system . the sender mail server 18 receives a send request from the sender station 2 and conducts the proper handshaking for sending the signed email to the recipient mail server 20 , e . g . a recipient smtp server . the authentication server 8 may also conduct a number of other functions , such as controlling the number of emails sent by a sender within a given time - frame . the authentication server 8 may be embodied in a network server publicly accessible on the internet or it can be embodied in a network appliance that resides on an organization &# 39 ; s private network for the purpose of signing emails . there is also the possibility that the authentication server 8 may act as an smtp server and therefore forward the signed email to the existing smtp mail servers . the recipient mail server 20 is the recipient &# 39 ; s existing smtp server . the recipient mail server 20 may remain unchanged by the integration of the authentication system . the recipient mail server 20 is typically contacted by the sender &# 39 ; s smtp server 18 or the authentication server 8 , receives the signed email , stores the signed email for the recipient to retrieve , conducts the proper handshaking for allowing the recipient to retrieve any emails received for him , and retrieves the emails stored for a recipient , when requested by the recipient , and transfers them to the recipient &# 39 ; s email client software . the recipient station 14 may be a typical desktop workstation , a server or any other suitable device for retrieving email from a mail server . the recipient station 14 may run any operating system ( e . g . : windows ®, macos ®, linux ®, etc .) and any email client application typically used to retrieve / read / write / send email ( e . g . : eudora ®, outlook ®, outlook express ®, netscape ®, etc .). a recipient module 24 is associated with the recipient station 14 . the recipient module 24 may be an email client plug - in interfacing with the recipient &# 39 ; s existing email client application . the recipient module 24 , which may be the same plug - in used for contacting the authentication server 8 and getting emails signed as described earlier , is activated when an email is received by the recipient as part of the normal email retrieval . at such a time , the recipient module 24 verifies whether the email contains a signature from the authentication server 8 . the recipient module 24 generates a public key request 32 triggered at reception of the signed email to retrieve the sender &# 39 ; s public key . upon reception of the public key , the recipient module 24 validates the signature of the signed email , and marks the email accordingly for the recipient to see . for example , if the email does contain a valid signature , the email may be highlighted as part of the list of emails contained in the recipient &# 39 ; s inbox . other configurations are possible , with the use of other software than an email client plug - in . for example , a proxy daemon may filter out emails which don &# 39 ; t contain signatures or contain invalid signatures so that the recipient may not even see them in his inbox . a public key module 22 is connectable to the recipient station 14 and the database 3 . the public key module 22 receives the public key request from the recipient module 24 for retrieving the public key from the database 3 in association with the sender . the public key module 22 looks up the requested public key , retrieves it , and , if it is found , returns it to the recipient module 24 . the public key module 22 may be a server separate from the authentication server 8 , with possibly a different network address and / or a different physical location , or it can be seen from the outside as having the same network address , or be hosted on the same hardware , as the authentication server 8 . its location , visibility , and possible aggregation with another system component may not change its role or behaviour . the present system places the burden of certifying the legitimacy of email on the sender . referring now to fig3 , the sender module 2 has his email signed by the signing module ( not shown ) on the authentication server 8 using the sender - specific private key prior to it being delivered to the recipient ( arrow 40 ). the signed email is then delivered to the recipient mail server 20 ( arrows 42 ) either through the authentication server 8 itself or using the sender mail server 18 . after the signed email is extracted from the recipient mail server 20 ( arrow 44 ), the recipient module 24 contacts the public key module 22 ( not shown ) on the authentication server 8 ( arrow 46 ) and requests the sender &# 39 ; s public key . the recipient module 24 may also cache already obtained public keys for future use . using the sender &# 39 ; s public key , the recipient module 24 can verify that the email was indeed sent by the sender . while the sender may be required to have an account on the authentication server 8 , the recipient is not required to have such an account , though having an account on the authentication server 8 may provide recipients with advantages ; blacklisting senders and enabling end - to - end encrypted exchanges being two such examples . in addition to fig1 and 2 , fig4 to 6 illustrate other possible embodiments of email authentication systems according to the present invention . of course , other embodiments may also be considered . for example , the authentication server 8 may be a single physical machine , but may also be a set of independent physical machines instead . fig4 shows the combining module 12 integrated in the authentication server 8 and sending the signed email to the sender mail server 18 or the recipient mail server 20 . in fig5 , the database 3 and the public key module 22 are separate from the authentication server 8 . in fig6 , the recipient module 24 is integrated in the recipient mail server 20 . as shown in fig7 , the sender may log in to the authentication server 8 using the openssh remote login suite ( arrow 50 ). the signing module may comprise an authentication engine 53 along with other modules for that purpose . in that case , there may be a database 62 to validate logins ( arrow 52 ). openssh is useful for : a ) verifying that the sender indeed has access to the authentication server &# 39 ; s services , b ) securing the exchange between the authentication server 8 and the sender module 4 , c ) allowing communication between the sender module 4 and the authentication server 8 even if the sender &# 39 ; s isp is filtering the smtp port . it is possible , however , to provide these capabilities using other software combinations . using ssl with an http connection is such an example . in fact , it is possible to tunnel all communication between the sender module 4 and the authentication server 8 over http in the case where this is the only service that is not filtered by the sender &# 39 ; s isp . a custom - built connection mechanism may also be used . once the connection is established , the authentication engine 53 may then retrieve the sender &# 39 ; s private key from the database 3 ( arrow 54 ). using this private key , the authentication server 8 may then feed the message and the private key to the signing module 6 , which may be an encryption software 64 ( arrow 56 ) such as gpg . to avoid sending large attachments for signing by the authentication server 8 , the sender may instead send the hash checksum of the attachments and the email text body , which may then be both signed by the authentication server 8 . the signed email , resulting from running the encryption software on the data provided by the sender , may then either be delivered to the recipient mail server 20 ( arrow 58 ) via existing mail servers using traditional mail services packages , such as sendmail , or only the generated signature may then be provided back to the sender for him to send using his existing email servers , as explained earlier . regardless of the actual delivery mechanism being used , the signature may be customized for the purposes of the system &# 39 ; s architecture . the list of recipients and a few other mail headers , for example , may also be part of the signature in order to avoid false reports of illegitimate emails ( i . e . recipients claiming they received an email when in fact they had stolen it and counterfeited its headers to file a false complaint against the sender ). there are , of course , a number of variations and features that can be implemented in this system . if the recipient is also a member ( has an account in the system ) he may be allowed to blacklist senders , either by personal choice or following the receiving of what the recipient considers illegitimate email . in this case the authentication server 8 may check the sender &# 39 ; s recipients and refuse to sign emails destined to recipients who blacklisted the sender . instead of gnupg , other public key cryptographic software may also be used , such as pgp , or a cryptography suite may be developed custom for this invention . in order to avoid attracting potential brute - force breaking of keys by spammers wanting to abuse this scheme , the authentication server 8 may use keys that have expiry dates instead of keys that never expire . the size of the cryptographic keys and their duration will have to be chosen in function of the computational capabilities available at that period in time . over time , the size of the keys may have to increase and / or their duration may have to shorten in order to keep the degree of difficulty of breaking the keys high enough that abusers will not be successful in breaking the system . the use of random expiration dates ( opaque to the users ), may also be considered . also , it may be possible to implement a rating system such as those already existing on many web sites ( ex . : amazon . com , ebay . com , etc .) to rate senders . hence , recipients may be allowed to judge senders on the content they send . the software used by the recipients to talk to the authentication server may then query the server for the rating of the sender . using this information , the recipient &# 39 ; s software may then choose to either apply filtering to the received message or display messages differently according to the rating of the sender . the database 3 may contain the following information pieces for each sender : membership id ; email addresses ( a single member may decide to service more than one address through a single membership ); and private and public keys . other information fields relevant to the signing of senders &# 39 ; emails may be added . for example , a field may be added for listing the recipients from which this sender is blacklisted from sending to . it is also worth noting that the public key may instead be stored in another database . upon receiving a signed message , the recipient module 24 may : 1 ) recognize the signed message ; 2 ) retrieve the sender &# 39 ; s public key from the public key module 22 ; 3 ) verify the email signature using the public key , the signature and the appropriate public key cryptography software . all recipients , whether they have an account on the authentication server 8 or not , are allowed to retrieve senders &# 39 ; public keys . by having an account with the authentication server 8 , the recipient may also be allowed to create blacklists of users from which he desires not to receive any mail from . this may involve having a database that takes care of blacklisting , or it may involve implementing blacklisting in the software provided to the recipient . in addition to blacklisting , the recipient may be able to instruct the authentication server 8 to hold messages from certain senders for a certain amount of time , in the case where it &# 39 ; s the authentication 8 server that sends the messages to the recipient &# 39 ; s mail server 20 , for example . it can also be possible for the recipient mail server 20 of the recipient to verify the mail signature by automatically completing steps 1 ) to 3 ) listed above ( as shown in fig6 ). fig8 illustrates the system &# 39 ; s possible architecture of the public key module 22 for dealing with requests for public keys from the recipient . the recipient module 24 communicates with the public key search engine 81 ( arrow 80 ), and the latter communicates with a public key database 90 ( arrow 82 ) to retrieve the public key the recipient is asking for . the public key database may be the same database 3 storing the private keys . if the recipient is not equipped with the appropriate software to communicate with the authentication server 8 , the sender &# 39 ; s email should still be humanly readable . in essence , the sender &# 39 ; s email should appear as a gpg signed mail , or an email with an extra attachment containing the signature , depending on how the invention is implemented . fig9 illustrates a possible architecture for implementing the registration of a new sender ( new member ) to the system . typically , the new member may use his web browser to connect to a secure web site ( possibly apache with openssl ) and fill - in the required fields for creating a new account ( arrow 100 ), such as name , address , credit - card number , etc . the web server 120 then provides this information to a registration engine 122 ( arrow 102 ) which then verifies the member &# 39 ; s information and contacts the credit - card clearance server 124 ( arrow 103 ) to validate the credit card information provided by the user . once this is successful , the registration engine 122 gives control to the member addition engine 126 ( arrow 104 ) which carries out a number of tasks to finalize the member &# 39 ; s registration . typically , this may involve : 1 ) creating a pair of private and public keys for the new member ( arrow 105 ), 2 ) providing the private key to the member signature database 3 ( arrow 106 ), 3 ) providing the public key to the public key database 90 ( arrow 107 ), 4 ) adding the new user to the login database 62 ( arrow 108 ) so that the member may be able to log in and get email signed , and 5 ) create a new entry for the user in the member database 63 ( arrow 109 ). the member database 63 may contain the following entries for each member : private membership id ( numeric id used internally ) public membership id ( alphanumeric id used for the user to log in ) encrypted credit card number contact information user preferences more fields may also be added . for example , members may be allowed to use a web interface to subscribe / unsubscribe from “ official ” vendor newsletters . this may easily be extended to provide users with an easy to use digital identity management system . once the user has been added to the member database , he is provided with a membership registration confirmation ( arrow 110 ) which contains an alphanumeric user - id ( possibly supplied by the user and validated to make sure it doesn &# 39 ; t already exist ) and a password for logging - in ( also possibly supplied by the user and validated for length and complexity ). during the initial trial of the system , users may be allowed to become members for free in order to evaluate the system . as such , they may probably not be required to provide their credit - card information . instead , they may be presented with a bar code image which they may have to print out and send back using traditional letter mail in order to confirm their registration . this process may discourage potential abusers from disrupting the system by creating a large number of illegitimate accounts . also , the number of messages each sender is allowed to send may be limited to a certain number per hour , say one hundred ( 100 ). hence , even if a member &# 39 ; s system is compromised , it cannot be used to send unlimited amounts of email . this maximum may be maintained even for paying customers to act as a throttle . members wanting to send more mail may possibly be required to pay an additional fee and / or justify their need . during the initial evaluation period of the implementation , it may be desirable to provide different qualities of certification . as such , the email from paying senders may be of “ better ” certification quality than that of email from senders participating in the system &# 39 ; s free trial use . this may be visible to the recipient using a different highlighting color for the various email certification types , or using some other form of filtering . this system of providing different grades of certification may also be extended for the lifetime of the production implementation of this invention . while this invention , as currently described , is unlikely to take care of the case where a member &# 39 ; s system has been compromised and is used to send illegitimate email , leaving it to the member &# 39 ; s responsibility to update his anti - virus software or pay the penalties for his system having sent illegitimate email , stop - gap measures and enhancements may be added in the future to reduce the impact of such breaches . in addition to the basic functionality described above , there are a number of enhancements that can be added . it is possible , for example , for the authentication server 8 to act as a broker for end - to - end encrypted communication between the sender and the recipient , if both have an account on the authentication server 8 . in that case , the members may likely have to create a private and public key pair on their systems when signing up for a membership on the authentication server 8 , and provide their local public keys to the authentication server 8 for use by other members . hence , the server may have two public keys in its database for each user , one for authenticating senders , and one for allowing members to securely exchange data . said encrypted exchanges may also be signed by the authentication server . in order to log complaints with the entity servicing the authentication server 8 , the recipient of an illegitimate email may provide the servicing entity with a verbatim copy of the received mail including the signature and the mail headers ( containing the sender &# 39 ; s address .) the origin of the email may then be verified using the database 3 , and appropriate action may be carried out , possibly following a yet to be defined user agreement . one possible outcome is the blacklisting of the sender by the recipient . as such , this may require adding the appropriate entries in the appropriate databases . in addition , there may be appliance versions of the authentication server 8 implemented for providing to 3 rd parties for signing their own users &# 39 ; emails . for example , it may be desirable for companies like ibm ® or yahoo !® to have their own authentication server instead of relying on an external server . in such a case , they may be provided with network appliances implementing the above - described invention to sign their own users &# 39 ; email . these appliances may possibly implement a minimum level of synchronization with a central server and possibly provide interfaces for direct communication with other such appliances . emails sent from such appliances may likely require two signatures , one for the user and one for the appliance . the user signatures may probably be used similarly as described earlier for a single authentication server . the appliance key may be used to hold the appliance &# 39 ; s owning organization accountable for their use of the invention &# 39 ; s privileges . mass - mailings , for example , may likely be prohibited . in order to avoid abuse , the appliances are likely to be counter - fit proof and tamper - proof . some sort of keepalive signal may be used to make sure appliances are on - line all the time . some remote - login capability may also be relevant for ensuring the proper operation of the appliance . to properly deal with these appliances , the software used by the recipients may be made to properly handle multiple authentication servers . the authentication server id may be included as part of the signature provided by the authentication server for the sender to send with his mail . some authentication of the appliance may be carried out with a central authentication server . the appliance &# 39 ; s public key , for example , may not be available from the appliance itself , but from a central authoritative authentication server . example synchronization between authentication appliances may be blacklisting . if joe @ ibm . com is blacklisted by heather @ sudo . org , then the appliance taking care of sudo . org , or the main authentication server if sudo . org doesn &# 39 ; t have an appliance , may contact the appliance serving ibm . com and inform it to add a blacklist rule for heather @ sudo . org in its database . this may involve having a database specifically taking care of blacklisting . while embodiments of this invention have been illustrated in the accompanying drawings and described above , it will be evident to those skilled in the art that changes and modifications may be made therein without departing from the essence of this invention .