Overview of sic!mail
Sicmail consists of a number of (open source) components written by
others, and quite a substantial amount of glue between. A lot of
thought has gone into choosing the feature set and implementing it in
an appropriate manner.
Most basically, of course, sicmail should be able to send and
recieve mail in a safe manner.
Chalmers, being a university, has a very distributed environment,
where every department is more-or-less autonomous. Sicmail must handle
this, letting sysadmins control their respective domains without being
able to control others'.
Although Chalmers is split this way, there is a centrally
managed Kerberos cell, which means that each user on campus has a
campus-wide username (called a CID) and password. Having email
addresses at more than one domain is common.
Users are also demanding, and should have a rich set of features
for their mail accounts, including (but not limited to) automatic
filtering, virus/spam-filtering, vacation autoresponses and personal
There must also, because of the scale, be a way of managing who may
change what. This must be possible without more than occasional
intervention by sicmail staff.
The following image tries to explain what's happening.
Incoming email enter the system through one or more email-addresses
(to the left). It is delivered to one or more mail accounts (to the
right) and/or email addresses external to this mail server (below),
possibly through a maillist (center).
All spam/virus/filtering is performed inside the mail account boxes
to the right, using each mail account's respective settings.
Important things to notice:
- Email addresses and account names do not have to match. The
address firstname.lastname@example.org is bound to
the account foo. Although there is
an account called pelle, it does not
receive mail sent to email@example.com, as that address is not
bound to that account. Mail sent to firstname.lastname@example.org is also not received by the
- Accounts can have many different email addresses, even at
different domains, bound to it. The account viktor has three addresses bound to it: email@example.com, firstname.lastname@example.org and email@example.com.
- Email addresses can be bound to more than one recipient. firstname.lastname@example.org is bound to the mail
account viktor, the external email address
email@example.com, and the internal
- Internal maillists deliver incoming mail to many recipients. The
reason to have them is that ordinary users can be given control over
- The internal maillist name, e.g. domain2-list-1 is only an identification. It is
not visible to the outside in any way, and specifically has nothing
to do with what email addresses are bound to it.
- Spam filtering, virus control and vacation responses happen
inside the mail account boxes to the right. You cannot have
virus control "on an email address", and cannot have an automatic
response for a maillist. Only the user owning the mail account can
control and use such features.
- Mail accounts are always named after the owner's CID.
The next question is who may do what. The rules are:
- Email addresses are created, modified and destroyed by the
administrators of the respective domain. All addresses @domain1.chalmers.se are controlled by the
administrators for the domain1.chalmers.se domain. Those
administrators can also assign other people as co-administrators for
- Maillists are created, modified and destroyed by domain
administrators. Administrators for a domain called
domain2.chalmers.se have the right to handle any maillist
whose name begins with domain2-. Note:
Creating a list does not mean that it is reachable from the
outside. You have to bind some email address to it first.
- Maillists can also have ordinary users assigned as
administrators. Such administrators can only modify the list (add
and remove recipients and admins), but not create and/or destroy
it. They also cannot affect which email addresses are bound to the
list (as they would need to modify a domain to do that).
- Mail accounts can be created and destroyed only by superusers
and so-called "addmins" (pun intended). Normally every user that has
a CID will get an account created automatically.
- Mail accounts can always be modified by the user that owns
them. Additional users can be added to an admin list.
- Domain administrators for domains that have email addresses
bound directly to an account can also modify it (in the example
above, the admins for the domain1.chalmers.se
domain may modify the account foo. Admins
for domain2.chalmers.se can, however,
not modify the bar account, as there
is no direct link between them.
All this configuration is stored in a MySQL database. To make the
interface friendlier, and to implement the access control rules above,
a network enabled configuration daemon (speaking a text command
protocol) acts as a frontend to the database.
This configuration server is called sicmail. It is
implemented in a framework called graal, and is often
referred to by that name. For power-users, you can talk directly to
this daemon and issue commands over SSL. There is a client which makes
this a bit friendlier, which can be downloaded from this server.
If you do not want to download that client, you can use https://mail.medic.chalmers.se/webgraal/ which is a web interface directly into the graal server.
For end users, however, the web application https://mail.medic.chalmers.se/cgi-bin/sicmail is much friendlier, being
graphical and reasonably beginner-friendly. It also speaks to the
graal server in the back-end.