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.

5 years, 10 months

long time user of mailman 2, new to docker-mailman and docker

by pjbondi＠systemdatabase.com

Hello to all: I'm getting this stack trace with the following redacted settings. # ALLOWED_HOSTS * # DEBUG True # HYPERKITTY_API_KEY llllllllllllllllllllllllllllllllllllllllllllllllll # MAILMAN_ADMIN_EMAIL xxxxxxx(a)yyyyyyyyyyyyyy.com # MAILMAN_HOSTNAME mailman-web # MM_HOSTNAME yyyyyyyyyyyyyy.ca # MTA postfix # SECRET_KEY kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk # SERVE_FROM_DOMAIN yyyyyyyyyyyyyy.ca # SMTP_HOST smtp-relay.sendinblue.com # SMTP_HOST_PASSWORD pppppppppppppppp # SMTP_HOST_USER xxxxxxx(a)yyyyyyyyyyyyyy.com # SMTP_PORT 587 # SMTP_USE_TLS True # [very long startup snipped] Applying postorius.0001_initial... OK Applying postorius.0002_auto_20160210_0721... OK Applying postorius.0003_drop_addressconfirmationprofile... OK Applying postorius.0004_create_email_template... OK Applying postorius.0005_auto_20180707_1107... OK Applying postorius.0006_auto_20180711_1359... OK Applying postorius.0007_auto_20180712_0536... OK Applying postorius.0008_auto_20190310_0717... OK Applying postorius.0009_auto_20190508_1604... OK Applying postorius.0010_auto_20190821_0621... OK Applying postorius.0011_auto_20191109_1219... OK Applying postorius.0012_auto_20200420_2136... OK Applying postorius.0013_auto_20201116_0058... OK Applying sessions.0001_initial... OK Applying sites.0002_alter_domain_unique... OK Setting systemdatabase.ca as the default domain ... Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3.8/site-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: no such table: django_site The above exception was the direct cause of the following exception: Traceback (most recent call last): File "manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/usr/lib/python3.8/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/usr/lib/python3.8/site-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python3.8/site-packages/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python3.8/site-packages/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/usr/lib/python3.8/site-packages/django/core/management/commands/shell.py", line 86, in handle exec(options['command']) File "<string>", line 1, in <module> File "/usr/lib/python3.8/site-packages/django/db/models/query.py", line 741, in update rows = query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3.8/site-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3.8/site-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3.8/site-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3.8/site-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3.8/site-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3.8/site-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: no such table: django_site

2 years, 2 months

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

1 year, 4 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>

3 years, 9 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!

5 months, 1 week

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)

3 years, 5 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

4 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

2 years, 3 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.

8 years, 2 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).

7 years, 10 months

Mailman-users search results for query "Postorius"