Search results for "Postorius" - Mailman-users

Re: Splitting hosts: mta&core vs postorius

by samuel.d.darwin＠gmail.com

> the fourth paragraph: "Because the REST server has full administrative access, it should never be exposed to the public internet. By default it only listens to connections on localhost. Don’t change this unless you really know what you’re doing." Let's say that you are trying to embed Hyperkitty into a larger Django project that's horizontally deployed in an autoscaling group or K8S. The mailman-core component would be better served from a fixed IP address and a single server. In order for mailman-web to communicate with mailman-core, it needs to listen on a network interface, not localhost. So, you'd like to have a config field, and listen on a reachable interface and then configure the AWS Security Groups or Firewall to limit access. The proposed "listen" field is optional, and in its absence, it defaults to the current behavior, which is localhost. This scenario matches the "really know what you’re doing" case. You'd be facilitating a more advanced architecture, although not requiring it, and still default to localhost. However, again I say "theoretical", because we ran into other difficulties with embedding Hyperkitty in a larger Django project. It seems easier to break that into a bite sized pieces, and only address them one at a time.

2 years, 2 months

Re: Core, Hyperkitty and Postorius releases

by Odhiambo Washington

On Fri, May 14, 2021 at 2:52 PM Jeff Steele <jeff(a)steele.com> wrote: > > > On May 14, 2021, at 7:49 AM, Odhiambo Washington <odhiambo(a)gmail.com> > wrote: > > /bin/sh: sass: Permission denied* > > > > Did you check the permissions on your sass binary? > My mailman installed in /opt/mailman/mm find /opt/mailman/ -type f -name sass yielded nothing! pip3 install sass generated so many errors then ended with: ERROR: Command errored out with exit status 1: /opt/mailman/mm/venv/bin/python -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-cltizg93/sass_9783b9d070744303b5c04271674abc23/setup.py'"'"'; __file__='"'"'/tmp/pip-install-cltizg93/sass_9783b9d070744303b5c04271674abc23/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-1g2omozl/install-record.txt --single-version-externally-managed --compile --install-headers /opt/mailman/mm/venv/include/site/python3.7/sass Check the logs for full command output. I will have to blow away mailman and start afresh. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v "^$|^.*#" :-)

4 years, 10 months

Re: Postorius fails to show list because of a large message being held

by Gilles Filippini

Hi, Brian Carpenter a écrit le 14/07/2020 à 12:54 : > On 7/14/20 6:49 AM, Gilles Filippini wrote: >> Mailman Core logs: >> [2020-07-14 10:41:21 +0000] [36] [CRITICAL] WORKER TIMEOUT (pid:49) >> [2020-07-14 10:41:21 +0000] [49] [INFO] Worker exiting (pid: 49) >> [2020-07-14 10:41:22 +0000] [50] [INFO] Booting worker with pid: 50 > > I am pretty sure that timeout is related to gunicorn. If it is, then > increasing the worker out timeout setting for gunicorn should work. You > tend to get such errors when doing an export of a large membership > roster. This is the first time I have seen it related to a held message. > > I have this in my setup: > > mailman.cfg: > > [webservice] > configuration: /opt/mailman/mm/gunicorn.cfg > > gunicorn.cfg: > > [gunicorn] > workers = 4 > timeout = 900 > > You will need to restart gunicorn after adjusting the timeout setting. Sorry for the late answer, I was afk the last 24 hours. I can confirm that this solution works. Thanks a lot! And thanks to Mark for the added details. But it sounds weird that printing out the number of held messages could timeout because of these messages' size. Best, _g.

5 years, 8 months

Re: Timeout error on anonymous subscribe

by Mark Sapiro

On 10/14/24 06:13, Gerald Vogt wrote: > Hi, > > sorry to bother, but does anyone have an idea why this doesn't work? I > am on mailman 3.3.10 by now but still not difference. I wonder why > nobody else has the same problem. I didn't think my setup would be so > special... > > Thanks, > > Gerald > > vogt＠spamcop.net wrote: >> >> Hi, >> >> I am running a mailman 3.3.9 server (pip installation). It's working >> fine so far. However, I have problems setting a template. I set a >> '[list:user:action:subscribe]' template for a list with some simple >> text like "test1234". How are you creating the template? If you are creating it via Postorius, what is your setting for POSTORIUS_TEMPLATE_BASE_URL and what does the entry in the template table in the database look like? POSTORIUS_TEMPLATE_BASE_URL should be the same URL you use to access Postorius up to but not including the `/postorius/` or `/mailman3/` part. I.e, for this list whose info page is at https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/, the setting is ``` POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org' ``` -- 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: Postorius no connection to REST API

by Mark Sapiro

On 8/13/21 7:18 AM, Richard Rosner wrote: > > I set them all to https. which solved the https error. But I still get Error 500. >>From apache log: > [Fri Aug 13 15:47:58.833305 2021] [mpm_event:notice] [pid 26720:tid 139986206332032] AH00489: Apache/2.4.48 (Debian) OpenSSL/1.1.1d mod_wsgi/4.6.5 \ > Python/3.7 configured -- resuming normal operations > [Fri Aug 13 15:47:58.833436 2021] [core:notice] [pid 26720:tid 139986206332032] AH00094: Command line: '/usr/sbin/apache2' > [Fri Aug 13 15:49:41.673108 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.\ > rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] > [Fri Aug 13 15:49:41.905868 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12\ > 7.0.0.1) > [Fri Aug 13 15:59:25.049708 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.\ > rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] > [Fri Aug 13 15:59:25.059217 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12\ > 7.0.0.1) You need SSLProxyEngine on and possibly one or more of the SSLProxyMachineCertificate* directives in your apache config to proxy via https. See <https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertifica…> et seq. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

lmtp runner not starting

by Guillermo Hernandez (Oldno7)

This morning I upgraded the mailman3 installation of the less traffic server I have: a bunch of lists, with very slow traffic. (see pip lists at the end) I sent test mails to a pair of lists, but none were distributed or archived. postorius seemed working well. First I thought it was some I did wrong in the upgrade procedure, but then I realized the lmtp runner was not running. I followed old messages about similar problem (many of them in this same mailman-users list), but I cannot see what is wrong. There is no error logged in mailman.log. the mailman.cfg of the lmtp is the default (and was working at least a pair of weeks ago) *-*-*-*-*-*-*-*-* from mailman.cfg [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: 127.0.0.1 lmtp_port: 8024 smtp_host: localhost smtp_port: 25 configuration: python:mailman.config.postfix *-*-*-*-*-*-*-*-* There is no one listening in port 8024. I tried changing the port (to 9024), with the same results. postfix seems working well. I's just there is nothing listening on port 8024 because lmtp runner is not running :) (from maillog): connect to 127.0.0.1[127.0.0.1]:8024: Connection refused (another simple test) root@www:/usr/local/mailman3 # telnet localhost 8024 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused I'm running out of ideas. Any clue to somewhere to dig in? *-*-*-*-*-*-*-*-*-*-* runners started Apr 01 17:24:40 2023 (4681) out runner started. Apr 01 17:24:40 2023 (4680) virgin runner started. Apr 01 17:24:41 2023 (4679) command runner started. Apr 01 17:24:42 2023 (4688) retry runner started. Apr 01 17:24:43 2023 (4686) in runner started. Apr 01 17:24:44 2023 (4683) digest runner started. Apr 01 17:24:44 2023 (4684) nntp runner started. Apr 01 17:24:45 2023 (4682) archive runner started. Apr 01 17:24:46 2023 (4685) bounces runner started. Apr 01 17:24:47 2023 (4687) task runner started. Apr 01 17:24:47 2023 (4687) Task runner evicted 0 expired pendings Apr 01 17:24:47 2023 (4687) Task runner deleted 0 orphaned workflows Apr 01 17:24:47 2023 (4687) Task runner deleted 0 orphaned requests Apr 01 17:24:47 2023 (4687) Task runner deleted 0 orphaned messages Apr 01 17:24:47 2023 (4687) Task runner evicted expired cache entries Apr 01 17:24:48 2023 (4678) pipeline runner started. Apr 01 18:24:48 2023 (4687) Task runner evicted 0 expired pendings Apr 01 18:24:48 2023 (4687) Task runner deleted 0 orphaned workflows Apr 01 18:24:48 2023 (4687) Task runner deleted 0 orphaned requests Apr 01 18:24:48 2023 (4687) Task runner deleted 0 orphaned messages Apr 01 18:24:48 2023 (4687) Task runner evicted expired cache entries *-*-*-*-*-*-*-*-*-* pip lists with versions installed root@www:/usr/local/mailman3 # pip list | grep mailman django-mailman3 1.3.9 mailman 3.3.8 mailman-hyperkitty 1.2.1 mailmanclient 3.3.5 root@www:/usr/local/mailman3 # pip list | grep django django-allauth 0.51.0 django-appconf 1.0.5 django-compressor 4.0 django-extensions 3.2.0 django-gravatar2 1.4.4 django-haystack 3.2.1 django-mailman3 1.3.9 django-picklefield 3.1 django-q 1.3.9 djangorestframework 3.13.1 root@www:/usr/local/mailman3 # pip list | grep postorius postorius 1.3.8 -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

2 years, 11 months

Re: The email confirming the registration of an account on postorius is not correctly translated in Italian

by Mark Sapiro

On 7/30/20 9:43 AM, Massimo Zappalà wrote: > > Everything works, except for this: > > When I register a new account on postorius, he sends me a confirmation email totally in English, except the following final block which is sent in Italian: > > in my /usr/lib/python3/dist-packages/allauth/locale/it/LC_MESSAGES/django.po > > #: templates/account/email/email_confirmation_message.txt:7 > #, python-format > msgid "" > "Thank you from %(site_name)s!\n" > "%(site_domain)s" > msgstr "" > "Grazie da %(site_name)s!\n" > "%(site_domain)s" OK. > By carefully analyzing the same file .po, I notice that the Italian translation of the whole text already exists. > Why does the confirmation email arrive in English? > > #: templates/account/email/email_confirmation_message.txt:1 > #, fuzzy, python-format This is marked fuzzy so it isn't used. If you believe the translation is correct, remove the above line (or remove ' fuzzy,' from it) and then recompile the django.mo with msgfmt. Note that the current HEAD on github <https://github.com/pennersr/django-allauth/blob/master/allauth/locale/it/LC…> has the above line as just #, python-format > #| msgid "" > #| "User %(user_display)s at %(site_name)s has given this as an email " > #| "address.\n" > #| "\n" > #| "To confirm this is correct, go to %(activate_url)s\n" > msgid "" > "Hello from %(site_name)s!\n" > "\n" > "You're receiving this e-mail because user %(user_display)s has given yours " > "as an e-mail address to connect their account.\n" > "\n" > "To confirm this is correct, go to %(activate_url)s\n" > msgstr "" > "Ciao da %(site_name)s!\n" > "\n" > "L'Utente %(user_display)s di %(site_name)s ha registrato questo indirizzo e-" > "mail.\n" > "Per confermare, clicca qui %(activate_url)s\n" -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

Re: mailman3 postorius cannot retrieve template

by Andreas Barth

* Quanah Gibson-Mount (quanah(a)symas.com) [211104 22:59]: > > > --On Thursday, November 4, 2021 8:25 AM -0700 Mark Sapiro > <mark(a)msapiro.net> wrote: > > >On 11/4/21 5:04 AM, Wolfgang Bock via Mailman-users wrote: > >> > >>My conclusion: > >>I ask you to consider these experiences in an update for the mailman3 > >>packages in debian bullseye. It would save time, questions and nerves. > > > > > >Issues with Debian packaging should be directed to Debian. > > Or as previously discussed, the debian packages should be avoided entirely. I strongly disagree with that statement. Distribution packages have their own up- and downsides. Of course, how they are done is to be discussed with the distribution, so: if something is wrong with a debian package, please follow the instructions on bugs.debian.org on reporting bugs. However, they have the advantage that they're integrated with the distribution. They have the disadvantage that they're stable for some time - that is why it's called a stable release. If they have all the features someone wants, they usually work fine (and my first mm3-installation was the default debian package). If one looks for bleeding edge, of course that's not what one can expect from a distribution package - but that's also a feature. Andi

4 years, 4 months

Re: Accept these non-members

by Mark Sapiro

On 3/8/26 09:53, Lars Bjørndal wrote: > > All addresses, both addresses that I know has sent messages to the list and others, are marked as MemberRole.nonmember> Action.defer > > When I view non-members in postorius, I get some differences: > > Some ar marked: Regular List default, and others Regular Default processing. The `mailman shell` interaction prints the internal name of the action. In this case Action.defer Postorius displays that action ac Default processing >>> What's the difference between Action.accept and Action.defer? >> >> >> Action.accept accepts the message immediately with no further checks. >> Action.defer passes the membership checks but still goes on to check other >> things like >> >> mis-addressed email commands >> messages with implicit destination >> messages with too many explicit recipients >> messages that are bigger than a specified maximum >> messages with no, or empty, Subject headers >> messages with digest Subject or boilerplate quote >> messages matching a bounce_matching_header line > > Hm, this is a mystery to me. Is there othere places I can search for addresses that are aloud to send to the list? No. Your nonmembers that can post have moderation_action = Action.defer. That allows their post to pass membership tests but still continues to check other things like the above that can result in the message being held. On the other hand, Action.accept will accept the message without additional checks. As the Postorius help says Accept -- accepts any postings without any further checks. Default Processing -- run additional checks and accept the message. To give a concrete example if the list's configured Maximum message size is 40 Kb, and a nonmember whose moderation_action = Action.defer posts a 50 Kb message to the list, the message will be held for moderation because it's too big, but if a nonmember whose moderation_action = Action.accept posts a 50 Kb message to the list, the message will be accepted without being held for moderation. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 week, 3 days

Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Ulf R.

Hello, I know this should be the way to upgrade: https://docs.mailman3.org/en/latest/upgrade-guide.html I have 3.3.10 installed. I saw that some python packages are outdated an tried this which install all outdated packages in a row: pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install -U One outdated package was django and this part happened: ------------------------------- vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) Installing collected packages: Django Attempting uninstall: Django Found existing installation: Django 4.2.16 Uninstalling Django-4.2.16: Successfully uninstalled Django-4.2.16 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 which is incompatible. postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. Successfully installed Django-5.1.4 ------------------------------- So I made a roll back. Is this really the only secure way to update the venv?: pip install -U mailman postorius django-mailman3 hyperkitty mailman-web May be yes and I have to ignore the rest? ;-) Thank you und regards

1 year, 3 months

Mailman-users search results for query "Postorius"