Any docker-compose file for this tool?
jlgarnier opened this issue · 12 comments
Hi all,
I'm looking for an example docker-compose file to deploy a test instance of this tool (I'm really not a Docker expert): would anyone mind sharing one?
Thanks in advance for any help!
Hi,
You can start with the following example as a basis for your compose.yaml file and adapt it according to the documentation and your requirements. Please note that even for a test you will need to add the proper DNS records for your domain to make it works.
services:
mailman:
image: d3fk/mailman2
container_name: mailman
hostname: ${EMAIL_HOST}
restart: always
ports:
- "80:80"
- "25:25"
- "465:465"
environment:
EMAIL_HOST: ${EMAIL_HOST}
URL_HOST: ${URL_HOST}
LIST_ADMIN: ${LIST_ADMIN}
MASTER_PASSWORD: ${MASTER_PASSWORD}
URL_PATTERN: ${URL_PATTERN}
URL_ROOT: ${URL_ROOT}
extra_hosts:
- ${EMAIL_HOST}:127.0.0.1
You can replace the env vars by your values in the compose.yaml or create in the same directory a .env file that will be easier to maintain e.g.:
.env
URL_HOST=lists.example.com
EMAIL_HOST=mails.example.com
LIST_ADMIN=youremail@example.com
MASTER_PASSWORD=example
URL_PATTERN=http
URL_ROOT=lists/
You can complete the compose.yaml and .env with environment variables listed in the ENVIRONMENT section
Then simply run your compose file with docker-compose up -d and visit your $URL_HOST/$URL_ROOT/admin to start managing your mailing lists (indicate the mapped port after the URL_HOST if required).
Hope this helps.
Dont forget to visit the logs of the mailman container you have created:
$ docker logs mailman
The logs will display the deployment steps of the container and provide you in the end with a valid DKIM public key value and the DKIM txt record that can be added to your DNS records to enable DKIM check for your mailman mailing list server.
The mailing lists cannot be really functional with a host set to localhost since they require a valid EMAIL_HOST name to be configured.
Hi,
Glad it helps and thank you for the feedback ! 😁
NB:
-
Yes, in the .env file the environment variables have to be given with a = as if they are set with a linux export.
-
In the compose.yaml file the environment values can be set either with an array or a dictionary (so either
- URL_HOST=lists.example.comorURL_HOST: lists.example.comhttps://docs.docker.com/compose/compose-file/compose-file-v3/#environment). Any boolean values (true, false, yes, no) need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser. -
Regarding the LE certificate, if you need a rapid set up you can make use of the official core Certbot image
certbot/certbot.
Hi,
The port redirection you mention is just port mapping, it is invisible for exim from the container, so they are not involved if your listed mapped ports are well open ports on your cloud IT.
This observed behaviour with new subscription is due to the configuration of mailman set by default in this container that were thought to be more convenient ... as stated in the documentation (mailman configuration).
You can activate the option entitled "Should administrator get notices of subscribes and unsubscribes?" from the mailing list interface(General options section) or change the default config file by using a volume.
NB: The MX DNS record is also important: it declares that your EMAIL_HOST is authorised to send email for your domain/subdomain name 😉
I then suspected I had to add
- A record: server1 IN A < server IP address>
- A record: mails IN A (seems CNAME here is forbidden), may be useless
- MX record: mails IN MX 50 server1.eurosmart.com.
In your case, the A record for your domain name simply enables you to access your mailman website with a domain name, so, not strictly compulsory but pretty useful.
As your URL_HOST and EMAIL_HOST are different, you'll indeed also need an A record for your EMAIL_HOST to declare the subdomain/domain that will be associated to your email server/load-balancer/reverse-proxy.
The MX record is indeed required, you can define different priorities if you have several MX.
A PTR record will also have an important impact on your email deliverability since a reverse DNS lookups is made by email servers to ensure your email server is well who it says to be.
If you have gmail addresses in your mailing lists, a DKIM record will also probably be part of the minimal records since it seems that gmail would not accept mails from servers without a valid DKIM to avoid spoofing (not experimented, only got feedback about it ... maybe other email providers are requiring/will require it)
The other suggested records by the DNS configuration section of the documentation (i.e SPF and DMARC) are currently only improving the deliverability of your emails but they are more and more often checked by emails servers and they currently impact the SPAM tagging of your messages.
By the way, I don’t know where the issuing IP address mentioned
BTW it is probably the IP of the computer you used (or seen by the email server: might be a proxy depending on your configuration) to subscribe the new users to the list.
and Mailman is now able to send notifications for subscriptions.
Email notifications ? If email notifications for subscriptions are well sent by Mailman and delivered to a recipient, this recipient address receiving the notifications should also receive the messages sent to the list if this email address is well part of the members addresses of this list.
I just couldn’t find how to set up the PTR record.
If part of your list members do not receive the message you might indeed encounter a problem of email deliverability due to a miss configured PTR record/reverse DNS: some email servers are less regarding to the PTR record but they are mostly small or local email servers, for the most used email servers it is now part of the rules to systematically check the PTR record before permitting the messages delivery.
The PTR record can be configured and controlled by the IP block owners (usually the server hosting company so probably you local hosting provider for your email service).
In case you own the local DNS server on our own, you'll need to create a reverse DNS zone.
In the event where your d3fk/mailman2 never sent an email till now you can check that you can send an email directly from the MTA (Exim) of your running d3fk/mailman2 container to one of your valid email address with something like the following command:
$ docker exec -ti mailman exim -v workingmail@workingdomain.tel
wait a few seconds for the empty prompt then enter the following lines
From: user@lists.mydomain.tel
Subject: Test mail
Simple test message
Finally send your test email by pressing ctrl+d ; you should see the details about the SMTP connection that might help you for debugging purpose.
Hope this helps.