| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Keys are generated using the config from the previous commit and stored
in the dkim data volume. The key length is set to 1024 bits for
compatibility with nameservers. See this quote from the opendkim
readme:
BIND servers have a 256 byte limit on serving TXT records, so a 1024
bit RSA key is recommended if using BIND as your primary DNS server.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
The postfix user is added to the opendkim group so that the MTA can
eventually interact with the filter over its socket file.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Removing this option causes the UIDs and GIDs to match, which is
desirable since GIDs have not yet been predictable. The other
differences with --system don't matter for our purposes.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Incoming mail for an mlmmj list is caught by a virtual mapping and
directed via virtual transport to the mlmmj system for processing.
Outgoing mail is implicitly allowed since it originates from the
localhost.
The postfix entrypoint script now dynamically generates these mailing
list mappings on startup from data in the mlmmj spool directory, so user
configuration is minimal. In addition, the script will now sync the
user's mailing list parameters into the spool directory, thus
automatically creating new lists and deleting old ones.
The list creation logic is implemented in a new script `make_list.sh`.
This is made necessary as the mlmmj built in tooling for this must be
run interactively, so we duplicate the logic. This is separate from
`entrypoint.sh` mainly because we need to drop privileges to the mlmmj
user while creating files.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Protect user privacy by stripping IP addresses from headers received
from authenticated mail submission. Headers for mail received from
other servers are unaffected.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
As hinted by the previous commit, the mailnode system is built in a
single docker image for simplicity. Defining multiple Dockerfiles would
lead to many redundant tasks and be harder to maintain. So a common
image for all services is built.
However, the compose file spawns a unique container for each service,
and communication occurs via the filesystem, through volumes. Note also
that some fields in docker-compose.yml are required to be set by the
end-user.
The mail system is oriented around virtual users, so that nobody needs
their own unix system account. However, best security practice is to
create a dedicated user to own the mails - this user shouldn't be used
for any other purpose. For this, the Dockerfile creates the user
"vmailbox".
The reason for declaring port exposure for TCP/80 is to enable automated
TLS encryption with nginx-proxy-acme. This port is not actually opened
by the compose file.
Signed-off-by: Malfurious <m@lfurio.us>
|
