Secure Messaging

M-Box

POP/IMAP Message Store

M-Box is a high performance message store, supporting IMAP (Internet Message Access Protocol) and POP (Post Office Protocol), providing the message storage and access component of an Internet messaging solution.

Email clients deliver messages to M-Switch SMTP, which handles message switching and realted services such as spam filtering. M-Switch in turn delvers new messages into M-Box using Local Message Transfer Protocol (LMTP) where they can be retrieved by email clients using wither POP or IMAP. M-Box gets configuration information, including client authentication from an LDAP directory, such as Isode’s M-Vault.

m-box

Key Features

High Performance

M-Box has an optimized database design and multi-threaded architecture, which gives high performance and allows a very large number of users to be supported on a single server. Multiple M-Box can robustly share a single file store, enabling straightforward service scaling for very large deployments.

Flexible Message Processing using SIEVE

SIEVE is a delivery time scripting language for email processing, enabling users to manage actions such as automatic email filing, and vacation alerts. Personal SIEVE scripts are configured in the directory and can be managed by the Internet Messaging Administrator web application. There is also a “global” sieve script, so that custom processing can be defined for all users.

IMAP/POP Protocol Support

IMAP and POP are both protocols with a large number of optional extensions. M-Box has comprehensive support of these optional extensions, making it ideal for environments supporting a wide mix of email clients. Details of protocol support are listed on the M-Box: Open Standards page.

Simple Migration

M-Box provides a fully automated, on-the-fly migration system, capable of migrating both message data and authentication information from an existing POP or IMAP service. The single POP mailbox, or all the user’s personal IMAP mailboxes, are migrated dynamically on login, using only standard, secured POP3 or IMAP connections. On completion, the user is automatically provisioned with an account in the directory. In the majority of cases, this allows for a switchover from an existing system entirely transparent to the user, with no pre-population of account data required.

Authentication & Security

Authentication of IMAP and POP users may be performed using SASL, built over Isode’s SASL infrastructure. Data confidentiality may be provided either by SASL and/or by TLS. M-Box supports IMAP Access Control, which can be managed by IMAP clients, for example to enable folder sharing.

Management

Configuration Management

The configuration management of M-Box is integrated with the directory based configuration of the messaging infrastructure using the MConsole management GUI. M-Box configuration information is held in the (LDAP) directory, which enables client/server management of data and sharing of information between M-Box servers. This includes configuration information for the M-Box server, but the most important information is on users.

The core model is “one user; one account; one directory entry”. While this can be managed with Isode’s directory data entry tools, in many deployments account management and user option selection will be integrated with the customer provisioning system, with the directory forming a back end to this.

Operational Management

M-Box specific operational control is provided by the msadm tool, which enables checking of accounts and msstat which provides connection information. Msadm provides scripted creation of accounts, and enables message expiration, so that old message can be removed. M-Box provides logging of key events, and uses Isode events for errors and operational information. M-Box allows for SNMP monitoring of general status and network connection.

User Management

Web-based administration is provided by the Internet Messaging Administration (IMA) application, which can be used to create and manage user email accounts, shared folders, user groups as well as edit the message store configuration and examine the directory configuration.

An M-Box server is based around a message database, and has three multi-threaded servers that access this database; imapd (supports access using IMAP), pop3d (supports access using POP) and lmptd (supports access using LMTP).

m-box-architecture

The most important part of the M-Box architecture is the database design. M-Box uses a database abstraction layer, so that it is possible to use different database back-ends. This has been prototyped with several back-ends. Two database back-end are currently being provided, one for standard usage and one for archive access.

The underlying database is mapped onto the underlying file store using a format which we call “mdir”. This uses the basic approach of the popular maildir format, which enables mailbox sharing without use of file system locks. Mdir differs from maildir primarily to enable performance improvements, particularly in support of IMAP. Key features of the mdir format:

  • No locks. This is critical for high performance, and robust horizontal scaling.
  • Each message in a single file. This simple approach gives inherent high robustness, as any data corruption will be constrained to a single message. It also allows standard file system backup mechanisms to be used for online backup.
  • Use of file store hierarchy. Folders and mailboxes are structured using the file store hierarchy. This approach is inherently robust and allows use of standard OS tools on the database. A key benefit is that each account is represented by a single directory hierarchy, which simplifies provisioning support and in particular account deletion.

A quick analysis might suggest that this simple approach, while very robust, would not give good performance. In fact, exactly the opposite is true. Modern files systems are highly optimized for exactly the sort of operations that are performed by M-Box. In particular:

  • File system directories are indexed using b-trees, and have optimized layout on disk. Use of large directories with key indexing information in the filename is therefore very efficient.
  • Files are intelligently laid out on the disk, which means that use of relatively small block size (good to gain high disk utilization, as messages are generally small) does not impact performance for large files.

In essence, M-Box is working with the tuning of the underlying file system, which is one of the reasons for its excellent performance. Our tests have shown that M-Box is faster than servers that use complex approaches to optimize performance, and that the approach taken gives benefits of simplicity, robustness and high performance

A key benefit that mdir provides is support of horizontal scaling with an architecture that allows multiple M-Box servers to access a single file store. This architecture gives ‘horizontal scaling’, and enables additional M-Box servers to be added to support more users. Load balancing between the M-Box servers will usually be achieved by use of a network load balancer. The file store will be chosen with appropriate size, performance and expansion options for the deployment. It may be a file system on one of the M-Box servers, but in most cases it is likely to be a separate network file server appliance. The file access protocol will depend on performance and scaling targets for the total system. Options include:

  • NFS (Network File System). The traditional protocol for this sort of functionality.
  • iSCSI. A mapping of the SCSI (Small Computer Systems Interface) protocol commonly used onto IP. iSCSI can be used with a clustering file system to provide a low cost, higher performance alternative to NFS.
  • SAN (Storage Area Network). A more expensive, higher performance option.

Although this approach gives an elegant way to scale an M-Box deployment by adding more servers, the major advantage of this architecture is in simplified management. This architecture leads to user mailboxes being deployed on a single file store, with each account having a separate directory. Increase in storage is simply a question of increasing the size of the file server. This makes it easy to add and remove accounts.

Many mailbox servers, particularly those with complex databases, lock mailboxes to specific servers. This leads to two problems:

  1. In order to make mailbox location transparent to the end user, a tier of application servers will generally be introduced, so that the user gets redirected to the right server.
  2. When servers are added, or usage grows, there will be the requirement to migrate users between servers. This adds product and operational complexity.

M-Box’s architecture avoids these problems.

M-Box Open Standards conformance is listed below.

RFC 1123 Requirements for Internet hosts – application and support. R. Braden, October 1989
RFC 1734 POP3 Authentication command. J. Myers, December 1994
RFC 1939 Post Office Protocol – Version 3. J. Myers, M. Rose, May 1996
RFC 2033 Local Mail Transfer Protocol. J. Meyers, October 1996
RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed, October1996
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed, N. Borenstein, November 1996
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein, November 1996
RFC 2047 Multipurpose Internet Mail Extensions (MIME) Part Three: Header Extensions for Non-ASCII Text. K. Moore, November 1996
RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein, November 1996
RFC 2087 IMAP4 QUOTA extension. J. Myers, January 1997
RFC 2088 IMAP4 non-synchronizing literals. J. Myers, January 1997
RFC 2177 IMAP4 IDLE command, B. Leiba, June 1997
RFC 2342 IMAP4 Namespace. M. Gahrns & C. Newman, May 1998
RFC 2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade, November 1998
RFC 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman, June 1999
RFC 2920 SMTP Service Extension for Command Pipelining. N. Freed, September 2000
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil, January 2003
RFC 3501 Internet Message Access Protocol – Version 4rev1. M. Crispen, March 2003
RFC 3516 IMAP4 Binary Content Extensio. L. Nerenberg, April 2003
RFC 3691 Internet Message Access Protocol (IMAP) UNSELECT command. A. Melnikov, February 2004
RFC 3894 Sieve Extension: Copying Without Side Effects. J. Degener, October 2004
RFC 3848 ESMTP and LMTP Transmission Types Registration. C. Newman, July 2004
RFC 4314 IMAP4 ACL extension. A. Melnikov, December 2005
RFC 4315 INTERNET MESSAGE ACCESS PROTOCOL – UIDPLUS extension. M Crispen, December 2005
RFC 4467 Internet Message Access Protocol (IMAP) – URLAUTH extension. M. Crispin, May 2006
RFC 4469 Internet Message Access Protocol (IMAP) – CATENATE extension. P. Resnick, April 2006
RFC 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Meas, A. Melnikov, June 2006
RFC 4551 IMAP Extenstion for Conditional STORE Operation of Quick Flag Changes Resyncronization. A. Melnikov, S.Hole, June 2006
RFC 4731 IMAP4 extension to SEARCH command for controlling what kind of information is returned, A. Melnikov, D. Cridland, November 2006
RFC 4959 The IMAP Extension for SASL Initial Client Response. Robert Siemborski, A. Gulbrandsen Sept 2007
RFC 4978 The IMAP COMPRESS Extension. Arnt Gulbandsen, August 2007
RFC 5032 WITHIN Search extensions to the IMAP Protocol. Eric Burger, September 2007
RFC 5092 IMAP URL Scheme. A. Melnikov, C Newman, November 2007
RFC 5161 The IMAP ENABLE Extension. A. Melnikov, A. Gulbrandsen, March 2008
RFC 5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A. Melnikov, D. Cridland, C. Wilson, March 2008
RFC 5228 Sieve: A Mail Filtering Language. T. Showalter, January 2008
RFC 5230 Sieve Email Filtering: Vacation Extension. T. Showalter, N. Freed, January 2008
RFC 5231 Sieve Email Filtering: Relational Extension. W. Segmuller, B. Leiba January 2008
RFC 5233 Sieve Email Filtering: Subaddress Extension. K. Murchison, January 2008
RFC 5256 Internet Message Access Protocol – SORT and THREAD Extensions. M. Crispin, K. Murchison, June 2008
RFC 5267 Contexts for IMAP4, D. Cridland, C. King, July 2008
RFC 5258 IMAP4 LIST Command extensions. B. Leiba, A. Melnikov, June 2008
RFC 5260 Sieve Email Filtering: Date and Index Extensions. N. Freed, July 2008
RFC 5804 A Protocol for Remotely Managing Sieve Scripts. T. Martin, A. Melnikov, July 2010
RFC 6152 SMTP Service Extension for 8-bit MIME transport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, March 2011
RFC 6154 IMAP LIST Extension for Special-Use Mailboxes. B. Leiba, J. Nicolson, March 2011
RFC 6851 Internet Message Access Protocol (IMAP) – MOVE Extension. A. Gulbrandsen, N. Freed, Ed. Oracle, January 2013
Draft The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions. Arnt Gulbrandsen, July 2010

Ready to request an Evaluation?

Thankyou for considering Isode’s software products. To request an evaluation, please select the product(s) you are interested in, then fill out the enquiry form.

Select your Evaluation products: