Release planning for version 2.3.1

[Udera]

What do you think of releasing a version 2.3.1 soon? I think we already merged some nice fixes and with the recent problem of the removed demime in Exim 4.88 we risk to run into many complaints in the future (e.g. new Debian this year). We won't be able to do everything scheduled for 2.3.1, but I'd like to review your Mailman-fixes and also properly integrate a LMTP transport (without integration in web interface or database).
@rimas-kudelis

[rimas-kudelis]

We have so much issues and PR's marked for 2.3.1 that I'm not sure we can wrap it all up quickly.

On the other hand, if you think we've introduced enough changes to mandate a new release, I don't mind that. We can always retarget whatever doesn't make it into 2.3.1 and have another release later at some point.

[Udera]

Good. I will try to check what I can do in the next weeks. Everything else will be moved to the next release 2.3.2. I also hope to find an afternoon for vexim3.

[Udera]

I have reviewed a couple of PR, now I'd like to decide on those with the "to review" label:
https://github.com/vexim/vexim2/pulls?q=is%3Apr+is%3Aopen+label%3A%22to+review%22

After the merges we should do some testing and then push out vexim 2.3.1. Are there other things you want to get in?

[rimas-kudelis]

We have several long-standing code-related PR's (such as #106) which require more and more polishing with each commit we make, so in general, I'm in favor of reviewing and accepting as many of them as possible. However, as usual, I don't have enough free time (and perhaps even motivation) to actually review them properly, so I guess I'll leave these decisions up to you for now.

[Udera]

I already had a look into the LMTP transport (#150), I wanted to do it differently but it didn't work out that easily (using the same router as we do currently). It's not a huge thing to implement but it would require some changes to the interface (which we suppose would be much easier on a newer interface).

Custom user names is really interesting (#106), at this point we could think about fiddling in LDAP support (or at least design it in a way that it is possible). The PR is rather small, we could give it a quick test and put it in. We risk to change it later.

All these spam-reducing stuff (#153, #161), I'm not really convinced of these solutions. We could put them into our wiki for people wanting to use it. We should review the anti-spam measures at some point, e.g. implementing something like policy.d but directly within exim (should be possible with ACLs to give "points" for certain features of a mail and reject them in the end if the total score exceeds a certain value).

[rimas-kudelis]

Re #150: I'd really like to avoid additional UI and DB changes, so I'd prefer LMTP to be a server-wide option for now. Furthermore, I'm not sure this is something a virtual domain administrator or even the end user should mingle with, so I guess I would have preferred it even if we were working on Vexim3.

Re #106: the use-case says it all, and assuming it's a small change as you say, I really don't think it would hurt for us to have it.

Regarding the other two: I'm too lame on the spam fighting front to weigh in on that. :) Although you made me wonder why you'd want to implement something directly in Exim when it is already implemented in another package.

[Udera]

I didn't have much time lately. I still think we should push vexim 2.3.1 a bit, some things which should go into it:

• Database issues: Migrate MySQL database to utf8mb4 (or ASCII where appropriate) #242
• Always accept postmaster mail: Always accept postmaster email for virtual domains #228, fix: Postmaster no delete #248
• Postgres update scripts: PgSQL upgrade scripts #196 Postgresql instructions and config-examples (work-in-progress) #244 (or move it to later??)

unsure (I don't use it, if someone finds the time to fix it would be great):

• specific Debian files: Fix conflicts and improve Debian config #199, vexim-acl-check-helo.conf in split Debian configuration? #109

later (or if someone has time):

• local mailboxes: Disable virtual domain delivery to local mailboxes #218
• User experience: Mail forward emtpy address #162

Then, we can split off a vexim2.3 branch, and on master we can continue, implement some of the outstanding pull requests with new features. We can test them. Smaller things can be back-ported until vexim2.4 is considered stable enough.

@rimas-kudelis I hope you have some time to look into the mysql issues.

[VVD]

Is vexim alive?

[rimas-kudelis]

@VVD, it's not as active as we'd want it to be, but I wouldn't consider it completely dead either. More like, it's just pretty stale.

For more context, Vexim consists of three mostly independent parts, which can be stale or active mostly independently of each other:

1. Configuration snippets for MTAs and MDAs: may age over time, but we tend to update them as necessary.
2. Setup/update SQL scripts: only used once and basically don't age. However, each schema change/update make update/installation more complex, so I wanted to find a better way to maintain it.o
3. PHP front-end for mailbox management: this is the really old and rusty part. We were hoping to replace it with a modern PHP frontend one day, but haven't done this so far. However, there is already an alternative frontend in Python (veximpy) available for it.

[VVD]

@rimas-kudelis, thanks for information.

[modified by @rimas-kudelis: report moved to #276]

3. It isn't ready yet, doesn't support apache and etc. :-(

[runout-at]

@VVD cold you report bugs in an extra topic and provide a pull request please - don't hijack threads.

what do you mean with It isn't ready yet, doesn't support apache and etc. :-( ? Vexim2 runs with Nginx, Apache, lighttp (I did test these) and for sure with many others.

[VVD]

@VVD cold you report bugs in an extra topic and provide a pull request please - don't hijack threads.

Ok, I'll create new bug report, but without pull request.

what do you mean with It isn't ready yet, doesn't support apache and etc. :-( ? Vexim2 runs with Nginx, Apache, lighttp (I did test these) and for sure with many others.

It was answer on this suggestion:

3. PHP front-end for mailbox management: this is the really old and rusty part. We were hoping to replace it with a modern PHP frontend one day, but haven't done this so far. However, there is already an alternative frontend in Python (veximpy) available for it.

[VVD]

#276