|
Signed and Encrypted E-Mail |
  
|
|
Signed and Encrypted E-Mail |
|
CopiaFacts has a feature option which can sign and encrypt e-mail. Currently it supports S/MIME signing and encryption, and DomainKeys/DKIM signing. Any combination of the three features can be applied to an individual e-mail transmission, though not all combinations are useful.
Preparation
To load the special F7SECURITY.DLL, the $email_security configuration command must be supplied.
For DKIM signing, you will need to generate a key and make a matching entry in the DNS records for the domain from which the e-mail is being sent. For information on Domain Keys and DKIM, see the following links:
http://www.ietf.org/rfc/rfc4871.txt?number=4871
http://tools.ietf.org/html/draft-delany-domainkeys-base-01
http://antispam.yahoo.com/domainkeys
http://en.wikipedia.org/wiki/DomainKeys
The DKDNS utility can be used to generate keys and DNS records, but actually modifying the domain DNS records must be done independently. The key published in the DNS records is the 'public' key and the key used for signing is the 'private' key.
Currently, it appears that HTML e-mails containing cascading style sheets (CSS) are modified on receipt by Gmail, Yahoo and Hotmail, to prevent incoming CSS elements breaking their webmail interface. This modification then results in the DKIM signature being rejected as invalid. It is therefore recommended that the HTML component of e-mails to these destinations should not include CSS.
Examples are provided in the Examples section.
Certificates Used in E-Mail Security
There are number of sources for certificates which can be used with the CopiaFacts E-Mail Security Option. Many larger organizations will have facilities to generate certificates and keys for their staff. A certificate can be obtained at a low annual cost in the form of a Digital ID from Verisign, Inc at:
Suitable certificates for personal use can also be obtained free of charge from Thawte at:
http://www.thawte.com/secure-email/personal-email-certificates/index.html
and from Comodo at:
http://www.comodo.com/products/certificate_services/email_certificate.html.
Certificates are normally downloaded from the sites listed above and installed automatically in a browser. For use by CopiaFacts the certificate must then be exported into a file. For a public key file the extension .CER is recommended, and for one containing both the public and private keys, the extension .PFX is recommended. The .PFX file will require a password when exported from the browser, and the password must be specified to CopiaFacts to enable the use of the certificate.
A certificate used for S/MIME signing must be associated with a specific e-mail address, which must also be used in the From: header in the e-mail. The certificate used for encryption will normally be associated with the e-mail address of the recipient, but it is theoretically possible to sign an e-mail using the public key of a third party.
The following additions must be made in the FS file:
Each FS file which sets up a signed transmission must include an $email_sign_keyfile command specifying the name of a file containing the key. Such files will normally have extension .PFX. A private key is required to sign e-mail, and the key file must contain a reference to the e-mail From: address in the mail item.
Each FS file which sets up a signed transmission must include an $email_options command with a SmimeSign keyword.
Each FS file which sets up a signed transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable SMSIGN_ALGORITHM. This should be set to MD5 or SHA1 as appropriate. SHA1 is the default.
The following additions must be made in the FS file:
Each FS file which sets up a signed transmission must include an $email_dkim_keyfile command specifying the name of a file containing the key. Such files will normally have extension .PEM.
Each FS file which sets up a signed transmission must include an $email_options command with a DKIM keyword.
Each FS file which sets up a signed transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable DK_SELECTOR. The value is placed in the "s=" parameter of the DomainKey-Signature: header. It specifies which public key is to be used by the receiving mailserver to verify the signature.
Each FS file which sets up a signed transmission (or its referenced USR or UJP file) may optionally include a $var_def command defining the variable DK_CANONICALIZATION. This specifies whether the DKIM verifier is to verify that the signed content is exactly the same (DKSIMPLE) or to tolerate common modifications such as whitespace replacement and header field line rewrapping (DKRELAXED). The latter is the default. The canonicalization can be specified separately for the headers and the body by separating two keywords with a vertical bar: for example "DKRELAXED|DKSIMPLE" specifies relaxed checking for the headers and simple checking for the body. Note that the keyword DKNOFWS (for 'no folding white spaces') is a synonym for DKRELAXED.
The following additions must be made in the FS file:
Each FS file which sets up a signed transmission must include an $email_encrypt_keyfile command specifying the name of a file containing the public key of the recipient. Such files will normally have extension .CER. The recipient will need the matching private keyfile installed in their mail client to decrypt the incoming email.
Each FS file which sets up a signed transmission must include an $email_options command with a SmimeEncrypt keyword.
Each FS file which sets up an encrypted transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable SMENCRYPT_ALGORITHM. This should be set to one of the values listed for this variable in Appendix D.
Topic url: http://www.copia.com/support/refmanual/index.html?signed_and_encrypted_e_mail.htm