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 > >

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

5 years, 11 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 '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 10 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

11 months, 3 weeks

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)

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

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

6 years, 3 months

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. --------------------------------------------------------------

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

2 months

Re: SMTPAuthenticationError at /accounts/login/

by Mohsen Masoudfar

Hi Stephen, Thank you for the hint. I was focused too much on the documentation and was looking for the answer in the wrong place. Problem fixed. My problem started with "SMTP authentication not supported" and after fixing that, which was a Postfix parameter, I got this issue and was also looking in Postfix or Django configuration for the answer. This problem is solved and I wished there was a chance to update the documentation, so that these sort of information could be added in the documentation for other people who try to use mailman3. Thanks Mohsen -----Original Message----- From: Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> Sent: Thursday, April 9, 2020 4:06 AM To: Mohsen Masoudfar <mmasoudf(a)aaas.org> Cc: mailman-users(a)mailman3.org Subject: [MM3-users] SMTPAuthenticationError at /accounts/login/ [EXTERNAL EMAIL] mmasoudf(a)aaas.org writes: > I have setup the stack according to: > Mailman Suite Documentation. Release 3.3 PDF file. > I configured > EMAIL_HOST_USER and > EMAIL_HOST_PASSWORD > in Django settings.py. I could not find the place that I might > configure it for Postfix I think it helps to start thinking about it from the other end. That is, Postfix is the mail server for all users on a multiuser system. Therefore in "normal" configurations it will use the authentication mechanisms provided by the host operating system.[1] You need to have a user for Mailman in any case, typically called "mailman" or "list".[2] Once you've configured a user for Mailman on the Postfix side, you use that user and authentication data for Mailman core, Postorius, and HyperKitty to send mail via Postfix. > I am running the site on AWS and to be able to use AWS mail-servers > I have to define following parameter for AWS: > smtp_sasl_password_maps which points to a hash for AWS 'ACCESS KEY > ID' and 'SECRET ACCESS KEY' I don't think that has anything to do with the Mailman-to-Postfix side of things; that's for Postfix to send to AWS's mail exchanger (aka MX). Steve Footnotes: [1] It may also be possible to create Postfix-only "virtual" users who have no existence as far as the OS is concerned, but I don't know anything about that. [2] I haven't thought carefully about whether using Mailman's user in Django would be a security risk, but as long as it only has access to Mailman I don't see how it can do more harm than Mailman itself can, and I don't see why it would be more subject to exploitation than Mailman itself is. Anybody with security chops who wants to weigh in, please do.

5 years, 9 months

Mailman-users search results for query "Postorius"