Search results for "Postorius" - Mailman-users

Urgent help needed...

by Darren Smith

Hello, This morning our Mailman 3/Hyperkitty/Postorius installation has become unresponsive. When looking at the machine, postgres is pegging all 4 CPUs on the machine. We did some digging in postgres, and here is the query that is causing problems: "SELECT hyperkitty_email.date FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id = 'fooey(a)rootsweb.com' ORDER BY hyperkitty_email.date ASC LIMIT 1;" We have found that it doesn't matter what mailinglist_id is being used. We have also found that this might be an issue with the LIMIT 1 - our investigation is showing that using LIMIT 1 in postgres makes things execute very differently than if you use a limit 2 or more, and that this is probably what is going on. Basically, every time this gets called, it pegs an entire CPU for 20-30 seconds. It appears to be called a LOT. So our users are getting 504 gateway timeouts right now. What has changed: We have been in the process of importing our 40 million archived emails from our old mailman 2 archives. Questions: 1) We have tried doing a grep in the codebase - mailman3, hyperkitty, postorius, django - basically anything that might be calling this code, but we can't find it. Does anyone know what generates this query? 2) We are positing that it might be our archive imports that are causing this problem. Does anyone know of any sort of limit/threshold that might cause this to go haywire? Any help you can give, any direction you can point us would be useful. Right now our lists are just down for our users. Thank you, Darren

8 years, 5 months

Re: Pre-approved howto

by Mark Sapiro

On 7/5/18 6:14 AM, thor.rustad(a)gmail.com wrote: > I have tried to understand the concept of pre-approved messages, but I'm spending way too much trying to figure it out. Help! There is a list attribute, moderator_password, which is not currently exposed in Postorius and therefore must be set via 'mailman shell'. Here's a sample session. > $ mailman shell -l junk(a)msapiro.net > Welcome to the GNU Mailman shell > The variable 'm' is the junk(a)msapiro.net mailing list >>>> m.moderator_password >>>> from mailman.config import config >>>> m.moderator_password = config.password_context.encrypt('xxx123').encode('us-ascii') >>>> m.moderator_password > b'$6$rounds=656000$SKMqTlPybIZSBjYB$wCga5qALCv8oobp4cDql2iKEg8T6qIgk8XEKYbkk9QXENeFQDHZ1M4AtmqfureYQDB5g.Az.nZPrWAr9N9g1N0' >>>> commit() That will set the list's moderator_password to the encrypted value of 'xxx123'. Then, if a post to the list contains Approved: xxx123 either as a header in the message (recommended if possible) or as the first non-blank line in the first text/plain part of the message, the post will be 'pre-approved'. The header can actually be any of Approve:, Approved:, X-Approve: or X-Approved: and if it is not a header, but is found in the first text/plain part of the message, it will be removed from that part and a best effort will be made to remove it from other text/* body parts in case it is also in an alternative part. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 4 months

Re: Member Issue Discovered

by Mark Sapiro

On 10/20/20 6:54 AM, Brian Carpenter wrote: > > On 10/19/20 11:32 PM, Mark Sapiro wrote: >> >> Mailman 3 is totally different from Mailman 2.1 in this respect. Mailman >> 2.1 had no concept of user. All it knew was addresses subscribed to >> lists and an address subscribed to one list had no connection to the >> same address subscribed to another list or being an owner or moderator >> of a list. > > I think this should still be the case for non-registered list members. > List owners/moderators are different. They HAVE to be registered users > of Postorius/Affinity in order to manage/moderate a list. Here's a thought. For Affinity/Empathy at least, how about using Mailman core's user as the Affinity registered user. I.e., if someone's first interaction is to register with Affinity, have that registration create a core user to keep the Affinity registration data. This core user already accommodates a display_name and password and email address(es). If the person already is a core user when registering for Affinity, just update the core user as needed, probably only a password reset or just setting it if it is currently None. Then you don't have the issue of another, separate registration for Affinity. This would be more difficult for Postorius/Hyperkitty because those users are Django users, but that isn't an issue for Affinity. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

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

by Simon Coggins

Thats part of the issue. It looks like these are in the PendingsDB but not showing up in the UI. Even if I go into Subscription Requests -> Pending Approvals or Pending Confirmations no pending items are shown at all. But in the pendingDB via mailman shell I can see 3 pending unsubscriptions. -Simon --- [https://www.cqu.edu.au/] Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins(a)cqu.edu.au<mailto:s.coggins@cqu.edu.au> [https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939 On 1 Nov 2021, at 12:26 pm, Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>> wrote: On 10/31/21 7:15 PM, Simon Coggins wrote: The version of postorius is 1.3.4 Then you should be able to click Subscription requests even though the badge shows 0 and click Unsubscription Requests in the dropdown. I know it's an issue, but the badge only counts subscription requests pending approval and not unsubscription requests. -- Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

Re: Verification emails 'helo' rejected

by Greg Newby

Thanks for this, Odhiambo. Unfortunately it doesn't address my situation. See below: On Tue, Oct 15, 2024 at 3:21 AM Odhiambo Washington <odhiambo(a)gmail.com> wrote: > > > On Mon, Oct 14, 2024 at 10:43 PM Greg Newby via Mailman-users < > mailman-users(a)mailman3.org> wrote: > >> Hi friends. >> >> I'm now getting a 500 server error upon signing up a new username on the >> web-based front end. The username is created in the back end, but the >> verification email does not get sent. >> >> This is GNU Mailman 3.3.9 (Tom Sawyer), venv, Ubuntu 24.04LTS, PostgreSQL, >> Postfix >> >> Here are the corresponding logfile entries from mailmanweb.log: >> smtplib.SMTPRecipientsRefused: {'redacted(a)gmail.com': (504, b'5.5.2 >> <mail>: >> Helo command rejected: need fully-qualified hostname')} >> >> and from mail.log: >> Oct 14 12:06:26 domain postfix/smtpd[722764]: NOQUEUE: reject: RCPT from >> localhost[127.0.0.1]: 504 5.5.2 <mail>: Helo command rejected: need >> fully-qualified hostname; from=<root(a)lists.domain.tld> to=<root@localhost >> > >> proto=ESMTP helo=<mail> >> > ^^^^ Note the problem isn't the "From:" address. That is being correctly configured from mailman-web.py and settings.py via the variables below. The problem is it's going "To:" root@localhost. I don't know why this is happening - shouldn't it be going to redacted(a)gmail.com? Also, based on settings below shouldn't this be From: postorius(a)lists.domain.tld not From: root(a)lists.domain.tld? More: > >> lists.domain.tld is the domain for Mailman3. I don't know why it's trying >> to send email from root@. >> >> I've seen places where 'localhost' appears in the Mailman settings >> (settings.py, mailman.cfg, mailman-web.py), and tried changing them to the >> host's FQDN and restarting mailman3 and mailman3-web, but the problem >> persists. >> > > Find and fix these values to what they should be as explained. > > # The sender of emails from Django such as address confirmation requests. > # Set this to a valid email address. > DEFAULT_FROM_EMAIL = 'johndoe(a)domain.name' > > # The sender of error messages from Django. Set this to a valid email > # address. > SERVER_EMAIL = 'johndoe(a)domain.name' > > I use listmaster(a)lists.domain.name in my servers. > In the default files via the venv installation, these were already set properly: EMAILNAME='lists.domain.tld' <-- I set this myself These were default in settings.py and mailman-web.py: DEFAULT_FROM_EMAIL = 'postorius@{}'.format(EMAILNAME) SERVER_EMAIL = 'root@{}'.format(EMAILNAME) I set them explicitly to postorius(a)lists.domain.tld and root(a)lists.domain.tld and restarted mailman and mailman web, and this did not change the problem with the server error and mail log entries above. > I am not sure what files on your server contains them in your server. > > And while at it, also fix the site_owner: email in mailman.cfg. > That was already set to my email address, and I do correctly get site emails, such as cron output. Further guidance would be appreciated. ~ Greg

2 years

mailman3-web postorious error "invalid request block size: 14056 (max 4096)...skip"

by Frederik

Until about one month ago, I had mailman3 and mailman3-web successfully running on Debian 12. However, when I access any page such as https://example.com/mailman3/postorius/lists/ now, I just get a 500 server error. /var/log/mailman3/web/mailman-web.log logs this at every request: invalid request block size: 14056 (max 4096)...skip I read somewhere that adding buffer-size = 65536 to uwsgi.ini might help. It indeed makes a difference, but unfortunately I just get another error instead: [pid: 4067215|app: -1|req: -1/1] () {256 vars in 14055 bytes} [Tue Jan 28 18:06:30 2025] => generated 0 bytes in 0 msecs ( 500) 0 headers in 0 bytes (1 switches on core 0) There are no other errors in the logs. I proxy mailman in Apache like this: Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico Alias /mailman3/static /var/lib/mailman3/web/static <Directory "/var/lib/mailman3/web/static"> Require all granted </Directory> <IfModule mod_proxy_uwsgi.c> ProxyPass /mailman3/favicon.ico ! ProxyPass /mailman3/static ! ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost-mailman3/ </IfModule> and mailman3's uwsgi.ini looks like this: [uwsgi] uwsgi-socket = /run/mailman3-web/uwsgi.sock enable-threads = true chdir = /usr/share/mailman3-web wsgi-file = wsgi.py master = true process = 2 threads = 2 uid = www-data gid = www-data env = HOME=/tmp plugins = python3 attach-daemon = python3 manage.py qcluster logto = /var/log/mailman3/web/mailman-web.log buffer-size = 65536 Any idea what could be wrong or how to debug this further? I'm using mailman3-full 3.3.8-2~deb12u2 and mailman3-web 0+20240312-1 packages.

1 year, 9 months

Re: Manage Member(s) Mailman Settings / Display Names

by Jim Ward

I will admit I was partial to the MM 2.1 columns and checkboxes but the end result is the same, HOWEVER: 1) The member 'Display Name' does not seem to be available to be managed by me the domain/list administrator. 2) The 'Search Members' function appears to be limited to the email address only and does not include display name These items are important to me as the list I am running includes many that are not, nor will they really ever be, technically savvy enough to access and manage their own account. ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Friday, January 10, 2020 7:05 PM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Manage Member(s) Mailman Settings / Display Names On 1/10/20 4:55 PM, Jim Ward wrote: > Mailman2 allowed me to list my members and modify a number of their attributes (display_name, etc) > > Postorius is a beautiful interface BUT I am evidently not finding how to manage my members to the extent that I could in Mailman2 It's not like MM 2.1 where you have a membership list with columns of checkboxes, but if you pull down the Users menu and select Members or Non-Members, each user has an options link that allows you to set/change options. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…

6 years, 9 months

Re: EMWD/Affinity/Empathy in 2023

by Mark Sapiro

On 1/16/23 07:58, jaboyib556--- via Mailman-users wrote: > > However, I saw reports of EMWD being a one-man show and the owner sadly passing away in 2021; but I've also seen threads here referring to the Affinity and Empathy projects in 2022. It wasn't clear to me if EMWD is still an active business and Affinity and Empathy are still active offerings. Does anyone here have any direct contact/relationship/experience with EMWD/Affinity/Empathy following the owner's passing? Or knowledge of any other offerings publicly available today that are similar to Affinity/Empathy? I have had some contact, but not much. As far as I know, they are still in business and offering list hosting including Mailman 3 lists with Affinity and Empathy. They no longer offer support for installation and maintenance of Mailman on other people's servers. When we first were developing Mailman 3, we designed it in a modular fashion with a REST API for the core engine so that users who were so inclined could develop their own web UIs for archiving and list management. We also recognized that we needed to develop our own to make a complete package. Thus, we developed HyperKitty and Postorius for that, but we have always hoped that the community would develop others (hopefully open source and Python based). As far as I know, it was only EMWD that did this and for business reasons, kept it proprietary. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

Re: Email to list owner on list creation only sent when using mailman create --notify command

by Perry Kollmorgen

Ok, thanks for the information. Regards, Perry ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, 10 June 2024 2:10 PM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Email to list owner on list creation only sent when using mailman create --notify command On 6/9/24 5:26 PM, Perry Kollmorgen wrote: > Hi, > > This is only a minor issue, however as a nicety for new list owners I am hoping there is work around or something I have missed. > > I have the following file: templates/domains/<fqdn_listname/en/domain:admin:notice:new-list.txt > > When I use the mailman create command with the --notify option the new owners receives an email with the correct template info from the above file. > > However when I use mailmanclient python bindings or Postorius to create an list, there is no email sent. This is a bug. Currently only `mailman create` sends this notice, but as you note, list creation via rest should do it too. I have created https://gitlab.com/mailman/mailman/-/issues/1156 for this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ 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 pcjkollmorgen(a)hotmail.com

2 years, 5 months

Re: Ann: Mailman Core 3.3.5 is out

by Mark Sapiro

On 9/29/21 9:59 AM, Brett Delmage via Mailman-users wrote: > On Wed, 29 Sep 2021, Eggert Ehmke via Mailman-users wrote: > >> Should I upgrade my Mailman 3.3.3 installed from Debian Bullseye? I >> would have >> to bypass the Debian installer. Or will there be Debian packages >> available? >> Same question for Postorius 1.3.6 Since Mailman 3.3.4 has been out for over six months and the latest Mailman 3 in even Debian sid is still 3.3.3, I would expect a long wait before these latest releases are available in Debian/Ubuntu. > I am excited to see 3.3.5 with its many updates available. Thanks to all > the contributors. > > I would like to know this too, as I was just about to install parallel > to the Debian package(s). I expect there are many of us. > > Going forward, what is the best way to maintain a stable version of > 3.3.5 with security and defect fixes only, exluding new features? Is > picking and applying individual checkins on gitlab the only way? I would suggest abandoning the Debian packages and installing as documented at <https://docs.mailman3.org/en/latest/install/virtualenv.html>. You should be able to keep all your existing configuration files and the database. You could even keep `list` as the Mailman user if desired. Once you have done this, upgrading via pip from PyPI or even from GitLab is very simple. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Mailman-users search results for query "Postorius"