On Mon, 31 May 2004, Dave Crocker wrote:
An elaboration on the second diagram occurs to me, with some
clarification of the terminology:
2. How do we model the components and downstream interactions of srv2 and
pc2:
This diagram applies directly to the email system at the University of
Cambridge. Some annotations by me to the right...
| SMTP
+---MTA----+
| |
| messages | MTA queue
| |
+----------+
| LMTP
+--<srv1>--+
| | MDA
| messages |
| | server-side message store (inbox)
+----------+
| POP (usually)
+--<pc1>---+
| |
| messages | client-side message store
| |
+----------+
Messages are retained on pc1 and not on srv1.
My annotations above apply to this scenario. In this case the client may
use sieve to direct POPped messages to different mailboxes.
The other common scenario uses our MDA's sieve to direct messages and
IMAP to access them, in which case the client-side store is optional and
mirrors the server-side message store.
This is not particularly clean from the architectural point of view, as
indicated by the fact that sieving may happen in two places dependent on
the usage model.
And the reason for elaborating the MTA depiction is to raise the
question about the distinction between the MTA and srv1. When pc1 takes
over responsibility for a message, as a result of a moving it to the
pc1, what is the difference between MTA's holding messages and srv1's
holding messages? Both are used for queuing, and both hand off
responsibility to the next machine in the sequence.
The MTA queue is processed with a push model. Messages usually do not stay
there long (less than a second), but may be delayed if srv1 is down or if
the recipient has run out of disk quota etc. Delivery is still incomplete,
and may fail causing the message to be bounced. Any resource limits (e.g.
disk space) are usually system-wide.
The server message store is processed with a pull model. Messages often
stay there for hours (e.g. overnight) or indefinitely. Delivery has
completed (the Return-Path: header is now present etc.), so the message
will no longer bounce. Disk space limits are per-user.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/