Regular Project Meeting

[Nebukadneza]

meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab

We just had our first Mailu-Project-Video-Meeting! 🎉🎉🎉🎉🎉

It was great to be able to talk about the project, and @HorayNarea, @ofthesun9 and myself were able to discuss and sort out quite a chunk of work for the upcoming 1.8-release-candidate.

We not only agreed on trying to have follow-up meetings, possibly even regularly, but we also wanted to share the meeting-notes we took with everyone. In an open/free/libre project, the communication going on should also be visible and open/free.

So, from now on, this issue will serve as a drop-off point for the meeting notes. We don’t have a good idea how to best structure meeting/agenda-planning, so for now we agreed that we set a rough agenda for the next date at the end, and if someone wants to bring up an additional topic, this issue can be used to comment.

The voting for finding the next date is up on: https://nextcloud.ghostdub.de/apps/polls/s/UcyBGlzHMRrno9NG

Thanks to everyone involved!

2020-08-09

Attendees

• @HorayNarea
• @Nebukadneza
• @ofthesun9

Agenda

• Went through PRs sorted in 1.8-rc milestone
  • »Mob«-Merge the clearer portion
  • Discuss and comment on others
• Discuss alpine vs. debian
  • Gut-feeling: Most alpine issues sorted out
  • ClamAV-issue probably(?) related to swap rather than alpine/musl
  • Xapian solves missing/broken FTS on alpine
  • ⇒ Conclusion: For now, don’t invest the work/time to migrate to debian, stick with alpine
  • ⇒ Alpine update makes sense (approved)
• Agree @KaiyouS idea of posting »voting« messages in unclear-state-PRs/issues is a good idea
• Agree to introduce "Later" milestone to capture stuff that is imminently useful, but disregarded for current milstone due to scoping only.
• Agreed to have regular meetings from now on
  • The date for the next one will be voted at: https://nextcloud.ghostdub.de/apps/polls/s/GOGVrQZ3vOgAo9Ac

Follow-up topics

• Staying up to date with upstream versions
• Discussing HA for setup.mailu.io
• Triaging and scoping of biggest open issues
  • Open Relay issues when (incorrectly) using IPv6
  • Recurring BORS/Build&Test-Pipeline issues
  • (?) … Whatever other big issues currently are open (?)

[Diman0]

What I would also like to discuss

• implement bug fix template (most reported issue are very low quality)
• enabling github wiki for purpose of creating internal documentation on how mailu works internally.
• Enabling github stale robot ( https://github.com/probot/stale ) to automatically close issues.
  • e.g. automatically close issues with no comment for the last 3 weeks and no label assigned to it.

[Nebukadneza]

2020-08-23

Attendees

• Nebukadneza
• Dimitri

Agenda

• idea (dimitri): have a wiki!
  • only editable for contributors
  • only documenting internal / developer technical facts
  • thus not a lot of chance contents get out-of-sync with implementation
  • currently development is slower, so no big architectural changes
  • examples:
    • authentication architecture
    • integration of antispam in rspamd (instead of as milter)
    • etc …
  • Use as a base for content: Architecture : find some simplicity #1133
  • ⇒ Decision: Open wiki for contributors now, and see where we can get with it
    • Allow additional discussion in chat for limited time (e.g. 2 days?), then simply start the experiment
• adding dimitri to contributors
• go through PRs, fix and approve a few
• discuss issue template Discussion: Create issue templates for github #1331
  • good idea to reduce time triaging simple issues
  • maybe add instructions to get logs

Thank you for opening an issue with Mailu. Please understand that issue are meant for bugs and enhancement-requests — for user-support questions, please first try to reach out to us on <matrix link here>.

To be able to help you best, we need some more information …

## Before you open your issue
- [ ] Check if no issue or pull-request for this exists
- [ ] Check documentation and FAQ <add link>
- Please understand `Mailu` is made by volunteers in their free time — be conscise, civil and accept that delays can occur.

## Description
<How to write a good description text here>

## Environment & Versions
<Instructions to find versions and describe environment>

## Replication Steps
<Description on how to describe how to reproduce the issue>

## Logs
<If applicable, describe / link to documentation how to get logs. Tell user to scan logs for private information>

Follow-up topics

• Staying up to date with upstream versions
• Discuss big current issues
  • Open Relay issues when (incorrectly) using IPv6
  • Recurring BORS/Build&Test-Pipeline issues
  • (?) … Whatever other big issues currently are open (?)
• Enabling github stale robot (https://github.com/probot/stale) to automatically close issues
  • e.g. automatically close issues with no comment for the last 3 weeks and no label assigned to it

[Nebukadneza]

Poll to find a date for the next meeting: https://nextcloud.ghostdub.de/apps/polls/s/UcyBGlzHMRrno9NG

[Diman0]

Additional topics I'd like to discuss:

• Discuss scope of 1.8 release. Do we code freeze after last milestone 1.8 items are met? (https://github.com/Mailu/Mailu/milestone/10)
• Also go through last items on 1.8 milestone. Do we want to include these or move to ´later' milestone? These issues had no activities for last 6-8 months.
• Go through issues/PR's to determine if we must add more to 1.8 milestone (determine scope of 1.8). I'd like to include the PR for config export/import.

[Nebukadneza]

2020-09-19

Attendees

• Nebukadneza
• Dimitri
• Lub

Agenda

• Sort out 1.8-rc issues to define prerelease scope some more
  • try to make the rc as small as possible since a lot of changes are already in
  • ⇒ delay the config-import to "later"
• tls pull request ⇒ fine for 1.8, probably good for reducing hard to debug user problem
• timeline for RC vs release
  • push both back by exactly one month
• Do we know how to release?
  • release notes ⇒ ask around?
  • documentatation ⇒ ask around?
  • docker images ⇒ probably work out of the box?
  • setup ⇒ make stable + RC + master selectable
    • find out what actually runs (Infra/setup/.env, …?)
    • make sure 1.8-rc is not preselected
• Staying up to date with upstream versions
  • look at this in 1.9
  • which is meant? python/js-deps or services (postfix, dovecot, …)
  • biggest problem: after updates, manual testing required
  • ⇒ discuss after 1.8 release
  • idea: maybe a bot like renovate can help with automatic PRs?
• Stale issue handling?
  • relax defaults a bit ⇒ dont be trigger happy in closing, maybe 3 weeks or so?
  • idea: exempt issues with: priority-label or milestone set
  • How to handle voted issues?
    • ones with no voting at all ⇒ close
    • ones with < 5 🎉 smiley ⇒ close
    • ones with >= 1 👍 smiley ⇒ leave open
  • ⇒ try to find time mon/wed to pair with diman to make stale bot run as dryrun
• Add lub to the contributors team — currently we need more reviewing power, and this is great help!
• !! Dario: Update renovate rules to include all current contributor users

Follow-up topics

• (after 1.8) Staying up to date with upstream versions? Renovate-bot?
• Discuss big current issues
  • Open Relay issues when (incorrectly) using IPv6
  • Recurring BORS/Build&Test-Pipeline issues
• Talk about the vision of the Project — related: Architecture : find some simplicity #1133

[Diman0]

Additional topics:

• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.

[Diman0]

• For next release, use a project to keep track of all issues/PRs we want to include. There are SO many issues we could pick up for a new release it is difficult to have proper vision on what issues we want to include. Using github projects it is easy to see what items will entail a release and what the actual status is.

[Nebukadneza]

Scheduler-Voting for next video-meeting:
https://nextcloud.ghostdub.de/apps/polls/s/UcyBGlzHMRrno9NG

[Diman0]

additional topics

• Discuss issues Ship stock MariaDB images from setup #1217 and Ship stock PostgreSQL images from setup #1216. Do we want to ship database servers with mailu? We already ship sqllite for the more novice user and people with small deployments. Managing an external database is complicated. We still provide all options in setup, but the user must set up his own external database server.

[Nebukadneza]

• Work on a clear, concise definition what each issue and PR label means.

[Nebukadneza]

2020-10-03

Attendees

• Nebukadneza
• Dimitri
• Lub
• ThomasSänger

Agenda

• replication — how? how complex? what to support?

• stalebot discussion

  • current label configuration seems fair to us — requirement is pre labelling
  • to make the stale bots configuration clearer: update stalebots posted message:
    • add: why marked stale? what will happen?
    • add: how to un-stale something? what needs to be done?
    • add: WHEN will it be closed? (describe actual timing behavior)
    • clearify: stale only meant for when contributors cannot tag/triage new issues
    • essentially 1st 4 points of the config
  • link discussion issue in PR
  • describe PR in discussion, add that "we now think its fair"

• 1.8 release

  • lubs idea: make a "soft release" where we technically release 1.8, but don’t "advertise" it
  • this way, we only need to make one release, but without pushing new users to use it before 1.8 is stabilized
  • maybe post a big notice/announcement about "1.8 is ready to test, but not finished yet, please test but "
  • thomas: setup is currently biting the user at many points — with new release a lot users will use setup, fallout could be big
    • need to judge time-tradeoff: fallout vs. polishing setup
  • big blocker: replicas for stack ⇒ can lead to corruption
    • maybe currently just remove the user-visible replication setup option (step 5?)
    • maybe add line to the expermiential notice in setup for stack: "please check your config by hand. please think hard about replication" or so
  • shipped postgres image?
    • loudly(!) deprecating instead of removing now
    • thomas: add checkbox "i’m updating", and only allow mailu-postgres then
    • lub: simple warning in that setup checkbox is easier (but switch default)
    • also add to release notes
    • future: is there a migration path for removing mailu-postgres
  • steps needed for actual release
    • finalize changelogs
    • add both 1.7 (still default) and 1.8 and master to setup + docs
    • add 1.8 "only for testing" notice to setup, keep 1.7 as default
    • check for more forgotten version-containing files (mergify, etc?)
    • merge PR with these changes
    • branch off 1.8
    • tag branched commit to be marked as github-release
      • add note this release is "for announcement purpose only: hub-images are from branch, release tag is beginning of (release-)branch — don’t be confused" or so
    • ⇒ now get branchbuild for 1.8
    • in infra PR: add 1.7 and 1.8 and master for setup composefile
    • merge infra PR

• Move milestones by 14 days

• Discuss issues Ship stock MariaDB images from setup #1217 and Ship stock PostgreSQL images from setup #1216. Do we want to ship database servers with mailu? We already ship sqlite for the more novice user and people with small deployments. Managing an external database is complicated. We still provide all options in setup, but the user must set up his own external database server.

  • for both its easy, all available in env variables
  • postgres: no good upgrade path, user needs to dump/reimport everything
  • mariadb: sometimes manual intervention required for upgrades
  • postgres has long release cycles though, so we’d be fine for ~5 years or so
    • "The PostgreSQL Global Development Group supports a major version for 5 years after its initial release."
  • dario: novice users are more fine with sqlite, simpler, batteries included, advanced user who need higher performance would know how to link their external official DB
  • lub/thomas use external image already :D
  • if focussing on sqlite and deprecating mailu-postgres: provide migration path
    • good use-case for import-export CLI PR: Added CLI command to export and import the configuration #1604

• Post to all PRs: currently freezing and focussing on 1.8 — thanks & please be patient

  • Create pinned issue with this content!
  • Gist of content: "Sorry we focus on stabilizing 1.8 now — this eats our time curently. After 1.8 is fine and stable, we will have a round of PR-triaging where we will assing your PR to either 1.9 or $later. Thanks for the contribution & time, etc etc …"

• revive mailu-dev!

Follow-up topics

• github master vs main changes?
  • Github will not "force rename" existing branches
  • discuss if we want to do that
• (after 1.8) Staying up to date with upstream versions? Renovate-bot?
• Discuss big current issues
  • Open Relay issues when (incorrectly) using IPv6
  • Recurring BORS/Build&Test-Pipeline issues
• Talk about the vision of the Project — related: Architecture : find some simplicity #1133
• Work on a clear, concise definition what each issue and PR label means.
• For next release, use a project to keep track of all issues/PRs we want to include. There are SO many issues we could pick up for a new release it is difficult to have proper vision on what issues we want to include. Using github projects it is easy to see what items will entail a release and what the actual status is.
• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.

[nylocx]

Hi, it has been a few month without hearing anything from you. Is Mailu still actively developed or is it currently stalled? I really love my mailu deployment and it's working rock solid for more than two years now, thanks for that! But I noticed that the pace of new features has slowed down and the RC 1.8 was not yet released. I really hope it is ok to use this issue for such a question, if not feel free to delete my post.
Kind regards,
Alex

[decentral1se]

Mailu is rad and we're running an instance at https://autonomic.zone to evaluate if we can use it to run our own mail server. Would love to get involved to help the project out - I am wondering how best to do that? I already started reviewing some PRs and approving/commenting them (mostly small docs/typo fixes etc.). I am lurking in the matrix channel with the same handle if you wanna chat.

[Nebukadneza]

Hi,

thanks for reaching out! Unfortunately, we are back at the point where the "steering party" is kind of missing. After @kaiyou and @muhlemmer (among others) seem to have stepped back, I attempted to help out where I could. There was a great phase of fun activity where @lub and @Diman0 (among many others) helped out a great deal, and we made some progress sorting issues and PRs and readying the 1.8-rc.

However, unfortunately, after having been drowned in dayjob work I now also have a disruptive change in my private life, which leaves me certain I won’t have the time to contribute more in the coming ~2-3 years. That said, I still love EMail as a federated open means of communication, and Mailu is a great project to push the very freedom-saving part of actually being federated. I run 1.8-rc, I will continue to do so, and I’m happy to see any progress on this project.

When looking in the matrix channel, @Diman0 and @lub are still often active, among a lot of others who aren’t on the contributors team on github, but are actively supporting other users, and helping the project in various ways. This is great!

I would love to see it if a team of people would come together again, and keep Mailu alive. These meetings with open agenda and some notes above IMO provided great value. Mob-reviewing issues and PRs was super effective. And it helps building a shared goal for the project.
If anyone wants to bring the project back on track, re-instantiating such a contributors meeting would be my tip for a first step.

Sorry to disappoint — and I really hope the best for this great project ^_^.
Best,
-Dario

[decentral1se]

Thanks for this update @Nebukadneza and for your work.

Does someone want to add me to the contributors team? I would happily be merging typo fixes/docs updates/etc. and if @Diman0 @lub @3-w-c would be interested to chat on matrix/here/etc. about what we could prioritise with limited time, that'd be great!

In any case, we should open a dedicated "maintainers wanted" ticket and pin it, I think. To increase visibility and to see who is up for it.

[Diman0]

Only the owners (https://github.com/orgs/Mailu/people) can make you a contributor. I do not mind if more people join the team.
I concur with Dario. The first step is to get back to regular meeting. For me it is important to have regular meetings. Without regular meetings and thus no structure it is difficult for me to find motivation.

With regular meetings we can create structure again. Decide what will be prioritized and actually do it. Triaging bugs is also easier when performed in a group.
I guess our first topic would be making 1.8rc the new stable version (assuming there are no showstoppers).

Having a video conference (just like the previous meetings in this issue) would be a good start.
We can keep using Jitsu (https://jitsi.fem.tu-ilmenau.de/) for this. Jitsu runs fully in your browser. No additional plugins are needed.

[decentral1se]

Yes super cool @Diman0! I am down to have a meeting. For anyone else interested, we're chatting on https://matrix.to/#/#mailu-dev:tedomum.net in #mailu-dev about how to organise a date/time and would love to hear from you ❤️

[3-w-c]

Anyone not in the Matrix channel(s) – here's a date poll for the dev meeting! UTC+2 timezone (CEST, 1 hour ahead of BST) https://framadate.org/t7l4n5eQzBUpaEes

Please try and respond by this Friday, June 4th, at 1700 UTC.

[micw]

I added myself too. Would like to support any progress to https://github.com/Mailu/helm-charts but got no time in the last months :-/

[Diman0]

Obviously we need some kind of agenda for the new meeting. I think it is handy we at least discuss the following. Most points are taken from the previous meeting notes (items are ordered randomly):

• release 1.8 asap
• Add more contributors to the project?
• An x-weekly project meeting
• An x-weekly triage meeting where we discuss issues and review pr's
• github master vs main changes?
  • Github will not "force rename" existing branches
  • discuss if we want to do that
• (after 1.8) Staying up to date with upstream versions? Renovate-bot?

• Discuss big current issues
  • Open Relay issues when (incorrectly) using IPv6
  • Recurring BORS/Build&Test-Pipeline issues
    • Travis CI will not work anymore in the future (I'm surpised it still works). We need to move to another alternative such as github actions.
    • clamav antivirus downloading updates for each build, can cause builds to fail because we are blacklisted by clamav for downloading to often updates.
• Talk about the vision of the Project — related: Architecture : find some simplicity #1133
• Work on a clear, concise definition what each issue and PR label means.
• For next release, use a project to keep track of all issues/PRs we want to include. There are SO many issues we could pick up for a new release it is difficult to have proper a vision on what issues we want to include. Using github projects ,it is easy to see what items will entail a release and what the actual status is.
• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.
• What to do with ancient PRs that have been blocked/in limbo for 1+ year?

[Diman0]

The result from the poll is that we have the meeting on
19:00h (UTC+2) on Wednesday 16th June

[Diman0]

Mailu regular project meeting of 11 August 2021

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab

Present

• Dimitri (Diman0)
• Calix (3wc)
• Erwin (Erriez)
• Nextgens
• Haley

topics

Actions from last meeting

• 3wc will create a poll for determining a new time for the next poll. . The next meeting date is still next month (on August 11th). Some people preferred an earlier time for the meeting. ==> Done
• Remove PR#1716 from 1.8 milestone and mention this in the PR. ==> Done
• Create an issue to investigate hostname/port usage in the infrastructure settings on the reference configuration documentation page. ==> Done
• Create issue and PR for discussed rate limiting changes. Update lubs PR with blocked for further discussion. ==> Done
• Keep working on the 1.8 release :) ==> Done :)
• Create an issue that some parts that rely on DNS are non-atomic (e.g https://github.com/Mailu/Mailu/blob/master/core/dovecot/conf/ham.script). This must be resolved if we move from static IP to live resolution in the future. ==> NOT Done
• Mwraz will contact kubernetes contributors if they want to assist with the helm-charts repo. ==> ?????

Agenda items from last meeting

I guess we move these again to the next meeting for the last time?

• work on a clear, concise definition what each issue and PR label means.
• More clear description of inner workings of stalebot.
• Do we need improved documentation on how to contribute to the project?
  • How do we review pull requests?
  • definitions of labels for issues and PRs
• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.
• What to do with ancient PRs that have been blocked/in limbo for 1+ year?
• For next release, use a project to keep track of all issues/PRs we want to include. There are SO many issues we could pick up for a new release it is difficult to have proper a vision on what issues we want to include. Using github projects ,it is easy to see what items will entail a release and what the actual status is.
• After 1.8, how to stay up to date with sources? e.g. used python libraries. Maybe we could use something like https://github.com/renovatebot/renovate

Agenda suggestions for this meeting

dimitri

• #1926 - no logging of failed logon attempts admin/webmail and no rate limiting (bruteforce protection)
• SSO experience is not optimal (in master). E.g. Login page still acts as if you are trying to login webmail. (I guess I should just create an issue for this)

erriez

I'd like to mention progress on a few issues like CI build speed and multi-architecture support.
#1830 increase CI/CD speed
#1200 multi-arch support / arm support
#1924 Optimize Rainloop image

nextgens

feedback on:
#1902 (TLS certificate validation for known domains)
#1915 (rate limits)

3wc

Would we like to apply to the NLNet User-operated internet fund, deadline 2021-10-01

Transcription

• Should we make a separate issue about non-atomic, DNS-reliant parts?

  • maybe an existing issue already?
  • It is part of the discussion for moving from static hostnames resolved at startup to dynamic resolution.
  • It is still handy to have a separate issue so we don't lose sight that this will be an issue if we move to dynamic dns resolution.
  • nextgens will make a new one

• Helm / kubernetes?

  • Haley: I'm using it, but not the official repo because there are issues with the helm charts. Helm chart definitions are not in sync with development. Also difficult to find the official Helm chart.
  • Di: Been added now, will be there in future. Previously only one person, Michael, who was responsible for Helm chart repo. But he hasn't been able to be involved in a year. Maybe Haley could contact him?
  • Ha: Think I contacted him, gave a different one? Used that one, adapted / modified. Got it running.
  • Di: Could you put the repo in the notes?
  • Ha: Not sure.. just have it locally. Could do a diff of the official and local charts. Mailserver tightly integrated with environment which required some changes.
  • ??: Do we have any stats on who is using what configuration?
  • Dim: No, all the deployments use the same images.
  • ??: Would it be a good idea to fingerprint, environment variables -- so we know what % of users is using each kind of env?
  • ??: Typical Docker env variable. In k8s, you have node env variables you use. But implies we extract info from within the user's environment.
  • Di: Would need to be opt-in. Current tracking is opt-in, only works for docker compose. Think it's automatically checked.
  • ??: Uncheck for dev purposes. Uncheck for live use.
  • ??: Where is the data coming from?
  • Di: No idea.
  • ??: Struggling to find people who maintain k8s set-up, is it actually used?
  • ??: Main issue with something being used or not is ease-of-use. If something is too hard to use, people won't use it. Was head of business process automation at one point - easier the tools were, the more people were using it.
  • Haley will check if he can create an updated helm-chart and will look into the possibility of creating tests.

• activity of contributors

  • we have not seen activity from new contributors.
  • The same people review everything
  • ??: reviewed a PR but only tested on k8s how to test?
  • Di: testing documentation on mailu.io
  • Er: Mention in the documentation how to contribute with Git authentication manager: ! [remote rejected] master -> master (refusing to allow a Personal Access Token to create or update workflow '.github/workflows/CI.yml' without 'workflow' scope)
  • Di: shorten the list of contributor access remove people who've been inactive in a certain time. people who haven't reviewed pull requests or done $otherthing (sorry didn't hear) for 6 months? 1 year? Some people haven't been active in 2 years.
  • c: think it's separate question about removing old contribs vs how to help new ones.
  • NG: Different levels - direct push, contributors. Maybe not a good idea for people who haven't been involved for years to retain push access.
  • NG: Real discussion should be around 2 highest levels. Trusted author, push access, ???.
  • ??: Thought only github actions could push directly?
  • Di: No.
  • type of authors are:
    • project owner, has push access (god like)
    • contributor and list of trusted authors (is allowed to review and only needs 1 review)
    • contributor, can create PRs and needs 2 reviews. This person can also review
  • Ha: This happens often in corporate world. But e.g. in open source world, NSA pushed reduction in randomness via NIST. Matter of security. Should decide on a timeline when to remove access. Require approval by someone else.
  • ??: Are there situations where we need to push directly?
  • Di: Yes, whenever CI is broken. Also setting up new workflows. Also fixing a couple of small things for 1.7. We had a unique situation with 1.8 being a release candidate, backports only work from master to last version so we couldn't easily backport to 1.7. Won't have that any more.
  • ??: What's the current workflow when someone gets push acces?
  • Di: You create a PR. After review, it is automatically build, tested and merged using mergify/bors/github actions.
  • Di: We have currently 4 project owners.
  • Di: I will create an issue to discuss what metrics we will use. After a consencus has been reached we can add this to the documentation.

• Make smtp_tls_policy_maps easily configurable #1902

  • NG: Secure connection by default to known-good domains. SMTP → opportunistic encryption. bunch of options for automatic encryption. most of the major providers do not use unencrypted connections. hitting the major providers could improve encrypt a large volume of common traffic. trust that those servers will continue to offer secure way.
  • Ha: certificates mainly used to confirm identity of remote site, won't interfere with encryption process. personally only care about encryption, not identity verification. e.g. self-signed certs. worked at ISP, automated entire certification process, realised many registrars did not even verify identity of people requesting SSL keys.
  • ??: have an allow-list. validate the identity of remote peer?
  • NG: That's exactly what this PR does.
  • Ha: Keep in mind the source of the list. Protect the integrity of it. Brightmail (??)
  • Consensus: The considerations made in the PR are already sound.

#1915

• NE: Are we trying to limit nuisances? What is it exactly that we're trying to do? Rate-limiter for a different purpose.
• NE: 1 thing - protection of the account. 2 - prevent denial of service.
• haley
  • uses special email address that can only be used for loggin ing
  • aliases are used for receiving and sending emails
  • This way nobody can guess the password, because they try to login using the alias. they do not know the special email address
• NG: 2 different kinds of rate limiters - per user, and per IP address.
• ??: haveibeenpwned - conceptual problem leaking info to 3rd party about user passwords. Also "insular" mail distro. But how to make it configurable? If it's configurable nobody will use it.
  • ??: Think it's a requirement
  • c: opt-in on the server level?
  • Di: yes, that's what I meant
  • ??: Linux brute force - password database, check for it
  • ??: how does the password checking work?
  • ??: send subset of the hash of the password
  • Ne: Haveibeenpwned runs locally (via javscript) in the clients internet browser. Only a part of the password hash is sent. At most haveIbeenpwned knows in what bucket your password resides. This check will only happen on password change in the admin interface.
  • Di: That is a sound idea. In general we agree to implement all limitations in the PR and also agree with the exemptions measures to prevent legitimate users being rate limited.

erriez

I'd like to mention progress on a few issues like CI build speed and multi-architecture support.
#1830 increase CI/CD speed
#1200 multi-arch support / arm support
#1924 Optimize Rainloop image

• we will first focus on small PRs to incrementally improve CI/CD. E.g.
  • PR for reducing size of the images
  • PR for increasing speed
  • Once all possible work is done, only then start working on multi-arch support.
  • In other words do not everything at once in 1 PR.

Action points (as result of this meeting)

• Dimitri will create an issue for 1.9 roadmap suggestions
  • We probably already have all topics. We have many PRs already in the pipeline waiting for review and many interesting PRs have already been merged with master in this year after 1.8rc release.
• We will try using a project for keeping track of everything.
• Nextgens open an issue about non-atomic DNS operations
• ??Will create an issue for: Dimitri will figure out how the statistics gathering works and how we can gather the statistics. Hint:

  Mailu/core/admin/mailu/manage.py

  Line 30 in 3a96bf2

  def advertise():

• dimtiri will create an issue to discuss
  • metrics for removing contributors from the project or giving them less access. E.g. someone who was not active for 1 year
  • How can we improve getting more people involved
• everyone will review Make smtp_tls_policy_maps easily configurable #1902
• nextgens add instructions to PR 1902 for sending emails automatically to assist with reviewing the PR.
• All will have a look at the PR to allow sending from any address.
• All will have a look at Ratelimit outgoing emails per user #1916
• again move all topics moved from last meeting to the next meeting
  • In the next meeting we will discuss these issues.
• Haley will look into creating/updating helm-charts (note: see https://github.com/Mailu/helm-charts).

[Diman0]

Topics next meeting (moved again)

• work on a clear, concise definition what each issue and PR label means.
• More clear description of inner workings of stalebot.
• Do we need improved documentation on how to contribute to the project?
  • How do we review pull requests?
  • definitions of labels for issues and PRs
• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.
• What to do with ancient PRs that have been blocked/in limbo for 1+ year?
• For next release, use a project to keep track of all issues/PRs we want to include. There are SO many issues we could pick up for a new release it is difficult to have proper a vision on what issues we want to include. Using github projects ,it is easy to see what items will entail a release and what the actual status is.
• After 1.8, how to stay up to date with sources? e.g. used python libraries. Maybe we could use something like https://github.com/renovatebot/renovate. Or do we keep the same workflow.
• Kubernetes (helm-chart repo) status.
  • Contributors?
  • What must be done to get this in a proper state again?
  • What improvements are required in the documentation

[Diman0]

Mailu regular project meeting of 10 November 2021

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
❗ Note: Future meetings will start at 19:00h. ❗

Present

• Diman0
• Nextgens
• ghostwheel42
• HaleyACS

Points from previous meetings

• work on a clear, concise definition what each issue and PR label means.

==> Diman0 will create definitions and ask in dev chat for others to agree.

• More clear description of inner workings of stalebot.

==> Diman0 will create a proposal. Via PR we can finetune the text.

• Do we need improved documentation on how to contribute to the project?
  • How do we review pull requests?

==> Moved to after 1.9 release

• Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.
  ==> Lately this situation has been improved. We do need to update the issue template that kubernetes issues should be reported in the helm-chart repo.
• What to do with ancient PRs that have been blocked/in limbo for 1+ year?
  ==> We have discussed all blocked PRs.

---

Extra note for anyone reading. For the last few years, the Mailu project has seen very few core contributors that actively contribute in the same time period. For this reason it is very important for us to prevent feature creep. The Mailu solution is already very complex. With every release we must update all the used packages and base images. To keep overview we need to prevent that the complexity does not increase even more. This is a very important metric for reviewing pull requests.

• Add SnappyMail webmail #1796 Add SnappyMail webmail
  • Close this pull request. Two webmails are sufficient for the project. The Mailu project always had a very low amount of active contributors. We cannot use another webmail that adds more cost of ownership. We would have to maintain this and update it for every future release. Any webmail is basically an imap client. You can simply run your own image and connect via IMAP to Mailu.
• Remove startup resolution of HOST_* variables to IP addresses in *_ADDRESS variables #1716 Remove startup resolution of HOST_* variables to IP addresses in *_ADDRESS variables
  • It makes sense to use dynamic DNS resolution. It will have a big impact. We will look into implementing this after the 1.9 release. This entails replacing socrates (which handles hostname resolving). Most likely we will eventually close this PR and continue in a new PR. For now we keep it open as reminder to tackle this after the 1.9 release.
• Fix 1552 configurable folder names #1555 Fix 1552 configurable folder names
  • Close it. Adds too much complexity with not enough gain for the project. This can be achieved via overrides for dovecot. E.g. you can add an alias for the Junk folder. This way you will see the Junk folder and your alias folder.
  • @nextgens, could you add to the PR an example or a pointer to relevant dovecot documentation on how to add an alias folder?
• ClamAV Debian based build #1482 ClamAV Debian based build
  • With enough memory (at least 3GB) and 1GB swap we have no reported clamav issues. We probably don't have to switch to debian and can close this PR. This is superseded by the other PR that documents you need enough RAM and SWAP. Clamav reports you need at least 2GB+ RAM assuming you do not run any other applications on the same machine. With all other applications (postfix, nginx, dovecot etc), this means you really need at least 3GB or even 4GB of memory.
  • All issues are only reported on Mailu 1.7 (clamav 2019 release). Most likely the issue is already addressed in clamav.
  • Clamav repo contains no issues for freshclam not deleting tmp files.
  • We will ask the in relevant clamav thread if anyone still experiences this on mailu 1.8. If we do not receive a response within a couple of weeks, we will close the issue and PR
• Rsyslog logging for postfix #1441 Rsyslog logging for postfix
• Functionality must be optional and not the default. This is already implemented. PR appears in limbo ( no activity). This PR is much needed for kubernetes users. Diman0 will push the requested changes in the PR. Other members will review the PR.
• add DEFAULT_DOMAIN feature #1344 add DEFAULT_DOMAIN feature
  • Close the PR with the message that we are not planning supporting this. This adds yet more complexity to the project with almost no real gain.
• Allow user to install, remove and activate roundcube plugins #1326 Allow user to install, remove and activate roundcube plugins
  • Superseded by ghostwheels PR updated roundcube to 1.5.1 and carddav to 4.3.0 #2035. He is looking into using the official roundcube image. Assuming he incorporates the official roundcube image, then you can provide your plugin list via env var. Assuming ghostwheel implements this, we can close this PR afterwards. For now keep it open.
• RFC: Mailu directory structure #1224 RFC: Mailu directory structure
  • Looks good. The proposed structure is excellent. Accept this PR with the message that we will try implementing this a couple of releases later. This is something for a 2.0 release. It will needs tons of testing and will require everyone who uses Mailu to take manual migration steps.
• Ability to use both webmails simultaneously (Rainloop and RoundCube) #967 Ability to use both webmails simultaneously (Rainloop and RoundCube)
  • Close the PR. Makes Mailu too complex. You can only use one webmail within Mailu, period. If you don't like this, then you can simply run an extra non-Mailu webmail image and connect via IMAP to Mailu.
• Add managesieve proxy #428 Add managesieve proxy
  • Close the PR. All communication only goes through front. Nginx does not support managesieve proxying. We are not changing this. If NGINX gets support for proxying sieve, we will implement this in Mailu. Another option is that someone adds to Mailu web administration the possilbility to alter your sieve scripts.
• Format python, rst and yml source with pre-commit hook #1860 Format python, rst and yml source with pre-commit hook
  • We will close this PR. We do not like that formatters (e.g. black) affect git blame. Suddenly the commit author affected all lines in the file due to using a formatter.
  • There are also proven cases that formatters such as black lead to non-working code or differently working code. The black project issues section shows multiple open issues for this.
  • We will look into the following (add this to issue Use code lint / formating for python #1839)
    • Update development guidelines on how to use a linter in visual code that warns you about code not being compliant with the pep8 standard.
    • Enhance CI workflow with a linter. If linter finds issues, add a message to the PR that the linter check failed with the report. The PR author and any reviewers are now informed the PR does not follow pep8 guidelines.

---

• Kubernetes (helm-chart repo) status.
  • Contributors?
  • What must be done to get this in a proper state again?
  • What improvements are required in the documentation

==> Moved to next meeting. HaleyACS is looking into what changes are required for helm-charts for the master branch (upcoming 1.9 release).

New points

• Socrates
  • ghostwheel will implement a replacement. This is not a show stopper for 1.9. This can be done after 1.9.
  • After that we will archive the socrates github project and inform kaiyou to take the pipy project offline.
• DKIM
  • do we want to keep keys on the file system? Or in the database?
  • If we move to the database, then we could automatically import the keys. No manual action is requried.
  • Auto-generate keys when creating a new domain via the web ui
    • users must check the DNS records part anyway after adding a new domain.
    • Maybe add a clearer message you must REALLY configure all shown DNS records.
  • Maybe add a configuration check page? This page tells you what is not securely configured.
  • When creating a new key, you want a new dkim selector. Because this leads to a new dns lookup. It will be immediately looked up. You will have no dns propagation timing issues.
  • Introduction of new page that shows all used keys within mailu.
    • Offers possibility to generate new keys.
    • Offers possibility to make new keys active.
  • Most mailu administrators have no deep knowledge about dkim/arc keys. We must always keep this in the back of our minds when making changes to how DKIM/ARC keys are handled in Mailu.
  • A lot of more technical talk. @nextgens please update the existing issue (or create new issue) with the most important points we discussed.
• Ask kaiyou for credentials for mailuci/mailu. The project owners should have access to the docker repositories.
  • Maybe for the future think about Shamir's Secret Sharing Scheme for sharing the above secrets.
• Ask kaiyou about DNS domain credentials or how to handle adding new records (such as TLSA)
  • Maybe consider for the future https://joker.com/.
    • This DNS registrar offers creating sub accounts for changing settings.
    • These accounts can still be revoked by the main account. This is perfect for providing access to other Mailu contributors.
    • Also offers API access.
• Update issue Metrics for removing/demoting contributors #1932: metrics for demoting.
  • Diman applied discussed action steps in the issue.
  • It is worrisome not many people commented.

[Diman0]

I did not mention we also discussed 1.9 progress. We are aiming releasing 1.9 during during Christmas (before end of year). There are only a couple of points left. The current open PRs and the open issues mentioned on the project board.

[Diman0]

Mailu dev meeting of 8 December 2021

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
Notes link: https://demo.hedgedoc.org/TG_6KhdWRuaUPY-tFBOFIQ?both

Present

• Diman0
• Nextgens
• HaleyACS

Points from previous meetings

work on a clear, concise definition what each issue and PR label means.
==>
Diman0 will create definitions and ask in dev chat for others to agree.
==>
Diman0 created the definitions. During the meeting we agreed the labels are fine.

More clear description of inner workings of stalebot.
==>
Diman0 will create a proposal. Via PR we can finetune the text.
==>
Diman0 Created the PR and it has been merged.

Do we need improved documentation on how to contribute to the project (development guidelines/hints)?
How do we review pull requests?
=>
Moved to after 1.9 release.
==>
Still moved to after 1.9 release. But Diman partially started on the wiki. Feel free to contribute:
https://github.com/Mailu/Mailu/wiki/Pull-request---Review-guide-lines

Enhance pull request template to refer to contributing guidelines. Recently we have seen an influx on PRs on a specific version (branch 1.7) instead of master.Thus leading to the situation where what the PR addresses is already part of master. People don't read the contributing guidelines before creating a PR.
==>
Lately this situation has been improved. We do need to update the issue template that kubernetes issues should be reported in the helm-chart repo.

What to do with ancient PRs that have been blocked/in limbo for 1+ year?
==>
We have discussed all blocked PRs. In previous meeting. These have been finally handled.

Kubernetes (helm-chart repo) status.
Contributors?
What must be done to get this in a proper state again?
What improvements are required in the documentation
==>
Moved to next meeting. HaleyACS is looking into what changes are required for helm-charts for the master branch. Master branch is broken. 1.8 still works with helm-charts. More info in the discussion topic below.

Socrates

• ghostwheel will implement a replacement. This is not a show stopper for 1.9. This can be done after 1.9.
• After that we will archive the socrates github project and inform kaiyou to take the pipy project offline.
• Ghost will submit a PR to let a container print a more clear warning if there are DNS issues as a temporary workaround.

DNS
I'm quite certain that Mailu domain is handled via PowerDNS hosted by tedomum.net(org that hosts our matrix server). Kaiyou is one of the admins for tedomum.net. See https://tedomum.net/service/

Current state - Pulse of last month

Mailu: https://github.com/Mailu/Mailu/pulse/monthly#open-pull-requests
Helm-charts: https://github.com/Mailu/helm-charts/pulse/monthly

Topics

If not already discussed see above: Helm-chart repo:

• Contributors?
• What must be done to get this in a proper state again?
• What improvements are required in the documentation
• Helm-charts is not in sync with main project in regard to environment variables. See the last 2 new issues I created. One of the missing env variables is very old (POSTMASTER).
• Should we mention in Mailu 1.9 notes, not to use this yet with helm-charts? Or will the helm-chart be updated in time? I'd like to release end of this year.
  ===>
  This topic is partially moved to next meeting due to abense of micw.
  In release of 1.9 we will mention to use helm-charts with Mailu 1.8.
  Helm-charts only work with 1.8. It does not work with master (1.9).
  New in 1.9 is that rspamd contacts admin for dkim keys. Possibly it works after socrates is replaced.
  There are also many configuration options missing. A very disconcerting example is that a user found out that the ancient POSTMASTER environment variable is not configurable in the helm-charts. This means that the helm-charts repo has never been brought into sync with the main mailu project. In the next meeting we will discuss how to continue with this situation.

Mailu 1.9 release

• Status of things we still need to do
  • Review Diman0's pull requests
  • Roundcube PR
  • Status Socrates replacement?
• Code freeze window? In other words, when do we release? Diman needs about 1 to 2 days to do all the work for releasing (There are ton of release notes and breaking changes. Plus many new security settings that must be clearly described in the release notes.)
  ==>
  Code freeze at 24 December. We will not accept new pull requests.
  In the subsequent week Diman will release Mailu 1.9.
  Before this date all open pull requests with p0 label must be reviewed (obviously).
• fix the default for DEFER_ON_TLS_ERROR #2076
• Remove Mailu PostgreSQL #2069
• Implement versioning for CI/CD workflow. #2058
• updated roundcube to 1.5.1 and carddav to 4.3.0 #2035
  • For this one (roundcube update), ghostwheel will
    • update roundcube and carddav. We keep using apache for now.
    • Implement a selector for the plugins shipped with roundcube (that is how I understood him. So not allow the downloading and enablement of plugins via roundcube plugin repository)
• rsyslog PR Rsyslog logging for postfix #1441
  • Diman forgot add crond startup. After adding crond startup to start.py, the PR is ready for review.

security overview page?

The Mailu solution is very complex. Nobody knows what security measures are really in place. Most people don't know how to securely configure Mailu. This page should inform you:

• What security features does Mailu have?
• What are the relevant settings?
• How-To change these settings. Per relevant subject describe how to configure it.
• Maybe best practices? This is what we advise!

==>

• Is this a good idea?
  • Yes. But it should be a common configurations page with best practices. It does not matter for the user what security related things are in place. These already have sane default values. What does matter is how to properly configure Mailu. So have a single contained page where you can find all relevant settings that you want to tweak after deploying mailu. With best practices.
• Should we include this with mailu 1.9?
  • We did not discuss this. But due to scope it will probably be later.
• I made an initial draf here https://github.com/Mailu/Mailu/wiki/Security-overview
  • Feel free to help editing it.

Any other topics

For mailu release after 1.9:

• Have a look at having some kind of page that shows you if DNS is setup correctly. So a healthcheck page that you can refer to if everything is configured correctly.

  • E.g. when you access the domain info page, it will check all entries. If something is incorrect, then you are informed.

  • Possibly this could be an unique page for all domains accessible via sidebar menu.

  • The main point is too have some check that you can use to make sure Mailu (and your domain) is configured correctly.

  • For handling DNS/domain Settings, we have as options:

    • do nothing (current situation). Mention what to configure.
    • Use something like python lexicon to automatically set entries in DNS Server.
      • Not really part of the core goals of project
    • Ship our own authoritive dns server (e.g PowerDNS)
      • Not really part of core the goals of project
    • We choose option 1.

  • What do we include in our configuration examples? Do we also include?

    • Set reverse ip/ptr
    • What ports to open / port checker

  • For checking DNS related settings it makes sense to check via internal and external resolver.

• After 1.9 release, we will create an issue for brainstorming about this.
• Maybe revisit this again in the next meeting?

Points for next meeting:

• Discuss 1.9 release (that has been released).
• Improved documentation in regard development
  • Do we need improved documentation on how to contribute to the project (development guidelines/hints)?
  • How do we review pull requests?
  • Diman partially started on the wiki. Feel free to contribute: https://github.com/Mailu/Mailu/wiki/Pull-request---Review-guide-lines
• (see last topic) Have a look at having some kind of page that shows you if DNS is setup correctly. So a healthcheck page that you can refer to if everything is configured correctly. Will my mail server work?

[Diman0]

Point for next meeting

• Replace rainloop with another webmail?
  • Rainloop has multiple high priority security bugs which were not addressed for the last 3 years. There is even a security bug reported 7 years ago that is still open.
    • no logout for a one month and no logout on browser close RainLoop/rainloop-webmail#729
    • Vulnerability in https://mail.rainloop.net/ RainLoop/rainloop-webmail#2128
    • Mail leak through cached ajax requests RainLoop/rainloop-webmail#1390
    • etc
  • Brainstorm about possible replacements for rainloop. A potential candidate could be snappymail ( https://snappymail.eu/ ). It is based on rainloop, but it appears to be more secure. It explicitly mentions fixes related to security (https://github.com/the-djmaze/snappymail/releases).
• Code scanning. Discuss if we want to automatically scan our code with an interval for known CVE or bad code practices. E.g.
  • trivy
  • xanitizer
  • snyk
  • OSSAR
• Dependabot. Automatic updates via bot. It submits a PR for each single updated dependency. E.g. for each image if alpine has a new version. For all packages in requirements.
  • Do we want to use this? Can anyone share his experience with dependabot?
  • For more info https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates
• Handle backports differently.
  • Currently, every backport triggers a new release.
  • We could change this so a backport does not trigger a new release and built. It is only merged on branch X.Y (e.g 1.9).
  • This way we can gather multiple backports before releasing an update for X.Y and X.Y.Z (e.g. 1.9 and 1.9.3).
  • This can be done fairly easy:
    • remove branch 1.9 in CI.yml. Merges on branch 1.9 (x.y) do not trigger the workflow.
    • create a copy of the CI.yml that is used for branch 1.9 (x.y) only which is triggered manually.
  • With this, the X.Y (1.9) and X.Y.Z (1.9.x+1) image will be built and released whenever we manually trigger the workflow for backports.

[Erriez]

I'd like to add a topic to test migration from a production environment version 1.8 to the new planned 1.9.0. Is this already tested by someone and is the documentation on https://mailu.io/master/maintain.html?highlight=upgrade#migrating-an-instance complete? Related to issue #1200.

[Diman0]

I completely forgot to post the previous meeting notes 😮

Mailu dev meeting of 12 January 2022

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
Notes link: https://demo.hedgedoc.org/TG_6KhdWRuaUPY-tFBOFIQ?both

Present

• Diman0
• nextgens
• ghostwheel42

Current state - Pulse of last month

Mailu: https://github.com/Mailu/Mailu/pulse/monthly#open-pull-requests
Helm-charts: https://github.com/Mailu/helm-charts/pulse/monthly

Topics

1.10 / 2.0 plans

• Replace rainloop with another webmail?

  • Rainloop has multiple high priority security bugs which were not addressed for the last 3 years. There is even a security bug reported 7 years ago that is still open.
    • no logout for a one month and no logout on browser close no logout for a one month and no logout on browser close RainLoop/rainloop-webmail#729
      Vulnerability in https://mail.rainloop.net/ Vulnerability in https://mail.rainloop.net/ RainLoop/rainloop-webmail#2128
    • Mail leak through cached ajax requests Mail leak through cached ajax requests RainLoop/rainloop-webmail#1390
      etc
  • Brainstorm about possible replacements for rainloop.
    • A potential candidate could be snappymail ( https://snappymail.eu/ ). It is based on rainloop, but it appears to be more secure. It explicitly mentions fixes related to security (https://github.com/the-djmaze/snappymail/releases).
    • ===> Let's use snappymail.eu.
      - Most likely it is sufficient to only replace the URL for downloading the targ.gz release in the Dockerfile.

• Big ideas for this release?

  • In other words, will it be 1.10 or 2.0?
  • Share ideas you'd like to work on.
    • This can be used as start point for the github issue to discuss the roadmap for the next release.
      =====>
    • introduce snappymail.
    • rootless containers
      • probably requires init container
    • replacement socrates?
      • Not known if ghostwheel has time for this
    • The security/keys page for Mailu admin.
    • DNS report
  • Have some UI that tells you if DNS is correctly configured.
  • Have a look at BuildX
    • means we can build for multiple platforms including ARM
    • means we remove the build arm script
    • means CI will be changed massively.
    • For ARM, we could maybe build once per week to make sure the build time for normal builts is not too long.
  • autoconfiguration for email clients?
    • automx: https://rseichter.github.io/automx2/?
    • integrate whatever we choose with mailu (part of mailu)?
    • also good time to drop starttls for imap/pop/smtp(sending mail).
      • So only support direct SSL/TLS
      • Could be done via environment_variable. When not configured, then starttls supported. If configured (default for new deployments) then it is disabled.
      • Another idea is to disable starttls, and report a custom error (when you use explicit starttls) that you must switch to implicit SSL/TLS port 465.

• 2fa

  • scope:
  • what would we want? u2f/webauthn, totp.
  • only web-facing?
  • imap as well? E.g. xoauth2.
  • For example if we use google as idp
    • You login Admin using google as idp
    • In Admin you must generate a token.
    • configure email client will use this token.
    • password login is not allowed for email client.

===>

• 2fa (for web facing part) only makes sense if you only have tokens with limited lifetime for imap login.
• means for imap you should have xoauth2.
  • Means we need autoconfiguration. Otherwise the email client will not use xoath2.
• means using single sign on via idp (which mailu could be as well).
• Maybe after next release.

Misc:

• Update alpine and all other dependencies (will always be done as part of release workflow)

• Dependabot. Automatic updates via bot. It submits a PR for each single updated dependency. E.g. for each image if alpine has a new version. For all packages in requirements.txt.

  • This practically means, master is on bleeding edge. Always fully up to date.
  • Fully configurable. E.g. how many pull requests may it create. How often does it check for dependendies? However it must run AT LEAST ONCE per month.
  • Do we want to use this? Can anyone share his experience with dependabot?
  • For more info https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates

===>
Lets give it try.
5 pull request as a maximum
Check once per month.

[henniaufmrenni]

Just a quick notice that U2F is deprecated and replaced with WebAuth and will be removed in Chrome 98.
I also don't think 2fa only makes sense when tokens have a limited lifetime, since having the ability to create/revoke tokens or making admin changes would require the second factor.

[nextgens]

Just a quick notice that U2F is deprecated and replaced with WebAuth and will be removed in Chrome 98. I also don't think 2fa only makes sense when tokens have a limited lifetime, since having the ability to create/revoke tokens or making admin changes would require the second factor.

@henniaufmrenni We'll discuss it tonight (and later on #2222); feel free to join.

[nextgens]

Next meeting we should probably talk about #2138 (comment) too (whether recommending that our users deploy DANE/TLSA records is wise)

[Diman0]

Mailu dev meeting of 18 may 2022

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
Notes link: https://demo.hedgedoc.org/TG_6KhdWRuaUPY-tFBOFIQ?both

Present

• Diman0
• nextgens
• ghostwheel
• HaleyAcs

Current state - Pulse of last month

Mailu: https://github.com/Mailu/Mailu/pulse/monthly#open-pull-requests
Helm-charts: https://github.com/Mailu/helm-charts/pulse/monthly

Topics

• support for other technologies -=== This topic is moved to the next meeting
  • kubernetes / swarm
  • ipv6
  • internal dns resolution (socrates)
• 2fa
  • Moved to next meeting
• security (hardened malloc allocator )
  • https://dustri.org/b/using-hardened_malloc-in-alpine-linux.html
  • Good idea. Nextgens will submit a PR for implementing this.
• Mission statement? https://github.com/Mailu/Mailu/wiki/Mission-statement
  • We made some changes and are happy with the mission statement.
  • Diman0 will submit a PR in the future for adding this to the documentation.
• Pr triage
  • we have processed some open PRs.
• versioning (semantic or not), see https://semver.org/
  • We probably want to use semantic versioning. We did not do this yet. From the next Mailu release, we could communicate we will use semantic versioning from now on.
  • In the next meeting, further discuss how we want to handle this. For example, we could switch to doing all development only on the main branch (no x.y branch anymore) and use tags. The workflow use this tag to create a new release with the appropriate version number./
• Drop swarm, split from support for other technologies
  • No issues have been received for a long time for docker swarm. It appears nobody is using it. None of the core developers use it.
  • We will announce that it will be dropped, backport this to 1.9
  • Then we will remove it from master.

[leolivier]

Hi
What is the status of your thoughts about multiarch/ARM support in Mailu?
As you can see in #1200 , a lot of people are waiting for this and I am myself trying to maintain a multiarch version of Mailu as much as possible with a specific CI.yml based on @Erriez work (see https://github.com/leolivier/Mailu and eg https://hub.docker.com/repository/docker/leolivier/mailu-nginx)
But as said above,

1. this is very different from the standard CI file
2. the builds take at least 1.5hr and sometimes abort with very weird reasons for some images (admin mainly)
   Edit: BTW, why do we always build all images when we only change one??? Why, when we update a lib in roundcube, should we rebuild the admin, nginx and all the rest? I suppose this was already discussed in the past but fFor me, the best solution to the long builds would be to run them only on what has changed. It's probably a very big change in the project structure (eg one git project for each images) but worth a study...
3. also, from time to time, there are specific processing for ARM, eg in the last admin build does not work anymore although there seems to be no change in the admin code so maybe due to changes in alpine or whatever... Hard to understand.

So, it might require more work on maintenance and tests side...
On the other hand, arm becomes unavoidable, a lot of companies are moving to arm processors for "ESG" reasons (eg less electrical consumption)

Anyway, thanks all for your work on Mailu!

[Diman0]

Mailu dev meeting of August 17th 2022

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
Notes link: https://demo.hedgedoc.org/TG_6KhdWRuaUPY-tFBOFIQ?both

Present

• Diman0
• nextgens
• ghostwheel

Current state - Pulse of last month

Mailu: https://github.com/Mailu/Mailu/pulse/monthly#open-pull-requests
Helm-charts: https://github.com/Mailu/helm-charts/pulse/monthly

Topics

• bug in podop involving dovecot.

  • There is already a PR with a fix
  • ghostwheel will review it.
  • We dont have the privileges to deploy packages to pipy for podop. We will merge it with the main project. E.g. Add a libs\podop folder where we will move it.
  • We will do the same with socrates.
    • step 1 move it to the main project.
    • step 2 to replace it?

• mailu alpine main image

  • Due to socrates and podop residing in ./libs/*, they will not be available to the docker context when building images. For this reason we should have a mailu base image available. All other mailu images use this base image
  • For building locally we still have to decide how to proceed.
    • State that you must copy the libraries locally before building?
    • Or actually move the libraries to /core/main/libs ? Perhaps the mailu base image could be called the mailu_libs image?

• restful api

  • use api token.
    • configured via mailu.env.
      • When api-token is set in mailu.env it is enabled. HTTP 403 error when authentication is wrong.
      • Second setting configures the listen address for the API endpoint. Default is localhost.
    • Look at ghosts project for usage flask-restx. https://github.com/ghostwheel42/Mailu/tree/apiv1

• Skip

  • Nextgens/Ghostwheel have not enough time available to focus on Mailu. For this reason we will move these features to the next release
    • A security/keys page for Mailu admin interface.
    • 2fa

• Todo: We still have these feature to implement for the next release. The person working on it will be ...

  • rootless containers (diman)
  • restful api (diman)
  • merge socrates (ghostwheel)
  • After the buildx PR has been merged (ghostwheel & nextgens)
    • have a look at using a alpine base image for podop & socrates (diman)
    • security hardened malloc allocator (is an alpine package). See also https://dustri.org/b/using-hardened_malloc-in-alpine-linux.html. (diman)
  • enable dependabot to send email alerts for CVEs only (diman).

• Triage

  • We had a look at PRs. We also assigned PRs so they get some attention.

[Diman0]

Mailu dev meeting of December 14th 2022

Meeting link: https://jitsi.fem.tu-ilmenau.de/MailuDevCollab
Notes link: https://demo.hedgedoc.org/TG_6KhdWRuaUPY-tFBOFIQ?both

Present

• Diman0
• nextgens
• ghostwheel

Current state - Pulse of last month

Mailu: https://github.com/Mailu/Mailu/pulse/monthly#open-pull-requests
Helm-charts: https://github.com/Mailu/helm-charts/pulse/monthly

Topics

• TLS_PERMISSIVE and banks in DE

  • reason for discussion: A bank (or all banks?) in DE refuse to send email if the destination email server does not support TLS & startls.
    -> clarify OUTBOUND_TLS_LEVEL / DEFER_ON_TLS_ERROR / INBOUND_TLS_ENFORCE
    It is not completely clear what these settings do.
  • After talking about this we determined (we think) that mailu uses smart default settings. There is no need to change this.
  • Remove OUTBOUND/INBOUND_TLS_LEVEL. We use the smart defaults already. No need to offer knobs for this in mailu.env (this also simplifies the mailu.env which is already quite bloated). People who do want to change this, can still do this by overriding the postfix configuration file.
  • Double check these settings can really be configured via override.
  • Add FAQ entry & mention via release notes that you can configure this via override. People who know what they do & accept they cannot receive/send mail from/to everyone can still use more strict settings.
  • In the future have a thorough look on everything in mailu.env settings.

• Simplifying the setup experience (for instance removing SUBNET, getting rid of alternatives to sqlite, ...)

  • The setup utility contains many settings that are advanced and not required. The setup page should guide less experienced users. It should enforce the smart defaults. After running setup, you can still change things by reading the documentation and modifying the config. But in the general use case we must guide the user in making the right choices.
  • What could we remove from setup.mailu.io
    • remove DB_* and document SQLALCHEMY_DATABASE_URI. Default should be SQLite. If you still want a different database, we document how to change this after running setup and creating the initial docker-compose.yml file.
    • SUBNET. There is no need to define the subnet. Docker-compose can handle this.

• Wizard functionality to check how fine mailu is configured. Like the nextcloud check on settings page.

  • This would be awesome. It would prevent many issues from less experienced users. A page where you can hit the TEST button and then mailu tells the user if everything is configured correctly and if everything works correctly.
  • test port 25 connectivity outbound & inbound.
  • Maybe check TLS levels
  • DNS records etc.
  • reverse DNS
  • All the bells and whistles you need for using Mailu and send/receive email.
  • For the next Mailu version we could look at implementing this 'test my installation' test page.
  • For this current release we could focus on:
    • Keep the scope very small
    • check outbound port 25
    • check DNSSEC capable resolver.
    • If both tests fail, then we DO start the admin container but either:
      • We show in the admin page really clearly mailu won't work.
      • OR we spawn maybe a separate HTTP server that provides this message.
      • It will be clear for the end user why it doesnt work and what doesnt work. The current situation, having to check in the logs why admin does not start is too complicated for some users.

• Target date for release

  • Review current PRs and release?
  • Or do we still want to add more functionality?
  • rspamd's overrides
  • ====>
    • It would be nice if we could release in January.
    • We want to implement at least (showstoppers):
    • Open PRs from nextgens & diman0
    • the rspamd overrides
    • above mentioned simplification of setup
    • above mentioned test functionality

• PR 2566 - proxy protocol stuff

  • Overly complicated and a niche scenario.
  • Does not fit with the main goals of the project.
  • Still we want to make it possible to use it for the people who really want this.
  • Do not merge the PR.
  • We will add two new exit points that allow a user to make ANY changes they want to the nginx config. So all niche cases and exotic things can be configured in nginx.
  • We do this by adding two exit points in start.py
    • An exit point that is called before the nginx config is parsed.
    • An exit point that is called after the nginx config is parsed.
    • E.g. if you create a specific .sh file, then it would be called before/after the config parsing. A user could add search&replace lines to make all changes he wants.
  • This functionality should probably be added to ALL containers. There are users who do want advanced stuff that do not fit with the project. This can make any changes they want. We don't have to add knobs to mailu.env for settings that do not fit with the mailu goals.
  • The user who submitted the PR can still use proxy protocol via those exit points.

• Moderation of #mailu-dev

• None of us are admin. We have seen some situations where spambots joined & people discussed no development things. We need the ability to moderate.

• diman will ask for admin permissions.

• diman will assign moderators

• mailu-dev channel is only for active discussion about the main mailu project between contributors. It is not mean for end-users. We will update the description of the channel.

• we think about muting people who join the mailu-dev channel

• mute people who have not contributed in the mailu-dev channel.

• For the user's mailu channel, add an description that mailu is a volunteer non-paid project.

Moved to next meeting

• Inter-container comms