Email Client

Specifies whether Secure Sockets Layer (SSL) or Transport Layer Security (TLS) should be used to provide secure communications for this connection. Refer to TLS/SSL Support in Rhapsody for details.

• Enabled - enable SSL/TLS support.
• Disabled (default) - disable SSL/TLS support.

The name and path of the mail folder which contains the message (Inbox by default).

Determines how the Rhapsody message is set using the received email. It can either be part of the incoming message (normal mode), the entire email body or the entire email envelope:

• Normal (default) - if the email content type is set to any kind of multi-part message (in other words, if it matches multipart/*), then either the first (Message as Attachment configuration option set to False) or second body part (Message as Attachment configuration option set to True) of the message is used as the source. If the email content is not a multi-part message then the source is simply the e-mail body. The selected source is then retrieved from email as either a string (if it is some form of text message) or directly as an input stream, and this is written into the Rhapsody message body.
• Receive Raw E-Mail Body - the communication point writes the entire contents of the incoming email body to the Rhapsody message body. When multiple MIME parts are received, the Rhapsody message body contains all those MIME parts, including the MIME boundaries, allowing the route to perform any processing on the communication point.

• Receive Raw E-Mail Header and Body- the communication point writes the entire content of the email to the Rhapsody message body. This includes all the incoming headers and the entire body, which may include multiple body parts separated by MIME boundaries.

  If you manually attempt to unpack the e-mail message (most likely a multi-part MIME message), there is a risk you may do so incorrectly such that some parts of the received e-mail message are not processed correctly. For example, if the MIME boundaries are not correctly parsed, any file attachments to the incoming e-mail message may either be lost or more likely embedded as base64 blocks inside the message.

  Therefore, if you intend to use the raw e-mail modes, you must use appropriate tools either to parse that message. These tools may take the form of external e-mail processing tools executed via a commandlinefilter, or a custom filter that uses proper e-mail libraries to generate or process the message (for example, the JavaMail library). You should not use the standard Batch/De-batch filter or JavaScript filter to pack or unpack the MIME body parts, because they may not perform the task correctly.

Email headers to extract from the incoming message and set as Rhapsody message properties. Options can be set for each property to determine whether it is decoded, and how repeating headers are handled:

• E-mail Header Name - the email header you want to extract from a message property.

  • Uses case-insensitive matching.
  • Not unique - there is no requirement that the same header be only extracted once.
  • Only ASCII characters are permitted.

  If an email header is configured to be extracted but was not found in the incoming email, then the corresponding message property is not set at all (not even to null or an empty string).

• Property Name - the message property that you want to store the extracted email header in.

  • The following message properties are reserved: ReceivedDate, From, Subject, Size, ContentType, AttachmentFileNames, mailClient:priority, mailClient:To, mailClient:CC.
  • Message property names are case-sensitive.

  Message properties are unique. You cannot extract multiple email headers into the same message property or extract the same email header twice into the same property.

• Transformation - determines whether the header is to be decoded or folded:
  • Decode and Unfold - The incoming header value is first unfolded (to remove the wrapping due to the 80/1000 character line limit) and then decoded. This option should be selected for text/unstructured fields.
  • Unfold - The incoming header value is unfolded but not decoded.
  • None - No transformations are performed on the incoming header value.
• Repeat Handling - determines how to handle repeating headers:
  • Retrieve First - The message property is set to the first occurrence of the email header that was found.
  • Retrieve Last - The message property is set to the last occurrence of the email header that was found.
  • Retrieve All - All repeats of the email header are retrieved and set in the message property as a property list.

Specifies whether Secure Sockets Layer (SSL) or Transport Layer Security (TLS) should be used to provide secure communications for this connection. Refer to TLS/SSL Support in Rhapsody for details.

• Enabled - enable SSL/TLS support.
• Disabled (default) - disable SSL/TLS support.

Determines the Rhapsody message body that is used to build the outgoing email message:

• Normal (default) - when the normal sending mode is configured, the outgoing message is either the Rhapsody message body, or the alternate body text provided in the configuration, with the option of attaching the message body to the email as a file (in other words, a separate MIME part). Additional options allow the content type and priority of the email to be set, and allow for it to be encrypted and signed using S/MIME.
• Send Raw E-Mail Body - the Rhapsody message body is inserted directly as the e-mail body without any changes. This means that a multi-part body with MIME boundaries can be provided here in order to send a multi-part message. No encoding or verification of the provided e-mail body is performed - you must provide a valid email body. You must also set the ContentType header correctly, which is required for multi-part messages.
• Send Raw E-Mail Header and Body - the Email Client communication point uses the Rhapsody message body as the entire content of the e-mail, including all headers and the body. The body of course can include multiple parts to the message, separated using MIME boundaries. When the message is ultimately sent, the communication point uses all recipients defined in the email headers. No encoding or verification of the provided email message is performed; you must provide a valid email message.

The MIME (Multi-purpose Internet Mail Extensions) content type of the content being sent. By default, this is set to text/plain for plain text emails. However, it can be changed to another MIME type such as text/html to allow HTML emails to be sent and rendered correctly in an email client.

Specifies how the message is signed. There are two ways of encoding signed messages:

• Clear signed (default) - clear-signed messages carry the signature as a standard MIME attachment outside the message body. The disadvantage of this is that a mail gateway is free to translate the character sets of the message body. If this occurs, the digital signature is broken (since the signature guarantees the original contents of the message are unaltered) and a false warning of message tampering results.
• Opaque signed - opaque signed messages treat the entire message as an attachment which is not altered by mail gateways that attempt to translate character sets or recode MIME headers. This guarantees the message, but is illegible to the gateway. It is also illegible to non-S/MIME clients which cannot unwrap the envelope.

MAPI/Internet mail gateways are a good example of situations that require opaque signed messages. As MAPI handles messages and attachments in a proprietary (that is, non-MIME) format, the actual MIME headers are generated at the SMTP gateway, not in the secure mail client. Therefore, a clear signed message signature cannot account for the MIME header's content, which automatically invalidates the digital signature as the message passes through the SMTP gateway.

Additional email headers to set on the outgoing email using Rhapsody message properties. This email headers configuration property is optional and if missing or present and empty then we simply do not set any additional email headers.

• Property Name - the message property that contains the extracted email header you want to use.

  • If the message property is not found when sending a message then the corresponding email header is not created at all.
  • If the message property is actually a property list then a separate repeat of the email header is created for each value in the property list.

• E-mail Header Name - the name of the email header you want to insert into a message property.

  • Only ASCII characters are permitted.
  • If the same email header is used for multiple message properties, then multiple instances of the header are created at runtime (in the order defined in the configuration).

  The following special email headers cannot be set in this way: From, Reply-To, To, Subject, Date, ContentType, CC, and BCC.

• Transformation - determines whether the header is to be decoded or folded:

  • Encode and Fold - the value is encoded using RFC2047, and then folded in an attempt to keep each line shorter than 80 characters in length (and forced to be shorter than 1000 characters in length).

    If the encode option is not selected, then the user is responsible for performing any necessary encoding on the value prior to giving the message to the communication point. The Email Client communication point does not perform any validation on this value.

    The encode and fold option uses UTF-8 character encoding if any encoding is required and verifies the value is composed of ASCII characters before encoding.

  • Fold - the value is folded to keep it under 80/1000 characters in length.
  • None - no transformations are applied to the value.