Status of this repo / docker image

[prometheanfire]

Classification

• Question

Reproducibility

• Always

Description

I see that you marked this repo as Unmaintained repo, are there plans to hand this off to someone. I'd be a shame to loose this (especially given the 1 million+ pulls). If you are looking for manpower I could probably help out a bit. I ran a very similiar setup to the docker image before migrating to it about a month ago...

[hardware]

Unmaintained status is not final if someone wants to take care of it. For now I have not found anyone to maintain this repo in an active and regular way, most people just want to make pull request (and that's fine), but that's not enough to maintain a project properly. And I do not want to leave any status, so I preferred to be clear about my position about the images set to find someone asap.

I have probably spent more than 1500+ hours on this docker image since 2016 and I need a maintainer who can take care of it on a monthly basis, because security and auditing are important, not a bit from time to time. But if several people can take care of it from time to time, it's good too.

This image was downloaded 1 million times last 6 months (jeez it's crazy), so that means a lot of people are using it, even small companies to my knowledge, so it's a responsibility.

[prometheanfire]

I'd be willing to help out, I already maintain stuff for a distro downstream, though not mail (mainly ldap as related to this repo). I think the problem may be that it is more than one person can handle. What about this is taking the most time? Where would help be best applied?

Following...

[hardware]

What about this is taking the most time ?

Testing / building / upgrade / project monitoring.

When you maintain an image for yourself it's easy, you can try and fail, then retry. But when people are using it with different purpose and usage, a good testing process, stability and backward compatibility are important, but that takes time.

Where would help be best applied ?

The next steps for this image are :

• Upgrade to Rspamd 2
• Upgrade to Treafik 2
• Upgrade to Debian 10 in stable branch (already working on the latest branch)

When you upgrade something, you need to test each piece of software, unit tests are very useful in this case, but it is not enough. After each change, you need to check the building process, the logs and behavior of all 6 images (mailserver_default, mailserver_reverse, mailserver_ecdsa, mailserver_ldap, mailserver_ldap2, mailserver_traefik_acmev1, mailserver_traefik_acmev2), then test in real conditions for weeks before pushing in stable branch.

[sknight80]

@hardware if we start adding testing infrastructure to this:

When you upgrade something, you need to test each piece of software, unit tests are very useful in this case, but it is not enough. After each change, you need to check the building process, the logs and behavior of all 6 images (mailserver_default, mailserver_reverse, mailserver_ecdsa, mailserver_ldap, mailserver_ldap2, mailserver_traefik_acmev1, mailserver_traefik_acmev2), then test in real conditions for weeks before pushing in stable branch.

Would be easier for maintaining the images? I am using this image and others from you, and I am willing to allocate my time to review, improve the repo.

[prometheanfire]

I believe the traefik-2 change was merged a week or two ago.
I could look at the rspamd-1 -> rspamd-2 upgrade. Though that'd fall behind the traefik-2 and debian-10 changes as they are already merged (just time wise).
For Debian 10, this means the testing needs to hit the scenarios to be approved for stable.

I wonder if some CI testing like we've done in openstack would help (we have a test unit called 'grenade' that tests upgrades, along with various scenarios).

After each change, you need to check the building process, the logs
and behavior of all 6 images (mailserver_default, mailserver_reverse,
mailserver_ecdsa, mailserver_ldap, mailserver_ldap2,
mailserver_traefik_acmev1, mailserver_traefik_acmev2)

I personally do not know what goes into each of these configurations and tests, but it can likely be automated.

acmev1 and v2 can likely be merged as they are hitting the same code path (just verify that it gets the right data from the datastructure and puts it in the right place for both acmev1 and acmev2). Once the datastructure munging part is tested, whatever goes for standard testing would occur.

The ecdsa testing sounds like it's testing if random_curve can be made to work with postfix? The readme looks like it handles that already documentation wise. It may also be easier to state what is supported / tested and leave going beyond that to the end user. Need to know when and what to test and all that. (hopefully this would drop that test).

I do not know why there are two ldap tests either, nor do I know the reason for the default and reverse tests, but perhaps they could be pruned down or focused.

Should be able to drop to 5 tests in my view.

1. mailserver_default
2. mailserver_reverse
3. mailserver_ecdsa
   a. dropped
4. mailserver_ldap
5. mailserver_ldap2
6. mailserver_traefik_acmev1
7. mailserver_traefik_acmev2
   a. merged with other acme test

I'm not sure why the images need to be deployed in the real world for so long and so many configurations. Are you looking to test something specific or has it caught something unexpected in the past? If not I'd reduce this test to be what's needed, not what feels good (sounds like over-caution may be a thing here).

[marcdeop]

I would be willing to help maintaining this software :-)

I have created a room at matrix.org: #mailserver:matrix.org in case anybody wants to join and have a more interactive talk/discussion.

Best,

Marc

[sknight80]

Hi Marcdeop! Sounds good. I joined to the chat.

[prometheanfire]

joined as well

[chuckmckinnon]

I'll join the chat. This is a great project, the best of its kind I've found, and it would be a shame for it to go unmaintained.

Count me in. I'll join.

[albjeremias]

is there a donation button somewhere? thank you so much for this project..

[albjeremias]

I'm not sure why the images need to be deployed in the real world for so long and so many configurations. Are you looking to test something specific or has it caught something unexpected in the past? If not I'd reduce this test to be what's needed, not what feels good (sounds like over-caution may be a thing here).

because email is complicated.. and if you want to test acme and SSL certificates you will need a real server for the tests!

mailserver_default

mailserver_reverse
mailserver_ecdsa
a. dropped
mailserver_ldap
mailserver_ldap2
mailserver_traefik_acmev1
mailserver_traefik_acmev2
a. merged with other acme test

I would suggest some other tests:

• test LDAP authentication
• test send an email
• test receive an email
  • test imap if email was received
  • test pop3 if email was received
• test spam filters somehow (SPF, DKIM, DMARC, ARC, ratelimit and greylisting capabilities)
• test automatic GPG
• test auto-responder, auto-forward
• test fetchmail
• test the webmail if logging in works
• test that you can login to postfixadmin
• find a test for unbound/NSD/traefik/SSL..?
• test LDAP (if login works)