Mail Integration

To act as a part of an e-mail system, imip-agent provides a number of programs that may be invoked by mail transfer agents (MTAs) upon sending or receiving messages. In order to uphold portability and to minimise configuration issues, these programs need only be registered as simple mail handlers or transports, thus potentially supporting a wide range of MTAs.

Once imip-agent has processed a message, it may then deliver it to its intended recipient. The mail storage systems that may receive messages from imip-agent need only support the delivery mechanisms used by imip-agent. Otherwise, few constraints should be imposed by each kind of system on the other.

mail_integrationIncoming mailPerson routerResource routerPerson handlerResource handlerRecipient databaseSchedulingMailboxes(Cyrus, Dovecot, ...)Free/busy

The following mail integration topics are described:

MTAs

Currently, imip-agent supports Exim and Postfix, although this support should be readily broadened, and offers configuration resources for these supported systems so as to allow imip-agent to be deployed within existing mail-sending and delivery infrastructures.

Identifying Recipients

Integrating imip-agent

Notes

Exim

Routers identify recipients of mail that shall be handled by imip-agent

Transports invoke imip-agent programs

Exim is widely deployed as the default MTA for Debian. Consequently, it is desirable to support this software in imip-agent.

Postfix

Virtual aliases identify recipients of mail that shall be handled by imip-agent

Transports invoke imip-agent programs

Postfix is also widely deployed and is sometimes preferred by administrators.

Some hints on mail system configuration can be found in the MTA guide.

Identification of Recipients

In principle, any mechanism supported by the MTA can be used to identify recipients; imip-agent does not employ identification mechanisms of its own. Thus, the task of identifying recipients is one of MTA configuration, with the following mechanisms tested:

Identification Mechanisms

Tested with...

LDAP

Exim, Postfix

Simple (list-based identification)

Exim, Postfix

It is worth repeating that imip-agent does not try and validate users. Once the MTA has decided that a recipient can actually receive a message, and once that message is passed to one of the agent programs, the software will process that message and record information for the recipient in the filesystem structures for the user.

See the usage guide for information on preparing data stores for users in advance of any mail being received for them.

The Calendar System Address

Since imip-agent may send messages on behalf of calendar users, the address it uses to do so must be recognised by the MTA. This may be done by adding an entry to the /etc/aliases file such as the one defined in the conf/aliases.example file:

calendar: root

More suitable routing can be defined as desired. See the MESSAGE_SENDER setting defined in the config.txt file described in the configuration guide.

Invoking the Agent Programs

Regardless of identification or delivery mechanisms, the imip-agent software must be integrated into the mail processing pipeline so that messages can be interpreted and processed. This is done by configuring the MTA's transport mechanisms.

Delivery

To deliver messages to their ultimate recipients after having processed them, imip-agent currently employs either local SMTP connections or LMTP. There is nothing in principle preventing imip-agent from also supporting other common delivery mechanisms, however.

Delivery Mechanisms

Tested with...

Local SMTP

Exim, Postfix

LMTP

Exim, Postfix

See the mailbox integration guide for a brief overview of configuring mail storage solutions.