Paranoid Penguin - Secure Mail with LDAP and IMAP, Part II
Notice the localhost> prompt after a successful login: I'm now logged in to a cyradm shell session. To see a complete list of available commands, all I need to do is type ? or help. There are 20 commands in all, and each can be abbreviated, sometimes in two different ways. The help screen lists all versions of each command.
To create a mailbox, I can use the command createmailbox. Alternatively, I can use the abbreviation create or even a simple cm, like this:
localhost> cm user.bwooster localhost>
This is the very model of command-line efficiency, but notice that the user name corresponding to our new mailbox isn't really user.bwooster—it's simply bwooster. The user. prefix must be used for all mailboxes you create in Cyrus IMAP. Thus, to create a mailbox for the user bubba, I'd use the command cm user.bubba. To then create subdirectories for that mailbox, I'd use cm user.bubba.sent, cm user.bubba.drafts and so forth.
This user. prefix is visible only to Cyrus and to its administrators. In fact, when our user Bubba connects to the server with Evolution or some other IMAP client, rather than user.bubba he simply sees a folder named Inbox, even though its real name is user.bubba. Similarly, submailboxes appear as sent, drafts and so on, indented beneath Inbox.
Another thing worth noting about the e-mail account creation command is the lack of any feedback whatsoever from Cyrus upon successful completion. If you're like me, you find this unnerving; you periodically want to use the listmailbox command, lm for short, to see what you have:
localhost> lm user.bwooster (\HasNoChildren)
Believe it or not, this is all we need to do with Cyrus IMAP to allow user bwooster to receive and read his e-mail, assuming there's an LDAP record with a UID of bwooster. In Cyrus IMAP, creating a new user mailbox has the effect of creating that user's IMAP account. But before I move on to the topic of configuring the Postfix MTA to deliver e-mail to Cyrus IMAP, a few words about Cyrus IMAP ACLs.
Each mailbox in a Cyrus IMAP system can have one or more ACLs associated with it in which each ACL defines which actions a given user may perform on the referenced mailbox or folder. By default, a new mailbox has only one ACL, one that grants the mailbox's owner full administrative rights over the mailbox.
Interestingly, administrators by default have only lookup and administer rights on the new mailbox. You can look up the name of the mailbox using the listmailbox command, and you can set ACLs on it. But if you need to delete the mailbox, you first must create an ACL for the mailbox that grants your administrative account administrative rights. This is a feature, not a bug; it helps prevent things from getting deleted accidentally.
Continuing with our example, below are the commands for removing the mailbox we just created, using our administrative account mick_admin:
$ cyradm -u mick_admin localhost IMAP Password: ***** localhost> setaclmailbox user.bwooster mick_admin all localhost> deletemailbox user.bwooster
The second command issued here is of particular note; it begins with the cyradm command setaclmailbox, which may be abbreviated as sam or setacl. This is followed by the mailbox in question (user.bwooster), in turn followed by the account name to which we wish to grant (or deny) access, mick_admin in this case. Finally, either a group of permission codes or a special string is indicated. In this example, we have the special string all, which is short for all permissions. To delete the user.bwooster mailbox, it would have been sufficient simply to specify c, for create or delete mailbox or submailboxes. Other possible ACL permissions are listed in Table 1.
Table 1. cyradm ACL Permission Codes (adapted from the cyradm(1) man page)
|l||Lookup (visible to LIST/LSUB/UNSEEN)|
|r||Read (SELECT, CHECK, FETCH, PARTIAL, SEARCH, COPY source)|
|s||Seen (STORE \SEEN)|
|w||Write flags other than \SEEN and \DELETED|
|i||Insert (APPEND, COPY destination)|
|p||Post (send mail to mailbox)|
|c||Create and Delete mailbox (CREATE new submailboxes, RENAME or DELETE mailbox)|
|d||Delete (STORE \DELETED, EXPUNGE)|
|none||Special string meaning no permissions|
|read||Special string meaning lrs|
|post||Special string meaning lrsp|
|append||Special string meaning lrsip|
|write||Special string meaning lrswipcd|
|all||Special string meaning lrswipcda|
ACLs are covered in detail in the cyradm(1) man page and are explained in Cyrus IMAP's HTML documentation. I highly recommend that you get into the habit of at least reviewing, if not always customizing, the ACLs on each mailbox you create with cyradm. On some sites, it may not be necessary for users to retain the default permission c. If all user submailboxes (user.whomever.sent, user.whomever.saved and so on) are created for them by you, for example, you may prefer that they not have the ability to create new ones or delete them accidentally.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space