Other

To trigger the delivery of your eMails out of your client (e.g. Outlook or Thunderbird), the following (normally at the beginning)

• <r> or <PSPRegistered/> The message gets signed (notarized) upon sending on the PrivaSphere Secure Messaging Platform
• <egov> or <PSPeGov/> The message gets signed (notarized) upon sending on the PrivaSphere Secure Messaging Platform and the recipient can only access while being logged in with a certificate according to Swiss law or appropriately identified otherwise (see "For entries to courts and authorities").
• <c> or <PSPConfidential/> Triggers the message to be routed to the PrivaSphere Secure Messaging platform on the PrivaSphere Signature Service (confidential mail for corporate integration)
• <s> or <PSPSigned/> for signing eMails using the PrivaSphere Signature & Policy Service

see also:

• Registered Secure eMail
• Registered Secure eMail with return receipt

Other Subject Tags

• <sms:+41 79 xxx xx xx> or <PSPMUCSMS phone="+41 79/xxx-xxxx" /> sends the Message Unlock Code (MUC) via SMS (only for ONE recipient)
• <muc:xxxxx> sends the message with a predefined Message Unlock Code (MUC) (5 to 20 alphanumeric characters)
• <muc4all:xxxxx> uses the same (one) MUC for all recipients (also for encrypted PDF files) if the email is sent via secure SMTP
• <nomuc> The recipient will never be asked for a MUC - even he is not registered on the platform (only protection against "passive listener" - following the link gains access to the content).
• <hidesender> The sender's email address will be hidden in the notification mail
• <showsender> The sender will be displayed in the notification mail
• <hidesubject> The subject will not be displayed in the notification mail
• <showsubject> The subject will be displayed in the notification mail
• <safeRoute> The recipient will be asked for a MUC irrespective of the senders trust relationship
• <unSafeRoute> The recipient will not be asked for a MUC if he is a registered user (or the recipient is member of a completely or via LDAP integrated mail domain) else he will be requested for one
• <lang:...> or <PSPLang="xx" /> The recipient language will be set to the value specified if he is not registered. If he is registered the value will be taken from it's profile (en/de/fr/it)
• <muctext:xxxxx> The value in this tag will be displayed as the prompt text in the webpage where the Message Unlock Code (MUC) will be requested for verification
• <onlyWeb> A secure mail can only be read in the browser. It will not be delivered (POP, domain, PGP / SMIME). This mail is "personal" - for example, an administrator of your mail server can not access the message content. It can be used e.g. for the delivery of payroll reports, etc.
• <mustRegister> A receiver, which still does not have PrivaSphere account, is forced to open one. Otherwise, the message can not be read.
• <keyInPickUp> This functionality offers an advanced encryption of email on the PrivaSphere platform ("Beta ", see documentation (German only)).
• <rcvByCert> Receiving of this message is only possible if recipient is authenticated with its valid certificate (e.g. SuisseID).
• <cPdf>  Sending the secure eMail directly as encrypted PDF file to the recipient - the encryption password is either an automatically generated or an user pre-defined MUC (Message Unlock Code). Use this option for example for recipients who inform you that their web-access is limited very and therefore not including PrivaSphere.
• <noStore> - The message content is not stored on the PrivaSphere platform - command for sending a single message in 'NoStore' mode.
• <store> - The message is sent as a normal secure email which is available on the platform. Command switches off 'NoStore' if it is set as the default in sender’s profile.
• <noSocial> - Message not readable while logged in with social Login (as facebook, twitter, ...)
• <notConfidential> - Message not sent confidentially (only on PrivaSphere Signature & Policy Service to override policy of your security responsilbe - for it to work the responsible needs to put you on a list of users entitled to do so - there is also a never confidential sender list.
• <PSPStatus/> - Query the trust status of a recipient. Available only to customers with an appropriate contract.
• <encHtml>: Push as AES encrypted html5 local store attachment
• <salary>: send private confidential documents to employees such as salary reports
• <noSmtpRcpt>: No read receipt generated for this message
• <sigAtta>: digital signing of PDF files sent as attachments with eMails (only for the PrivaSphere Signature and Policy Service)

Ease of use with Outlook AddIn

For Outlook users, PrivaSphere and the partner Infover AG developed a AddIn to route eMails with this tags. For more information please contact our sales team.

https://www.privasphere.com/info@privasphere.com

Subject Line Transport Encoding certain email clients, we recommend the use of the PrivaSphere add-ins in the address rewriting mode - contact us for details

See also:

• Message Unlock Code "MUC"
• Send and receive in your mail program
• Generate subject tags for the email program

The .eml extension files are used for emails generated by Outlook, Outlook Express, Windows Live Mail, Mozilla Thunderbird, IncrediMail, Windows' notepad, etc. They obey to the RFC-822 which defines multipart emails, i.e. emails containing pictures and HTML.

In PrivaSphere Secure Messaging signed eMails (such as Registered secure eMails) are downloadable as *.eml files.

To open these files and proof the digitale signature most email clients can be used.

Mozilla Tunderbird / Microsoft Outlook / Windows Live Mail

It is possible to view an *.eml file in one of those programs.

In one configuration, the PrivaSphere Signature & Policy Service issues QuoVadis secure e-mail certificates for your senders upon demand directly in an automated and highly secure process.

The personal certificates are stored centrally on the platform and are available to users for automatically signing outgoing emails.

Some of your counterparts might start to reply to you in encrypted form without asking whether you want to receive messages in that form.

When trying to read such messages, in your mail program, you are likely to see an error message like:

e.g. in your Outlook as you do not have the decryption key locally.

You have two options in this case:

1. create a new mail to decrypt@privasphere.com and drag the non-openable message from your inbox into that message
2. if this happens more frequently, you might want to relay your inbound mail traffic through a privasphere filter that will automatically attempt to decrypt such messages for you.

Please contact us, if your are interested in obtaining this extra feature for a moderate fee.

see also:

• Digital Signatures
• Inbound Mails for decrypt / Certificate harvest

Transport Neutral Encapsulation Format or TNEF is a proprietary e-mail attachment format used by Microsoft Outlook and Microsoft Exchange Server. An attached file with TNEF encoding is most usually called winmail.dat or win.dat and has a MIME type of Application/MS-TNEF.

PrivaSphere Secure Messaging transports this attachment type unchanged (sent via SMTP) and unpacks it to display the attachments for download in the web mail (best effort).

more information: http://en.wikipedia.org/wiki/TNEF

PrivaSphere suggests the senders to not use this format. How to switch it off in Outlook - see: http://support.microsoft.com/kb/278061/de

To analyze the mail status for technical support, sometimes it's needed to see the mail header information.

To get headers in Microsoft Outlook:

Open 'properties'  - headers can be marked and copied to an editor.

To preserve all headers and content it's posible to forward an email as an attachement:

PrivaSphere Signature & Policy Management can decrypt inbound SMIME encrypted emails if they are encrypted with the signature certificate applied by PrivaSphere on your behalf while sending the mails.

To decrypt:

• Variant 1: send the encrypted email as an attachment via the platform to <decrypt@privasphere.com> - PrivaSphere will decrypt the email on your platform inbox and deliver it secured by another transport (provided you configured this – otherwise use your webmail).

• Variant 2: automatic routing on the customer’s gateway to PrivaSphere – PrivaSphere will decrypt the email (and deliver it securely).

PrivaSphere cannot authenticate senders on such messages (as it does otherwise for almost all message types). However, inbound SMIME encrypted may be signed with an external sender’s signature.

Even based on a sender signature, PrivaSphere cannot proof nor verify the sender’s identity, but it is available on the decrypted message and it is your responsibility as recipient to check the identity of the sender based on the signature.

Sometimes, senders encrypt for you but do not sign themselves, which leaves that authenticity even less clear. Therefore, a notice is added to the mail subject to inform about this and special caution needs to be taken on such messages and please encourage your contact partners to activate the message signature at the same time if SMIME encryption is used.