The user certificate required for the signature (please also refer to S/MIME (X.509)) can be

•imported automatically by the appliance from an accredited CA via the interface integrated in the SEPPmail Secure E-Mail Gateway (see Managed PKI)
 

•issued by the local CA present on the SEPPmail Secure E-Mail Gateway or
 

•imported manually - individually or as bulk import - for the corresponding user

 

. The central functions required for this purpose are included in the SEPPmail Secure E-Mail Gateway by default and are provided to the operator together with the encryption licence.

 

Automatic signature

Outgoing emails can be automatically signed in the name of the sender by the SEPPmail Secure E-Mail Gateway. The user group for which this should be done, if necessary, can be controlled as required via the ruleset.

 

Manual signature

The signature of emails by the SEPPmail Secure E-Mail Gateway can also be enforced manually via the control functions (Controlling The Appliance) which are already known from encryption.

 

Digital email signature with a company certificate

Signing emails with an S/MIME company certificate serves the same purpose on a company level as signing with an S/MIME user certificate on a personal level. This version requires only a single certificate for the entire company. However, since S/MIME certificates are generally only valid for one email sender address, all outgoing emails will receive the same (technical) sender. This means that all emails of the company – regardless of who

is the actual sender in the company – appear with the same email address to the recipient.

This results in some problems:

•The correct (sender) user name may be displayed to the recipient., but when recording the contact in the corresponding email client under the name of the actual sender, the email address of the technical sender (see above) will be saved.
If this contact were to be used later, the message would be incorrectly addressed to the central sender address from the company certificate!
 

•Since this one sender address is used frequently, there is a high probability that it will be falsely classified as SPAM. In the worst case scenario, this would have the effect that all outgoing emails of the company would be rejected by the recipients!
 

•Non-delivery reports (NDR), i.e. emails informing about the non-delivery of an email, are generally no longer sent to the original sender but to the technical sender. The actual sender thus does not receive any notification if their sent email could not be delivered!
 

Conclusion:

This type of signature is not recommended in the productive environment, as the necessary support effort would be immense over the short or long term!

 

Validation of signatures

The information whether an email has been signed and which result was achieved when verifying a signature is displayed by the SEPPmail Secure E-Mail Gateway through a specific mark in the email subject line. By default, this mark is:

 

[signed OK] for valid signatures

[signed INVALID] for invalid signatures

 

If an email from the Internet already has such mark, it will be removed even before the signature is checked by the SEPPmail Secure E-Mail Gateway. This makes faking a non-existing valid signature impossible and ensures that the recipient will always see the correct verification result!

Additionally, the operator of the SEPPmail Secure E-Mail Gateway can decide whether the signatures are removed or left in the email after verification and the corresponding marking in the subject line. Removing signatures after a successful verification may be advisable. This, for instance, prevents getting different results in the event of a double verification, by the SEPPmail Secure E-Mail Gateway and the email client, e.g. due to different trust setting or missing CA certificates. Another reason for removing the signatures can be mobile terminal devices which often have problems handling signed emails. Thus, in most cases, signatures are usually added directly at the client when replying. However, this will fail due to the signature certificates which are generally non-existent.

 

The following example highlights how critically the handling of signature messages to the recipient should be regarded. A secure email gateway appliance generates the following email footer when verifying the signature:

At a first glance, this type of notification on an email signature seems to be very informative:

•The email is original
 

•The email is unadulterated
 

•The certificate is valid
 

But!

An attacker could attach this footer to their unsigned email as well, thus sending a fake email from the outside. The gateway using this method for marking signed emails could not recognise this fake. The recipient of this email would thus be tricked to believing that this is a valid signature.