mailman/templates/mailman.cfg.j2

# AUTOMATICALLY GENERATED BY MAILMAN ON 2020-01-20 11:51:47 UTC
#
# This is your GNU Mailman 3 configuration file.  You can edit this file to
# configure Mailman to your needs, and Mailman will never overwrite it.
# Additional configuration information is available here:
#
# https://mailman.readthedocs.io/en/latest/src/mailman/config/docs/config.html
#
# For example, uncomment the following lines to run Mailman in developer mode.
#
# [devmode]
# enabled: yes
# recipient: your.address@your.domain
[mailman]
# This address is the "site owner" address.  Certain messages which must be
# delivered to a human, but which can't be delivered to a list owner (e.g. a
# bounce from a list owner), will be sent to this address.  It should point to
# a human.
site_owner: {{ mailman_site_owner }}

# This is the local-part of an email address used in the From field whenever a
# message comes from some entity to which there is no natural reply recipient.
# Mailman will append '@' and the host name of the list involved.  This
# address must not bounce and it must not point to a Mailman process.
noreply_address: {{ mailman_noreply_addr }}

layout: {{ mailman_layout }}

[database]
{% if mailman_db == 'postgresql' %}
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgres://{{ mailman_db_user }}:{{ mailman_db_pwd }}@{{ mailman_db_host }}/{{ mailman_db_name }}
{% endif %}
[mta]
incoming: {{ mailman_mta_incoming }}
outgoing: {{ mailman_mta_outgoing }}
lmtp_host: {{ mailman_lmtp_host }}
lmtp_port: {{ mailman_lmtp_port }}
smtp_host: {{ mailman_smtp_host }}
# How to connect to the outgoing MTA.  If smtp_user and smtp_pass is given,
# then Mailman will attempt to log into the MTA when making a new connection.
smtp_port: {{ mailman_smtp_port }}
{% if mailman_smtp_auth %}
smtp_user: {{ mailman_smtp_user }}
smtp_pass: {{ mailman_smtp_pwd }}
{% endif %}
{% if mailman_smtp_secure_mode == 'starttls' %}
smtp_secure_mode: {{ mailman_smtp_secure_mode }}
{% endif %}
configuration: {{ mailman_smtp_conf }}

[paths.master]
# Important directories for Mailman operation.  These are defined here so that
# different layouts can be supported.   For example, a developer layout would
# be different from a FHS layout.  Most paths are based off the var_dir, and
# often just setting that will do the right thing for all the other paths.
# You might also have to set spool_dir though.
#
# Substitutions are allowed, but must be of the form $var where 'var' names a
# configuration variable in the paths.* section.  Substitutions are expanded
# recursively until no more $-variables are present.  Beware of infinite
# expansion loops!
#
# This is the root of the directory structure that Mailman will use to store
# its run-time data.
var_dir: /opt/mailman/var

# This is where the Mailman queue files directories will be created.
queue_dir: $var_dir/queue
# All list-specific data.
list_data_dir: $var_dir/lists
# Directory where log files go.
log_dir: /var/log/mailman
# Directory for system-wide locks.
lock_dir: $var_dir/locks
# Directory for system-wide data.
data_dir: $var_dir/data
# Cache files.
cache_dir: $var_dir/cache
# Directory for configuration files and such.
etc_dir: $var_dir/etc
# Directory containing Mailman plugins.
ext_dir: $var_dir/ext
# Directory where the default IMessageStore puts its messages.
messages_dir: $var_dir/messages
# Directory for archive backends to store their messages in.  Archivers should
# create a subdirectory in here to store their files.
archive_dir: $var_dir/archives
# Root directory for site-specific template override files.
template_dir: $var_dir/templates
# There are also a number of paths to specific file locations that can be
# defined.  For these, the directory containing the file must already exist,
# or be one of the directories created by Mailman as per above.
#
# This is where PID file for the master runner is stored.
pid_file: $var_dir/master.pid
# Lock file.
lock_file: $lock_dir/master.lck

[paths.fhs]
var_dir: {{ mailman_var_dir }}
# This is where the Mailman queue files directories will be created.
queue_dir: {{ mailman_spool_dir }}
log_dir: {{ mailman_log_dir }}
lock_dir: {{ mailman_lock_dir }}
# Directory for configuration files and such.
etc_dir: {{ mailman_conf_dir }}
list_data_dir: $var_dir/lists
data_dir: $var_dir/data
cache_dir: $var_dir/cache
ext_dir: $var_dir/ext
messages_dir: $var_dir/messages
archive_dir: $var_dir/archives
template_dir: $var_dir/templates
# This is where PID file for the master runner is stored.
pid_file: $var_dir/master.pid

[passwords]
# When Mailman generates them, this is the default length of passwords.
password_length: {{ mailman_password_length }}

[webservice]
# The hostname at which admin web service resources are exposed.
hostname: {{ mailman_webservice_hostname }}

# The port at which the admin web service resources are exposed.
port: {{ mailman_webservice_port}}

# Whether or not requests to the web service are secured through SSL.
use_https: {{ mailman_webservice_https }}

# Whether or not to show tracebacks in an HTTP response for a request that
# raised an exception.
show_tracebacks: {{ mailman_webservice_tracebacks }}

# The API version number for the current (highest) API.
api_version: 3.1

# The administrative username.
admin_user: {{ mailman_api_user }}

# The administrative password.
admin_pass: {{ mailman_rest_api_pwd }}

# Number of workers to start.
# http://docs.gunicorn.org/en/stable/settings.html#workers
workers: {{ ansible_processor_count * 2 }}

[ARC]
# This section defines email authetication parameters, in particular, with
# respect to the ARC(Authenticated-Recieved-Chain) protocol. See
# http://arc-spec.org/ for reference.
#
# The DMARC protocol is the industry standard for cryptographically validating
# both the content and originating source of email. However it is regularly
# the case that mailing lists break this source of authentication via modifying
# the From, and possibly other headers, and altering the contents of
# emails by, say, adding a common footer to outgoing mail.
# The ARC protocol is the industry standard for rectify this.
# ARC cryptographically seals the outgoing emails by adding a collection
# of headers.  These headers act quite analagously to a chain of DKIM
# signatures, where each intermediary validates the ARC signature(if one exists)
# of the incomming message, and then appends its own collection of header fields.
# Enabling this protocol makes it possible for email service providers
# to validate the content & originator of an email, even if it has taken multiple
# steps from the originator to the recipient.
#
# The general implementation of ARC within Mailman is addition of two
# additional handlers to the pipeline.  One, ate the very beginning of the
# pipeline cryptographically validaties the incomming ARC headers before the
# message has been modified, and appends its results to the
# Authentication-Results header.
#
# The second handler is at the end of the pipeline.  It cryptographically
# signs the message, with all modifications that have been made, along
# with the analysis of the validation handler, and adds its output as
# a new set of ARC header fields.

# This flag globally enables ARC signing & validation. To enable, set this to
# yes.
enabled: {{ mailman_arc_enabled }}

# DKIM & DMARC authentication checks on incoming email is critical to using ARC
# successfully. Mailman can do these check on its own, but if you already perform
# these checks earlier in your pipeline, say via a milter previous to Mailman,
# they can be used instead, as long as you specify your domain as a trusted
# domain below.  If those checks are not placed in an Authentication-Results
# header from a trusted domain they will be ignored.
dmarc: {{ mailman_dmarc_enabled }}
dkim: {{ mailman_dkim_enabled }}

# TRUSTED DOMAINS
#
# This is the domain name of your mailserver.  Necessary to set correctly.
# authserv_id: your_domain.com
authserv_id:

# This list should include all additional domains
# that you manage that may be handling your incoming mail
# Only necessary to update if there are local domains or subdomains
# that are performing DKIM, DMARC, or SPF checks.

# trusted_authserv_ids: subdomain.your_domain.com, trusted_other_domain.com
trusted_authserv_ids:

# KEY MANAGEMENT
#
# In order for your server to be able to cryptographical sign its messages
# a DKIM public/private key pair will need to be created.
# See: http://www.gettingemaildelivered.com/dkim-explained-how-to-set-up-and-use-domainkeys-identified-mail-effectively
# for reference.  The following parameters let the software find your
# private & public keys

# privkey: /some/location/yourprivatekey.pem
# selector: test
# domain: your_domain.com

privkey:
selector:
domain:

[antispam]
# This section defines basic antispam detection settings.

# This value contains lines which specify RFC 822 headers in the email to
# check for spamminess.  Each line contains a `key: value` pair, where the key
# is the header to check and the value is a Python regular expression to match
# against the header's value.  Multiple checks should be entered as multiline
# value with leading spaces:
#
# header_checks:
#   X-Spam: (yes|maybe)
#   Authentication-Results: mail.example.com; dmarc=(fail|quarantine)
#
# The header value and regular expression are always matched
# case-insensitively.
header_checks:
{% for h in  mailman_antispam_header_checks %}
   {{ h }}
{% endfor %}

# The chain to jump to if any of the header patterns matches.  This must be
# the name of an existing chain such as 'discard', 'reject', 'hold', or
# 'accept', otherwise 'hold' will be used.
jump_chain: hold

[runner.nntp]
class: mailman.runners.nntp.NNTPRunner
start: {{ mailman_start_nntp_runner }}

{% if mailman_use_hyperkitty_archiver | bool %}
[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
configuration: {{ mailman_conf_dir }}/mailman-hyperkitty.cfg
{% endif %}