Search results for "Postorius" - Mailman-users

Re: Upgrade-path from Ubuntu18LTS to recent mailman release

by Stefan Bauer

Thank you all for your time. I managed to do a fresh installation. The MM documentation is very good. As i only use sqlite, i will give it a try to just copy the database files. Stefan Am Do., 5. Mai 2022 um 11:11 Uhr schrieb Stephen J. Turnbull < stephenjturnbull(a)gmail.com>: > Stefan Bauer writes: > > > thanks alot. That looks promising. Can we just copy the current > > mailman3-database and take the configurations or is there a specific > > migration path we have to follow? > > Much of the documentation on mailman.readthedocs.io discusses > migrations and upgrades. You should read those for general hints. > > The distro Mailman to venv Mailman case is more discussed here on the > mailing list than in those documents. I don't have pointers to those > threads or the time to look offhand, maybe over the next few weeks as > I work on our GSoC project. If you do find any, and would post them > here, I'll make sure they get into the docs. > > The main thing is to backup Mailman configs (probably in /etc/mailman > or /etc/mailman3) and the backend database (core, Postorius, possibly > HyperKitty depending on configuration, and the django-mailman auth > stuff) before trying to migrate. (For the backend database I would > just dump the RDBMS unless non-Mailman content is really huge.) The > nature of the virtualenv install is such that it *will not* overwrite > any of the distro files at all (as long as you put it in /usr/local or > /opt). However, you want to preserve the configs and database and > reuse them, so those *must* be backed up. > > > We are currently running 3.1.1-9 (Ubuntu 18). > > Ubuntu 18 is probably old enough that you need to be careful about > MySQL and its derivatives. The specific problems are (1) you need to > specify the right UTF-8 variant for the coding system, and (2) more > recent versions of Mailman tend to make certain records overflow. > > If you're using PostgreSQL these caveats *do not* apply. If you're > using sqlite3 (I doubt it, but just for completeness) you should > change to PostgreSQL or MySQL. If you're using something else (same > caveat), I can't really say. Probably somebody out there is using > Oracle or whatever, but we don't know about that. :-) > > Steve > >

4 years, 5 months

Re: Handling of SPAM mails in mailman3 - Check for X-Spam Header

by Torge Riedel

Am 18.01.20 um 19:38 schrieb Mark Sapiro: > On 1/18/20 6:58 AM, Torge Riedel wrote: >> Am 16.01.20 um 21:43 schrieb Mark Sapiro: >>> This won't work for posts from members because the header checks are >>> done between member moderation checks and non-member moderation checks, >>> but if you create a Header Filter for header 'x-spam' and pattern 'yes' >>> with action hold, a message from a non-member which has an X-Spam: Yes >>> header should be held for that reason. >>> >>> >> Hi Mark, >> >> thank you for your answer. Just to understand that right: In case a >> posting with an "X-Spam: Yes" header comes from a member, it will not be >> held? It will be directly forwarded to the list? > No. I apologize for being unclear. > > A post from a member will first be handled according to that member's > moderation action which may be the list's default action for posts from > members or a specific action for that member. > > If that moderation action is reject, discard or hold, the post will be > rejected, discarded or held as a moderated member post regardless of any > header filters. > > If the action is accept, the post will be accepted without any further > checks including the header checks. > > If the action is defer (default processing) the message will be held for > matching the X-Spam: Yes header. > > What I meant was if the member's (or default) action was hold, the post > would be held, but the reason would be moderated member, not header match. > > The bottom line here is the moderation action of accept should only be > used in cases of a highly trusted member (such as a list owner) because > it bypasses other checks, but the address is still subject to spoofing. > In the normal case where a moderation hold is not desired, use the defer > (default processing) action. > Hi Mark, thanks for clarification. I will add a header filter. One final question: When adding a new header filter I can select between different actions. And there is one named "Default Anti-Spam action" (roughly translated from German). I cannot find anything else about this somewhere else in the settings (Postorius). So what it is the "Default Anti-Spam action"? Best regards Torge

6 years, 9 months

Re: problem configuring mailman3 on debian bullseye

by Servizio Informatico U.I.C.I. Sezione territoriale di Brescia

Hi, I created a template but after some tests I deleted it. Now I created only a standard list without modifying any templates. So they are the standard templates coming with the distribution. I did not change also the language Roberto Burceni Servizio informatico sezionale Tel. 0302209417 (lunedì e giovedì mattina dalle 9:00 alle 13:00, martedì emercoledì pomeriggio dalle 14:00 alle 18:00 E-mail: servizioinformatico(a)uicibrescia.it Sito web:https://www.uicibrescia.it Il 15/03/23 16:30, Odhiambo Washington ha scritto: > > > On Wed, Mar 15, 2023 at 6:21 PM Servizio Informatico U.I.C.I. Sezione > territoriale di Brescia <servizioinformatico(a)uicibrescia.it> wrote: > > Hello all, > > I'm a blind server administrator living in Italy. I use mailman since > 2010 and I was very happy for this list manager. > > When was released the version 3 I started to have many problems to > configure it. > > In this days I installed a new server for my association and I > have this > problem that I don't know to solve. > > The server is a debian bullseye. > > I installed mailman3-full from the standard packege. > > I'm using nginx as web server. > > I configured mailman3 and mailman3-web wit https support. > > All is working fine, but if I attempt to subscribe someone it does > not > work. > > I send a subscription e-mail to the address list and I receive > correctly > the request to confirm subscription. When I reply to the request > mailman > log gives this error: > > requests.exceptions.SSLError: HTTPSConnectionPool(host='localhost', > port=443): Max retries exceeded with url: > /postorius/api/templates/list/listname.domain/list:user:notice:welcome > > (Caused by SSLError(SSLCertVerificationError("hostname 'localhost' > doesn't match either of 'example.com <http://example.com>', > 'www.example.com <http://www.example.com>'"))) > > The strange thing is that I configured a domain list.example.com > <http://list.example.com> and in > the configuration files I put this domain. > > Mailman3-web works fine I can create lists and make settings. > > Have you an idea about this issue? > > > Assuming that you created this template - list:user:notice:welcome - > what are its contents? > > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 7 months

Re: Archive Policy not reflecting in Hyperkitty

by Nathan Dixon

I'm not sure if it's also related, but within the mailman-web and mailman-core docker containers, crontab -e only shows these entries: # do daily/weekly/monthly maintenance # min hour day month weekday command */15 * * * * run-parts /etc/periodic/15min 0 * * * * run-parts /etc/periodic/hourly 0 2 * * * run-parts /etc/periodic/daily 0 3 * * 6 run-parts /etc/periodic/weekly 0 5 1 * * run-parts /etc/periodic/monthly And all of those folders are empty. I'm not sure where the synchronisation task for Hyperkitty should actually being run from? Thank you On Tue, 7 May 2019 at 10:20, Nathan Dixon <nathan.dixon(a)evadon.com> wrote: > The change to the archiving policy aren't reflected in Hyperkitty after > many days for all the lists. > > The only error that I am seeing in the /web/mailmanweb.log is: > INFO 2019-05-02 14:16:55,062 38 hyperkitty.tasks AsyncTask task "<function > unlock_and_call at 0x7f5d8851f048>" with args "(<function > update_from_mailman at 0x7f5d88544a60>, 'task:status:%s:%s', '<list > address>')" and kwargs "{}" finished with errors. > > I'm not sure if that could be related? (I have changed the actual list > address to <list address> for security reasons) > > Thank you > > On Sat, 4 May 2019 at 16:24, Abhilash Raj <maxking(a)asynchronous.in> wrote: > >> On Fri, May 3, 2019, at 8:38 AM, Nathan Dixon wrote: >> > So the issue I am seeing is that when I set a lists archive policy to >> > prviate, it isn't reflecting that in Hyperkitty. >> > >> > I am running the docker installation of Mailman, postorius and >> hyperkitty. >> > So I go into the docker instance of mailman-core and run this: >> > >> > python3 manage.py shell from hyperkitty.models.mailinglist import >> > MailingList MailingList.objects.all().values_list('name', >> 'archive_policy') >> > >> > And all my lists are showing '2', regardless of how I set the mailing >> list >> > archive policy. >> > >> > This might be a duplicate of >> > >> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… >> > >> > Am I missing something in my install? Or is this a bug? >> >> It can take upto an hour for this change to reflect in Hyperkitty. Did >> you wait >> for that long? >> >> This happens because Hyperkitty stores it's own data, and queries Mailman >> Core periodically to fetch updates every hour. In future, we might be >> able to >> do this in more realtime fashion by using an event based pub/sub model. >> But, >> we are not there yet. >> >> >> > >> > Many thanks for your attention, >> > >> > -- >> > >> > *Nathan Dixon* MEng >> > Senior Software Architect >> > m: +44 (0)7402 690311 >> > >> > t: +44 (0)20 81231252 >> > e: nathan.dixon(a)evadon.com >> > w: www.evadon.com >> > >> > This e-mail and any attachments are confidential and may be protected by >> > legal, professional or other privilege. If you are not the intended >> > recipient you should not store it, copy it, re-transmit it, use it or >> > disclose its contents, but should return it to the sender immediately >> and >> > delete your copy from your system. The views expressed are those of the >> > sender and not necessarily those of Evadon. Please note that whilst we >> scan >> > all e-mails for viruses we cannot guarantee that any e-mail is >> virus-free. >> > Please be advised that we expressly reserve the right to monitor email >> > content for the purposes of ensuring compliance with legal requirements >> and >> > company policies and your sending to, or receiving from, us of any email >> > constitutes your agreement to these terms. >> > >> > >> > Evadon Dynamics Limited, registered in England No. 09494097. Registered >> > Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, >> Sheffield, >> > S1 2BJ >> > _______________________________________________ >> > 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/ >> > >> >> -- >> thanks, >> Abhilash Raj (maxking) >> _______________________________________________ >> 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/ >> > > > -- > > *Nathan Dixon* MEng > Senior Software Architect > m: +44 (0)7402 690311 > > t: +44 (0)20 81231252 > e: nathan.dixon(a)evadon.com > w: www.evadon.com > > This e-mail and any attachments are confidential and may be protected by > legal, professional or other privilege. If you are not the intended > recipient you should not store it, copy it, re-transmit it, use it or > disclose its contents, but should return it to the sender immediately and > delete your copy from your system. The views expressed are those of the > sender and not necessarily those of Evadon. Please note that whilst we scan > all e-mails for viruses we cannot guarantee that any e-mail is virus-free. > Please be advised that we expressly reserve the right to monitor email > content for the purposes of ensuring compliance with legal requirements and > company policies and your sending to, or receiving from, us of any email > constitutes your agreement to these terms. > > > Evadon Dynamics Limited, registered in England No. 09494097. Registered > Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, > S1 2BJ > -- *Nathan Dixon* MEng Senior Software Architect m: +44 (0)7402 690311 t: +44 (0)20 81231252 e: nathan.dixon(a)evadon.com w: www.evadon.com This e-mail and any attachments are confidential and may be protected by legal, professional or other privilege. If you are not the intended recipient you should not store it, copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. The views expressed are those of the sender and not necessarily those of Evadon. Please note that whilst we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free. Please be advised that we expressly reserve the right to monitor email content for the purposes of ensuring compliance with legal requirements and company policies and your sending to, or receiving from, us of any email constitutes your agreement to these terms. Evadon Dynamics Limited, registered in England No. 09494097. Registered Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, S1 2BJ

7 years, 5 months

MHonArc archiver setup/config?

by Stephen J. Turnbull

Bryan Fields writes: > I've had a request to setup this for a mm3 list. It looks like it's supported > from the config files, From the comments in the implementation files, I would say that no consideration has been given to private archives. I don't know how MHonArc handles that, so if it's a concern I can only warn you to be careful. > but I'm at a loss for exactly how to go about this. > Has anyone setup this with mm3 and can provide an overview? I haven't set it up. However, what I would do is 1. Copy .../mailman/config/mhonarc.cfg to /etc/mailman3 (or wherever you keep mailman.cfg). 2. Edit base_url and command in /etc/mailman3/mhonarc.cfg. base_url may already be appropriate for your system, but the "/path/to/archive" part of command will need to be adjusted. $hostname, $listname, and $fqdn_listname are variables supplied by Mailman at runtime. I don't know enough about MHonArc to say if the usage of $listname (just the local part of the posting address) and $fqdn_listname (posting address including domain) is appropriate. I would think you'd want to use the same variable in both places, so be careful. 3. Create any directories in "/path/to/archive" that MHonArc won't, and make sure they have appropriate ownership and search ("x") permissions all the way down. 4. Check that your webserver is configured to serve MHonArc at the location specified in base_url. 5. Add the stanza [archiver.mhonarc] enable: yes configuration: /etc/mailman3/mhonarc.cfg to /etc/mailman3/mailman.cfg 6. (Recommended) Mailman is perfectly happy to supply several archivers at the same time so add [archiver.prototype] enable: yes to mailman.cfg. This drops all the posts into a maildir somewhere under $var_dir as a backup in case the MHonArc archiving doesn't work, and nothing else -- it's not a usable archive for browsing. I guess there's probably a way to import them back into MHonArc, but if not presumably you can script it usng some variant of the command in mhonarc.cfg. Once the MHonArc configuration is doing the right thing you can disable it and delete the maildir contents. (Don't just "rm -rf $var_dir/archive", though -- Mailman uses that to queue messages being archived. I think archiver.prototype uses $var_dir/archive/prototype as its maildir.) 7. Restart Mailman. I don't think you need to do anything for Postorius, it will fetch the base_url from Mailman to populate the archive links. And that should do it on the Mailman side (except for the caveat about private archives). Steve

1 year, 9 months

Re: Confirmation emails to Users has wrong domain name (example.com!)

by Abhilash Raj

On Wed, Sep 29, 2021, at 9:50 AM, Odhiambo Washington wrote: > 1. Confirmation emails to Users has wrong domain name (example.com!) > <https://docs.mailman3.org/en/latest/faq.html#id1> > <https://docs.mailman3.org/en/latest/faq.html#confirmation-emails-to-users-h…> > > This happens when your reverse (SSL) proxy isn’t setting up the correct > headers when proxying requests. Fix this by setting the right > proxy_set_header directives: > > # For Nginx. > location / { > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-Host $host; > proxy_pass http://localhost:8000/; > } > > Appropriate headers for different web servers needs to be set if something > other the > > > > How is this supposed to be mitigated in Apache when using WSGI? It seems like Apache has this `ProxyPassReverse` thing, which should do the same job: https://www.nginx.com/resources/wiki/start/topics/examples/likeapache/ I haven't tried it myself, but it might help! > > My config: > > WSGIDaemonProcess hyperkitty threads=25 python-path=/usr/local/mailman > user=mailman group=mailman > WSGIPythonHome "/usr/local" > WSGIProcessGroup hyperkitty > > <VirtualHost *:443> > ServerName lists.doma.ain > ServerAdmin odhiambo(a)gmail.com > > SSLEngine on > SSLCipherSuite > ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > SSLCertificateFile > "/usr/local/etc/letsencrypt/live/lists.doma.ain/cert.pem" > SSLCertificateKeyFile > "/usr/local/etc/letsencrypt/live/lists.doma.ain/privkey.pem" > SSLCertificateChainFile > "/usr/local/etc/letsencrypt/live/lists.doma.ain/chain.pem" > > CustomLog /var/log/mm3-lists-access.log combined > ErrorLog /var/log/mm3-lists-error.log > LogLevel info > > Alias /favicon.ico /usr/local/mailman/static/hyperkitty/favicon.ico > Alias /static /usr/local/mailman/static > > > <Directory "/usr/local/mailman/static"> > Order Allow,Deny > Require all granted > Allow from all > </Directory> > > WSGIScriptAlias /mailman3 /usr/local/mailman/etc/wsgi.py > process-group=hyperkitty > WSGIScriptAlias /hyperkitty /usr/local/mailman/etc/wsgi.py > process-group=hyperkitty > WSGIScriptAlias /postorius /usr/local/mailman/etc/wsgi.py > process-group=hyperkitty > WSGIScriptAlias /archives /usr/local/mailman/etc/wsgi.py > process-group=hyperkitty > > <Directory "/usr/local/mailman/"> > <Files wsgi.py> > Require all granted > </Files> > WSGIProcessGroup mailman-web > </Directory> > > </VirtualHost> > > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", egrep -v '^$|^.*#' :-) > _______________________________________________ > 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/ -- thanks, Abhilash Raj (maxking)

5 years

Lessons learned and a couple little gotcha for newbies

by William Oliver

I just finished, with great help from Mark Sapiro on the list, a new installation of mailman3. I used the instructions at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/insta… and https://docs.mailman3.org/en/latest/install/virtualenv.html There were a couple of gotchas that I didn't see well documented. 1) I got the error django.template.library.InvalidTemplateLibrary: Invalid template library specified. ImportError raised when trying to load 'hyperkitty.templatetags.decorate': cannot import name 'escape_html' from 'mistune.scanner' (/opt/mailman/venv/lib/python3.9/site- packages/mistune/scanner.py) when I ran 'mailman-web migrate' The fix was trivial: I just added the lines: from mistune.util import escape_html from mistune.util import escape_url to /opt/mailman/venv/lib/python3.9/site-packages/mistune/scanner.py It's not hard to search for those definitions, but if someone doesn't know a smattering of python, it might not be obvious. 2) Similarly, migrate (using postgres) also gave the error: File "/opt/mailman/venv/lib/python3.9/site- packages/django/db/backends/postgresql/utils.py", line 6, in utc_tzinfo_factory raise AssertionError("database connection isn't set to UTC") I was able to find a discusson of this one at https://stackoverflow.com/questions/68024060/assertionerror-database-connec… which had me downgrade to an older version of psycopg2-binary: pip install psycopg2-binary==2.8.6 There might be a different fix, but this worked. 3) When I ran the test "uwsgi --ini /etc/mailman3/uwsgi.ini" I got the error: ModuleNotFoundError: No module named 'settings' This was also trivially fixed by adding the path: export PYTHONPATH=$PYTHONPATH:/etc/mailman3 in /opt/mailman/.bashrc 4) Sometimes when I rebooted the machine, when I ran 'systemctl start mailman3' I'd get the error that mailman wouldn't start because the lock was stll there. I never could figure out where the lock was, so I worked around it by replacing ExecStart=/opt/mailman/venv/bin/mailman start with ExecStart=/opt/mailman/venv/bin/mailman start --force in /etc/systemd/system/mailman3.service I'm sure there's something bad about doing that, but it works for me, so far. 5) I had a problem with mail to outside people not being delivered while mail to the local host was delivered. It turned out that this was because in my mailman.cfg I had "smtp_host:my.listserver.tld when it should have been localhost. The error was "relay access denied." To fix this, I had to add my.listserver.tld to "mynetworks" in /etc/postfix/main.cf, ie change: mynetworks = 127.0.0.0/8 10.0.0.0/24 to mynetworks = 127.0.0.0/8 10.0.0.0/24 111.222.333.444 <--- my ip address However, Mark Sapiro (a God) told me this was because I had changed a line in the [mta] section of mailman.cfg. I had changed smtp_host: localhost to smtp_host: mydomain.tld Here's the thing. The reason I did this was because the instructions at https://docs.mailman3.org/en/latest/config-core.html give this as their model: [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: mail.example.com lmtp_port: 8024 smtp_host: mail.example.com <---- not localhost smtp_port: 25 The instructions are good, but there are a few places where one size does not fit all, I guess. 6) A second error in delivery to outside addresses resulted in an "Access denied" error. A search on the internet revealed that this had to do with (for me) smtpd_recipient_restrictions in postfix. See, for instance: https://know.mailsbestfriend.com/postfix_error_relay_access_denied_noqueue_… Changing this fixed things. I'm not sure, but I think this shows up mostly with installations that include dovecot. 7) If you are using virtual domains in postfix, you need to use the "unusual postfix configuration" in https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… virtual_alias_maps = hash:/path-to-mailman/var/data/postfix_vmap 8) You need to manually set the local virtual host for mailman3. Somehow, I got the impression from the installation instructions that this was done automagically to the default x.mydomain.tld if your domain is mydomain.tld. It doesn't. 9) Follow the instructions verbatim, and follow them in the order provided. I installed postfix and nginx out of order, and it did OK, but once you get into the python virtual environment, it is easy to miss something if you don't do it in order. 10) Jot down lots of notes. This is one of the more complicated installations I've done, mostly because it involved configuring a zillion packages to talk to each other: Postfix, nginx, postorius, hyperkitty, django, and others (I'd never heard of "whoosh" or "sass" for instance). All of these can be unforgiving with configuration errors. The default installation instructions assumed a number of packages I'd never used. I'm an apache/dovecot/mysql kind of person, and I had to switch to nginx/postgres to use the instructions as the written defaults. I'm sure I could have used apache and mysql, but it would mean trying to figure out what didn't work without following the installations verbatim. I'd never even heard of postorius, hyperkitty, or django. So, it was easy to get confused a bit. Taking notes of changes I made was important in being able to back out of disastrous choices. Plus, once I'd installed it on one machine, I sat down and installed it on another machine, and it was very useful to have written down how I fixed an issue when it came up again -- and I didn't remember exactly what I had done. 11) Make multiple sequential backups of configuration files. I went down a couple of paths I shouldn't have gone down. For instance, with the vmap issue, I got it in my head that it was a postfix configuration issue, not a mailman issue. So I kept changing things in postfix. Once I was told that it was in *mailman* I had to set the virtual host, I needed to back out of about 8 tweaks I'd made to main.cf in /etc/postfix. If I hadn't been making main.cf.backup.01, main.cf.backup.02, etc. I would have had to spend another few hours trying to remember what inappropriate changes I had made. This is particularly true for me because I am not a great typist, and when I try to retype something to back out, there's a reasonable chance I'll mistype something and it still won't work. With these backups, I don't have both manually back out of things *and* proof my typing again and again. It's a lot easier to delete backups once things are working than to try to remember what you did late at night after a couple of bourbons. 12) Choose one set of installation instructions and follow it. Don't try to mix instructions from different tutorials unless you really know what you are doing. I didn't. For instance, there's a different set of mailman3 installation instructions at: https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 It does things a little differently. It's useful to look at that when you are debugging why something's not working, but you can get into some trouble trying to do both installations at the same time -- which I found myself doing when something wasn't working. It didn't help. billo

4 years, 9 months

Weird response to postings after subscriptions and accounts

by Paul Arenson

I accidentally posted to a test account I had not actually used. Am reposting to my correct account. Sorry to the moderators. In my test of the two forms of signup, I am getting these unexpected results. Is it my settings or is something weird within the program itself? 1) https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… 2) Choose "You can also subscribe without creating an account. If you wish to do so, please use the form below" 3) Then I have to approve it. They get "Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org 4) But I have to approve it.I assume this is because they do not yet have a real account. And they should be listed as a NON MEMBER? 5) But even when they sign up here: https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… they get an email from my provider (NOT MY LIST????) as follows: "Hello from mailman3.emwd.com! You're receiving this e-mail because user iCloud has given yours as an e-mail address to connect their account. To confirm this is correct, go to https://list.tokyoprogressive.org/accounts/confirm-email/MTE3:1iA44k:E7w7xh… Thank you from mailman3.emwd.com! mailman3.emwd.com" 6) And this is where it gets weird. If they send from their email program and get the welcome (Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You can unsubscribe or make adjustments to your options via email by sending a message to....... I then get a notice: "Your mail to 'discuss(a)list.tokyoprogressive.org' with the subject test notice Is being held until the list moderator can review it for approval. The message is being held because: The message is not from a list member" 7) While if they send FROM THE interface it goes through. 8) What I am confused about. Signing up for an account should make them a member, right? Subscribing should make them a non member, no? But here it seems that both make them a non member. And worse, someone with an account sending from the Interface has their message get through while the same person sending from an email program has me get a notice that a non member is trying to post. Before I can move my actual members over from another mailing list provider, I want to make sure what works and what doesn't. Thanks. PS I am running out of test accounts to use to test my own setup. Thanks. paul!!!Subscribe to this list still shows up at the bottom.

7 years, 1 month

MM3 not starting afte an upgrade

by Gelpi Andrea

Hi, to day in a Debian system I upgraded some packages. After the MM3 doesn't start anymore. These are the packages I upgraded: [UPGRADE] clamav:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-base:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-daemon:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-freshclam:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamdscan:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] gcc-10-base:amd64 10.1.0-4 -> 10.1.0-6 [UPGRADE] libc-l10n:amd64 2.30-8 -> 2.31-1 [UPGRADE] libclamav9:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] libgcc-s1:amd64 10.1.0-4 -> 10.1.0-6 [UPGRADE] libnss3:amd64 2:3.42.1-1+deb10u2 -> 2:3.42.1-1+deb10u3 [UPGRADE] python3-django-hyperkitty:amd64 1.3.2-1 -> 1.3.2-1.1 [UPGRADE] python3-django-postorius:amd64 1.3.2-2 -> 1.3.2-2.1 [UPGRADE] qemu-guest-agent:amd64 1:3.1+dfsg-8+deb10u5 -> 1:3.1+dfsg-8+deb10u6 MM3 on start up says: Jul 23 13:29:39 posta mailman3[2608]: Traceback (most recent call last): Jul 23 13:29:39 posta mailman3[2608]: File "/usr/bin/mailman", line 11, in <module> Jul 23 13:29:39 posta mailman3[2608]: load_entry_point('mailman==3.2.1', 'console_scripts', 'mailman')() Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ Jul 23 13:29:39 posta mailman3[2608]: return self.main(*args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main Jul 23 13:29:39 posta mailman3[2608]: rv = self.invoke(ctx) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/bin/mailman.py", line 69, in invoke Jul 23 13:29:39 posta mailman3[2608]: return super().invoke(ctx) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke Jul 23 13:29:39 posta mailman3[2608]: return _process_result(sub_ctx.command.invoke(sub_ctx)) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke Jul 23 13:29:39 posta mailman3[2608]: return ctx.invoke(self.callback, **ctx.params) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke Jul 23 13:29:39 posta mailman3[2608]: return callback(*args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func Jul 23 13:29:39 posta mailman3[2608]: return f(get_current_context(), *args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/commands/cli_control.py", line 81, in start Jul 23 13:29:39 posta mailman3[2608]: status, lock = master_state() Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/bin/master.py", line 104, in master_state Jul 23 13:29:39 posta mailman3[2608]: os.kill(pid, 0) Jul 23 13:29:39 posta mailman3[2608]: PermissionError: [Errno 1] Operation not permitted There is a permission error, but on what? Thanks for any help. Regards -- Gelpi ing. Andrea -------------------------------------------------------------- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. --------------------------------------------------------------

6 years, 2 months

My django container keeps getting shutdown by oom-killer

by Hirayama, Pat

Greetings, Ok, I just updated the docker containers that are running my Mailman 3 installation over the weekend. mailman-core is now 3.3.10, with mailman-ngnix at 1.28.0, mailman-postfix at 3.10.5-r0 and mailman-django-uwsgi at "latest". I think I have got everything working normally — messages seem to be processed correctly, and I can access the web pages on the web interface. And I have updated various scripts to use --run-as-root until I can get around to reconfiguring mailman-core to use a non-root user. Anyway, since that time, the EC2 instance that the containers are running on becomes "unreachable", to use AWS's parlance. I can restore functionality by rebooting the instance. According to AWS, this is an application or operating system issue, not their instance. Which means auto-recovery doesn't get activated. This always happens overnight, usually after midnight, though one time it was around 10:40. I don't see any crontab entries that correlate. And the after midnight issues don't always happen at the same time, so it seemed unlikely that it was a crontab job that was causing it I finally looked at the host (rather than the logs of each container) and realized that the oom-killer was killing django-admin. As a temporary workaround, I've limited memory on the mailman-django-uwsgi container to 4 GiB (though, since I just did that this morning, I won't know until after midnight (presumably) if it worked or not), and set the RestartPolicy to always. I'm thinking that this points to a memory leak or some kind? I did have to add a bunch of packages to my Dockerfile when I rebuilt the container, since the last build was like 5 years ago, so I suppose it could be that django is just using more memory than it used to, though at the moment, I see that it is around 1 GiB: FROM python:3.12-alpine3.22 RUN apk update && apk add --no-cache --virtual build-deps \ cargo gcc libffi-dev musl-dev && \ apk add --no-cache gettext postgresql-dev sassc build-base pcre-dev python3-dev libc-dev linux-headers && \ pip install --upgrade pip setuptools wheel && \ pip --no-cache-dir install django-haystack==3.3.0 hyperkitty==1.3.12 \ postorius==1.3.13 psycopg2 uwsgi==2.0.25 whoosh && \ apk update && apk del --no-cache build-deps WORKDIR /opt/mailman/mailman-suite/mailman-suite_project USER mail EXPOSE 8000 CMD ["uwsgi", "--ini", "uwsgi.ini"] Any insights, ideas or assistance would be appreciated. Thanks! Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering - Infrastructure Fred Hutch Cancer Center O 206.667.4856 phirayam(a)fredhutch.org<mailto:phirayam@fredhutch.org>

11 months, 1 week

Mailman-users search results for query "Postorius"