MailTransport Guide
The MailTransport manages one or more mailprocessors.
Each mailprocessor is associated with one remote mailbox on a POP or IMAP server.
The mailprocessor periodically polls the remote mailbox for new email messages.
When a new email message is detected, the mailprocessor issues a request
to a URI and includes the email message as an argument.
Configuration
The MailTransport is configured with information in the resource
ffcpl:/etc/MailTransportConfig.xml
.
In general the MailTransport configuration is dynamically managed (see below)
however the transport configuration must provide at least a URI identity for the
MailTransport and may include optional mailprocessor configurations.
<MailTransportConfig>
<id>URI idenitifier for this transport</id>
...Optional mailprocessor configurations...
</MailTransportConfig>
The mailprocessor configuration syntax is described in the documentation for the
mailproc-register accessor.
Dynamic Management of MailProcessors
A MailTransport may be dynamically configured with multiple mailprocessors
using the following accessors.
MailProcessors added dynamically persist across transport restarts including
hot, cold or full shutdown of NetKernel.
The currently active MailTransport configuration is always available at
ffcpl:/etc/MailTransportConfig.xml
(Note: the dynamic persistent configuration overrides the original master configuration using the scratch
filesystem of the fulrcum module).
The transport configuration can be reset to the original configuration by issuing a request
to active:mailprocConfig-flush
.
MailProcessors
A mailprocessor periodically polls a POP3 or IMAP mailbox for unread mail messages.
When a new email message is found it is retrieved from the mailbox and
a request for the processURI is issued using the following format:
[proccessURI]+header@[headerURI]+body@[bodyURI]+attachment1@[attachment1URI]...
Where header is a
MessageHeaderAspect
and body, attachmentN are
instances of MessageBodyAspect.
In the event that the body contains multipart/alternative text messages (eg HTML with plain/text alternative)
the request will instead have the form...
[proccessURI]+header@[headerURI]+body1@[bodyURI]+body2@[bodyURI]+attachment1@[attachment1URI]...
The message header has the same form as that used to specify the delivery of a message with the
SMTPServer
(ie <email> root element
with one or more to, from, subject etc tags). In particular the metadata, including filename, of any
attachements is provided in the header.