Key Web Links:
www.citadel.org, Citadel home site.
Application Layer Protocol, telling what Citserver can be asked to do.
Uncensored
Citadel Server. (Registration required.) The Citadel Support
room on this server is where you get support.
I'm going through my design for an ideal PIM suite, and evaluating Citadel in the server role and its Webcit web interface, or Thunderbird plus Lightning, as the client.
Supports contacts, calendar, tasks and notes. Good.
E-mail management is a major theme in Citadel. UCLA-Mathnet's present design is a UW-IMAP server on each home directory server, holding the mail for users resident there, to collect all eggs in one basket: a person loses service if his homedir server goes down, but not if a different server is lost. We would have to seriously consider using a Citadel instance on each homedir server to provide mail over IMAP.
Citadel is capable of replicating rooms
(collections of PIM
and other objects) among multiple instances.
Webmail is very popular at UCLA-Mathnet (using Horde). Citadel would be an ideal replacement for Horde if it served IMAP itself. On the other hand, when a faculty member's password is stolen by a keystroke logger, spammers utilize webmail, authenticating as him, getting us on blacklists. In this case it's an advantage to put the webmail server on a separate machine.
Citadel can set up readonly or
read-write access to rooms
with what looks like the kind of
granularity that we need.
Citadel has a long history of serving Internet chat rooms. Likely it has a lot of exposure to hackers, and corresponding bug fixes. We need to get some more explicit information on this issue from the developers.
Citadel supports a lot of protocols. For each of them a SSL/TLS connection can be activated (STARTTLS or equivalent) (except see XMPP).
Citadel/504 -- This is the IANA-registered native chat room protocol.
SMTP -- Sending and receiving e-mail. Includes ESMTP. But the controls and restrictions on authenticated access are a lot less elaborate than for Postfix, and likely we would use Citadel as the Mail Delivery Agent (MDA) but not the Mail Submission Agent (MSA) which accepts incoming mail from the spammers. Inter-mailer transport is via LMTP, which Citadel and Postfix both support (including UNIX domain sockets, which are preferable in this context).
IMAP -- Passing mail to the user's reader software. IMAP is a major theme of Citadel. It can also be used to get access to PIM objects. See the discussion previously about replacing our existing IMAP servers with Citadel.
POP3 -- Analogous to IMAP but deprecated in our environment.
XMPP -- As a chat room server, Citadel has been upgraded to use the modern instant message protocol, XMPP. It interoperates with the native chat room protocol. The current version has a regression in SSL support in XMPP -- which my testing indicates has been fixed; I have been using SSL with no problems.
HTTP -- Citadel includes a web client
called Webcit that runs
on the server and translates the native protocol to semantically
approprite Ajaxified web pages, e.g. contacts, calendars, or mail
folders. In other words, you can use all features of Citadel from any
web browser (on which Ajax works). It also provides semantic support
for the GroupDAV PIM protocol, which in this context interoperates with
iCalendar (iCal). However, it does not do the superior CalDAV
protocol.
Citadel includes the Webcit web client, and a text-mode (ncurses) client of the kind commonly used for chat rooms, but for GUI desktop support the user needs something like Thunderbird with Lightning. It remains to be seen how flexible client software is in dealing with Webcit's supported protocols, on Android and iPhone. A back version of Android's web browser has trouble with the Ajax login form, but it also has trouble with other seemingly innocent forms.
Citadel can be configured to use PAM authentication, and this is the mode I use for testing, but it does not do real SASL, and in particular it knows nothing of GSSAPI. Webcit uses either its own login form (HTTP) or the protocol-specific analog of Plain Authentication (loginID and password). This is the kind of authentication commonly provided on mail reading software and groupware, and while I would like something better, we can't give Citadel a negative rating for doing what everyone else does.
I would like to store both PIM objects
and mail in the users' home directories. But Citadel has a Berkeley DB
file where all the content is saved. At Mathnet we make a special backup
of users' mailboxes and restore them on request. We would need to write
our own utilities to extract room
content so as to continue this
service.
A normally supported mode for Citadel is to have several federated servers, with some rooms replicated on all servers and others (such as personal mailboxes) accessible on only one. However, there is no indication in the documentation that Citadel could federate with other servers of a foreign type, e.g. to read or deposit mail or PIM objects in a folder belonging to the user but on a Zimbra or generic IMAP server.
Citadel includes LDAP support, both RFC 4519 (POSIX) and Windows Active Directory. When we move to LDAP, Citadel can move with us.
This is not on the list of requirements, but other organizations make good use of instant messaging to coordinate work in the field, and there is a good chance that it would also prove useful to UCLA-Mathnet. Instant messages can be sent and received via native (text-based) Citadel, Webcit and XMPP; all interoperate.
Going beyond the feature checklist from the ideal PIM design, perhaps the best way to evaluate Citadel is to lay down a sequence of operations which a client user might actually do that covers all the major features, and see how Citadel behaves on this scenario.
The user configures his mail reader, calendar software, XMPP client, etc. with Citadel's URI, and specifying mandatory TLS and mandatory authentication (the latter for SMTP). What is the needed URI, and does our documention show it? Can Citadel and the client accomplish the connection? What possibilities are there for single sign-on (transitive authentication)? (Look for GSSAPI, X.509, others.)
If you have your own departmental certificate authority, make sure to make its root certificate available to the clients before starting the test, to avoid embarrassing complaints that the server's certificate is not trusted. If the server presents a self-signed certificate with a Common Name of '*' then you have forgotten to set up the keys directory for citserver or webcit; either program will then manufacture a self-signed certificate with dubious trust value (rather than just exiting).
HTTPS for Webcit -- Works, no problems. Firefox and Opera use their own special root certificate storage.
IMAP with Thunderbird -- Works, no problems. Uses its own root certificate storage.
IMAP with Pine/Alpine -- Works, no problems. Uses OpenSSL root certificate storage (/etc/ssl/certs).
SMTP (outgoing mail) -- My MTA will present a X.509 certificate, but Citadel does not use it for authentication; it only does Plain authentication. Similarly when Citadel connects to another MTA that could accept a X.509 certificate. For a smart host (to which all outgoing mail is sent) you can specify it as user:password@host:port, to use Plain authentication, but this is not per-user authentication.
GroupDAV/iCalendar with Thunderbird -- Works, no problems.
XMPP -- Works. Pidgin uses its own root certificate storage and has a very limited collection of commercial roots. Pidgin, on the Add/Modify Account tab, needs:
Create the account on the serversince it is already created.
Use Webcit to compose a mail message and send it out.
The web-based editor for composition works fine except for one complaint: an absolute font size is set and it comes out too small on my display.
Yes.
No, this is not supported on a per-user basis. (You can give one user and password for sending to a fixed outgoing relay (smart host).)
The default sender is First_Last@serverhost, e.g. Jim_Carter@simba.math.ucla.edu. Under Advanced - Edit Your Contact Information, find Primary E-Mail Address and fill in the desired sender address, e.g. jimc@math.ucla.edu. However, the server must be configured to allow users to masquerade this domain. See Administration - Domain Names and Internet Mail Configuration - Masqueradable Domains.
*** Off-site mail is sent out with the recipient unmodified. However, for internal recipients it expects to send to what's in the Global Address Book, i.e. First_Last. I have not yet figured out how to get it to use the UNIX loginID.
It isn't mucked up with advertising or lurid templates, but it comes out as multipart/alternative with text and HTML forks, and as far as I can see there's no way to turn this off.
Reconfigure the mail infrastructure to deliver mail to Citadel, and send some spam and some non-spam.
Yes.
*** No, either all mail is run through SpamAssassin during submission, or none is. Spam is rejected by a status code 5xx to the sender. We require per-user opt-in for legal reasons, so this would have to be hacked.
*** I tried and failed to get it to run all the mail through SpamAssassin.
Yes.
Not tested due to problems connecting to SpamAssassin (spamd). But Citadel's policy is to reject spam with 5xx, never deliver it.
Use Webcit to read the mail received in the previous step.
Yes.
Yes.
Yes.
**Need to test.
Yes. The signature is stored within Citadel; it isn't reading $HOME/.signature.
Yes.
Read mail with separate client software. Does Citadel deliver the mail using IMAP? Do client features work as usual? Can the client work around Mathnet's wacked-out namespace issue? (Or does Mathnet have to fix that, at long last, atomically with the installation of Citadel?) List of clients to check:
**** Citadel provides personal mail folders such as Drafts, Sent-Mail, etc. as subdirectories of the INBOX directory (folder). And it insists that they be used. At Mathnet (and probably elsewhere), the default folder would be just Drafts etc. at the toplevel of the namespace. So I had to edit my .pinerc file (using Pine's configuration editor), like this:
UW-IMAP: postponed-folder=~/Mail/Drafts
Citadel: postponed-folder=INBOX/Drafts
This is probably a showstopper because at the UCLA Mathematics Department we would have a great deal of trouble to get our users, many of them elderly, to adjust their GUI clients accordingly.
This is all using Webcit.
diarymode, to record past activities?
Try editing the room's parameters. Look formessage expire policyand either set it to a long time or to forever (either is allowed). In this context PIM objects aremessages. There is also an expire policy inherited from the floor containing the room.
The room aide (or general aide) can move a message out. It appears that the default configuration is to make the owner of a private room a room aide. (This can be turned off but we want it on.)
Citserver itself has these commands:
- ICAL sgi -- Emit server generated invitations to a meeting with listed participants.
- ICAL respond -- Victim responds to mail including a vEvent object (meeting invitation) by accepting or declining.
- ICAL conflicts -- Victim compares a vEvent to see if he already has conflicting meetings.
- ICAL handle_rsvp -- Meeting maker updates the vEvent according to whether the victim accepted or declined.
- ICAL freebusy -- Find when a given user is available for a meeting.
Wnat Webcit does with them needs some research.
In addition there are the ICAL getics and ICAL putics commands which bulkload the entire calendar: getics is to send it to the client and putics is to replace the entire calendar with uploaded material.
Do these clients behave normally with calendars served from Citadel? (Both viewing and creating events.)
The evaluation is similar to the calendar case with these additions:
Yes, and not only that, you can enable self-service subscription, with an e-mail confirmation message.
Do these clients behave normally with contacts served from Citadel? (Both viewing and creating them.)
Basically, the evaluation is the same as for the calendar, with these additions:
This should be tested on these clients:
Instant message activities to be tested:
Basic instant message chat -- Works, interoperates between Pidgin and Webcit
Are there buddy restrictions (i.e. do you need to establish a relation to chat)? You can chat with anyone, but presence notifications are sent only to buddies.
Presence: is the client notified when the buddy logs in and drops off? -- **** Yes, but logging out kills the buddy relation! This is bad, but it's an explicit design feature of the Citadel XMPP service implementation.
Fine grained presence: Can the participant set sub-states such
as do not disturb
or chatty
? Pidgin can send these.
But I have never seen them arrive at the partner's client.
Does Citadel propagate a signal that the buddy is typing? Pidgin can send this. Citadel does not forward it, possibly for the same reason it doesn't send fine-grained presence.
What other extensions are there, such as URL pass-through, attached files, or voice chat? -- If I correctly read RFC 3920, the server has no part in extensions: the client sends whatever XML stanza it pleases, the server is supposed to pass it on without interpretation, and the partner responds to the best of its ability, if any.
While Citadel contributes positively in our environment, it certainly is not perfect. Here is a list of items I've found, not too well organized. I'll try to annotate the issues as I fix, or don't fix them.
Using Opera-11.00. The browser
takes a long time to render each page, and from tcpdump it looks like it
does at least a HEAD request for each of at least 40 elements (Javascript,
CSS and icons). The main page has don't cache
headers, but the
rest appear to have a lifetime of at least 1 hour. (Needs more investigation.)
When you hit Advanced in the left sidebar, the page has this identifier as its page title. The same page title appears on all the pages under Your Info, and likely other dependent pages as well.
Administration - View the Outbound SMTP Queue: when you get into this page the only way you can get out is to hit a button (like Administration) in the left side bar.
I would very much like to use our Kerberos credentials to authenticate to Citadel. This would be on all relevant protocols: IMAP (highest priority), POP3 (deprecated in our environment), XMPP, and presumaby Citadel on 504. The latter two require convincing the clients to present the credential. Also important is single sign-on using Webcit. There is said to be a way to get Firefox to do GSSAPI, but it's also acceptable for Webcit to solicit a certificate when setting up the SSL connection, and to honor it if it's signed by our pet certificate authority.
On Webcit's login page, when
responding to a password guessing attack, it announces User Not Found
or
Wrong Password
as appropriate. The attacker can start by identifying
users, and then chew on their passwords. Better to just say Login
Incorrect
, which requires him to search a Cartesian product space, not
knowing if a particular target user even exists. This is how OpenSSH does it.
We are attacked in this way multiple times per day. (This issue was pointed
out by Chris.)
The Webcit session cookie (which is not restricted to secure connections) has no listed expiration date. It appears to be very volatile, disappearing possibly on a page reload. There is a cookie called WC_rooms_expanded which lasts until the end of time; its payload appears to be innocuous.
In Administration - Restart after paging
users, it shows a box titled Message to your Users
whose content
is didn't find Template [box_serverrestartpage] 21 21
, and it doesn't
restart.
It's supposed to send to a smart host
at otter.mine.nu:587. Viewing the outbound queue: connection refused.
Guess what, Postfix is not listening on that port. Because that feature is
not turned on, because CFT never uses it anyway for incoming mail. (Until
now, all mail was outsourced.) Exponential backoff running the queue is
good for scalability but a pain for debugging. I changed to localhost:25
and did /usr/local/citadel/sendcommand SMTP runqueue
and the message
was sent out.
The message was rejected by the recipient because the envelope said it was from jimc@jacinth.cft.ca.us. This is not publicly resolvable. It needs to use otter.mine.nu, which is a public name, although it doesn't accept incoming mail. This is set in Administration - Site Configuration - General. Changing the hostname requires restarting the server. Now the recipient swallows it.
If you submit a mail message when the queue is empty, Citadel will not ship it out immediately but rather will wait about 1 minute to run the queue. (Based on a sample size of 1 message.) This is not too unreasonable, but annoying to an impatient person. Here's a suggestion: if the queue hasn't been run for more than 1 minute, send the message immediately, otherwise wait for the next scheduled time.
The admin guide says that
Citadel always refuses third party relay from unauthenticated clients: an
incoming message must be addressed to a local user. To relay, the client must
authenticate. Default behavior is to toss the incoming body From
line
and rebuild it using the authenticated user name. This can be turned off, not
recommended.
Also, if an outside source sends in mail allegedly from your own domain, Citadel normally rejects it. This can also be turned off.
Citadel has a nice design where it runs messages through SpamAssassin before accepting them for delivery; it rejects spam with a 5xx status code. Unfortunately we can't handle that for legal reasons. UCLA-Mathnet needs per-user opt-in, and needs to deposit spam in a separate maibox (folder).
This is what a message looks like when sent by Citadel. I've excluded Received headers after the local Postfix got it.