search

vexim / vexim2

Virtual Exim 2
Other
70 stars 47 forks source link

Release planning for version 2.3.1 #233

Open Udera opened 7 years ago

Udera commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I already had a look into the LMTP transport (https://github.com/vexim/vexim2/pull/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 commented 7 years ago

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 commented 6 years ago

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:

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

later (or if someone has time):

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 commented 2 years ago

Is vexim alive?

rimas-kudelis commented 2 years ago

@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 commented 2 years ago

@rimas-kudelis, thanks for information.

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

  1. It isn't ready yet, doesn't support apache and etc. :-(
runout-at commented 2 years ago

@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 commented 1 year ago

@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:

  1. 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 commented 1 year ago

https://github.com/vexim/vexim2/issues/276

VVD commented 9 months ago

Please add patches from these issues to version 2.3.1 too: https://github.com/vexim/vexim2/issues/279 https://github.com/vexim/vexim2/issues/281

Udera commented 8 months ago

281

this adds a new feature and changes the db-structure. I´d use a new version and not only a patch version.

runout-at commented 8 months ago

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:

  1. 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.

sorry for the delay...

Python does not need a specific webserver. The python application runs on a WSGI (uwsgi, gunicorn, ...) or ASGI (hypercorn, uvicorn, ...) engine. For several reasons it makes sense to put a webserver in front of this engine. It's similar to php using php-fpm (or uwsgi) and put a webserver in front of it. In the old times Apache would have handled php itself but that had major drawbacks.

VVD commented 8 months ago

A larger zoo means more time for support and worse support. I don't want to switch to something else, especially on python.

vanzhiganov commented 8 months ago

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:

  1. 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.

sorry for the delay...

Python does not need a specific webserver. The python application runs on a WSGI (uwsgi, gunicorn, ...) or ASGI (hypercorn, uvicorn, ...) engine. For several reasons it makes sense to put a webserver in front of this engine. It's similar to php using php-fpm (or uwsgi) and put a webserver in front of it. In the old times Apache would have handled php itself but that had major drawbacks.

Python is not good alternative for project with lack of development activity like Vexim. Because, a python packages have amount of incompatible updates from version to version.

rimas-kudelis commented 8 months ago

Each time there's some movement in the pull requests or issues in this repository, I have this urge to rewrite Vexim using Symfony. But then I remind myself how little I use Vexim myself anymore, which translates directly into how little priority it has for me personally. So I just put it off, because meh, it's okay for me as it is.

But I do think that Vexim2's codebase is a dead-end. It's ugly and should be rewritten using modern practices before introducing any new functionality. Especially when such functionality involves database schema changes, because having a yet another non-versioned schema change would only grow the "zoo" of different Vexim DB schemas in use, which I'd like to avoid. Perhaps we should adopt an official policy about this?

As for the Python version, @runout-at did all the work there by himself, so I don't think any of use here is in the position to command him what technological choices to make.

runout-at commented 8 months ago

Thx. It was just my opinion but i think it's off topic here. If someone have the urge to discuss religious aspects of PHP vs Python - feel free to open a new Issue.

Udera commented 8 months ago

I didn't like the idea of changing the language either. However, if you use mailman, then you need python anyway. My problem is, that I never done anything with webapps in python, so it needs some time to learn it. Just from looking at the code, I feel a bit lost 😨

rimas-kudelis commented 8 months ago

I'm wondering if we should tag 2.3.1 after all. Got an email from @gldickens3 today, who upgraded a couple Debian servers and hit a bug which we fixed over three years ago, but never tagged for release (2a9479d).

Anyone up for reviewing any PRs before the release? I'd specifically like to merge #264 in, but I'd say other PRs which don't change the DB schema could also be considered.

Udera commented 8 months ago

I'd specifically like to merge #264

I went over your PR quickly and it look ok so far.

Anyone up for reviewing any PRs before the release?

I would switch my db on a working setup to utf8mb4 and then probably try a new install with this https://github.com/vexim/vexim2/pull/253.

if we should tag 2.3.1

no tags at all? If we manage to test a bit, we will know at least that this version seems to work more or less and there are no conflicts or not too much inconsistencies between the merged PR.

runout-at commented 7 months ago

I'm fine with doing a new release.

As Exim had a mayor change in the last years (since last vexim release): Did anyone check if vexim has to change something for that? At least the variables $local_part and $local_part do not work as before as I remember. It's some time since I did this on my server.

kaluang commented 7 months ago

yes, afaik the mailman router does not work anymore starting Exim 4.96.

You have to add this line to mailman_router after line 517 in "vexim2/docs/configure": local_parts = dsearch,filter=dir;MAILMAN_HOME/lists

and in line 1049 in mailman_transport you have to change $local_part to $local_part_data

(weirdly those lines do not work in my Exim 4.92, but I did not investigate that further)

I did not come across other issues so far, but I also made several changes to my exim4.conf over the years. So I have some significant differences to "vexim2/docs/configure" in my current configuration.

EDIT: To clarify, this is only applicable for Mailman2 that is currently supported by the example configuration

Am 12.01.2024 um 14:08 schrieb runout-at:

I'm fine with doing a new release.

As Exim had a mayor change in the last years (since last vexim release): Did anyone check if vexim has to change something for that? At least the variables $local_part and $local_part do not work as before as I remember. It's some time since I did this on my server.

— Reply to this email directly, view it on GitHub https://github.com/vexim/vexim2/issues/233#issuecomment-1889155425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOF77HEC3FSHSHRZVOXAMLYOEYV7AVCNFSM4C4NTH7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYHEYTKNJUGI2Q. You are receiving this because you are subscribed to this thread.Message ID: @.***>

runout-at commented 7 months ago

I'm going through my old PRs now. some are partly obsolete as functionality has been included into the default config (at least in Debian). So it' should be easier to include those features in Vexim. Shall we do this with this new release?