Mailu: Use fixed versioning for upstream Alpine:3.7

[muhlemmer]

I was playing around a bit to get Swarm to work. This involved removing earlier downloaded images and re-download them (today). I got all kinds of funky behaviour and decided to got back to the "classic" approach (docker-compose). However, after all the cleanup and running docker-compose up -d against my original .env (which worked yesterday) I still get all sorts of strange behaviour.

After going throug the logs, I found this:

smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_alias_maps.cf: unused parameter: dbpath=/data/main.db
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_alias_maps.cf: unused parameter: query=SELECT destination   FROM     (SELECT destination, email, wildcard, localpart FROM alias      UNION      SELECT (CASE WHEN forward_enabled=1 THEN (CASE WHEN forward_keep=1 THEN email||',' ELSE '' END)||forward_destination ELSE email END) AS destination, email, 0 as wildcard, localpart FROM user      UNION      SELECT '@'||domain_name as destination, '@'||name as email, 0 as wildcard, '' as localpart FROM alternative)   WHERE     (      wildcard = 0      AND      email = '%s'     ) OR (      wildcard = 1      AND      '%s' LIKE email     )   ORDER BY     wildcard ASC,     length(localpart) DESC   LIMIT 1
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-transport.cf: unused parameter: dbpath=/data/main.db
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-transport.cf: unused parameter: query=SELECT 'smtp:['||smtp||']' FROM relay WHERE name='%s'
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-reject-spoofed.cf: unused parameter: dbpath=/data/main.db
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-reject-spoofed.cf: unused parameter: query=SELECT 'REJECT' FROM domain WHERE name='%s'  UNION  SELECT 'REJECT' FROM alternative WHERE name='%s'
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_mailbox_domains.cf: unused parameter: dbpath=/data/main.db
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_mailbox_domains.cf: unused parameter: query=SELECT name FROM domain WHERE name='%s'  UNION  SELECT name FROM alternative WHERE name='%s'
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_alias_maps.cf: unused parameter: dbpath=/data/main.db
smtp_1       | postconf: warning: sqlite:/etc/postfix/sqlite-virtual_alias_maps.cf: unused parameter: query=SELECT destination   FROM     (SELECT destination, email, wildcard, localpart FROM alias      UNION      SELECT (CASE WHEN forward_enabled=1 THEN (CASE WHEN forward_keep=1 THEN email||',' ELSE '' END)||forward_destination ELSE email END) AS destination, email, 0 as wildcard, localpart FROM user      UNION      SELECT '@'||domain_name as destination, '@'||name as email, 0 as wildcard, '' as localpart FROM alternative)   WHERE     (      wildcard = 0      AND      email = '%s'     ) OR (      wildcard = 1      AND      '%s' LIKE email     )   ORDER BY     wildcard ASC,     length(localpart) DESC   LIMIT 1

This kind of messages repeat a couple of time and then this shows smtpd is crashing (same message is flooding the logs):

smtp_1       | postfix/master[107]: warning: process /usr/lib/postfix/smtpd pid 115 exit status 1
smtp_1       | postfix/master[107]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
smtp_1       | postfix/smtpd[116]: fatal: in parameter smtpd_relay_restrictions or smtpd_recipient_restrictions, specify at least one working instance of: reject_unauth_destination, defer_unauth_destination, reject, defer, defer_if_permit or check_relay_domains

So google tells me unused parameter means the config syntax is no longer supported. Big bummer if the server depends on the queries. I saw on Docker hub that mailu/Postfix:1.5 was re-build only yesterday evening, around 19:00 UTC. No version increment. (Bad boy! :p) This became the new suspect.

Although, on Github the :1.5 tag remains unchained, upstream alpine has released postfix-3.3.0 middle of June. The previous 1.5 versioned image was 2 months ago, before this release. The Dockerfile shamelesly pulls in any latest version on rebuild:

RUN apk add --no-cache postfix postfix-sqlite postfix-pcre rsyslog python py-jinja2

To confirm:

# docker exec -it 19cd0746f9d9 postconf -d | grep mail_version
mail_version = 3.3.0

So I went ahead to find the Postfix release notes for 3.3.0. And behold some mayor changes:

Postfix stable release 3.3.0 is available. This release ends support for legacy release Postfix 2.11.
....
Container support: Postfix 3.3 will run in the foreground with "postfix start-fg". This requires that Postfix multi-instance support is disabled (the default). To collect Postfix syslog information on the container's host, mount the host's /dev/log socket into the container, for example with "docker run -v /dev/log:/dev/log ...other options...", and specify a distinct Postfix syslog_name setting in the container (for example with "postconf syslog_name=the-name-here").

My guts tell me the issue has to do with the dropped support of 2.11. I remember a lot of DB query documentation online is still from the Postix 2.x days and probably not valid anymore.

Would it be possible to restore the original 1.5 build in the repository, and maybe do in version increment to 1.5.1 for the new build? Only then I can be 100% certain this is the problem. (Or you can try to break your own system by pulling the new images)

Original symptoms (for completeness):

1. No inbound mail arriving, tried sending from different domains
2. When trying to send from roundcube webmail, after hitting the send button, it tries to send forever, bu nothing happend. On page reload the message is nowhere to be found.

[muhlemmer]

I just found that alpine:3.7 is still using postfix-3.2. Perhaps tagging to that Alpine release in the Dockerfiles can solve this issue for now. (Tagging upstream version gives you more control on versioning in general)

I would try it myself, but I give up for the day. If needed I will fork and test after the weekend. Cheers!

[muhlemmer]

https://github.com/Mailu/Mailu/commit/3dca1a834cb17086c32e8889874528f43c8a29a9
Like, issue #522. I think I have a point here :stuck_out_tongue_closed_eyes:

[v1ru535]

Same issue here :/

[steffbeckers]

Setup Mailu for the first time an hour ago and got the same issue

[muhlemmer]

Pull #549 fixes the issues for the 1.5 branch. If there are users stranded, they could try the image I've uploaded for testing. muhlemmer/postfix:1.5 in docker-compose.yml. No warranty whatsoever, but at least you can try it out. (Or build the postfix image yourself with the dockerfile from the pull)

[v1ru535]

Test after this message, I'll come back soon :)
Thx guy

[v1ru535]

Big UP @muhlemmer , you fix this!

Thanks for the debug and the work, a lot of time won for me :)

[kaiyou]

Thank you so much for handling this while I was gone for a day, I urgently pinned the Alpine version this morning so the rebuild should do the job.

[kaiyou]

Next urgent fix: pin every alpine version and essential package version across Mailu.

[kaiyou]

I also just ported this to master so intrepid users may still receive emails.

[muhlemmer]

@kaiyou

Next urgent fix: pin every alpine version and essential package version across Mailu.

I think the most convenient way for future maintenance would be to include a versioned, but vanilla alpine image in this project. Then, all the Mailu Dockerfiles can point to this image. This way all the images are on a synchronized version and bumping would imply only to change a single file.

I'll submit a pull request against master later today, or after the weekend with my proposal.

For the 1.5 version, I think it is better _not_ to make structural changes and just tag all the Dockerfiles separately. If you haven't started doing this yet, I can send a pull request for this as well. Just let me know if we won't be doing the same job twice. :wink:

[muhlemmer]

Another question, what about the older versions? (<1.5). Are they still supported? Does this need backporting? Or are rebuilds somehow blocked?

[hoellen]

@muhlemmer I think not all images of Mailu need to use a specific Alpine version, e.g. the clamav image should remain alpine:edge. There are often vulnerabilities which needs fast (security) updates of clamav.

[muhlemmer]

@hoellen; As far as I now, the clamav security / virus database is pulled in by clamav on runtime and does not depend so much on the release cycle. So unless you are talking about frequent security flaws in the program itself, this should not be a problem.

I'm not familiar with the alpine support cycle. But most distros are backporting security fixes, which don't imply changed functionality.

From a repository management point of view. A versioned release should lock down changes. If a versioned release no longer is secure, schedule a new release. Use sematic versioning.

In order to make sure of this, when a release is done, upstream imports should also be locked to a version.

An "edge" version is allowed to do whatever, without any stability or testing promise. The same is for a "master" branch, like here in mailu. Master is allowed to break. Master is not for production.

So, my proposal:

1. Abstract the alpine image in this repo.
2. Make it point to alpine:edge in the mailu:master branch.
3. Upon a versioned release, change to alpine:ver only in the release branch.

Using a single place for this makes it more maintainable.

[hoellen]

@muhlemmer I mean security flaws in clamav itself. Unfortunately Alpine does not always backport the security updates. So we should keep that in mind.

[muhlemmer]

After careful consideration, I realize that my abstracted image solution would not work properly. It will need to be versioned by itself to prevent pulling in the :master base image from Docker hub.

@kaiyou, do you want me to start to pin the alpine release to all image in 1.5?

Next urgent fix: pin every alpine version and essential package version across Mailu.

In my opinion, we should let :master to use alpine:edge unless it really breaks something. This way compatinilty issues can be detected as early as possible and a proper fix to be made before a released version. Please let me know if you agree. (If not, I can also pin versions for :master if you want.)

[kaiyou]

Agreed with your latest suggestion. Closing here and let's go this way :)