Search results for "Postorius" - Mailman-users

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

2 years, 10 months

Re: Getting rid of held messages from the command line

by Mark Sapiro

On 03/14/2018 03:04 AM, Aymeric Mansoux wrote: > > So far so good, however, for some reasons, a couple of our lists have started to accumulate held messages that cannot be manipulated via the REST API. Regardless if we use the web interface or mailmanclient, it ends up with: > > Mar 14 10:58:32 2018 (24287) REST request handler error: > Traceback (most recent call last): > File "/usr/lib/python3.5/wsgiref/handlers.py", line 137, in run > self.result = application(self.environ, self.start_response) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 50, in wrapper > rtn = function(*args, **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/wsgiapp.py", line 214, in __call__ > return super().__call__(environ, start_response) > File "/usr/local/lib/python3.5/dist-packages/falcon/api.py", line 244, in __call__ > responder(req, resp, **params) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 167, in on_get > resource = self._make_collection(request) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/helpers.py", line 159, in _make_collection > for resource in collection] > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/helpers.py", line 159, in <listcomp> > for resource in collection] > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 70, in _make_resource > resource = super()._make_resource(request_id) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 39, in _make_resource > results = requests.get_request(request_id) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/model/requests.py", line 120, in get_request > result.data_hash, expunge=False) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/model/pending.py", line 138, in confirm > value = json.loads(keyvalue.value) > File "/usr/lib/python3.5/json/__init__.py", line 319, in loads > return _default_decoder.decode(s) > File "/usr/lib/python3.5/json/decoder.py", line 339, in decode > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > File "/usr/lib/python3.5/json/decoder.py", line 355, in raw_decode > obj, end = self.scan_once(s, idx) > json.decoder.JSONDecodeError: Unterminated string starting at: line 1 column 1 (char 0) > Mar 14 10:58:32 2018 (24287) 127.0.0.1 - - "GET /3.1/lists/xx(a)xx.xx/held HTTP/1.1" 500 59 > > Is there a way to manipulate/see/remove these mails differently? Right now this prevent moderation of any held messages (note: some lists do not suffer from this and the held panel or mailmanclient works perfectly fine). We've seen this issue before with a different underlying cause. See <https://gitlab.com/mailman/mailman/issues/256>. There are a couple of problems here. The serious problem is if there is a held message which somehow throws an exception in processing in mailman/rest/post_moderation.py, that totally breaks the Postorius held messages view for that list. We need to fix that. Also it would be good to see the problem message. Here are some things you can do in 'mailman shell' (aka mailman withlist). It is not clear what might not work, but you can try mailman shell -l list@domain which will respond Welcome to the GNU Mailman shell The variable 'm' is the list@domain mailing list >>> Then you should be able to do at the >>> prompts: >>> req_db = IListRequests(m) >>> reqs = list(req_db.held_requests) reqs is now a list of the held requests and you can do something like >>> for req in reqs: ... print('{}: {}'.format(req.id, req.request_type)) ... or since req_db.held_requests is a generator >>> for req in rdb.held_requests: ... print('{}: {}'.format(req.id, req.request_type)) ... either of which will produce a list like 1: RequestType.held_message with the IDs and types of each request. You can handle these requests with something like >>> from mailman.app.moderator import handle_message >>> handle_message(m, 1, Action.defer) where the second argument is the ID of the message and the action is one of Action.defer, Action.hold, Action.discard, Action.reject or Action.accept, the first two of which do nothing, but the others will do the indicated action. You can see the actual messages like this >>> msg_db = getUtility(IMessageStore) then >>> key = req[0].key >>> msg_db.get_message_by_id(key) which will return the actual held message that is in this case index 0 in the list of held_requests. You may have to do >>> commit() when done, although if you don't do abort(), just exiting with control-D should do a commit(). I hope you find this helpful, and if you do determine the content of the offending message(s), it will be helpful if you post that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 4 months

Re: 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]

11 months, 1 week

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, 2 months

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

Re: Confusing mailman user model

by Mark Sapiro

On 7/19/20 8:10 AM, Gilles Filippini wrote: > Hi, > > I'm trying to understand the Mailman user model, and I'm confused about > the respective roles of tables 'auth_user' and 'user'. auth_user is a Django auth table. These are the users listed in the Django admin web UI. user is Mailman core's users. > Both have an 'id' column referred to as 'user_id' when used as a foreign > key. But there seems to be no relation at all between them as they use > different ids for the same user. Right, they are unrelated. > Our mailman server was migrated from mailman2 to mailman3 about 1.5 year > ago, and there is an inconsistency I'd like to fix: > 2 of our users have a registered Mailman account with their respective > email addresses in table 'auth_user', but these very same addresses in > the 'address' table are linked to another old admin account in the > 'user' table. Their Mailman account is the 'old' one. the auth_user account is a Django account > > Then if add one of these addresses as a domain owner, it it the old > admin address which is selected instead. How could I fix that? That's because domain owner in a Mailman thing and involvs the Mailman user. You could delete the Django users via the Django admin UI and then re-register them via Postorius. That *might* work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

Re: mailman-web migrate fails with sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email

by Mark Sapiro

On 3/3/25 07:52, Stefan Bauer via Mailman-users wrote: > > trying to update mailman3 to lastest version, we fail during > > mailman-web migrate with: > > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, django_mailman3, > django_q, hyperkitty, postorius, sessions, sites, socialaccount > Running migrations: > Applying account.0006_emailaddress_lower...Traceback (most recent call > last): > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", > line 89, in _execute > return self.cursor.execute(sql, params) > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py", > line 328, in execute > return super().execute(query, params) > sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email This issue is due to changes in Django allauth to prevent creating multiple addresses differing only in case. The problem is if you have such multiple addresses in your account_emailaddress table, this migration fails. There is a script at https://www.msapiro.net/scripts/UC_fix that will fix this. You may need to adjust the shebang and replace psycopg2 with sqlite3. See https://github.com/pennersr/django-allauth/issues/3019 perhaps starting at https://github.com/pennersr/django-allauth/issues/3019#issuecomment-1748028… > We found a workaround to fake the migration with > > migrate --fake You should fix the issue with the DB and run the migrations. > Could this be some duplicate users with same mail-address? This is not related to Mailman users. It is Django users. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 4 months

Mailman-users search results for query "Postorius"