File: MailIntegration

package info (click to toggle)
imip-agent 0.3-2
  • links: PTS, VCS
  • area: main
  • in suites: experimental
  • size: 2,056 kB
  • sloc: python: 9,888; sh: 4,480; sql: 144; makefile: 8
file content (143 lines) | stat: -rw-r--r-- 5,157 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
= 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.

{{{#!graphviz
//format=svg
//transform=notugly
digraph mail_integration {
  node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Mail integration"];
  edge [tooltip="Mail integration"];
  rankdir=LR;

  mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan];

  subgraph {
    rank=same;
    personrouter [label="Person router"];
    resourcerouter [label="Resource router"];
    recipients [label="Recipient database",shape=folder];
  }

  subgraph {
    rank=same;
    personhandler [label="Person handler",style=filled,fillcolor=gold];
    resourcehandler [label="Resource handler",style=filled,fillcolor=gold];
    scheduling [label="Scheduling",shape=ellipse,style=filled,fillcolor=gold];
    freebusy [label="Free/busy",shape=folder,style=filled,fillcolor=gold];
  }

  mailbox [label="Mailboxes\n(Cyrus, Dovecot, ...)",tooltip="Mailboxes"];

  mail -> personrouter -> personhandler -> mailbox;
  mail -> resourcerouter -> resourcehandler

  recipients -> personrouter;
  recipients -> resourcerouter;

  personhandler -> scheduling;
  resourcehandler -> scheduling;
  scheduling -> freebusy;
}
}}}

== MTAs ==

Currently, imip-agent supports [[http://exim.org/|Exim]] and
[[http://www.postfix.org/|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.

{{{#!table
|| '''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|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:

{{{#!table
'''Identification Mechanisms''' || '''Tested with...'''
==
[[/LDAP|LDAP]] || Exim, Postfix
==
[[/Simple|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 [[../AgentPrograms|agent programs]], the
software will process that message and record information for the recipient in
the [[../FilesystemUsage|filesystem structures]] for the user.

See the [[../Usage|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|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
[[/Transports|transport mechanisms]].

== Delivery ==

To deliver messages to their ultimate recipients after having processed them,
imip-agent currently employs either local SMTP connections or
[[https://tools.ietf.org/html/rfc2033|LMTP]]. There is nothing in principle
preventing imip-agent from also supporting other common delivery mechanisms,
however.

{{{#!table
'''Delivery Mechanisms''' || '''Tested with...'''
==
[[/LocalSMTP|Local SMTP]] || Exim, Postfix
==
[[/LMTP|LMTP]]            || Exim, Postfix
}}}

See the [[../MailboxIntegration|mailbox integration guide]] for a brief
overview of configuring mail storage solutions.