Valid HTML 4.01 Transitional
Personal Information Manager Software

Evaluating Citadel

James F. Carter <>, 2011-01-30

Key Web Links:

Citadel versus Ideal PIM Client

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.

PIM Object Types

Supports contacts, calendar, tasks and notes. Good.

E-Mail Management

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.

Multi-User Access to PIM Objects

Citadel can set up readonly or read-write access to rooms with what looks like the kind of granularity that we need.

Network Service to Wild-Side Clients

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.

Services and Protocols Supported

Citadel supports a lot of protocols. For each of them a SSL/TLS connection can be activated (STARTTLS or equivalent) (except see XMPP).

Client Software

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.

Single Sign-On

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.

Location of PIM Objects

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.

LDAP Support

Citadel includes LDAP support, both RFC 4519 (POSIX) and Windows Active Directory. When we move to LDAP, Citadel can move with us.

Instant Message

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.

Usage Scenario

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.

Connect via TLS

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).

Compose Webmail

Use Webcit to compose a mail message and send it out.

Accept Incoming Mail

Reconfigure the mail infrastructure to deliver mail to Citadel, and send some spam and some non-spam.

Read Webmail

Use Webcit to read the mail received in the previous step.

Read Mail with GUI Client

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:

Calendar using Webcit

This is all using Webcit.

Calendar using GUI Client

Do these clients behave normally with calendars served from Citadel? (Both viewing and creating events.)

Contact List using Webcit

The evaluation is similar to the calendar case with these additions:

Contact List using GUI Client

Do these clients behave normally with contacts served from Citadel? (Both viewing and creating them.)

Task List using Webcit

Basically, the evaluation is the same as for the calendar, with these additions:

Instant Message (XMPP)

This should be tested on these clients:

Instant message activities to be tested:

Heterogeneous Complaints

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.

User Interface (Webcit)

Lame Use of Browser Cache

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.)

__CitadelSMTPspoolout__ as a Page Title

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.

No Tree Structure for Admin Mail Menu

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.


SASL, GSSAPI and Kerberos

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.

Helps Password Guessing Attack

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.)

Cookie Lifetime

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.

Administration and SMTP Server

Restart after Paging

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.

Doesn't Send Mail (fixed)

It's supposed to send to a smart host at 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.

Wrong Host Name (fixed)

The message was rejected by the recipient because the envelope said it was from This is not publicly resolvable. It needs to use, 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.

1 Minute Wait to Run SMTP Queue

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.

Authenticated SMTP (FYI, not a bug)

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.

Spam Suppression

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).

Electronic Mail

HTML Mail, Yuck

This is what a message looks like when sent by Citadel. I've excluded Received headers after the local Postfix got it.

Received: from (localhost [])
	by (Postfix) with ESMTP id 7DC3740FE0
	for ; Thu,  3 Feb 2011 22:42:32 -0800 (PST)
Date: Thu, 03 Feb 2011 22:41:42 -0800
Subject: Test message from Citadel
Message-ID: <>
From: "Jim Carter" 
MIME-Version: 1.0
X-Mailer: WebCit 7.85
Content-type: multipart/alternative; boundary=""
X-UID: 185025                                                  
Status: RO
Content-Length: 1072

This is a multipart message in MIME format.
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable -> -> Laguna, will laguna swa=
it? =20

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-155=
Email: (q.v. for PGP k=
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

(html)(body) -> -> Laguna, will l= aguna swallow it?

James F. Carter Voice 310 825 2897 FAX 310 2= 06 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA,=20= USA 90095-1555
Email: jimc (q.v. for PGP key)


My objections to the message are these:

Mandatory Mail Alias

The mailer wants to send from, but I need at least a Reply-To and preferably the actual From, saying

Try this: Go to the Mail room. Hit Advanced (in sidebar). In the lower right item group find Edit This Room. Pick the tab . . . I guess that's now how you configure it.

Dothbert replies: You configure your outgoing/incoming mail alias in your personal vCard.

How to do that: (A) Contacts - pick (or create) a vCard for your Display Name and fill in your Primary Internet E-mail Address and Internet E-Mail Aliases. Hmm, this was ineffective when jimc was the display name. Trying a display name of Jim Carter (with a space). That also was ineffective. (Odd, I now have 3 identical e-mail aliases.) Trying Jim_Carter. That also was ineffective. Under the Online Users tab you see yourself online and the first column gives a link to Edit something. You're editing your room, host and user name as shown in the Who is Online list.

Next try: Hit Advanced. Lower left corner, Your Info, Update Your Contact Information. I have a complete vCard there using Jim Carter (with a space) as the Display Name, and as the Primary Internet E-mail Address (which was not being used). Changing this to and removing the similar Internet E-Mail Alias: Ineffective, still using as the From address.

Use the source, Luke! Look at the GVEA command for a list of legal From addresses. Implemented in ./modules/vcard/serv_vcard.c subrt cmd_gvea. Content is CC->cs_inet_email (a string with the actual address, the primary one) followed by CC->cs_inet_other_emails. cs_inet_email is used many places. Possibilities are ./msgbase.c ./user_ops.c ./modules/vcard/serv_vcard.c . In the latter, vcard_upload_aftersave extracts field [M] from an altered vCard into these 2 memory areas. The same is done at login in vcard_session_login_hook. The card from which it is extracted is obtained by vcard_get_user(&CCC->user) which is defined in the same file. It's M.O. is to call CtdlMailboxName(u, USERCONFIGROOM) where u is a struct ctdluser. USERCONFIGROOM = My Citadel Config and this is most likely the vCard that you edit in Your Info (see above).

Another message to Dothebart:

I'm feeling kind of stupid about this, but I have three different vCard-like objects and am having trouble to influence them and get them used.

Advanced - Your Info - Change Your Preferences and Settings: Preferred Email Address shows as <> and Webcit actually uses this to compose outgoing mail. The dropdown list has only this value and it cannot be edited arbitrarily. When I use the text client and .G My Citadel Config, there is a message with subject Webcit Preferences which is very similar to the content here, except one row says Defaultfrom| which is different. I didn't tempt fate by trying to alter it. There is another object (no subject) whose Part 1 has mime-type text/x-vcard but I couldn't figure out how to do MSG4 to display it.

Advanced - Your Info - Update Your Contact Information: This shows a vCard form. I tried filling the desired address into Primary Internet E-Mail Address and Internet E-Mail Aliases (one, the other, or both), but it was never available as a selectable From address (or anywhere else that I looked). I did hit Save, and also logged out and logged in again, without effect.

Is there a way to send a raw API command using either Webcit or the text client? I'm curious to see what GVEA would report. I don't think I can use sendcommand because it would not be in the context of a logged-in session, so the server would not know whose addresses to report.

When you use getmail, what is the name of a specific user's aliased rooms such as Mail or My Citadel Config? If I knew that, I could inspect the mysterious vCard. Then, of course, the challenge will be to alter one or the other message.

XMPP (Instant Message)

Coarse grained presence

Pidgin lets you set several kinds of presence, e.g. do not disturb, and custom status messages, e.g. out to lunch. With ejabberd these would be propagated to the partner, but with Citadel you are either available or offline. The transition between these is reported promptly to the partner, but status variants are never seen by the partner. Hmm, see the Online Users tab; the third column (which I had never been able to figure out) shows a sleepy icon for a user who is logged in via Pidgin but is (literally) asleep.

Volatile Buddies

In a normal instant message context, pairs of people designate themselves as friends or buddies (the term normally used in XMPP). This means that they receive XMPP presence notifications, which are not sent to non-buddies. Becoming a buddy requires authorization from the other partner. The buddy state persists until one or both of the buddies unsubscribes.

Citadel has a unique view of the buddy relation: it cancels the buddy relation as soon as one of the users logs out, and it has a special cache of non-buddies called the mortuary so it can transmit these cancellations to a client who logs in later. Also I don't see any code to handle authorizations and authorization requests from the client are never answered. It would appear that the buddy state is supposed to be re-established whenever the user logs in.

I want to use the presence mechanism to monitor when my buddy comes online (and therefore is available to chat) or drops off. I also want to see sub-states such as do not disturb or out to lunch. I think Citadel is not going to provide these functions for me, and under the circumstances I think it isn't justified to rewrite Citadel's code to match my interpretation of normal use of the buddy concept.


I very much wanted Citadel to work for us; it would solve several of our current problems in one stroke. But I'm afraid Citadel has too many problem areas or showstoppers. Here are the problems by function:

Calendar and PIM Objects

Citadel uses the GroupDAV protocol, which in the context of the Thunderbird/Lightning client is upward compatible with iCalendar. In this protocol the client retrieves the entire calendar, makes changes, and rewrites the entire calendar. I worry that some users would have large calendars, contact lists, etc.; the department's event calendar normally has at least 20 events per week and extends several months in the future, and I have read forum postings (about other software) where users complain about capacity limits that can't accomodate their multi thousands (literally) of contacts. The probability of a race condition is proportional to the square of the object size. I worry about being able to do a stress test to gain confidence that race conditions are not happening.

The CalDAV protocol (which Citadel does not support) is superior because it retrieves and sends back PIM objects one at a time. Citadel also provides access to the PIM objects via IMAP, one at a time; this is how Kolab and Horde would communicate.

Incoming Mail (SMTP)

When mail is sent from off-site to Citadel, we require the client to authenticate before we will relay mail to an off-site destination, preventing spam. We have other mail services also available only to our authenticated users. In mail submission Citadel can use Plain authentication but cannot authenticate either by GSSAPI or by interpreting the sender's X.509 certificate optionally presented to set up TLS, which Postfix can do.

Due to legal requirements specific to our organization, we cannot make judgments about the content of mail which is correct as to form. Therefore we need to offer users an opt-in spam solution, and also, we have to actually deliver the spam, normally to a separate folder. Citadel takes the opposite approach: if configured, all mail is run through SpamAssassin during submission, and if it fails it is tossed with a 5xx result code. This design is attractive for a commercial site, but is forbidden in our case.

We also have a very effective spam suppressor, legal for us, called a greylist, and the hooks to use it are not obvious in Citadel.

Reading Mail (IMAP)

Our IMAP namespace was set up years ago and not optimally. Citadel has its own idea of the IMAP namespace which differs both from ours and from the arrangement which we would like to change to. This namespace cannot be configured. It will be traumatic and labor-intensive to get our users, particularly the elderly ones, to change their IMAP namespace. This issue is probably a showstopper for IMAP on Citadel.

Instant Message (XMPP)

While basic messaging works fine in Citadel, it has a bizarre interpretation of the buddy relation (equivalent to friends in other instant message protocols) which makes presence essentially useless. Also, I have never gotten it to respond to an IQ (information query). At least for my use-case, this is a showstopper.

Web Client (HTTP/S)

The brightest spot with Citadel is the web client, an obvious but neglected partner to any server that makes it useful even to users who cannot (or will not) install a dedicated client locally, e.g. on a web-enabled mobile phone.

So in conclusion, Citadel comes very close to doing what I want, but in each aspect (except Webcit) it turns out to have deficiencies which I cannot overcome or ignore. Thus I must reluctantly look for other server software.