Search results for "Postorius" - Mailman-users

Re: Postorius performance with over 1000 pending users

by Nick W

On 06/08/19 at 12:13, Nick W <mail(a)nickwynja.com> wrote: > Could it be that these requests are being submitted through Postorius? I'd > assume there would be some sort of honeypot input to prevent abuse. I'll > continue investigating and follow up with any insight I can on the cause of The > Problem. Some follow up here: cat /var/log/nginx/access.log | grep "POST /postorius/lists/mylist.exmple.com/" shows only a recent manual attempt I made to subscribe but not much else, which leads me to believe these requests aren't coming through Postorius. Now the more embarrassing part. The likely culprit is my stupidity. In an attempt to have subscription forms embedded on my static websites, I created this flask app to handle POSTs and subscribe people the the specified lists. https://github.com/nickwynja/fmmss/ I included a menial honeypot feature to handle spam requests, which I thought was working. It must not be but it appeared like it was, likely because I made the honeypot for my app at the same time I changed the subscription policy to 'confirm' and upgraded from Postorius 1.2.3 (when pending user subscriptions were no longer shown). Seems like I have some homework to do to prevent spam subscriptions through my app.

7 years

Re: customized welcome message

by Mark Sapiro

On 12/7/23 12:46, Nils wrote: > I didn't try to include html. > It completely ignored the template I've created and sent the html source > of the parent domain. Which seems totally random to me. How and to what did you set the URL for the template? What does the database query SELECT uri FROM template WHERE name = 'list:user:notice:welcome'; show? >> I see no URI setting in Postorius Settings > Automatic Responses. What >> Postorius version is this? Any local mods? > It's Postorius Version 1.2.4 installed through the mailman3-web package > for ubuntu focal (https://packages.ubuntu.com/focal/mailman3-web) This is very old. Current Postorius is 1.3.10. 1.2.4 is from February 2019. The Debian/Ubuntu packages are out of date. We recommend installing via the doc at https://docs.mailman3.org/en/latest/install/virtualenv.html -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

Re: New messages not being archived

by Sarah H

I have, it just ends up printing out the pages html in the error message after: </html> Jul 14 10:52:31 2021 (471314) Traceback (most recent call last): File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman_hyperkitty/__init__.py", line 154, in _archive_message url = self._send_message(mlist, msg) File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman_hyperkitty/__init__.py", line 210, in _send_message raise ValueError(result.text) ValueError: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Organic BC</title> <link rel="shortcut icon" href="/static/postorius/img/favicon.ico"> <link rel="stylesheet" href="/static/postorius/libs/bootstrap/css/bootstrap.min.css"> <link rel="stylesheet" href="/static/django-mailman3/css/main.css"> <link rel="stylesheet" href="/static/postorius/css/style.css"> <link rel="stylesheet" href="/static/postorius/libs/fonts/font-awesome/css/font-awesome.min.css" type="text/css" media="all" />    </head> <body> <nav class="navbar navbar-expand-md navbar-light bg-light navbar-default"> <div class="container"> <div class="navbar-header"> <button type="button" class="navbar-toggler collapsed" data-toggle="collapse" data-target="#header-nav" aria-expanded="false"> <span class="sr-only">Toggle navigation</span> <span class="fa fa-bars"></span> </button> <a class="navbar-brand" href="/mailman3/lists/"><span><img src="/static/postorius/img/mailman_logo_small_trans.png" alt="Mailman logo"/> Postorius</span></a> </div> <div class="collapse navbar-collapse" id="header-nav"> <ul class="nav navbar-nav mr-auto"> <li class="nav-item"><a href="/mailman3/lists/" class="nav-link"> <span class="fa fa-envelope"></span> Lists </a></li> <li class="nav-item"><a href="/archives/" class="nav-link"> <span class="fa fa-comment"></span> Archives </a></li> </ul> <ul class="nav navbar-nav navbar-right"> <li class="nav-item"><a class="nav-link" href="/accounts/login/?next=/hyperkitty/api/mailman/archive"> <span class="fa fa-sign-in"></span> Login </a></li> <li class="nav-item"><a class="nav-link" href="/accounts/signup/?next=/hyperkitty/api/mailman/archive"> <span class="fa fa-user-plus"></span> Sign Up </a></li> </ul> </div> </div> </nav> <div class="container" role="main"> <h1>Page not found</h1> <div class="alert alert-danger">This page either doesn't exist, or it moved somewhere else.</div> </div> <footer class="footer"> <div class="container"> <p class="text-center"> <a href="https://postorius.readthedocs.org">Postorius Documentation</a> • <a href="http://list.org">GNU Mailman</a> • Postorius Version 1.3.4 </p> </div> </footer> <script src="/static/postorius/libs/jquery/jquery-1.11.3.min.js"></script> <script src="/static/postorius/libs/popperjs/popper-v1.11.0.min.js"></script> <script src="/static/postorius/libs/bootstrap/js/bootstrap.min.js"></script> <script src="/static/django-mailman3/js/main.js"></script> <script src="/static/postorius/js/script.js"></script> </body> </html>

4 years, 10 months

Re: Changes in Django admin interface are not syncing to postorius gui /database

by ulf.rapphahn＠offis.de

Mark Sapiro wrote: > Lists, not Mailman lists. When you create a list in Postorius or Mailman > core, this is a Mailman list. A corresponding HyperKitty list will also > be created if hyperkitty is one of the active archivers for the list so > you see it in Django. > When you create a list in Django, it is only a HyperKitty list and will > be visible in HyperKitty, but no Mailman list is created so the list is > not in Mailman/Postorius. Thank you (also for Odhiambo) Now remains one question: We have a (internal) Active Directory (AD) Authentication for Mailman3. So everyone who wants to work as an owner nor moderator must be an AD-User. In hyperkitty I am able to assign these list rights directly to AD-Loginnames. With the logic above I have to assign these rights in postorius too by assining the mail address of the users AD-Account? (I see no AD-Data here). Or would it works to assing the mail address of the users AD-Account first an then the allocation will automaticly synced to hyperkitty - maybe using the mail address as key? What would be the best practice for owner/moderator user management? Thank you!

1 year, 7 months

Re: Reject with notification not working

by Stephen J. Turnbull

MegaBrutal via Mailman-users writes: > I get different errors depending on whether I define > the list:user:notice:rejected template. > > When the template is not defined: > > Mar 26 01:48:02 2026 (28606) Uncaught runner exception: 'ascii' codec can't > encode character '\xed' in position 21: ordinal not in range(128) The 21st byte of the stock version of the template is interpolated from $listname. It appears to either be (Latin1) LOWERCASE LETTER I WITH ACUTE or the leading byte of a 3-byte UTF-8 character (that appears to be a private use block). The 'ascii' codec for English is a legacy misfeature. We should be able to use UTF-8 but this can have bad effects on some systems. You can try to use UTF-8 instead by adding [language.en] charset: utf-8 > And this is what happens when I define the template: How did you define the template? In the file system, or via Postorius? I'm guessing Postorius because of the "port=8000" and the "/mailman3/api/..." path, but please confirm. > Mar 26 01:35:55 2026 (28606) Uncaught runner exception: > HTTPConnectionPool(host='localhost', port=8000): Max retries exceeded with > url: /mailman3/api/templates/list/ > hirlevel.lista.autistaktol.hu/list:user:notice:rejected (Caused by > NewConnectionError('<urllib3.connection.HTTPConnection object at > 0xf46e5910>: Failed to establish a new connection: [Errno 111] Connection > refused')) I don't understand this error. The ultimate reason that Mailman core is looking for a template via HTTP at Postorius is that core and the management UI may not be able to access a common file system. So Postorius puts it somewhere, and provides a callback to core to access it. On the Postorius side that is set in settings.py, like this: POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000' Each template that is set via Postorius gets an URI starting with that scheme and authority. I think that Postorius then uses the core REST API to send that URI to Mailman core which stores it in the database. However, I don't understand why connection would be refused, unless Postorius (uswgi) is not running. > I have so many questions... > > 1. What is it about the ASCII encoding? "ordinal not in > range(128)"? What do we even do with ASCII in 2026? I tried > to send a message that only contains ASCII characters, but > the result was the same, so it's probably not in the e-mail > contents. See above. I didn't check thoroughly but I think that for modern Mailman, every language except US English uses UTF-8. > 2. I configured uwsgi to listen on 127.8.0.1:8000, practically > because I didn't want to litter the main 127.0.0.1 address > with a plethora of ports. I don't understand what you mean by "litter the address with a plethora of ports". You need to use two separate ports, one for mailman-web's Django (aka uwsgi in your case, usually 8000) and one for Mailman core's REST API (usually 8001). That's all. Not sure why that is a problem. > Why does it ever want to use localhost:8000 for anything? See above about the arm's length relation between core and Postorius in template handling. Undoubtedly somebody was incautious about properly handling configuration, and that's the default buried in the fallback configuration. File a bug (I need to run and pick up my wife at work). Cite this email in it (get the URL from the Archived-At header). > Grepping through the config files, I'm consistent about > 127.8.0.1:8000, where does it get localhost (that is 127.0.0.1) > from? You've outsmarted yourself. Try modifying or adding POSTORIUS_TEMPLATE_BASE_URL = 'http://127.8.0.1:8000' in /etc/mailman3/settings.py (or wherever your primary settings file is). No promises about getting your templates, but that should at least fix your "can't connect" problem. You may have to edit and save the template to get the core side updated, though. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

2 months, 2 weeks

Re: Mailman notify generating emails for request that aren't visible.

by Abhilash Raj

> On Nov 1, 2021, at 9:07 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 10/31/21 10:42 PM, Simon Coggins wrote: >> Looking at the code in gitlab it looks like it wasn’t merged until 1.3.6: >> https://gitlab.com/mailman/postorius/-/blob/1.3.6/src/postorius/urls.py#L53 >> But it’s not in 1.3.5: >> https://gitlab.com/mailman/postorius/-/blob/1.3.5/src/postorius/urls.py#L49 > > > Yes, I was mistaken. That code was merged on 14 Feb 2021 and is not in Postorius 1.3.4 which was released on 2 Feb. It should have been in 1.3.5 and I don't know why it is not at https://gitlab.com/mailman/postorius/-/blob/1.3.5/src/postorius/urls.py#L49, but that is moot in any case. > 1.3.5 was a security release with no fixed included. It was branched off from 1.3.4 and only the security fix was applied. One Gitlab pro tip is when you are trying to determine which particular release a particular commit is included in, you can click on the the “…” three dots next to "parent 6096958a master” just under the title and it will show all the tags and branches that this commit is included in. https://gitlab.com/mailman/postorius/-/commit/0aba874cae15b1baae2839dca57d3… for example, is included in 1.3.6b1, 1.3.6 and jquery and master branch. -- thanks, Abhilash Raj (maxking)

4 years, 7 months

Re: Subscription requires confirmation when list is set as Open

by Joachim Schrod

Mark Sapiro writes: > > > I maintain a mailing list for a private holiday where people don't > > subscribe themselves; I subscribe them. I have vetted their email > > address beforehand. (The subscribers are mostly not able to handle a > > verification email, nor any email-based workflow at all.) Is there a > > configuration option for a mailing list that sets "Pre Verified" to > > true as a default? > > > This is https://gitlab.com/mailman/postorius/-/issues/563 it was fixed > by https://gitlab.com/mailman/postorius/-/merge_requests/930 which was > later extended by > https://gitlab.com/mailman/postorius/-/merge_requests/945 however these > are not available until Postorius 1.3.14 which is not yet released. > > These add a setting, POSTORIUS_DEFAULTS, which can be used to set these > defaults. E.g., setting > > POSTORIUS_DEFAULTS = {'mass_subscription_pre_verify': True} > > will set the default for Pre Verified to True. So far, the only defaults > that can be set in this manner are mass_subscription_pre_confirm, > mass_subscription_pre_approve, mass_subscription_pre_verify and > mass_subscription_invite and those not until Postorius 1.3.14, but more > may be added. Thanks a lot for this info -- I'm looking forward for an upcoming Postorius 1.3.14 release! ;-) :-) Happy holidays and a good new year to everyone, Joachim

1 year, 5 months

Re: hello， Discussion on how to subscribe to themailing list

by 朱超

Thanks for you apply. At 2023-01-18 02:50:09, "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote: >朱超 writes: > > > 1. It is not the MTA that refuses to send emails because the > > recipient's mailbox is too long, but the MUA that refuses to > > send the email because the recipient's mailbox is too long. > >That's still non-conforming to RFC 821, published in 1982. Seriously, >those mail clients are garbage and I have no sympathy for their users. >We're certainly willing to make some changes to Mailman to make things >a little easier for mailing list owners who have to deal with such >users, but there's no excuse for using those MUAs in 2023. > > > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token, > > but he reported 404. > >If you mean that literally, of course it did. example.com, and its >siblings in the org, net, and edu domains, as well as all subdomains, >are domains reserved for examples in documentation. They all resolve >to the same IP (owned by IANA), which simply provides a web page >explaining what those domains are for. There's no Mailman there. :-) > >For that to get a response from Postorius, at minimum you need to >substitute your Mailman web host for "www.example.com", and the list's >ID (usually the same as the posting address with "." substituted for >the "@") for $list_id. You may also need to change the URL path, >depending on the top-level urls.py you use for Postorius. Yes, I know why 404 is reported，The url should be postorius not be mailman3, https://www.example.com/postorius/lists/$list_id/confirm/?token=$token, and it report success. I am curious why there is no similar processing logic for unsubscribing in postorius。Can we optimize for this？ > > 2. It is recommended to modify postorius, in order to keep the > > logic function of the underlying mailman-core unchanged, > >More important than the detailed functions of mailman-core are the >original requirements and design. Core should handle email (both in >and out), and Postorius should handle web requests. It's asking for >trouble to have core send mail to confirm subscription requests by >mail, and Postorius to send mail to confirm subscription requests by >web. Among other things it violates "Don't Repeat Yourself": if we >(or you) change the confirmation template in core, we (or you) need to >also change the confirmation template in Postorius. But it's very >easy to forget, and an annoyance for reviewers to check. > >It's possible that the other core devs will overrule me on this, but >you shouldn't hold your breath waiting for that. I've been very good >at channeling the consensus of the devs for around 20 years now. :-) > If you use mailman-web (include postorius and django-mailman3 and django-allauth and so on) to set the template information, the template obtained by mailman-core is obtained by requesting mailman-web, so mailman-web saves the template information and can be used by postorius Used to process subscription information, which will not violate the principle of repeating yourself, For other scenarios, it may be a bit troublesome, but at present, I can use the template confirmation information to help me solve my difficulties. What we do is to make the mailman community better and better。 Thanks >Steve >_______________________________________________ >Mailman-users mailing list -- mailman-users(a)mailman3.org >To unsubscribe send an email to mailman-users-leave(a)mailman3.org >https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > >This message sent to tom_toworld(a)163.com

3 years, 4 months

Re: Mailman 3 Status Update Please?

by Simon Hanna

>> 2) updated for Python 3 and the latest P3 compatible Django utilities for >> archiving and email list collection, along with any new appropriate features? > That's a great question for the Postorius and HyperKitty folks. Core is > Python 3 already (and only), while P and HK should support both on Django. > mailmanclient is and will remain bilingual. Correction: Neither Postorius nor Hyperkitty currently support Python 3. The only thing blocking Postorius is django-mailman3. (I have a mr for the changes needed to the Postorius' code) I'm not sure about the status of hyperkitty.

9 years, 4 months

Re: Editing "automatic responses" tab i Postorius does not work

by Mark Sapiro

Mark Sapiro wrote: > > I'm sorry for totally missing your point in my prior reply. I now > understand. The page should not require entries in those fields. This is > now reported at <https://gitlab.com/mailman/postorius/issues/186>;, and > we will fix it. https://gitlab.com/mailman/postorius/issues/186 is fixed in the latest release. Unfortunately, there is now https://gitlab.com/mailman/postorius/issues/190 . I think that's an easy fix, but I won't have time to work on it for a few days (someone else may grab it in the mean time).

9 years

Mailman-users search results for query "Postorius"