Search results for "Postorius" - Mailman-users

[MM3-users]Incorrect URLs

by Mark Sapiro

There are various URLs exposed in various emails from the list, many of which are wrong. The underlying issue is there are generic replacements such as $listinfo_uri and $user_options_uri in various templates such as the welcome.txt list welcome message and the footer-generic.txt message and digest footer. Now that the Mailman 3 core engine has been separated from the web UI, the core doesn't know what these replacements should be and there is not yet an interface to get them from Postorius or whatever the web UI is. In the mean time, I have made list specific versions of welcome.txt (done before announcing the list) and footer-generic.txt (just now) with the correct URLs hard coded. The purpose of this post is two-fold. To explain the issue, and to test the footer. There are probably more of these incorrect replacements and I will fix them as I notice them or they are pointed out to me. Note that I am aware that the https URLs in the List-Subscribe: and List-Unsubscribe: headers added to posts are wrong, but I haven't got a handle on this yet. The mailto: links in those headers are correct as are the Archived-At: and List-Archive: URLs as there is an interface to get those from the archiver. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 years, 7 months

Re: Adding user - Error 409 Subscription request already pending

by Kevin Hurtley

Thanks Mark, This is sounding like a case of users will be users. As you suggested, I think my moderator is dealing with a user that can't find their confirmation (or understand they need to reply to it). So the moderator tried to override things by trying to add them in by using the "mass subscribe" operation. It sounded on Github that some opinion was that it wasn't necessary to see these pending requests, but as "users will be users" I think would be useful to see what is in queue for subscription requests, it would be better yet to be able to either clear them out or accept them there. But at very least seeing them there would go a long way helping out my moderators troubleshoot. On another request, user found the confirmation email, replied, and was accepted. However that email was several weeks old. So I'm guessing our default for expiration of requests is not the default of 3 days. But I haven't been able to find that setting. Is that in Postorius somewhere or will I need to change with the shell? I wonder if temporarily changing the Subscription Policy to "open" would allow those in pending to be accepted and clear that queue out? Thanks again for the input, much appreciated! Kevin Hurtley CoastAlaska, Juneau, Alaska

7 years, 6 months

Enforcing SSO and subscription options

by Stephen J. Turnbull

dlb-ml--- via Mailman-users writes: > I'm looking to see if there's any way to isolate the third-party > login section and prevent local account sign in and sign up. This > way, we can ensure that the people within our organization are > using a stronger auth method that prioritizes MFA, rather than just > username/password. This is really a Django/allauth question. I strongly recommend you ask there. Maybe Mark knows more, but my own experience with it is limited, and the client specified the setup, I just implemented it. > I did see that there is the SOCALACCOUNT_ONLY option, as provided > by allauth > (https://docs.allauth.org/en/latest/socialaccount/configuration.html) > but that broke any attempt to display the sign in page, My experience was using Shibboleth to authenticate to Apache, require authenticated user for all Mailman and Django locations, and Apache would communicate the authenticated user ID directly to Postorius. You could visit the page, but because you were already authenticated, you had to log out to log in. But -- Catch-22 -- that access would go through Apache and log you in. > assuming [SOCIALACCOUNT_ONLY] is not supported with the current > version of MM3. AFAIK, there's no code in Postorius that's specific to processing authentication -- that's all done by Django or Django plugins, and controlled by the standard Django and allauth parameters. So it's not something Mailman is related to supporting. This is a question of what allauth, and possibly Django core, supports. It's possible that Mailman defaults to a configuration that messes up Django's support, but if so I would bet that somebody with deep knowledge of how allauth works could tell you how to get the effect you want. > Is my plan to modify the templates viable? It's not clear what your goal is. If it's just to keep typical users on the straight and narrow, yes, that should work. But as far as I know, a competent user who is mischievous or malicious can probably craft requests to successfully access any locations that are not disabled in code or protected by the frontend webserver. Disabling the signup adapter will definitely make mischief much harder, but I can't promise it's impossible. But if you have a SSO system with an organization-specific IDP or a database of 3rd-party accounts with Google or whatever, I would think you'd want to use that as the source of ground truth directly, as I described my experience above, rather than creating a separate credientials database in Django. > Given the discussions on disabling the anonymous subscription form, > are the email commands a less spam-susceptible solution or are they > just as vulnerable as the form? The whole point of email commands was to allow anonymous signups (more precisely, pseudonymous signups tied to a mailbox). If you don't want "anonymous" signups, you don't want to enable the email commands.

1 year, 8 months

[MM3-users]Re: Installation issues

by Andrew Hodgson

Mark Sapiro wrote: >On 04/19/2016 11:40 AM, Andrew Hodgson wrote: > >> I have often wondered if there was a howto on how this specific mailman3.org server was built, so it gives us a production-like template to follow? >Sort of, but it's not (yet) public. The process I followed is very >convoluted and not what I would recommend anyone follow. Part of the >issue is I started with mailman-bundler not using a venv, but bundler >still installs a lot of stuff in Python 2 and Python 3 venvs. I then >proceeded to install the git master branches of mailman, >mailmanclient, mailman-hyperkitty, hyperkitty and postorius and their >dependencies system wide and ripped out most of the venv stuff. I started off without using venvs and ran into several issues, though one of them I think was due to the bundler pulling down an outdated dependency. My next stab at this was going to be using venvs, but creating the venv as the directory /opt/mailman which gives cleaner paths (to my mind anyway), but haven't got round to doing it yet. My main thing when looking at this is how package managers are likely to package Mailman3, especially from a Debian point of view. I know I can't second guess what is going to be done, but would like to try to build using similar goals if possible. Thanks. Andrew.

10 years, 6 months

Re: Hyperkitty import from mailman2

by Marvin Gülker

Am 24. December 2017 um 22:30 Uhr +0200 schrieb Sten Aus <sten.aus(a)eenet.ee>: > Oh my god. :) That's it! There are no latest messages and front page shows > only last month "activity". Thank you! I did not thought that I should check > some older posts. :D I know that feeling. It took me a while to figure this out as well. Error on OSI Layer 8. > But how did you manage to import all the lists and members from Mailman2 to > Mailman3? As I understand Mailman3 does not "support" (by manual) import > right now? You'll be surprised, but those mailinglists were not managed by Mailman2 before. They were managed by mlmmj[1]. I wrote a script that converted mlmmj's archive into mbox format, and then used the "hyperkitty_import" command as explained by the Hyperkitty manual[2]. This worked surprisingly well. As for the subscribers, Mailman 3's Postorius has a mass-subscription facility in the admin interface. I extracted the list of all subscriber emails from the mlmmj mailinglist and used that mass-subscription facility to subscribe people again. There's an option to disable delivery of the welcome email that should be ticked before this I guess, though. It can be reset afterwards again. Greetings Marvin [1] http://mlmmj.org/ [2] http://hyperkitty.readthedocs.io/en/latest/install.html#importing-the-curre… -- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F

8 years, 10 months

Re: A new issue with installation

by Andrew Hodgson

Abhilash Raj wrote: >On Sat, Feb 20, 2021, at 9:28 AM, Abhilash Raj wrote: >> >> >> On Sat, Feb 20, 2021, at 8:51 AM, Brian Carpenter wrote: >> > As usual, a new issue has arisen with installing Mailman 3. It seems >> > Postorius and Hyperkitty want to install a module called cryptography. >> > Which I am unable to install because of this: >> > >> > error: Can not find Rust compiler >> >> You need to install a Rust compiler. Depending on which distro you are >> using, you can run `sudo apt install rustc` or same command with `yum`. [...] >FAQ: https://cryptography.io/en/latest/faq.html#installing-cryptography-fails-wi… > >You can skip the Rust components by setting `CRYPTOGRAPHY_DONT_BUILD_RUST` but that would work just for this release and you won't be able to skip from the next release of cryptography. Its also possible to install an older version of Cryptography before installing Mailman dependencies which doesn't require this. Version 3.3.2 is the version I have been using recently at work. On a side note I have been experimenting with using underlying Debian packages for some of the Python dependencies and using the --system-site-packages option when creating the venv to simplify installation and reduce the number of compilation tools required on the system. Thanks. Andrew.

5 years, 8 months

Re: Mailing list welcome message won't update

by Mark Sapiro

On 1/16/25 13:43, via Mailman-users wrote: > HI Mark, > > I simply tested by unsubsribing to the mailing list and then re-subscribing to receive the welcome message. > > How do you test using the mailman command with user list? sudo -u list mailman addmembers -h or in your case, you may not have that subcommand in which case see sudo -u list mailman members -h However, that is all irrelevant. I only thought you might be testing by using `mailman` commands to add a member and if so and if the command is not run as user `list`, it might not have access to read the template. If you are (un)subscribing via Postorius or via email these are handled by Mailman runner processes which should all be running as user `list` and should have access to the template. So, as I said, I don't know what the issue is unless it is something with your Debian package which is ancient. Even Debian buster has mailman core 3.2.1. Does your empty list:member:generic:footer.txt work to not add any footer to list messages? If so, I can't think of any reason why your list:user:notice:welcome.txt wouldn't be used. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[GSoC 2026] [Feature Proposal] Per-List Backup and Restore Support

by sonika gutha

*Introduction: * My name is *Sonika Chowdary Gutha*, and I am a *second-year Computer Science undergraduate at BITS Pilani, India*. I recently completed a *6-month internship in Backend Development using Python and Django*, where I gained experience in building backend systems and working with REST APIs.I am also familiar with the *MERN stack and the Flutter framework*, and I have experience developing both web and mobile applications. In addition I have been introduced to the fundamentals of several programming languages, including *Python, C++, and JavaScript*. I am exploring the possibility of implementing a *per-list backup and restore feature* for Mailman. The goal of this feature is to allow list administrators or owners to *export the configuration and membership data of a specific mailing list into a portable backup file and restore it later when needed*. This could be useful in situations such as: - Migrating lists between servers - Recovering from configuration mistakes - Replicating list setups across environments *Implementation:* The following diagram provides a visual representation of the proposed backup and restore workflow <https://excalidraw.com/#json=PhUB9tdMrupMfpx7O6_i6,OLBUtBJjL5_sCR-UokrNHw> .: I plan to implement this feature in two parts. The main backup and restore logic should live in *Mailman Core*, since that is where the actual list configuration and membership data are stored. My idea is to define a *versioned JSON format* that captures the important per-list data such as list settings, members, owners, moderators, and relevant subscription preferences. On the export side, Core would gather this data and write it into a portable backup file. On the restore side, it would read the file, validate its contents, recreate the list if necessary, and restore the saved settings and memberships. On the *Postorius* side, I would implement the user-facing workflow for this feature. This would include an option for list owners or administrators to download a backup file for a specific list, as well as a page where they can upload and restore that file when needed. For the initial version, I plan to keep the feature focused and reliable by covering configuration and membership data first, while leaving more complex areas such as archives or other external components out of scope unless they are explicitly expected. *Questions:* 1. For the first version, what exactly should be included in the per-list backup: only settings and memberships, or also items like templates, ban lists, and member preferences? 2. Should the main export and restore implementation live in Mailman Core, with Postorius mainly responsible for the UI and workflow? 3. Is a *versioned JSON format* the preferred choice for the backup file? 4. Should restore only support creating or recreating a list from backup, or should it also support restoring into an already existing list?Thank you for your time and feedback. Please feel free to *suggest any changes or improvements to the proposed implementation*, also if possible hope i can get answers for the above questions which will be helpful for my proposal, I would be happy to incorporate them.:) Best regards, Sonika

7 months, 4 weeks

Re: One-click unsubscribe?

by Jered Floyd

> As I discovered (to my chagrin) Mailman's current simple RFC > 2369 List-Unsubscribe field doesn't, even for personalized lists where > there might be a personalized link in the footer. My understanding from up-thread is that the RFC 2369 headers are added pre-personalization. > The token would be the > encrypted (list, address) pair, possibly dated in clear (to allow > expiration of tokens and rotation of encryption keys). Unfortunately > RFC 8058 doesn't discuss that, I guess John assumed that people would > usually be unsubscribing from the most recent post. I don't think we can assume that it will be the most recent post, but it would likely be _a_ recent post. If we add a timestamp to the encrypted token I suggest there should be a pretty broad window allowed (i.e. several months). > On the assumption > that unsubscribes would be "rare", you wouldn't have to store the > token in the database. (Have to think about that, you might be able > to DOS attack by sending lots of fake unsubscribes and attack the > encryption with known plaintext attacks. Safety would suggest adding > a random nonce and that would need to be saved in the database.) Do you just mean a salt? Or are you suggesting adding a per-subscription nonce stored in the DB? (In which case, that could simply be the URI token...) I agree with your analysis, but this would be a very specialized attack, especially if we don't provide direct feedback on if the request was successful (which we are not required to do). I have trouble constructing a practical threat here and I think the encrypted tuple, or a plaintext tuple and truncated HMAC (like how SRS works) would be sufficient. The real risk without a per-subscription random unique identifier would be a replay attack -- the user is unsubscribed multiple times? That feels outside of the threat model. > Alternatively, you could reverse proxy this directly through the > front-end webserver to Mailman core with a new REST endpoint. That > gives me bad vibes because I can just see naive admins messing up the > configuration of the single endpoint, and "fixing" the problem by > reverse proxying port 8001 to the Internet. We'd have to be careful > that the urlconf not slop over to anything else, maybe something like > "listen" on the Internet at (nginx notation): > > location /mailman3/rfc8058/ { > proxy_pass http://localhost:8001/3.2/PROXIED/rfc8058; > } > > The "PROXIED" part is just to provide a REST namespace that is > obviously separate from the domains, addresses, users, lists, etc. > Maybe "SELF_AUTHORIZING" would be more accurate. I think that reverse > proxy sepcification would be safe enough. > > And you could combine the two strategies which would allow sites that > don't use Postorius to configure the reverse proxy, while sites that > do would get it for "free" since we'd configure Postorius to do it. I hadn't considered this -- I definitely like this approach because it means the same function need not be implemented twice, differently. I guess the big question is now just what the simplest content of the URI should be. > Aside: RFC 8058 says > > But anti-spam software often fetches all resources in mail header > fields automatically, without any action by the user, and there is > no mechanical way for a sender to tell whether a request was made > automatically by anti-spam software or manually requested by a > user. > > Weirdly, the RFC doesn't address this problem at all. :-( This has always been the risk with single-click anything. Given how common this is as a use case, I believe that the anti-spam/anti-phishing systems have stopped clicking links willy-nilly, or at least special case List-Unsubscribe URIs. I also see that inbound mail filters these days are more likely to rewrite clickable links to bounce through a redirector so the scan happens at access (rather than receipt) time -- so the link is only proxy-clicked when the user does intend to do so. A bigger threat might be web archives that include the list headers and clickable links. The GenAI companies are absolutely _hammering_ anything they can get a hold of with spiders that ignore all robots.txt or rate limit indicators. I have to keep blocking user agents and IP ranges because I'm spending $100s/month in excess egress fees on badly-written LLM spiders. The Internet is an increasingly hostile place. Regardless, not something we can do much about. --Jered

11 months

Re: [Mailman-Developers] Mailman 3.1 beta coming soon

by Mark Sapiro

On 12/02/2016 08:07 AM, Barry Warsaw wrote: > Hello Mailman 3 users and developers! > > It's been a long slog but I think we are finally ready to begin the release > process for Mailman 3.1. I am pretty happy about the state of the Core, and > Florian is going to do some more integration testing with HyperKitty and > Postorius. We still have a few issues and a merge proposal or two to address, > but I am planning to spin a beta of Core this weekend to facilitate testing. Barry, I understand you need to feel comfortable about everything going into the core and this takes time and energy to review all the MRs, but I think it is pretty important to get the DMARC mitigations into the core. If there's anything I can do to help with this, let me know. I will rebase my branch again and possibly make one minor tweak, but I think it should be OK. I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 11 months

Mailman-users search results for query "Postorius"