[mlmmj] Candidate for an 1.4.0.a1
Baptiste Daroussin <[email protected]> Fri, 02 Dec 2022 14:51:08 +0000
| Newsgroups | org.mlmmj.mlmmj |
|---|---|
| Message-ID | <[email protected]> |
Hello everyone, A 1.5 years ago, I migrated FreeBSD's mailing list to mlmmj. So far so good we are very happy with it. Since that date I have been working on modernizing mlmmj codebase, integrate our patches etc. While the work is clearly not done, I think it is advanced enough for it to be shared. Disclaimer: this is a very early alpha, mostly tested under FreeBSD! While I tried (and intend) to keep using only portable things, their maybe issues, the main goal is to open the gate to contributors, testers and open discussions. https://codeberg.org/mlmmj/mlmmj/releases The working has been ongoing here: https://codeberg.org/mlmmj/mlmmj The changelog is the following: * Add a test suite * Modernize code (dprintf, posix_spawn, asprintf, getline, daemon, ...) * Supporting passing email to a mta over ipv6 * Fix relaying in IPV6-only systems * Fix decode quoted printable subject * Fix parsing RFC1891 * Fix a crash if no owner has been defined * Validate ranges of all integers conversion * New 'nobounceprobe' tunable for debugging purpose * New 'send' tunable to allow email passthrough * Add support for 'X-Original-From' * Reduce subscription confirmation address length to fit RFC 5321 * Use arc4random is available * Reduce memory manipulation * When unsubscribing bouncers, keep the bounce file if something went * wrong and report in syslog what went wrong * Remove the -b option from mlmmj-unsub, it is not used anymore * simplify the locking mechanism My plans before a full 1.4.0: * Remove the php part * Merge interesting parts of mlmmj-receive-strip into mlmmj-receive Note that one thing I didn't do is merge the mungefrom patches. So far I consider mailing list should not be altering parts of the email that are part of the dkim signatures aka: - Should not modify the subject - Should not strip any part of the emial - Should not add a footer If so, emails going through a mailing list respects dkim/dmarc expectations. Note that I don't have strong feelings about this, so I can be convince to merge those patches. Open question: - should this still be mlmmj? (aka the continuation of the project?) if most do not like the approach, I will of course fork and rename, otherwise I will be happy to make it a continuation of the project. Best regards, Bapt