The settings file is required to set basic option for your Inboxen instance. It contains some secret information such as the secret_key
, you should ensure the permissions are set correctly and also that this file is kept safe as without it sessions, cookie storage and along with other things rely on this will not work1.
The Inboxen settings file can be located in several places on a system, it will use the first one it finds. Inboxen looks for the files in this order:
- The path specified in the environment variable:
INBOXEN_CONFIG
- ~/.config/inboxen/inboxen.config
- inboxen.config in the current working directory
- inboxen.config inside the base directory of the Inboxen project
If you're familiar with Django and would like to use your own settings module, you can set DJANGO_SETTINGS_MODULE
in the usual way2.
This also contains the default values for all configuration values.
../inboxen/config_defaults.yaml
To hit the ground running, the minimum you need to setup a development instance is:
secret_key: something-secret
debug: true
This is used as the global salt for cryptographic signing throughout Inboxen. This is security sensitive and should be generated using a random number generator. It's strongly suggested you use at least 50 characters of numbers, both case characters and symbols from a high entropy source.
This should be pairs of values denoting the name and email address of your admins, like so:
admins:
- - Me
- me@example.com
- - You
- you@example.com
This is a list of domains and/or IPs that Django will serve Inboxen on. There is support for wildcards, the syntax of which can be found in the Django documentation.
This value is prefixed to all URLs that are used in contexts outside of webpages, i.e. admin email notifications
Enabling this puts Inboxen into debug mode, this should never be used in a production environment as it exposes the state of some calls in Inboxen including the settings file. This should be used when developing on Inboxen as it allows for tracebacks to be displayed instead of emailed and disables allowed_hosts
checking.
A boolean flag which controls if the Inboxen instance permits registration, if disabled the site will not allow new users to be created through the public facing site and disables the links to the registration page.
This specifies the language code that is used as a fallback when one can't be detected by Django's locale middleware (or if the middleware is disabled). This should be set to a standard language ID format3.
This specifies where the directory is for serving static files. Django will use this directory to place static files when using:
python manage.py collectstatic
This specifies where the directory is for uploading media via the CMS. It should be writable by the Django app.
The email the server uses when sending emails.
The name of the site as displayed in page titles.
The link to the source code for the current instance. If you change any code in Inboxen this must be shared back under the terms of the AGPL v3, you should populate this with the link to the source code.
The link to the issue tracker. This link is displayed on error pages to encourage users to report problems.
The timezone used for the site, this is used for example when storing dates in the database.
If not 0
, this is the maximum number of emails a user can have before they need to delete some. This deletion can be done automatically if the user prefers.
Rate limits control various parts of Inboxen. Each rate limit section has a window (the timeframe a rate limit should be considering) and a count (the maximum number of times whatever that rate limit is protecting can happen with a window).
The following rate limits are available:
Controls how often a single user can create an inbox. Useful to prevent someone from exhausting all available inboxes.
Controls how often a user can try to login. This slows down password guessing attempts, but can block users who genuinely can't remember their passwords.
Controls how often a given IP can register a new account. Prevents circumventing of the inbox ratelimit.
Controls how often a user can download a single email. This is quite an intense workload for the server, so it is ratelimited to prevent the instance becoming overloaded.
The URL that celery will look at to find tasks and to store results.
The number of celery processes to start
Specifies the path where to store the liberation data. This needs to be kept secure as it will contain user data.
Which method should be used to accelerate liberation data downloads. This should be a dotted path to the django_sendfile2 backend you wish to use.
The name of the database.
User used when connecting to PostgreSQL.
The password used when connecting to PostgreSQL.
The host name or IP address to connect to for PostgreSQL.
The port to connect to for PostgreSQL.
The dotted path of the cache module you'd like to use.
The number of seconds before a cache entry is considered stale.
This is either the host and port for the memcached
backend or the path of the cache directory.