Search results for "Postorius" - Mailman-users

Re: Archive Policy not reflecting in Hyperkitty

by Nathan Dixon

Ok, I've figured out how to run the job manually. And here's the error I'm getting (list name and domain has been changed to <listname> and <domain>.com for security reasons): From within mailman-web container: bash-4.4# python3 manage.py runjob sync_mailman ERROR OCCURED IN JOB: sync_mailman (APP: None) START TRACEBACK: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) psycopg2.IntegrityError: null value in column "description" violates not-null constraint DETAIL: Failing row contains (4, <listname>@<domain>.com, <LISTNAME>, null, [<LISTNAME>] , 1, 2019-03-12 10:23:20.293675+00, <listname>.<domain>.com). The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django_extensions/management/commands/runjob.py", line 35, in runjob job().execute() File "/usr/lib/python3.6/site-packages/hyperkitty/jobs/sync_mailman.py", line 35, in execute sync_with_mailman() File "/usr/lib/python3.6/site-packages/hyperkitty/lib/mailman.py", line 131, in sync_with_mailman mlist.update_from_mailman() File "/usr/lib/python3.6/site-packages/hyperkitty/models/mailinglist.py", line 192, in update_from_mailman self.save() File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 718, in save force_update=force_update, update_fields=update_fields) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 748, in save_base updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 812, in _save_table forced_update) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 861, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3.6/site-packages/django/db/models/query.py", line 712, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1383, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1065, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3.6/site-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) django.db.utils.IntegrityError: null value in column "description" violates not-null constraint DETAIL: Failing row contains (4, <listname>@<domain.com>, <LISTNAME>, null, [LISTNAME] , 1, 2019-03-12 10:23:20.293675+00, <listname>.<domain>.com). END TRACEBACK So it looks like there's a null in one of the columns. This list was created using the Postorius interface. I had sent a couple of messages to the list while the archive attribute was set to public and then I changed it to private and sent some more test mails to it. Hopefully this will help us find a solution to this. Thanks On Tue, 7 May 2019 at 10:40, Nathan Dixon <nathan.dixon(a)evadon.com> wrote: > 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 > -- *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

Re: can't get mail into mailman3 in docker

by Stephen J. Turnbull

bob B writes: > Anyone have any ideas? First, what docker configuration are you using? One supplied by the Mailman project? If not, you need to tell us more about what's going on. If so, are there any containers other than those running the Mailman suite (Mailman 3 core, Postorius, HyperKitty)? In mydestination you have mydestination = $myhostname, localhost.$mydomain, localhost, mydomain.mydomain.com I do not understand the "localhost.$mydomain" entry. I guess that's a Postfix-ism, but I can't find any documentation about it. You could try taking it out (this is a very random suggestion). You say you have no /etc/postfix-mailman.cfg. Where are you looking for it? That file will only exist in the container, not in the host OS. (If it were in the host OS, it would be located somewhere like /opt/mailman/core/postfix-mailman.cfg.) Try `find /opt/mailman/core -name postfix-mailman.cfg`, although "automatically" might mean it's generated in the container when it starts. Abhilash would know, but he doesn't seem to be available. I really don't think it's the issue because I assume "bmimailmandr1" is the Docker container running Mailman core. If so Postfix is connecting to the configured LMTP port on localhost which is what it's supposed to do from the configuration. Since the container's Postfix appears to be connecting to the right place but the connection is refused, that Mailman core may not be running. For more help you'll have to wait for Abhilash. Steve

5 years, 2 months

Mailman web interface / uwsgi

by Jan Eden

Hi, I followed the installation instructions at https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…, which thankfully shielded me from configuring the Django applications for the web interface manually. All Django applications (postorius, hyperkitty, haystack etc) are loaded via mailman_web/settings/base.py, which is in turn referenced by the top-level settings file in /etc/mailman3. uwsgi is linked to mailman_web via /etc/mailman3/uwsgi.ini. So far, so good. I do not want to dive into the interaction between the various components and just want to switch from a http socket (http-socket = 0.0.0.0:8000) to a file socket (socket = /opt/mailman/mm/var/mailman.sock). After making this change in /etc/mailman3/uwsgi.ini, I applied it in the nginx proxy configuration proxy_pass http://127.0.0.1:8000; → proxy_pass http://unix:/opt/mailman/mm/var/mailman.sock; and received an error message (as expected): 2022/11/25 18:39:12 [error] 2978606#2978606: *3 upstream prematurely closed connection while reading response header from upstream, client: 37.201.155.65, server: lists.eden.one, request: "GET /mailman3/lists/ HTTP/2.0", upstream: "http://unix:/opt/mailman/mm/var/mailman.sock:/mailman3/lists/", host: "lists.eden.one" There are obviously a couple of places where the http-socket on port 8000 is referenced (e.g. mailman_web/settings/mailman.py, /opt/mailman/mm/hyperkitty.cfg). Is there an overview of the required changes when using a different (file) socket? Related question: My own (much simpler) Django applications use the following (e.g. in mysite_nginx.conf): upstream django { server unix:///private/tmp/mysite.sock; } location / { uwsgi_pass django; } instead of the "http://unix:/..." notation I tried for Mailman above. Is there any difference between the upstream/uwsgi_pass combination and the proxy_pass variant? Thanks, Jan

3 years, 11 months

Re: Residual signature?

by Paul Tomblin

On Thu, May 28, 2026, at 8:20 AM, Stephen J. Turnbull wrote: > Paul Tomblin via Mailman-users writes: > > > Like I said, there’s no templates listed in the UI. > > Ah, I read that as "no relevant templates". Sorry, I wasn't clearer because I didn't know about the non-UI templates before. > > The migration from Mailman 2 doesn't need a working Postorius, so it > doesn't use the same mechanism as the UI. It should write to a > parallel tree under the $mailman_home/$var/templates directory. The > fallback tree is in site-packages/mailman/templates, and otherwise Turns out there are a lot of files in /opt/mailman/mm/var/templates/lists, but I hadn't noticed them before because most of them where empty. In a few of the ones I don't subscribe to or which don't get a lot of traffic, those templates were "-- \nAdministration:" or sometimes "== \n-- Administration: %(web_page_url)slistinfo/%(_internal_name)s". I suspect that the ones that didn't have the text after Administration: versus the ones that did were some sort of bug in the conversion script, because I'm pretty sure I had the same footer configured for all those lists. But anyway, I had no idea those templates were there, so I'll have to file that away in my memory for next time I wonder why lists have footers that don't show up in the UI. Am I right in thinking that a UI configured template will override the ones in that directory tree? -- Paul Tomblin

5 months

Re: Column 'starting_email_id' cannot be null

by Odhiambo Washington

On Mon, Aug 18, 2025 at 11:32 AM kroerig--- via Mailman-users < mailman-users(a)mailman3.org> wrote: > Hello, > > after upgrading from Debian 11 to Debian 12 achiving incoming mails always > fails with > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 581, in get_or_create > return self.get(**kwargs), False > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 435, in get > raise self.model.DoesNotExist( > > During handling of the above exception (Thread matching query does not > exist.), another exception occurred: > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 73, in execute > return self.cursor.execute(query, args) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 209, in > execute > res = self._query(query) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 316, in > _query > self._do_get_result(db) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 147, in > _do_get_result > self._result = result = self._get_result() > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 349, in > _get_result > return self._get_db().store_result() > > During handling of the above exception ((1048, "Column 'starting_email_id' > cannot be null")), another exception occurred: > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", > line 47, in inner > response = get_response(request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line > 181, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/http.py", > line 40, in inner > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 117, in _decorator > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/csrf.py", > line 54, in wrapped_view > return view_func(*args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 163, in archive > add_to_list(mlist_fqdn, msg) > File "/usr/lib/python3/dist-packages/hyperkitty/lib/incoming.py", line > 153, in add_to_list > email.save() > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 763, in save_base > pre_save.send( > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 180, in send > return [ > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 181, in <listcomp> > (receiver, receiver(signal=self, sender=sender, **named)) > File "/usr/lib/python3/dist-packages/hyperkitty/signals.py", line 48, in > Email_on_pre_save > kwargs["instance"].on_pre_save() > File "/usr/lib/python3/dist-packages/hyperkitty/models/email.py", line > 239, in on_pre_save > thread, _thread_created = Thread.objects.get_or_create( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 588, in get_or_create > return self.create(**params), True > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 453, in create > obj.save(force_insert=True, using=self.db) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 776, in save_base > updated = self._save_table( > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 881, in _save_table > results = self._do_insert(cls._base_manager, using, fields, > returning_fields, raw) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 919, in _do_insert > return manager._insert( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 1270, in _insert > return query.get_compiler(using=using).execute_sql(returning_fields) > File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", > line 1416, in execute_sql > cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 66, in execute > return self._execute_with_wrappers(sql, params, many=False, > executor=self._execute) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 75, in _execute_with_wrappers > return executor(sql, params, many, context) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 84, in _execute > return self.cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 78, in execute > raise IntegrityError(*tuple(e.args)) > > Exception Type: IntegrityError at /hyperkitty/api/mailman/archive > Exception Value: (1048, "Column 'starting_email_id' cannot be null") > > Postorius Version 1.3.8 > HyperKitty Version 1.3.7 > > Any ideas how to fix this? > > Klauas It looks like you did not run some migrations. However, because this is packaged Mailman3, I am not sure I know how to do that. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 2 months

Re: nginx configuration on a multitasking server

by Mark Sapiro

On 12/22/21 9:22 PM, David Newman wrote: > > On my system that file lives here: > > /opt/mailman/venv/lib/python3.9/site-packages/mailman_web/urls.py It appears that you have installed following https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… and in that case, this is the file. > But the error persists after this addition and restarting MM3 and > mailmanweb and nginx: > > url(r'^mailman/', include('postorius.urls')), > > There is this 404 error in uwsgi.log: > > [pid: 73356|app: 0|req: 3/3] 127.0.0.1 () {48 vars in 1544 bytes} [Wed > Dec 22 21:13:48 2021] GET /mailman/admindb/listname => generated 5328 > bytes in 14 msecs (HTTP/1.0 404) 6 headers in 197 bytes (1 switches on > core 0) However, that's not the issue. You originally reported and I didn't look closely enough: > Update: The above worked fine until MM3 informed a list owner of pending > subscription requests, with a URL like this: > > https://lists.example.com/mailman/admindb/listname > > and that URL returned a 404 error. That URL is from a Mailman 2.1 installation. Are you still running Mailman 2.1? If so, you need to support Mailman 2.1's CGIs. In Apache, this would be something like ScriptAlias /mailman/ /parh/to/mailman/cgi-bin/ but nginx doesn't do that. You would need something like location /mailman/ { proxy_pass <something that can serve Mailman 2.1's CGIs.> } The something could be apache or ?? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

Re: MM3 templates

by Mark Sapiro

On 2/16/23 11:14, Odhiambo Washington wrote: > On Thu, Feb 16, 2023 at 9:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: >> >> I don't know why? What's the content of the template table in the database? >> ``` >> SELECT * FROM template; >> ``` >> > > root@localhost [mailmansuite]> SELECT * FROM template; > Empty set (0.03 sec) Well, that eliminates one possibility. I still don't know why. Mailman should be using all the list: templates from /opt/mailman/mm/var/templates/lists/kictanet.lists.kictanet.or.ke/en/ for messages from the kictanet(a)lists.kictanet.or.ke where the target language is English. Is the list's preferred language English and is the recipient's preferred language English? >> That's just wasting space. If you're putting the exact same templates in >> site/, domains/ and lists/, you might just as well delete the ones in >> domains/ and lists/ and Mailman will use the ones from site/. >> > > Well, space is cheap these days. More importantly, it could lead you to edit a template that isn't used because one of the other places is searched first. I would like to figure out what the issue is, but I don't know how to proceed. Have you checked /opt/mailman/mm/var/logs/mailman.log for anything relevant? If all else fails and we can't figure this out, you could always set the template(s) in Postorius. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

Re: Missing Base64 encoding from control message reply

by Mark Sapiro

On 9/22/23 09:32, Stephen J. Turnbull wrote: > > To diagnose, we really need to see that in context of the raw message > as received by the user. It was posted. The issue is the message declares Content-Transfer-Encoding: base64 but the body is not base64 encoded so the MUA tries to base64 decode it and even though that's invalid, produces the garbled output. > The only other thing I can think of is it might have something to do > with your internationalization settings. What is the default language > of the list? (This is available in Postorius.) Have you changed the > default encoding for English on your site? (I think you need to look > in mailman.cfg for this.) What is the default language of the site? I note that the message also declares Content-Type: text/plain; charset="utf-8" and Python's email package will base64 encode utf-8 message bodies. I also note that the messages Subject: is RFC 2047 encoded as utf-8. These tell me that the user's preferred_language if set or the list's preferred_language is not English or the charset for English is changed to utf-8. I tried to duplicate this in a test installation with the charset for English set to utf-8, but I get a similar response but with Subject: =?utf-8?q?The_results_of_your_email_commands?= and Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

Re: 404 on fresh install (Debian11)

by Mark Sapiro

On 3/22/23 03:42, thomas--- via Mailman-users wrote: > Hello, > very new to mailman3, I used to manage mailman2 on a Debian 10 server. > The server has been upgraded to Debian 11 and mailman2 disappear… > > I try fresh install of mailman3, prerequisite to data migration, but without success. > If some can help, I would be really greatful. > > <VirtualHost *:80> > ServerName newsletter.mydomain.tld > > Alias /static /var/lib/mailman3/web/static > Alias /favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico > > DocumentRoot /var/lib/mailman3/web/static > <Directory "/var/lib/mailman3/web/static"> > Require all granted You can probably fix the below error by adding options +Indexes here, but see below. > And now I have a 404 answer when consulting my http page. > > When trying to access `/static` sub-path, I get `Cannot serve directory /var/lib/mailman3/web/static/admin/: No matching DirectoryIndex found`. It is unclear to me what is doing a GET of /static/admin/ and why. GETs should by of actual files, e.g., things like /static/admin/css/base.css > I am a bit lost with that. So are we. Questions about the Debian package are better asked of Debian. See https://wiki.list.org/x/12812344 and https://mail.python.org/archives/list/mailman-users@python.org/message/T6LB… We can provide much better help and support if you install via the resources mentioned in the reply at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

Re: Rejecting held emails

by Mark Sapiro

On 04/26/2018 08:43 AM, Darren Smith wrote: > > We recently had a phishing message make it through our spam filters and > arrive at a mailing list. The good news is that since it was not from a > list member it was in the held message queue. > > I was able to find the message in the var/messages directory by searching > for a keyword in the subject. However, after rejecting the message from > Postorius, the message doesn't seem to be removed from the var/messages > directory. Do you mean Reject and not Discard? Phishing/Spam should never be "rejected" for backscatter reasons. Reject should only be used for somehow inappropriate posts from known people. > Is this expected behavior? I know that infosec people won't be too happy > about a phishing email sitting around on our disk. (Infosec guys are > notoriously paranoid. :) ) > > Is there some sort of cleanup process that would remove these messages? If > not, does this pose an issue where over time disk usage will creep up? This > could be a pretty significant problem if that is the case. It's not the behavior I would "expect", but it is the way it currently works, and yes, all your concerns are valid. This is <https://gitlab.com/mailman/mailman/issues/257> which I just edited to note that in addition to not removing the pending db entry, the message isn't removed either. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 6 months

Mailman-users search results for query "Postorius"