JavaMail Bridge Extension Swiftlet

The JavaMail Bridge Swiftlet connects both domains, JMS and eMail, and enables JMS clients to send and receive eMails including attachments with plain JMS. The Swiftlet is installed once somewhere within the router network and is now at the disposal of every JMS client. Through this, it is possible to send and receive eMails from JMS clients which are themselves within a network sector from which they have no mail server access.

Sending eMails via Outbound Bridges

An outbound bridge is bound to an input queue or an input topic where it receives a JMS message, creates a JavaMail message from it, translates JMS headers into JavaMail headers, enriches the JavaMail message by optional default headers (e.g. a default bcc), and transforms the JMS message body into the JavaMail message body. The transformation is done by pluggable transformer classes. The Swiftlet distribution contains 2 pre-built transformer classes, a TextMessageTransformer to send simple text messages and a MultipartTransformer to send complex eMails with any number of attachments. Finally, the resulting JavaMail message is sent to a configured mail server with the SMTP protocol.

It is possible to define an unlimited number of outbound bridges, bound to different queues/topics and external mail servers and thus create a very complex outbound eMail integration.

An outbound bridge can be activated/deactivated via the Scheduler Swiftlet by a schedulable job to send all eMails at once at a specific daytime or in given intervals.

Receiving eMails via Inbound Bridges

An inbound bridge is bound to a mail account on a particular mail server. It receives JavaMail messages either by the POP3 or by the IMAP protocol. To protect against denial-of-service attacks, an inbound bridge can be configured to receive only a limited number of messages per retrieve interval and/or reject messages which exceed a configured maximum size. For each received JavaMail message, a JMS message is created by a pluggable transformer class which transforms the JavaMail message body into the JMS message body, JavaMail headers are translated into JMS message properties, the JMS message is enriched by default properties and will be sent to a JMS destination which can be either a queue or a topic. The Swiftlet distribution contains 2 pre-built transformer classes, a TextMessageTransformer to receive simple text messages and a MultipartTransformer to receive complex eMails with any number of attachments.

It is possible to define an unlimited number of inbound bridges, bound to different queues/topics and external mail servers and thus create a very complex inbound eMail integration.

An inbound bridge can be activated/deactivated via the Scheduler Swiftlet by a schedulable job to receive all eMails at once at a specific daytime or in given intervals.

Outbound Bridges

An outbound bridge is bound to a queue or topic where it receives JMS messages. The format of the JMS messages is dependent on the transformer class of the outbound bridge. The JMS message will be transformed into a JavaMail message and will be sent to a configured mail server via SMTP.

Creating an Outbound Bridge

A queue or a topic serves as the input source to the outbound bridge. Before you create the bridge, ensure that the queue or topic exists.

Use the SwiftMQ Explorer App, connect, and select the JavaMail Bridge Swiftlet / Outbound Bridges:

Click Create a new Entity you'll see a dialog where you can specify your bridge configuration:

Field description:

Error Policy

Each outbound bridge has an attribute Error Policy which defines how to proceed in case the transformation fails (transformer throws an exception). Possible values for the error policy are:

If the error policy is error_queue, the attribute error-queue must contain a local queue name. This queue can be shared by all or unique per outbound bridge. It will be automatically created when the bridge starts. In case the transformer throws an exception, the input JMS message will be flagged with the following JMS vendor properties and forwarded to the error queue:

Creating Default Headers

Default headers are useful if you want that every mail should be archived, for example. In that case, you'd create a default header for bcc. Or if you have a default subject to be used if no subject is specified in the JMS message. Technically, all defined default headers are set in the outgoing mail message and may be overwritten by headers, translated from the JMS message. So in fact, you don't need to specify any headers in the JMS message but can define them statically for the bridge as default headers.

You can set any valid Mime header, e.g. X-Mailer to store the name of an eMail client. The following header names are keywords and have special meaning/handling:

• sender: The sender's eMail address.

• from: The From eMail address.

• to: The To recipient's eMail address.

• cc: The cc recipient's eMail address.

• bcc: The bcc recipient's eMail address.

• subject: The default subject.

To define default headers, select the Default Headers node of your newly created bridge:

Then specify a default header:

Repeat these steps to create additional default headers.

Defining Header Translations

A header translation defines a translation from a JMS message property into a mail header. Any valid Mime header can be specified. Mail headers with names sender, from, to, reply-to, cc, bcc, and subject are keywords and have a special meaning/handling (see above Creating Default Headers). For example, if a JMS client sends newsletters with addresses from a database or an order confirmation to a customer, it would specify JMS message properties in its message which are translated into from, to, and subject. If it stores the order number in the JMS message, a translation into X-ORDERNO could be defined.

To translate the JMS message id into a mail header, specify JMSMessageID, for the JMS correlation id specify JMSCorrelationID as the message property name.

The header translation is done after the default headers are set in the mail message so they overwrite default headers.

To define a header translation, select the Header Translations node:

Then specify a header translation:

Here is a translation into a custom mail header:

Repeat these steps to create additional header translations.

Defining JavaMail Properties

Depending on the connected mail server products (e.g. one bridge Sendmail, another one Kerio Mailserver), it may be necessary to configure different sets of JavaMail properties for each bridge.

The properties are used to create the JavaMail Session object which is done when the bridge is enabled. So whenever a property is added, removed, or changed, the bridge must be disabled and reenabled to activate the changes.

To define a JavaMail property, select the JavaMail Properties node of your newly created bridge:

Then specify a JavaMail property:

Repeat these steps to create additional JavaMail properties.

Activating the Bridge

All necessary configurations have been finished now and you can activate the bridge by checking the Enabled attribute:

The bridge is now active and is listening to the input source.

Outbound Message Transformer

An outbound message transformer is responsible for transforming a JMS message body into a JavaMail message body. It hides the actual message content and structure from the rest of the bridge. Therefore, a JMS client sends JMS messages which correspond with the configured transformer. Since transformers are pluggable, a developer can create his own transformer class which he uses for his JMS clients. This custom transformer class can use custom classes in an ObjectMessage, for example.

For convenience, the JavaMail Bridge Swiftlet includes two pre-built outbound transformers which fit most requirements: A TextMessageTransformer which uses text messages, and a MultipartTransformer that uses ObjectMessages with a java.util.ArrayList including text and attachments.

com.swiftmq.extension.javamail.outbound.TextMessageTransformer

The TextMessageTransformer accepts a JMS TextMessage and converts it to a mail message body with MIME type text/plain. It's a very basic transformer. Following the relevant parts of a JMS client which sends a TextMessage to an outbound bridge with a configured TextMessageTransformer.

Example:

TextMessage msg = session.createTextMessage();
msg.setStringProperty("MailSubject","TestMail, please ignore!");
msg.setStringProperty("FromAddress","testsender@mycompany.com");
msg.setStringProperty("ToAddress","testrecipient@mycompany.com");
for (int i = 0; i < nMsgs; i++)
{
  msg.setText("Hello,\n\n This is Msg No: " + (i + 1));
  sender.send(msg);
}

For this example, the outbound bridge configuration has to have defined header translations for MailSubject into subject, FromAddress into from, and ToAddress into to.

Hint: To send the mail message with MIME type text/html, either define a default header or a header translation for message header Content-Type, respectively.

com.swiftmq.extension.javamail.outbound.MultipartTransformer

The MultipartTransformer accepts an ObjectMessage containing a java.util.ArrayList. We have taken this approach to avoid having vendor-specific classes at the JMS client. The ArrayList has to have the following structure:

The HashMap objects on the ArrayList elements 1-n are optional. One can also only send an ArrayList with a single String element. A HashMap contains each a single attachment plus some properties describing the attachment:

The MultipartTransformer takes the ArrayList out of the ObjectMessage, and converts the String from element 0 into the mail message body with MIME type text/html if Send Multipart Text as HTML is set to true, otherwise text/plain (default). If set, it converts all HashMaps on elements 1-n into mail message body parts.

The following example contains the relevant code snippets of a JMS client which sends emails with attachments. It takes filenames as parameters of the main method, loads the files, and sends them as attachments. As you will see, it's very easy:

Example:

private static byte[] loadFile(String fn) throws Exception
{
  ByteArrayOutputStream bos = new ByteArrayOutputStream();
  BufferedInputStream bis = new BufferedInputStream(new FileInputStream(fn));
  int c;
  while ((c=bis.read())!=-1)
    bos.write(c);
  return bos.toByteArray();
}

private static String getExtension(String fn) throws Exception
{
  String s = new File(fn).getName();
  return s.substring(s.lastIndexOf('.')+1);
}

// excerpt from the main method

ObjectMessage msg = session.createObjectMessage();
msg.setStringProperty("MailSubject","Multipart TestMail, please ignore!");
msg.setStringProperty("FromAddress","testsender@mycompany.com");
msg.setStringProperty("ToAddress","testrecipient@mycompany.com");
for (int i = 0; i < nMsgs; i++)
{
  ArrayList al = new ArrayList();
  // add the actual message at element 0
  al.add("Message No "+(i+1));
  // add all attachment files at 1-n
  if (args.length > 4)
  {
    for (int j=4;j<args.length;j++)
    {
      HashMap hm = new HashMap();
      hm.put("filename",args[j]);
      hm.put("content-type","application/"+getExtension(args[j]));
      hm.put("content",loadFile(args[j]));
      hm.put("encoding","base64"); // Always use base64 encoding
      al.add(hm);
    }
  }
  msg.setObject(al);
  sender.send(msg);
}

Creating your own Transformer

The TextMessageTransformer and the MultipartTransformer are sufficient for most use cases. However, consider the case where you have already a working infrastructure where you send events to topics. For example, if a customer registers on a website and there will be a message published containing the new customer record in XML form. So you could easily write a custom transformer that extracts the relevant data including eMail address out of the XML and send him a "Welcome to our site!" eMail. You only have to create an outbound bridge with your custom transformer and let the bridge listen to the particular topic.

To create a custom transformer, you have to implement one of the following interfaces:

com.swiftmq.extension.javamail.outbound.Transformer

or

com.swiftmq.extension.javamail.outbound.Transformer2

Then create a jar file including your transformer class and all further custom classes you use and put it into the JavaMail Bridge Swiftlet deployment directory. The Swiftlet will be automatically redeployed and you can define your bridge.

Inbound Bridges

An inbound bridge is bound to a queue or topic where it sends JMS messages. It receives JavaMail messages from an account of a configured mail server either by POP3 or IMAP, respectively. The format of the JMS messages is dependent on the transformer class of the inbound bridge. The JavaMail message will be transformed into a JMS message and will be sent to the configured queue or topic.

Creating an Inbound Bridge

A queue or a topic serves as an output target to the inbound bridge. Before you create the bridge, ensure that the queue or topic exists.

Use the SwiftMQ Explorer App, connect, and select the JavaMail Bridge Swiftlet / Inbound Bridges:

After clicking Create a new Entity you'll see a dialog where you can specify your bridge configuration:

Field description:

Error Policy

Each inbound bridge has an attribute Error Policy which defines how to proceed in case the transformation fails (transformer throws an exception). Possible values for the error policy are:

Protecting against Denial of Service Attacks

Keep in mind that you open SwiftMQ to the outside world once you create an inbound bridge. Someone could easily flood the mail account of your inbound bridge with a large number of huge messages which in turn will bring your JMS clients down. To protect against such denial-of-service attacks you can limit the maximum size of the messages themselves and further limit the number of messages to retrieve within one interval. For example, you can define a retrieve interval of 10 minutes (600000 ms), limit the maximum number of messages to retrieve within one interval to 10, and finally set the maximum size of messages to 1 MB (1024 KB).

Creating Default Properties

The JMS message which will be generated from a JavaMail message can be enriched by JMS message properties. For example, you can create a default property that identifies the message to be created by this bridge and use it later in a message selector at your JMS client.

To define default properties, select the Default Properties node of your newly created bridge:

Then specify a default property:

Repeat these steps to create additional default properties.

Defining Property Translations

A property translation defines a translation from any valid Mime mail header (e.g. MessageID, Received, Content-Type, X-Mailer) into a JMS message property. The following mail header names are keywords and have special meaning/handling:

• sender: The sender's eMail address.

• from: The From eMail address.

• to: The To recipient's eMail address.

• cc: The cc recipient's eMail address.

• bcc: The bcc recipient's eMail address.

• subject: The default subject.

The translation will be done after setting the default properties and before the actual message transformation will be done. Therefore, the translation overwrites default properties and may be overwritten from the transformer.

To define a property translation, select the Property Translations node of your newly created bridge:

Then specify a property translation:

Here is a translation of the mail's Message-ID header into JMS property MailMessageID:

Repeat these steps to create additional property translations.

Defining JavaMail Properties

Depending on the connected mail server products (e.g. one bridge Sendmail, another one Kerio Mailserver), it may be necessary to configure different sets of JavaMail properties for each bridge.

The properties are used to create the JavaMail Session object which is done when the resp. bridge is enabled. So whenever a property is added, removed or changed, the bridge must be disabled and reenabled to activate the changes.

To define a JavaMail property, select the JavaMail Properties node of your newly created bridge:

Then specify a JavaMail property:

Repeat these steps to create additional JavaMail properties.

Activating the Bridge

All necessary configurations have been finished now and you can activate the bridge by checking the Enabled attribute. Then save the configuration. The bridge is now active and is listening to the input queue or topic, respectively.

Inbound Message Transformer

An inbound message transformer is responsible for transforming a JavaMail message body into a JMS message body. It hides the actual message content and structure from the rest of the bridge. Therefore, a JMS client receives JMS messages which correspond with the configured transformer. Since transformers are pluggable, a developer can create his own transformer class which he uses for his JMS clients. This custom transformer class can use custom classes in an ObjectMessage, for example.

For convenience, the JavaMail Bridge Swiftlet includes 4 pre-built inbound transformers which fit most requirements: 2 TextMessageTransformers that use TextMessages, and 2 MultipartTransformers which use ObjectMessages with a java.util.ArrayList including text and attachments.

Error Policy

Each inbound bridge has an attribute error-policy that defines how to proceed in case the transformation fails (the transformer throws an exception). Possible values for the error policy are:

There are 2 message properties used to flag the generated JMS messages whether the transformation process succeeded or not:

If JMS_SWIFTMQ_JAVAMAIL_ERROR is true, the body of the JMS message is undefined and the JMS_SWIFTMQ_JAVAMAIL_ERROR_TEXT can be used to log the message or to send a notification to the mail sender in case a property translation has been defined on the from address.

com.swiftmq.extension.javamail.inbound.TextMessageTransformer

The TextMessageTransformer accepts JavaMail messages with or without attachments. It uses the first body part with MIME type text/plain and transforms it into a JMS TextMessage. It's a very basic transformer. Following the relevant parts of a JMS client which receives a TextMessage from an inbound bridge with a configured TextMessageTransformer.

Example:

for (int i = 0; i < nMsgs; i++)
{
  TextMessage msg = (TextMessage) receiver.receive();
  boolean isError = msg.getBooleanProperty("JMS_SWIFTMQ_JAVAMAIL_ERROR");
  if (isError)
  {
    System.out.println("Error: " + msg.getStringProperty("JMS_SWIFTMQ_JAVAMAIL_ERROR_TEXT"));
  } else
  {
    System.out.println(">>> New Message from " + msg.getStringProperty("CustomerEMail"));
    System.out.println(msg.getText());
    System.out.println("<<< New Message");
   }
}

For this example, the inbound bridge has to have a property translation from the from mail header into the CustomerEMail message property.

com.swiftmq.extension.javamail.inbound.GenericTextMessageTransformer

The GenericTextMessageTransformer works exactly as the TextMessageTransformer except it uses text/*to lookup of the actual message to transform it into a JMS TextMessage. This transformer is useful for mails with a single part of MIME type text/html or text/plain. For example, if a mail is received with a single part of MIME type text/html and the TextMessageTransformer is used, the mail is not transformed because TextMessageTransformer looks for a text/plain MIME type. Therefore, you have to use GenericTextMessageTransformer to get the mail transformed. The JMS TextMessage will contain the HTML formatted mail text.

com.swiftmq.extension.javamail.inbound.MultipartTransformer

The MultipartTransformer generates an ObjectMessage containing a java.util.ArrayList. We have taken this approach to avoid having vendor-specific classes at the JMS client. The ArrayList has the following structure:

The bridge adds as many HashMaps to the ArrayList as attachments are contained in the JavaMail message. Each HashMap contains the following properties:

The following example contains the relevant code snippets of a JMS client which receives mails with attachments. It saves the attachments in the corresponding files. As you will see, it's very easy:

Example:

for (int i = 0; i < nMsgs; i++)
{
  ObjectMessage msg = (ObjectMessage) receiver.receive();
  boolean isError = msg.getBooleanProperty("JMS_SWIFTMQ_JAVAMAIL_ERROR");
  if (isError)
  {
    System.out.println("Error: " + msg.getStringProperty("JMS_SWIFTMQ_JAVAMAIL_ERROR_TEXT"));
  } else
  {
    ArrayList al = (ArrayList) msg.getObject();
    System.out.println(">>> New Message from " + msg.getStringProperty("CustomerEMail"));
    System.out.println(al.get(0));
    System.out.println("<<< New Message");
    for (int j = 1; j < al.size(); j++)
    {
      HashMap map = (HashMap) al.get(j);
      System.out.println("Filename    : " + map.get("filename"));
      System.out.println("Content-Type: " + map.get("content-type"));
      byte[] b = (byte[]) map.get("content");
      BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream((String) map.get("filename")));
      bos.write(b);
      bos.flush();
      bos.close();
    }
  }
}

com.swiftmq.extension.javamail.inbound.GenericMultipartTransformer

The GenericMultipartTransformer works exactly as the MultipartTransformer except it uses text/* to lookup the actual message to transform it into a JMS ObjectMessage. This transformer is useful for mails with a single part of MIME type text/html or text/plain. For example, if a mail is received with a single part of MIME type text/html and the MultipartTransformer is used, the mail is not transformed because MultipartTransformer looks for a text/plain MIME type. Therefore, you have to use GenericMultipartTransformer to get the mail transformed. The JMS ObjectMessage will contain the HTML formatted mail text at element 0 of the ArrayList.

Creating your own Transformer

The TextMessageTransformer and the MultipartTransformer are sufficient for most use cases. However, there might be cases where you want to create your own content, e.g. XML content in a TextMessage. To do this, you can create your own custom transformer.

To create a custom transformer, you have to implement the following interface:

com.swiftmq.extension.javamail.inbound.Transformer

Then create a jar file including your transformer class and all further custom classes you use and put it into the JavaMail Bridge Swiftlet deployment directory. The Swiftlet will be automatically redeployed and you can define your bridge.

Inbound Mail Filter

Mail filters can be attached to inbound bridges and reject unwanted eMails. The following mail filter types are available:

• Header mail filter.

• Body mail filter.

• Attachment mail filter.

• Size mail filter.

Mail filters can be chained and so make complex filtering possible. Each incoming eMail is checked against the configured filters and might be deleted or rejected and bounced back to the sender, depending on the configuration.

Mail Filter Configuration

To create a new mail filter, go to folder Mail Filters and click Create New Entity ...:

Click on Create a new Entity:

A mail filter consists of the following general attributes:

Each mail filter has different specific properties which can be created here:

Click Create a new Entity:

Header Mail Filter

A header mail filter can check the following eMail headers:

• from

• to

• cc

• bcc

• reply-to

• subject

The header name, e.g. subject, must be specified as a property name and a regular expression as the value. In the screenshot above, the mail filter checks the subject of the content of the word VIAGRA. Multiple properties with different headers can be defined and are handled like an and condition. For example, if the inbound bridge only accepts eMails from a particular domain and with a keyword in its subject, a from and subject property with the appropriate regex needs to be defined.

Body Mail Filter

A body mail filter checks the eMail body against the regular expressions of the filter properties. Multiple properties can be defined and are handled like an and condition. The name of the property can be freely selectable. The value contains the regular expression. For example:

Note that the mail filter uses DOTALL for the regex so the regex doesn't need to care about linefeeds.

Attachment Mail Filter

This filter checks the MIME-type of attachments. The name of the property must be mime-type and the value of the MIME-type is checked against those of the attachments. The value is NOT a regular expression but a regular MIME-type, e.g. application/pdf for PDF documents or application/* for everything under the application media type. Only 1 property mime-type can be defined. To filter multiple attachment MIME types, multiple filters can be defined.

The following attachment filter lets only pass PDF documents:

Size Mail Filter

A size mail filter checks the size of the eMail. There can only 1 filter property with the name max-size be defined. The value of the property is the maximum size of an eMail in KB. Setting Reject on Match to false has no effect on this mail filter. The following example defines a size mail filter that rejects all eMail with a size greater than 1 MB:

Chaining of Mail Filters

Mail filters can be easily chained to create more complex filters. Each filter of the chain is handled in an or fashion. For example, to create a filter for an internal support system with the following conditions:

• Sender must be from a wombat.com domain.

• Subject must contain TICKET#.

• Body must not contain VIAGRA, PORN.

• Attachment accepted is PDF files only.

• eMail size must be less or equal to 5 MB.

this chain needs to be defined (covers the whole configuration from the routerconfig.xml):

<swiftlet name="xt$javamail">
  <inbound-bridges>
    <inbound-bridge name="support-inbound" enabled="true"
                    mail-host="mx.wombat.com" mail-host-account-name="xxx" mail-host-account-password="xxx"
                    mail-host-port="143" protocol="imap" target-name="support-inbound"
                    transformer-class="com.swiftmq.extension.javamail.inbound.MultipartTransformer">
      <default-properties/>
      <mail-filter-definition mail-filter-reject-from-address="noreply@wombat.com"
                              mail-filter-reject-queue="support-reject">
        <mail-filters>
          <mail-filter name="01"
                       filter-type="header"
                       rejection-message="This is an internal support system for wombat.com only!"
                       return-to-sender="true">
            <filter-properties>
              <filter-property name="from" value=".*@wombat.com"/>
              <filter-property name="subject" value=".*TICKET#.*"/>
            </filter-properties>
          </mail-filter>
          <mail-filter name="02" filter-type="body">
            <filter-properties>
              <filter-property name="01" value=".*VIAGRA.*"/>
            </filter-properties>
          </mail-filter>
          <mail-filter name="03" filter-type="body">
            <filter-properties>
              <filter-property name="01" value=".*PORN.*"/>
            </filter-properties>
          </mail-filter>
          <mail-filter name="04" filter-type="attachment"
                       reject-on-match="false"
                       rejection-message="Only PDF attachments accepted!"
                       return-to-sender="true">
            <filter-properties>
              <filter-property name="mime-type" value="application/pdf"/>
            </filter-properties>
          </mail-filter>
          <mail-filter name="05" filter-type="size"
                       rejection-message="We don't accept eMails greater than 5 MB!"
                       return-to-sender="true">
            <filter-properties>
              <filter-property name="max-size" value="5120"/>
            </filter-properties>
          </mail-filter>
        </mail-filters>
      </mail-filter-definition>
      <property-translations/>
    </inbound-bridge>
  </inbound-bridges>
  <outbound-bridges>
    <outbound-bridge name="support-reject" enabled="true" smtp-host="mx.wombat.com" source-name="support-reject">
      <default-headers/>
      <header-translations>
        <header-translation name="01" message-property="from"/>
        <header-translation name="02" mail-header="to" message-property="to"/>
        <header-translation name="03" mail-header="subject" message-property="subject"/>
      </header-translations>
    </outbound-bridge>
  </outbound-bridges>
</swiftlet>

Reject Configuration

Whenever an eMail is rejected and the respective mail filter is configured to send the mail back to the sender, a message is stored into a reject queue which must serve as the input queue for an outbound bridge. 2 properties can be defined to configure the reject sender eMail address and the reject queue name:

The JMS message stored in the reject queue is a JMS TextMessage so the appropriate outbound bridge must have a TextMessageTransformer. The message properties set in the JMS TextMessage are:

• from

• to

• subject

The outbound bridge must have the appropriate property translations defined.

Job Scheduling

The JavaMail Bridge Swiftlet registers jobs in job group JavaMail at the Scheduler Swiftlet:

These jobs can be scheduled via the Scheduler Swiftlet to run at specific times or in intervals, based on calendars and so on.

Outbound Bridge

The Outbound Bridge job activates an outbound bridge on job start and deactivates it on job stop. The name of the bridge must be specified as a parameter. The job requires setting a maximum runtime to deactivate the bridge. Otherwise, it would be active forever.

The implementation of the Outbound Bridge job is quite simple. It sets the enabled attribute to true on job start and to false on job stop. Therefore, an outbound bridge that should run as a job should be initially disabled.

Inbound Bridge

The Inbound Bridge job activates an inbound bridge on job start and deactivates it on job stop. The name of the bridge must be specified as a parameter. The job requires setting a maximum runtime to deactivate the bridge. Otherwise, it would be active forever.

The implementation of the Inbound Bridge job is quite simple. It sets the enabled attribute to true on job start and to false on job stop. Therefore, an inbound bridge that should run as a job should be initially disabled.

Installation

The installation takes place via 'hot deployment'. See the documentation of the Deploy Swiftlet for further information.

Configuration

The configuration of the JavaMail Bridge Extension Swiftlet is defined within the element

      <swiftlet name="xt$javamail" .../>

of the router's configuration file.

Attributes of Element "swiftlet"

Definition

Values

Element List "outbound-bridges", Parent Element: "swiftlet"

Outbound Bridges. This element list contains zero or more "outbound-bridge" elements with this template definition:

Definition

Values

Element List "header-translations", Parent Element: "outbound-bridge"

Header Translations. This element list contains zero or more "header-translation" elements with this template definition:

Definition

Values

Element List "default-headers", Parent Element: "outbound-bridge"

Default Headers. This element list contains zero or more "default-header" elements with this template definition:

Definition

Values

Element List "javamail-properties", Parent Element: "outbound-bridge"

JavaMail Properties. This element list contains zero or more "javamail-property" elements with this template definition:

Definition

Values

Element List "inbound-bridges", Parent Element: "swiftlet"

Inbound Bridges. This element list contains zero or more "inbound-bridge" elements with this template definition:

Definition

Values

Element "mail-filter-definition", Parent Element: "inbound-bridge"

Definitions of inbound Mail Filters.

Definition

Values

Element List "mail-filters", Parent Element: "mail-filter-definition"

Mail Filter. This element list contains zero or more "mail-filter" elements with this template definition:

Definition

Values

Element List "filter-properties", Parent Element: "mail-filter"

Filter Properties. This element list contains zero or more "filter-property" elements with this template definition:

Definition

Values

Element List "property-translations", Parent Element: "inbound-bridge"

Property Translations. This element list contains zero or more "property-translation" elements with this template definition:

Definition

Values

Element List "default-properties", Parent Element: "inbound-bridge"

Default Properties. This element list contains zero or more "default-property" elements with this template definition:

Definition

Values

Element List "javamail-properties", Parent Element: "inbound-bridge"

JavaMail Properties. This element list contains zero or more "javamail-property" elements with this template definition:

Definition

Values

CLI Commands During Deployment

This Swiftlet performs the following CLI commands during deployment:

  cc /sys$threadpool/pools
  new javamail.outbound
  new javamail.inbound
  cc /sys$threadpool/pools/javamail.outbound/threads
  new extension.xt$javamail.outbound.%
  cc /sys$threadpool/pools/javamail.inbound/threads
  new extension.xt$javamail.inbound.%

CLI Commands During Undeployment

This Swiftlet performs the following CLI commands during undeployment:

  cc /sys$threadpool/pools
  delete javamail.outbound
  delete javamail.inbound