Modoboa’s documentation!¶

virtualenv users¶

When you deploy an application using virtualenv, you may have to compile some dependencies. For example, modoboa relies on lxml, which is a C python module. In order to install it, you will need to install the following requirements:

• python development files
• libxslt development files
• libxml2 development files
• libz development files

On a Debian like system, just run the following command:

$ apt-get install python-dev libxml2-dev libxslt-dev zlib1g-dev

1.6.0¶

An interesting feature brougth by this version is the capability to make different checks about MX records. For example, Modoboa can query main DNSBL providers for every defined domain. With this, you will quickly know if one the domains you manage is listed or not. To activate it, add the following line to your crontab:

*/30 * * * * <optional_virtualenv_path/>python <modoboa_instance_dir>/manage.py modo check_mx

The communication with Modoboa public API has been reworked. Instead of sending direct synchronous queries (for example to check new versions), a cron job has been added. To activate it, add the following line to your crontab:

0 * * * * <optional_virtualenv_path/>python <modoboa_instance_dir>/manage.py communicate_with_public_api

Please also note that public API now uses TLS so you must update your configuration as follows:

MODOBOA_API_URL = 'https://api.modoboa.org/1/'

Finally, it is now possible to declare additional sender addresses on a per-account basis. You need to update your postfix configuration in order to use this functionality. Just edit the main.cf file and change the following parameter:

smtpd_sender_login_maps =
    <driver>:/etc/postfix/sql-sender-login-mailboxes.cf
    <driver>:/etc/postfix/sql-sender-login-aliases.cf
    <driver>:/etc/postfix/sql-sender-login-mailboxes-extra.cf

1.5.0¶

The API has been greatly improved and a documentation is now available. To enable it, add 'rest_framework_swagger' to the INSTALLED_APPS variable in settings.py as follows:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.sites',
    'django.contrib.staticfiles',
    'reversion',
    'rest_framework.authtoken',
    'rest_framework_swagger',
)

Then, add the following content into settings.py, just after the REST_FRAMEWORK variable:

SWAGGER_SETTINGS = {
    "is_authenticated": False,
    "api_version": "1.0",
    "exclude_namespaces": [],
    "info": {
        "contact": "contact@modoboa.com",
        "description": ("Modoboa API, requires a valid token."),
        "title": "Modoboa API",
    }
}

You’re done. The documentation is now available at the following address:

http://<your instance address>/docs/api/

Finally, if you find a TEMPLATE_CONTEXT_PROCESSORS variable in your settings.py file, make sure it looks like this:

TEMPLATE_CONTEXT_PROCESSORS = global_settings.TEMPLATE_CONTEXT_PROCESSORS + [
    'modoboa.core.context_processors.top_notifications',
]

1.4.0¶

Some extension have been moved back into the main repository. The main reason for that is that using Modoboa without them doesn’t make sense.

First of all, you must rename the following applications listed inside the MODOBOA_APPS variable:

Then, apply the following steps:

1. Uninstall old extensions:

   $ pip uninstall modoboa-admin modoboa-admin-limits modoboa-admin-relaydomains
   

2. Install all extension updates using pip (check the Modoboa > Information page)

3. Manually migrate database:

   $ cd <instance_dir>
   $ python manage.py migrate auth
   $ python manage.py migrate admin 0001 --fake
   $ python manage.py migrate admin
   $ python manage.py migrate limits 0001 --fake
   $ python manage.py migrate relaydomains 0001 --fake
   $ python manage.py migrate
   

4. Finally, update static files:

   $ python manage.py collectstatic
   

This version also introduces a REST API. To enable it:

1. Add 'rest_framework.authtoken' to the INSTALLED_APPS variable

2. Add the following configuration inside settings.py:

   # Rest framework settings
   
   REST_FRAMEWORK = {
       'DEFAULT_AUTHENTICATION_CLASSES': (
           'rest_framework.authentication.TokenAuthentication',
       ),
       'DEFAULT_PERMISSION_CLASSES': (
           'rest_framework.permissions.IsAuthenticated',
       )
   }
   

3. Run the following command:

   $ python manage.py migrate
   

1.3.5¶

To enhance security, Modoboa now checks the strength of user passwords <https://github.com/dstufft/django-passwords>_.

To use this feature, add the following configuration into the settings.py file:

# django-passwords

PASSWORD_MIN_LENGTH = 8

PASSWORD_COMPLEXITY = {
    "UPPER": 1,
    "LOWER": 1,
    "DIGITS": 1
}

1.3.2¶

Modoboa now uses the atomic requests mode to preserve database consistency (reference).

To enable it, update the DATABASES variable in settings.py as follows:

DATABASES = {
    "default": {
        # stuff before...
        "ATOMIC_REQUESTS": True
    },
    "amavis": {
        # stuff before...
        "ATOMIC_REQUESTS": True
    }
}

1.3.0¶

This release does not bring awesome new features but it is a necessary bridge to the future of Modoboa. All extensions now have their own git repository and the deploy process has been updated to reflect this change.

Another important update is the use of Django 1.7. Besides its new features, the migration system has been reworked and is now more robust than before.

Before we begin with the procedure, here is a table showing old extension names and their new name:

Here are the required steps:

1. Install the extensions using pip (look at the second column in the table above):

   $ pip install <the extensions you want>
   

2. Remove south from INSTALLED_APPS

3. Rename old extension names inside MODOBOA_APPS (look at the third column in the table above)

4. Remove modoboa.lib.middleware.ExtControlMiddleware from MIDDLEWARE_CLASSES

5. Change DATABASE_ROUTERS to:

   DATABASE_ROUTERS = ["modoboa_amavis.dbrouter.AmavisRouter"]
   

6. Run the following commands:

   $ cd <modoboa_instance_dir>
   $ python manage.py migrate
   

7. Reply yes to the question

8. Run the following commands:

   $ python manage.py load_initial_data
   $ python manage.py collectstatic
   

9. The cleanup job has been renamed in Django, so you have to modify your crontab entry:

   - 0 0 * * * <modoboa_site>/manage.py cleanup
   

   • 0 0 * * * <modoboa_site>/manage.py clearsessions

1.2.0¶

A new notification service let administrators know about new Modoboa versions. To activate it, you need to update the TEMPLATE_CONTEXT_PROCESSORS variable like this:

from django.conf import global_settings

TEMPLATE_CONTEXT_PROCESSORS = global_settings.TEMPLATE_CONTEXT_PROCESSORS + (
  'modoboa.core.context_processors.top_notifications',
)

and to define the new MODOBOA_API_URL variable:

MODOBOA_API_URL = 'http://api.modoboa.org/1/'

The location of external static files has changed. To use them, add a new path to the STATICFILES_DIRS:

# Additional locations of static files
STATICFILES_DIRS = (
  # Put strings here, like "/home/html/static" or "C:/www/django/static".
  # Always use forward slashes, even on Windows.
  # Don't forget to use absolute paths, not relative paths.
  "<path/to/modoboa/install/dir>/bower_components",
)

Run the following commands to define the hostname of your instance:

$ cd <modoboa_instance_dir>
$ python manage.py set_default_site <hostname>

If you plan to use the Radicale extension:

1. Add 'modoboa.extensions.radicale' to the MODOBOA_APPS variable

2. Run the following commands:

   $ cd <modoboa_instance_dir>
   $ python manage.py syncdb
   

1.1.7: manual learning for SpamAssassin¶

A new feature allows administrators and users to manually train SpamAssassin in order to customize its behaviour.

Check Manual SpamAssassin learning to know more about this feature.

1.1.6: Few bugfixes¶

Catchall aliases were not really functional until this version as they were eating all domain traffic.

To fix them, a postfix map file (sql-mailboxes-self-aliases.cf) has been re-introduced and must be listed into the virtual_alias_maps setting. See Configuration for the order.

1.1.2: Audit trail issues¶

Update the settings.py file as follows:

1. Remove the 'reversion.middleware.RevisionMiddleware' middleware from the MIDDLEWARE_CLASSES variable
2. Add the new 'modoboa.lib.middleware.RequestCatcherMiddleware' middleware at the end of the MIDDLEWARE_CLASSES variable

1.1.1: Few bugfixes¶

For those who installed Dovecot in a non-standard location, it is now possible to tell Modoboa where to find it. Just define a variable named DOVECOT_LOOKUP_PATH in the settings.py file and include the appropriate lookup path inside:

DOVECOT_LOOKUP_PATH = ("/usr/sbin/dovecot", "/usr/local/sbin/dovecot")

1.1.0: relay domains and better passwords encryption¶

Due to code refactoring, some modifications need to be done into settings.py:

1. MODOBOA_APPS must contain the following applications:

   MODOBOA_APPS = (
     'modoboa',
     'modoboa.core',
     'modoboa.lib',
   
     'modoboa.extensions.admin',
     'modoboa.extensions.limits',
     'modoboa.extensions.postfix_autoreply',
     'modoboa.extensions.webmail',
     'modoboa.extensions.stats',
     'modoboa.extensions.amavis',
     'modoboa.extensions.sievefilters',
   )
   

2. Add 'modoboa.extensions.postfix_relay_domains' to MODOBOA_APPS, just before 'modoboa.extensions.limits'

3. AUTH_USER_MODEL must be set to core.User

4. Into LOGGING, replace modoboa.lib.logutils.SQLHandler by modoboa.core.loggers.SQLHandler

Then, run the following commands to migrate your installation:

$ python manage.py syncdb
$ python manage.py migrate core 0001 --fake
$ python manage.py migrate
$ python manage.py collectstatic

Finally, update both Dovecot and Postfix queries.

1.0.1: operations on mailboxes¶

The way Modoboa handles rename and delete operations on mailboxes has been improved. Make sure to consult Operations on the file system and Postfix configuration. Look at the smtpd_recipient_restrictions setting.

Run modoboa-admin.py postfix_maps --dbtype <mysql|postgres|sqlite> <tempdir> and compare the files with those that postfix currently use. Make necessary updates in light of the differences

1.0.0: production ready, at last¶

General parameters¶

The admin application exposes several parameters, they are presented below:

Custom logo¶

You have the possibility to use a custom logo instead of the default one on the login page.

To do so, open the settings.py file and add a MODOBOA_CUSTOM_LOGO variable. This variable must contain the relative URL of your logo under MEDIA_URL. For example:

MODOBOA_CUSTOM_LOGO = os.path.join(MEDIA_URL, "custom_logo.png")

Then copy your logo file into the directory indicated by MEDIA_ROOT.

Authentication¶

Modoboa supports external LDAP authentication using the following extra components:

• Python LDAP client
• Django LDAP authentication backend

If you want to use this feature, you must first install those components:

$ pip install python-ldap django-auth-ldap

Then, all you have to do is to modify the settings.py file. Add a new authentication backend to the AUTHENTICATION_BACKENDS variable, like this:

AUTHENTICATION_BACKENDS = (
  'modoboa.lib.authbackends.LDAPBackend',
  'modoboa.lib.authbackends.SimpleBackend',
)

Finally, go to Modoboa > Parameters > General and set Authentication type to LDAP.

From there, new parameters will appear to let you configure the way Modoboa should connect to your LDAP server. They are described just below:

If you need additional parameters, you will find a detailled documentation here.

Once the authentication is properly configured, the users defined in your LDAP directory will be able to connect to Modoboa, the associated domain and mailboxes will be automatically created if needed.

The first time a user connects to Modoboa, a local account is created if the LDAP username is a valid email address. By default, this account belongs to the SimpleUsers group and it has a mailbox.

To automatically create domain administrators, you can use the Administrator groups setting. If a LDAP user belongs to one the listed groups, its local account will belong to the DomainAdmins group. In this case, the username is not necessarily an email address.

Users will also be able to update their LDAP password directly from Modoboa.

Cleaning the logs table¶

Modoboa logs administrator specific actions into the database. A clean-up script is provided to automatically remove oldest records. The maximum log record age can be configured through the online panel.

To use it, you can setup a cron job to run every night:

0 0 * * * <modoboa_site>/manage.py cleanlogs
#
# Or like this if you use a virtual environment:
# 0 0 * * * <virtualenv path/bin/python> <modoboa_site>/manage.py cleanlogs

Cleaning the session table¶

Django does not provide automatic purging. Therefore, it’s your job to purge expired sessions on a regular basis.

Django provides a sample clean-up script: django-admin.py clearsessions. That script deletes any session in the session table whose expire_date is in the past.

For example, you could setup a cron job to run this script every night:

0 0 * * * <modoboa_site>/manage.py clearsessions
#
# Or like this if you use a virtual environment:
# 0 0 * * * <virtualenv path/bin/python> <modoboa_site>/manage.py clearsessions

Mailboxes¶

First, edit the conf.d/10-mail.conf and set the mail_location variable:

# maildir
mail_location = maildir:~/.maildir

Then, edit the inbox namespace and add the following lines:

inbox = yes

mailbox Drafts {
  auto = subscribe
  special_use = \Drafts
}
mailbox Junk {
  auto = subscribe
  special_use = \Junk
}
mailbox Sent {
  auto = subscribe
  special_use = \Sent
}
mailbox Trash {
  auto = subscribe
  special_use = \Trash
}

With dovecot 2.1+, it ensures all the special mailboxes will be automaticaly created for new accounts.

For dovecot 2.0 and older, use the autocreate plugin.

$ crontab -u <user> -e

* * * * * python <modoboa_site>/manage.py handle_mailbox_operations

Authentication¶

To make the authentication work, edit the conf.d/10-auth.conf and uncomment the following line at the end:

#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

Then, edit the conf.d/auth-sql.conf.ext file and add the following content inside:

passdb sql {
  driver = sql
  # Path for SQL configuration file, see example-config/dovecot-sql.conf.ext
  args = /etc/dovecot/dovecot-sql.conf.ext
}

userdb sql {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

Make sure to activate only one backend (per type) inside your configuration (just comment the other ones).

Edit the dovecot-sql.conf.ext and modify the configuration according to your database engine.

driver = mysql

connect = host=<mysqld socket> dbname=<database> user=<user> password=<password>

default_pass_scheme = CRYPT

password_query = SELECT email AS user, password FROM core_user WHERE email='%u' and is_active=1

user_query = SELECT '<mailboxes storage directory>/%Ld/%Ln' AS home, <uid> as uid, <gid> as gid, concat('*:bytes=', mb.quota, 'M') AS quota_rule FROM admin_mailbox mb INNER JOIN admin_domain dom ON mb.domain_id=dom.id WHERE mb.address='%Ln' AND dom.name='%Ld'

iterate_query = SELECT email AS username FROM core_user WHERE email<>''

driver = pgsql

connect = host=<postgres socket> dbname=<database> user=<user> password=<password>

default_pass_scheme = CRYPT

password_query = SELECT email AS user, password FROM core_user WHERE email='%u' and is_active

user_query = SELECT '<mailboxes storage directory>/%Ld/%Ln' AS home, <uid> as uid, <gid> as gid, '*:bytes=' || mb.quota || 'M' AS quota_rule FROM admin_mailbox mb INNER JOIN admin_domain dom ON mb.domain_id=dom.id WHERE mb.address='%Ln' AND dom.name='%Ld'

iterate_query = SELECT email AS username FROM core_user WHERE email<>''

driver = sqlite

connect = <path to the sqlite db file>

default_pass_scheme = CRYPT

password_query = SELECT email AS user, password FROM core_user WHERE email='%u' and is_active=1

user_query = SELECT '<mailboxes storage directory>/%Ld/%Ln' AS home, <uid> as uid, <gid> as gid, ('*:bytes=' || mb.quota || 'M') AS quota_rule FROM admin_mailbox mb INNER JOIN admin_domain dom ON mb.domain_id=dom.id WHERE mb.address='%Ln' AND dom.name='%Ld'

iterate_query = SELECT email AS username FROM core_user WHERE email<>''

LMTP¶

Local Mail Transport Protocol is used to let Postfix deliver messages to Dovecot.

First, make sure the protocol is activated by looking at the protocols setting (generally inside dovecot.conf). It should be similar to the following example:

protocols = imap pop3 lmtp

Then, open the conf.d/10-master.conf, look for lmtp service definition and add the following content inside:

service lmtp {
  # stuff before
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
  # stuff after
}

We assume here that Postfix is chrooted within /var/spool/postfix.

Finally, open the conf.d/20-lmtp.conf and modify it as follows:

protocol lmtp {
  postmaster_address = postmaster@<domain>
  mail_plugins = $mail_plugins quota sieve
}

Replace <domain> by the appropriate value.

Quota¶

Modoboa lets adminstrators define per-domain and/or per-account limits (quota). It also lists the current quota usage of each account. Those features require Dovecot to be configured in a specific way.

Inside conf.d/10-mail.conf, add the quota plugin to the default activated ones:

mail_plugins = quota

Inside conf.d/10-master.conf, update the dict service to set proper permissions:

service dict {
  # If dict proxy is used, mail processes should have access to its socket.
  # For example: mode=0660, group=vmail and global mail_access_groups=vmail
  unix_listener dict {
    mode = 0600
    user = <user owning mailboxes>
    #group =
  }
}

Inside conf.d/20-imap.conf, activate the imap_quota plugin:

protocol imap {
  # ...

  mail_plugins = $mail_plugins imap_quota

  # ...
}

Inside dovecot.conf, activate the quota SQL dictionary backend:

dict {
  quota = <driver>:/etc/dovecot/dovecot-dict-sql.conf.ext
}

Inside conf.d/90-quota.conf, activate the quota dictionary backend:

plugin {
  quota = dict:User quota::proxy::quota
}

It will tell Dovecot to keep quota usage in the SQL dictionary.

Finally, edit the dovecot-dict-sql.conf.ext file and put the following content inside:

connect = host=<db host> dbname=<db name> user=<db user> password=<password>
# SQLite users
# connect = /path/to/the/database.db

map {
  pattern = priv/quota/storage
  table = admin_quota
  username_field = username
  value_field = bytes
}
map {
  pattern = priv/quota/messages
  table = admin_quota
  username_field = username
  value_field = messages
}

db=> ALTER TABLE admin_quota ALTER COLUMN bytes SET DEFAULT 0;
db=> ALTER TABLE admin_quota ALTER COLUMN messages SET DEFAULT 0;

$ su - postgres
$ psql [modoboa database] < /path/to/modoboa_postgres_trigger.sql
$ exit

$ doveadm quota recalc -A

ManageSieve/Sieve¶

Modoboa lets users define filtering rules from the web interface. To do so, it requires ManageSieve to be activated on your server.

Inside conf.d/20-managesieve.conf, make sure the following lines are uncommented:

protocols = $protocols sieve

service managesieve-login {
  # ...
}

service managesieve {
  # ...
}

protocol sieve {
  # ...
}

Messages filtering using Sieve is done by the LDA.

Inside conf.d/15-lda.conf, activate the sieve plugin like this:

protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}

Finally, configure the sieve plugin by editing the conf.d/90-sieve.conf file. Put the follwing caontent inside:

plugin {
  # Location of the active script. When ManageSieve is used this is actually
  # a symlink pointing to the active script in the sieve storage directory.
  sieve = ~/.dovecot.sieve

  #
  # The path to the directory where the personal Sieve scripts are stored. For
  # ManageSieve this is where the uploaded scripts are stored.
  sieve_dir = ~/sieve
}

Restart Dovecot.

Map files¶

You first need to create configuration files (or map files) that will be used by Postfix to lookup into Modoboa tables.

To automaticaly generate the requested map files and store them in a directory, run the following commands:

$ cd <modoboa_instance_path>
$ python manage.py generate_postfix_maps --destdir <directory>

<directory> is the directory where the files will be stored.

Configuration¶

Use the following configuration in the /etc/postfix/main.cf file (this is just one possible configuration):

# Stuff before
virtual_transport = lmtp:unix:private/dovecot-lmtp

relay_domains =
virtual_mailbox_domains = <driver>:/etc/postfix/sql-domains.cf
virtual_alias_domains = <driver>:/etc/postfix/sql-domain-aliases.cf
virtual_alias_maps = <driver>:/etc/postfix/sql-aliases.cf

relay_domains = <driver>:/etc/postfix/sql-relaydomains.cf
transport_maps =
    <driver>:/etc/postfix/sql-spliteddomains-transport.cf
    <driver>:/etc/postfix/sql-relaydomains-transport.cf

smtpd_recipient_restrictions =
      # ...
      check_recipient_access
          <driver>:/etc/postfix/sql-maintain.cf
          <driver>:/etc/postfix/sql-relay-recipient-verification.cf
      permit_mynetworks
      reject_unauth_destination
      reject_unverified_recipient
      # ...

smtpd_sender_login_maps =
      <driver>:/etc/postfix/sql-sender-login-mailboxes.cf
      <driver>:/etc/postfix/sql-sender-login-aliases.cf
      <driver>:/etc/postfix/sql-sender-login-mailboxes-extra.cf

smtpd_sender_restrictions =
      reject_sender_login_mismatch

# Stuff after

Replace <driver> by the name of the database you use.

Restart Postfix.

mod_wsgi¶

First, make sure that mod_wsgi is installed on your server.

Create a new virtualhost in your Apache configuration and put the following content inside:

<VirtualHost *:80>
  ServerName <your value>
  DocumentRoot <path to your site's dir>

  Alias /media/ <path to your site's dir>/media/
  <Directory <path to your site's dir>/media>
    Order deny,allow
    Allow from all
  </Directory>

  Alias /sitestatic/ <path to your site's dir>/sitestatic/
  <Directory <path to your site's dir>/sitestatic>
    Order deny,allow
    Allow from all
  </Directory>

  WSGIScriptAlias / <path to your site's dir>/wsgi.py
</VirtualHost>

This is just one possible configuration.

To use mod_wsgi daemon mode, add the two following directives just under WSGIScriptAlias:

WSGIDaemonProcess example.com python-path=<path to your site's dir>:<virtualenv path>/lib/python2.7/site-packages
WSGIProcessGroup example.com

Replace values between <> with yours. If you don’t use a virtualenv, just remove the last part of the WSGIDaemonProcess directive.

Green Unicorn¶

Firstly, Download and install gunicorn. Then, use the following sample gunicorn configuration (create a new file named gunicorn.conf.py inside Modoboa’s root dir):

backlog = 2048
bind = "unix:/var/run/gunicorn/modoboa.sock"
pidfile = "/var/run/gunicorn/modoboa.pid"
daemon = True
debug = False
workers = 2
logfile = "/var/log/gunicorn/modoboa.log"
loglevel = "info"

To start gunicorn, execute the following commands:

$ cd <modoboa dir>
$ gunicorn -c gunicorn.conf.py <modoboa dir>.wsgi:application

Now the nginx part. Just create a new virtual host and use the following configuration:

upstream modoboa {
      server      unix:/var/run/gunicorn/modoboa.sock fail_timeout=0;
}

server {
      listen 443 ssl;
      ssl on;
      keepalive_timeout 70;

      server_name <host fqdn>;
      root <modoboa's root dir>;

      access_log  /var/log/nginx/<host fqdn>.access.log;
      error_log /var/log/nginx/<host fqdn>.error.log;

      ssl_certificate     <ssl certificate for your site>;
      ssl_certificate_key <ssl certificate key for your site>;

      location /sitestatic/ {
              autoindex on;
      }

      location /media/ {
              autoindex on;
      }

      location / {
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header Host $http_host;
              proxy_redirect off;
              proxy_set_header X-Forwarded-Protocol ssl;
              proxy_pass http://modoboa;
      }
}

If you do not plan to use SSL then change the listen directive to listen 80; and delete each of the following directives:

ssl on;
keepalive_timeout 70;
ssl_certificate     <ssl certificate for your site>;
ssl_certificate_key <ssl certificate key for your site>;
proxy_set_header X-Forwarded-Protocol ssl;

If you do plan to use SSL, you’ll have to generate a certificate and a key. This article contains information about how to do it.

Paste this content to your configuration (replace values between <> with yours), restart nginx and enjoy a really fast application!

uWSGI¶

The following setup is meant to get you started quickly. You should read the documentation of both nginx and uwsgi to understand how to optimize their configuration for your site.

The Django documentation includes the following warning regarding uwsgi:

Use uwsgi 1.2.6 or newer. If you do not, you will run into problems. Modoboa will fail in obscure ways.

To use this setup, first download and install uwsgi.

Here is a sample nginx configuration:

server {
    listen 443 ssl;
    ssl on;
    keepalive_timeout 70;

    server_name <host fqdn>;
    root <modoboa's settings dir>;

    ssl_certificate     <ssl certificate for your site>;
    ssl_certificate_key <ssl certificate key for your site>;

    access_log  /var/log/nginx/<host fqdn>.access.log;
    error_log /var/log/nginx/<host fqdn>.error.log;

    location <modoboa's root url>/sitestatic/ {
            autoindex on;
            alias <location of sitestatic on your file system>;
    }

    # Whether or not Modoboa uses a media directory depends on how
    # you configured Modoboa. It does not hurt to have this.
    location <modoboa's root url>/media/ {
            autoindex on;
            alias <location of media on your file system>;
    }

    # This denies access to any file that begins with
    # ".ht". Apache's .htaccess and .htpasswd are such files. A
    # Modoboa installed from scratch would not contain any such
    # files, but you never know what the future holds.
    location ~ /\.ht {
        deny all;
    }

    location <modoba's root url>/ {
        include uwsgi_params;
        uwsgi_pass <uwsgi port>;
        uwsgi_param UWSGI_SCRIPT <modoboa instance name>.wsgi:application;
        uwsgi_param UWSGI_SCHEME https;
    }
}

<modoboa instance name> must be replaced by the value you used when you deployed your instance.

If you do not plan to use SSL then change the listen directive to listen 80; and delete each of the following directives:

ssl on;
keepalive_timeout 70;
ssl_certificate     <ssl certificate for your site>;
ssl_certificate_key <ssl certificate key for your site>;
uwsgi_param UWSGI_SCHEME https;

If you do plan to use SSL, you’ll have to generate a certificate and a key. This article contains information about how to do it.

Make sure to replace the <...> in the sample configuration with appropriate values. Here are some explanations for the cases that may not be completely self-explanatory:

<modoboa's settings dir>

Where Modoboa’s settings.py resides. This is also where the sitestatic and media directories reside.

<modoboa's root url>

This is the URL which will be the root of your Modoboa site at your domain. For instance, if your Modoboa installation is reachable at at https://foo/modoboa then <modoboa's root url> is /modoboa. In this case you probably also have to set the alias directives to point to where Modoboa’s sitestatic and media directories are because otherwise nginx won’t be able to find them.

If Modoboa is at the root of your domain, then <modoboa root url> is an empty string and can be deleted from the configuration above. In this case, you probably do not need the alias directives.

<uwsgi port>

The location where uwsig is listening. It could be a unix domain socket or an address:port combination. Ubuntu configures uwsgi so that the port is:

unix:/run/uwsgi/app/<app name>/socket

where <app name> is the name of the application.

Your uwsgi configuration should be:

[uwsgi]
# Not needed when using uwsgi from pip
# plugins = python
chdir = <modoboa's top dir>
module = <name>.wsgi:application
master = true
harakiri = 60
processes = 4
vhost = true
no-default-app = true

The plugins directive should be turned on if you use a uwsgi installation that requires it. If uwsgi was installed from pip, it does not require it. In the configuration above:

<modoboa's top dir>

The directory where manage.py resides. This directory is the parent of <modoboa's settings dir>

<name>

The name that you passed to modoboa-admin.py deploy when you created your Modoboa instance.

bower command is missing in manage.py¶

bower command is missing in manage.py if you don’t use the --devel option of the modoboa-admin.py deploy command.

To fix it, regenerate your instance or update your settings.py file manually. Look at devmode in https://github.com/tonioo/modoboa/blob/master/modoboa/core/commands/templates/settings.py.tpl

Playing with parameters¶

To declare a new administration parameter, use the following function:

from modoboa.lib import parameters

parameters.register_admin(name, **kwargs)

To declare a new user parameter, use the following function:

parameter.register_user(name, **kwargs)

Both functions accept extra arguments listed here:

• type : parameter’s type, possible values are : int, string, list, list_yesno,
• deflt : default value,
• help : help text,
• values : list of possible values if type is list.

Account¶

To add a new tab to the account edition form, define new listeners (handlers) for the following events:

• ExtraAccountForm
• FillAccountInstances
• CheckExtraAccountForm (optional)

Example:

from modoboa.lib import events

@events.observe("ExtraAccountForm")
def extra_account_form(user, account=None):
    return [
        {"id": "tabid", "title": "Title", "cls": MyFormClass}
    ]

@events.observe("FillAccountInstances")
def fill_my_tab(user, account, instances):
    instances["id"] = my_instance

Domain¶

To add a new tab to the domain edition form, define new listeners (handlers) for the following events:

• ExtraDomainForm
• FillDomainInstances

Example:

from modoboa.lib import events

@events.observe("ExtraDomainForm")
def extra_domain_form(user, domain):
    return [
        {"id": "tabid", "title": "Title", "cls": MyFormClass}
    ]

@events.observe("FillDomainInstances")
def fill_my_tab(user, domain, instances):
    instances["id"] = my_instance

AccountAutoCreated¶

Raised when a new account is automatically created (example: LDAP synchronization).

Callback prototype:

def callback(account): pass

• account is the newly created account (User instance)

AccountCreated¶

Raised when a new account is created.

Callback prototype:

def callback(account): pass

• account is the newly created account (User instance)

AccountDeleted¶

Raised when an existing account is deleted.

Callback prototype:

def callback(account, byuser, **options): pass

• account is the account that is going to be deleted
• byuser is the adminstrator deleting account

AccountExported¶

Raised when an account is exported to CSV.

Callback prototype:

def callback(account): pass

• account is the account being exported

Must return a list of values to include in the export.

AccountImported¶

Raised when an account is imported from CSV.

Callback prototype:

def callback(user, account, row): pass

• user is the user importing the account
• account is the account being imported
• row is a list containing what remains from the CSV definition

AccountModified¶

Raised when an existing account is modified.

Callback prototype:

def callback(oldaccount, newaccount): pass

• oldaccount is the account before it is modified
• newaccount is the account after the modification

AdminMenuDisplay¶

Raised when an admin menu is about to be displayed.

Callback prototype:

def callback(target, user): pass

The target argument indicates which menu is being displayed. Possible values are:

• admin_menu_box : corresponds to the menu bar available inside administration pages
• top_menu : corresponds to the top black bar

See UserMenuDisplay for a description of what callbacks that listen to this event must return.

CheckDomainName¶

Raised before the unicity of a domain name is checked. By default, modoboa prevents duplicate names between domains and domain aliases but extensions have the possibility to extend this rule using this event.

Callback prototype:

def callback(): pass

Must return a list of 2uple, each one containing a model class and an associated label.

CheckExtraAccountForm¶

When an account is being modified, this event lets extensions check if this account is concerned by a specific form.

Callback prototype:

def callback(account, form): pass

• account is the User instance beeing modified
• form is a dictionnary (same content as for ExtraAccountForm)

Callbacks listening to this event must return a list containing one Boolean.

DomainAliasCreated¶

Raised when a new domain alias is created.

Callback prototype:

def callback(user, domain_alias): pass

• user is the new domain alias owner (User instance)
• domain_alias is the new domain alias (DomainAlias instance)

DomainAliasDeleted¶

Raised when an existing domain alias is about to be deleted.

Callback prototype:

def callback(domain_alias): pass

• domain_alias is a DomainAlias instance

DomainCreated¶

Raised when a new domain is created.

Callback prototype:

def callback(user, domain): pass

• user corresponds to the User object creating the domain (its owner)
• domain is a Domain instance

DomainDeleted¶

Raised when an existing domain is about to be deleted.

Callback prototype:

def callback(domain): pass

• domain is a Domain instance

DomainModified¶

Raised when a domain has been modified.

Callback prototype:

def callback(domain): pass

• domain is the modified Domain instance, it contains an extra oldname field which contains the old name

DomainOwnershipRemoved¶

Raised before the ownership of a domain is removed from its original creator.

Callback prototype:

def callback(owner, domain): pass

• owner is the original creator
• domain is the Domain instance being modified

ExtraAccountActions¶

Raised when the account list is displayed. Let developers define new actions to act on a specific user.

Callback prototype:

def callback(account): pass

• account is the account being listed

ExtraAccountForm¶

Let extensions add new forms to the account edition form (the one with tabs).

Callback prototype:

def callback(user, account): pass

• user is a User instance corresponding to the currently logged in user
• account is the account beeing modified (User instance)

Callbacks listening to the event must return a list of dictionnaries, each one must contain at least three keys:

{"id" : "<the form's id>",
 "title" : "<the title used to present the form>",
 "cls" : TheFormClassName}

ExtraAdminContent¶

Let extensions add extra content into the admin panel.

Callback prototype:

def callback(user, target, currentpage): pass

• user is a User instance corresponding to the currently logged in user
• target is a string indicating the place where the content will be displayed. Possible values are : leftcol
• currentpage is a string indicating which page (or section) is displayed. Possible values are : domains, identities

Callbacks listening to this event must return a list of string.

ExtraDomainEntries¶

Raised to request extra entries to display inside the domains listing.

Callback prototype:

def callback(user, domfilter, searchquery, **extrafilters): pass

• user is the User instance corresponding to the currently logged in user
• domfilter is a string indicating which domain type the user needs
• searchquery is a string containing a search query
• extrafilters is a set of keyword arguments that may contain additional filters

Must return a valid QuerySet.

ExtraDomainFilters¶

Raised to request extra filters for the domains listing page. For example, the postfix_relay_domains extension let users filter entries based on service types.

Callback prototype:

def callback(): pass

Must return a list of valid filter names (string).

ExtraDomainForm¶

Let extensions add new forms to the domain edition form (the one with tabs).

Callback prototype:

def callback(user, domain): pass

• user is a User instance corresponding to the currently logged in user
• domain is the domain beeing modified (Domain instance)

Callbacks listening to the event must return a list of dictionnaries, each one must contain at least three keys:

{"id" : "<the form's id>",
 "title" : "<the title used to present the form>",
 "cls" : TheFormClassName}

ExtraDomainImportHelp¶

Raised to request extra help text to display inside the domain import form.

Callback prototype:

def callback(): pass

Must return a list a string.

ExtraDomainMenuEntries¶

Raised to request extra entries to include in the left menu of the domains listing page.

Callback prototype:

def callback(user): pass

• user is the User instance corresponding to the currently logged in user

Must return a list of dictionaries. Each dictionary must contain at least three keys:

{"name": "<menu name>",
 "label": "<menu label>",
 "url": "<menu url>"}

ExtraFormFields¶

Raised to request extra fields to include in a django form.

Callback prototype:

def callback(form_name, instance=None): pass

• form_name is a string used to distinguish a specific form
• instance is a django model instance related to form_name

Must return a list of 2uple, each one containing the following information:

('field name', <Django form field instance>)

ExtraRelayDomainForm¶

Let extensions add new forms to the relay domain edition form (the one with tabs).

Callback prototype:

def callback(user, rdomain): pass

• user is the User instance corresponding to the currently logged in user
• rdomain is the relay domain being modified (RelayDomain instance)

Callbacks listening to the event must return a list of dictionnaries, each one must contain at least three keys:

{"id" : "<the form's id>",
 "title" : "<the title used to present the form>",
 "cls" : TheFormClassName}

FillAccountInstances¶

When an account is beeing modified, this event is raised to fill extra forms.

Callback prototype:

def callback(user, account, instances): pass

• user is a User instance corresponding to the currently logged in user
• account is the User instance beeing modified
• instances is a dictionnary where the callback will add information needed to fill a specific form

FillDomainInstances¶

When a domain is beeing modified, this event is raised to fill extra forms.

Callback prototype:

def callback(user, domain, instances): pass

• user is a User instance corresponding to the currently logged in user
• domain is the Domain instance beeing modified
• instances is a dictionnary where the callback will add information needed to fill a specific form

FillRelayDomainInstances¶

When a relay domain is being modified, this event is raised to fill extra forms.

Callback prototype:

def callback(user, rdomain, instances): pass

• user is the User instance corresponding to the currently logged in user
• rdomain is the RelayDomain instance being modified
• instances is a dictionnary where the callback will add information needed to fill a specific form

GetAnnouncement¶

Some places in the interface let plugins add their own announcement (ie. message).

Callback prototype:

def callback(target): pass

• target is a string indicating the place where the announcement will appear:
• loginpage : corresponds to the login page

Callbacks listening to this event must return a list of string.

GetDomainActions¶

Raised to request the list of actions available for the domains listing entry being displayed.

Callback prototype:

def callback(user, rdomain): pass

• user is the User instance corresponding to the currently logged in user
• rdomain is the RelayDomain instance being displayed

Must return a list of dictionaries, each dictionary containing at least the following entries:

{"name": "<action name>",
 "url": "<action url>",
 "title": "<action title>",
 "img": "<action icon>"}

GetDomainModifyLink¶

Raised to request the modification url of the domains listing entry being displayed.

Callback prototype:

def callback(domain): pass

• domain is a model instance (RelayDomain for example)

Must return a dictionary containing at least the following entry:

{'url': '<modification url>'}

GetExtraLimitTemplates¶

Raised to request extra limit templates. For example, the postfix_relay_domains extension define a template to limit the number of relay domains an administrator can create.

Callback prototype:

def callback(): pass

Must return a list of set. Each set must contain at least three entries:

[('<limit_name>', '<limit label>', '<limit help text>')]

GetExtraParameters¶

Raised to request extra parameters for a given parameters form.

Callback prototype:

def callback(application, level): pass

• application is the name of the form’s application (ie. admin, amavis, etc.)
• level is the form’s level: A for admin or U for user

Must return a dictionary. Each entry must be a valid Django form field.

GetExtraRolePermissions¶

Let extensions define new permissions for a given role.

Callback prototype:

def callback(rolename): pass

• rolename is the role’s name (str)

Callbacks listening to this event must return a list of list. The second list level must contain exactly 3 strings: the application name, the model name and the permission name. Example:

[
    ["core", "user", "add_user"],
    ["core", "user", "change_user"],
    ["core", "user", "delete_user"],
]

GetExtraRoles¶

Let extensions define new administrative roles (will be used to create or modify an account).

Callback prototype:

def callback(user, account): pass

• user is a User instance corresponding to the currently logged in user
• account is the account being modified (None on creation)

Callbacks listening to this event must return a list of 2uple (two strings) which respect the following format: (value, label).

GetStaticContent¶

Let extensions add static content (ie. CSS or javascript) to default pages. It is pretty useful for functionalities that don’t need a template but need javascript stuff.

Callback prototype:

def callback(caller, st_type, user): pass

• caller is name of the application (or the location) responsible for the call
• st_type is the expected static content type (css or js)
• user is a User instance corresponding to the currently logged in user

Callbacks listening to this event must return a list of string.

ImportObject¶

Raised to request the function handling an object being imported from CSV.

Callback prototype:

def callback(objtype): pass

objtype is the type of object being imported

Must return a list of function. A valid import function must respect the following prototype:

def import_function(user, row, formopts): pass

• user is the User instance corresponding to the currently logged in user
• row is a string containing the object’s definition (CSV format)
• formopts is a dictionary that may contain options

InitialDataLoaded¶

Raised a initial data has been loaded for a given extension.

Callback prototype:

 def callback(extname); pass

``extname`` is the extension name (str)

MailboxAliasCreated¶

Raised when a new mailbox alias is created.

Callback prototype:

def callback(user, mailbox_alias): pass

• user is the new domain alias owner (User instance)
• mailbox_alias is the new mailbox alias (Alias instance)

MailboxAliasDeleted¶

Raised when an existing mailbox alias is about to be deleted.

Callback prototype:

def callback(mailbox_alias): pass

• mailbox_alias is an Alias instance

MailboxCreated¶

Raised when a new mailbox is created.

Callback prototype:

def callback(user, mailbox): pass

• user is the new mailbox’s owner (User instance)
• mailbox is the new mailbox (Mailbox instance)

MailboxDeleted¶

Raised when an existing mailbox is about to be deleted.

Callback prototype:

def callback(mailbox): pass

• mailbox is a Mailbox instance

MailboxModified¶

Raised when an existing mailbox is modified.

Callback prototype:

def callback(mailbox): pass

• mailbox is the Mailbox modified instance. It contains a old_full_address extra field to check if the address was modified.

PasswordChange¶

Raised just before a password change action.

Callback prototype:

def callback(user): pass

• user is a User instance

Callbacks listening to this event must return a list containing either True or False. If at least one True is returned, the password change will be cancelled (ie. changing the password for this user is disabled).

TopNotifications¶

Lets extensions subscribe to the global notification service (located inside the top bar).

Callback prototype:

def callback(user, include_all): pass

• request is a Request instance
• include_all is a boolean indicating if empty notifications must be included into the result or not

Callbacks listening to this event must return a list of dictionary, each dictionary containing at least the following entries:

{"id": "<notification entry ID>",
 "url": "<associated URL>",
 "text": "<text to display>"}

If your notification needs a counter, you can specify it by adding the two following entries in the dictionary:

{“counter”: <associated counter>,

“level”: “<info|success|warning|error>”}

UserLogin¶

Raised when a user logs in.

Callback prototype:

def callback(request, username, password): pass

UserLogout¶

Raised when a user logs out.

Callback prototype:

def callback(request): pass

UserMenuDisplay¶

Raised when a user menu is about to be displayed.

Callback prototype:

def callback(target, user): pass

The target argument indicates which menu is being displayed. Possible values are:

• options_menu: corresponds to the top-right user menu
• uprefs_menu: corresponds to the menu bar available inside the User preferences page
• top_menu: corresponds to the top black bar

All the callbacks that listen to this event must return a list of dictionnaries (corresponding to menu entries). Each dictionnary must contain at least the following keys:

{"name" : "a_name_without_spaces",
 "label" : _("The menu label"),
 "url" : reverse("your_view")}

RelayDomainAliasCreated¶

Raised when a new relay domain alias is created.

Callback prototype:

def callback(user, rdomain_alias): pass

• user is the new relay domain alias owner (User instance)
• rdomain_alias is the new relay domain alias (DomainAlias instance)

RelayDomainAliasDeleted¶

Raised when an existing relay domain alias is about to be deleted.

Callback prototype:

def callback(rdomain_alias): pass

• rdomain_alias is a RelayDomainAlias instance

RelayDomainCreated¶

Raised when a new relay domain is created.

Callback prototype:

def callback(user, rdomain): pass

• user corresponds to the User object creating the relay domain (its owner)
• rdomain is a RelayDomain instance

RelayDomainDeleted¶

Raised when an existing relay domain is about to be deleted.

Callback prototype:

def callback(rdomain): pass

• rdomain is a RelayDomain instance

RelayDomainModified¶

Raised when a relay domain has been modified.

Callback prototype:

def callback(rdomain): pass

• rdomain is the modified RelayDomain instance, it contains an

  extra oldname field which contains the old name

RoleChanged¶

Raised when the role of an account is about to be changed.

Callback prototype:

def callback(account, role): pass

• account is the account being modified
• role is the new role (string)

SaveExtraFormFields¶

Raised to save extra fields declared using ExtraFormFields.

Callback prototype:

def callback(form_name, instance, values): pass

• form_name is a string used to distinguish a specific form
• instance is a django model instance related to form_name
• values is a dictionary containing the form’s values

UserCanSetRole¶

Raised to check if a user is allowed to set a given role to an account.

Callback prototype:

def callback(user, role, account): pass

• user is the User instance corresponding to the currently logged in user
• role is the role user tries to set
• account is the account being modified (None on creation)

Must return a list containing True or False to indicate if this user can is allowed to set role.