IMAP.MRK file format
I managed to dig up some information on the IMAP.MRK file, for anyone brave enough to want to modify it pragmatically. The format is actually fairly simple, one header followed by zero or more message records.
If a MSG file has no corresponding record, MDaemon will update the IMAP.MRK file the next time an IMAP client or WorldClient user touches the folder, and the message will be treated as UNSEEN and UNREAD
The header is defined as follows:
struct IMAPMrkHeader
{
unsigned HeaderVersion;
unsigned UIDValidity;
unsigned UIDNext;
unsigned LastWriteCounter;
unsigned Filler0;
unsigned Filler1;
unsigned Filler2;
unsigned Filler3;
unsigned CRLF;
};
Each MSG file will have one record, which is defined as follows:
struct IMAPMrkMessage {
char Filename[MAX_IMAP_FILENAME];
unsigned char Flags;
unsigned UID;
unsigned Size;
time_t Date;
};#define FLAG_SEEN 32
#define FLAG_ANSWERED 16
#define FLAG_FLAGGED 8
#define FLAG_DELETED 4
#define FLAG_DRAFT 2
#define FLAG_RECENT 1
#define MAX_IMAP_FILENAME 23
#define IMAP_RECORD_SIZE 36
So what do all those fields mean?
- HeaderVersion is a tag to identify what file format the IMAP.MRK is using. The current value is 1. UIDValidity is the IMAP UID Validity for the folder. UIDNext is the UID that will be used for the next message added to the folder.
- LastWriteCounter is a value that changes whenever something has changed in the file. This was added when IDLE support was added to the IMAP server, so that there’s a quick way to check for changes (by comparing this one value rather than doing a compare of the entire file’s contents).When changing records in the file, lock the IMAP folder, increment the LastWriteCounter, change the records, then unlock the folder.
- UIDNext is the next UID to be assigned. To add records, lock the IMAP folder, increment the LastWriteCounter, and for each record you’re adding, use the current UIDNext value as its UID and then increment UIDNext.
So how do you lock a folder?
- Lock an IMAP folder by creating a file “IMAP-foldername-email.lck”, where foldername is a “filename-safe” version of the folder name (” and ‘/’ characters replaced with ‘_’) and email is the owner’s email address (use “public” for public folders). If the lock file already exists, something is currently operating on the IMAP.MRK so you should wait until it is unlocked before you lock it and continue.
Hope this helps someone.
Setting ACLs on IMAP folders – Not just for administrators
In my last post I discussed what IMAP ACLs are implemented by MDaemon, and a little about how they work. In this post I want to make everyone aware of the ways that ACLs can be managed.
ACLs can be changed a number of different ways, not only by administrators using the MDaemon interface. ACLs can be changed using any of the following methods:
- The MDaemon GUI, under public folders or from within the user editor.
- The WebAdmin GUI, in similar locations.
- WorldClient allows users to share folders and set permissions.
- Outlook Connector allows users to share folders and set permissions.
- Any IMAP client can be used to set permissions.
- You can even change ACLs by using “telnet” to connect to the IMAP server.
This is significant as it allows any user to share their own IMAP folders out to other users. Note that only users who have the “administer” ACL or are a WebAdmin domain admin or global administrator can change ACLs.
To understand how to change rights, I have lifted the following information from RFC2086 – IMAP4 ACL extension
To set ACLs, use the SETACL command:
4.1. SETACL
Arguments: mailbox name
authentication identifier
access right modificationData: no specific data for this command
Result: OK – setacl completed
NO – setacl failure: can’t set acl
BAD – command unknown or arguments invalidThe SETACL command changes the access control list on the specified mailbox so that the specified identifier is granted permissions as specified in the third argument.
The third argument is a string containing an optional plus (“+”) or minus (“-”) prefix, followed by zero or more rights characters. If the string starts with a plus, the following rights are added to any existing rights for the identifier. If the string starts with a minus, the following rights are removed from any existing rights for the identifier. If the string does not start with a plus or minus, the rights replace any existing rights for the identifier.
To retrieve ACLs on existing folders, use GETACL:
4.3. GETACL
Arguments: mailbox name
Data: untagged responses: ACL
Result: OK – getacl completed
NO – getacl failure: can’t get acl
BAD – command unknown or arguments invalidThe GETACL command returns the access control list for mailbox in an untagged ACL reply.
Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipslda
S: A002 OK Getacl complete
For more information and a few additional commands, please do read RFC2086 – IMAP4 ACL extension
IMAP ACLs reference
There is some confusion about IMAP ACLs, and how they are used and implemented by MDaemon, Outlook Connector and WorldClient.
First, what are ACLs? ACL stands for “Access Control List”, and ACLs are a way of controlling who can see a folder, and what rights a user has within that folder.
There are 10 defined ACLs supported by MDaemon:
- l – lookup (mailbox is visible to LIST/LSUB commands)
- r – read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox)
- s – keep seen/unseen information across sessions (STORE SEEN flag)
- w – write (STORE flags other than SEEN and DELETED)
- i – insert (perform APPEND, COPY into mailbox)
- p – post (send mail to submission address for mailbox, not enforced by IMAP4 itself)
- c – create (CREATE new sub-mailboxes in any implementation-defined hierarchy)
- d – delete (STORE DELETED flag, perform EXPUNGE)
- a – administer (perform SETACL)
Note the differences between “write”, “insert”, “post” and “create” as these tend to confuse people somewhat.
Outlook Connector (and MDaemon Groupware before it) rely on the same set of IMAP ACLs, but implement them somewhat differently. For example, IMAP has no concept of “editing” an item, so instead, when you modify an item in Outlook Connector, Outlook Connector will INSERT a new item and DELETE the old item, so to edit, you require both the INSERT and DELETE rights.
In non-email folders, the “keep seen/unseen”, “w – write”, “p – post” rights are not used and can be ignored.
WorldClient implements ACLs in a nearly identical fashion to MDaemon and Outlook Connector, emulating as many of the permissions as closely as possible.
Note that users own all folders contained within their mailboxes at all times, and the owner of a folder always has all rights and even if these rights aren’t explicitly listed, they are granted. Public folders don’t have an owner.
Lastly, note that ACLs are inherited by subfolders when they are created, but permission changes to a parent don’t apply to children unless the administrator uses the “Set sub” folder to set permissions on subfolders.
keep looking »