PowerMail is a redundant & distributed system for receiving mail and storing it for users. The way PowerMail works is quite unorthodox, this document sets out how the different modules cooperate.
PowerMail only receives email and makes it available over POP. Furthermore, incoming email can be forwarded to other email addresses. Although most PowerMail installations will query a relational database for information about email addresses, messages are stored on disk.
The real strength of PowerMail lies in:
One single source of information about mailboxes. No /etc/passwd, no 'recipientdomains', or whatever. If a mailbox is listed in the userbase, it works.
Ability to scale. Distributed message hosting means that additional machines can be added on the fly without moving files around or growing filesystems.
Redundancy. Besides distributing messages over multiple machines, additional copies can be stored, leading to very high redundancy. Furthermore, it is easily possible to have multiple pop servers online at once, as well as multiple smtp servers, all talking to the same pool of messages. There is no single point of failure. And no NFS either.
Very high performance. PowerMail is about receving email. There is no queue, email is never bounced. Either
email is accepted or it is not - there is no way for the system to get jammed with incoming email. Messages
are sent straight to the disk. Retrieval works the same way, in reverse. On operating systems supporting this,
sendfile()
zerocopy TCP features are exploited for maximum throughput.
It is best to not compare PowerMail to traditional mailhosting solutions as this can be very confusing. Specifically:
There is no mapping between mailboxes and UNIX users. All user data is always read from the User Base, which is typically a relational database
Mailbox centric and not domain centric. A mailbox exists or it doesn't. There is no reason to configure which domains PowerMail is to host mailboxes for.
SMTP and POP daemons can be on different machines than the messages. PowerSMTP and PowerPOP do not access the disk directly - they contact the backends for that purpose.
Messages can live on multiple machines simultaneously and redundantly. A mailbox may span multiple machines.
PowerMail can best be thought of as mail hosting where adding a new mailbox consists of a single SQL insert statement.
The following concepts are used by PowerMail, followed by their specific meaning within PowerMail:
PowerMail contains an arbitrary number of Mailboxes. Contrary to existing practice, a mailbox name includes the domain name. A sample mailbox might be called 'info@company.biz'. PowerMail does not care which domain a mailbox resides under - the mailbox name includes the domain.
To know if a mailbox exists, the Userbase is queried. This will most often be a relational database. The stock PowerMail distribution works with MySQL. Besides storing which mailboxes exist, the Userbase also knows about Quotas and Mailforwarding.
A mailbox consists of messages. Each message is a single file on disk, even if it has multiple recipients. In other words, a single file can live in multiple mailboxes simultaneously. This means that a message with thousands of recipients is stored only once on disk.
The mentioned messages live on backends. Each backend is a very simpleminded fileserver. Typically, a single backend is used per host, unless that host has multiple filesystems, in which case a backend is started for each filesystem. Backends can be additively configured. A backend is accessed via the pplistener command.
Backends store messages as files on disk. Each message is one file.
Each message may live on multiple backends. This can be used both for redundancy as well as for bandwidth purposes. It is possible to assign storage backends to specific locations and make sure that POP traffic thus remains local.
Mail is received over the Simple Mail Tranport Protocol, SMTP. It is transferred to the reader via the Post Office Protocol, version 3, POP3.
The powersmtp daemon listens on the SMTP port (25) and checks with the Userbase if recipients exist. If they do, the message is received and sent to a backend. The recipient might also be a forwarded account, in which case the message is passed to the outgoing SMTP host.
The powerpop daemon listens on the pop3 port (110) and checks with the Userbase if the supplied user and password data exist in the database. If this is the case, all messages for this mailbox are retrieved from the backends. Duplicates are filtered out and the unified list is presented to the user.
Each backend runs the pplistener daemon which can be likened to a very simple ftp server. Each pplistener can be in read/write or in readonly mode. The latter might for example occur if the filesystem is full, or if the backend is about to be phased out and should accept no new data.