Search results for "Postorius" - Mailman-users

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, 1 month

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

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

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

Docker Mailman3 installation frustration

by ccsmith＠cetsi.com

I've been working on installing Mailman3 for several weeks now, with limited success. I have tried various installation methods following instructions on numerous different web pages. My experience has been that the instructions are often conflicting and never complete. My best success has been with the Docker version, so that's what I'm going to concentrate on here. I'm running Ubuntu 16.04 (under Citrix XenServer), with Apache httpd and postfix. Following the instructions on https://asynchronous.in/docker-mailman/, I did the following: * created the directories "/opt/mailman/core" and "/opt/mailman/web", * created "/opt/mailman/core/mailman-extra.cfg" and inserted the suggested [mta] directives, * inserted the "transport_maps", "local-recipient_maps", and "relay_domains" entries in the /etc/postfix/main.cf file, * created the necessary apache config files, * cloned "https://github.com/maxking/docker-mailman", * ran "docker-compose up -d" At this point, I am able to connect with Postorius. All of the text and icons show up properly; all is well. It tells me (correctly) that "There are currently no mailing lists." When I click on the "Login" link at the top right, the "Sign In" page displays correctly. (Aside: Why do so many apps/sites have difficulty with choosing between "login" and "sign in" and, in fact, use both terms? It can really be off-putting to non-tech users... and me.) If I input an incorrect login, I receive (correctly) the message "The username and/or password you specified are not correct." However, if I input the correct sign-in, I receive: "Server Error (500)". Running "sudo docker exec -it mailman-web cat ../mailman-web-data/logs/mailmanweb.log" shows me: ERROR 2017-07-12 20:34:25,073 25 django.request Internal Server Error: /accounts/login/ Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/django/core/handlers/exception.py", line 39, in inner response = get_response(request) ... more stuff ... File "/usr/local/lib/python2.7/smtplib.py", line 747, in sendmail raise SMTPRecipientsRefused(senderrs) SMTPRecipientsRefused: {u'pacetechadmin(a)cetsi.com': (451, '4.3.0 <pacetechadmin(a)cetsi.com>: Temporary lookup failure')} On the Docker host (ubuntuServer2), /var/log/mail.log shows: Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: error: open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: error: open /opt/mailman/core/var/data/postfix_lmtp: No such file or directory Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: connect from unknown[172.19.199.3] Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: regexp:/opt/mailman/core/var/data/postfix_domains is unavailable. open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains: regexp:/opt/mailman/core/var/data/postfix_domains: table lookup problem Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains lookup failure Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: regexp:/opt/mailman/core/var/data/postfix_domains is unavailable. open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains: regexp:/opt/mailman/core/var/data/postfix_domains: table lookup problem Jul 12 13:48:53 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains lookup failure Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: NOQUEUE: reject: RCPT from unknown[172.19.199.3]: 451 4.3.0 <pacetechadmin(a)cetsi.com>: Temporary lookup failure; from=<postorius(a)localhost.local> to=<pacetechadmin(a)cetsi.com> proto=ESMTP helo=<mailman-web> Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: error: open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: error: open /opt/mailman/core/var/data/postfix_lmtp: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: connect from unknown[172.19.199.3] Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: regexp:/opt/mailman/core/var/data/postfix_domains is unavailable. open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains: regexp:/opt/mailman/core/var/data/postfix_domains: table lookup problem Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: relay_domains lookup failure Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: regexp:/opt/mailman/core/var/data/postfix_lmtp is unavailable. open /opt/mailman/core/var/data/postfix_lmtp: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: regexp:/opt/mailman/core/var/data/postfix_lmtp lookup error for "root@localhost" Jul 12 13:48:54 ubuntuServer2 postfix/trivial-rewrite[19843]: warning: transport_maps lookup failure Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: NOQUEUE: reject: RCPT from unknown[172.19.199.3]: 451 4.3.0 <root@localhost>: Temporary lookup failure; from=<root(a)localhost.local> to=<root@localhost> proto=ESMTP helo=<mailman-web> Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: disconnect from unknown[172.19.199.3] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19931]: lost connection after RSET from unknown[172.19.199.3] Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19931]: disconnect from unknown[172.19.199.3] ehlo=1 mail=1 rcpt=0/1 rset=1 commands=3/4 And /var/log/mail.err is filling up with: Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: error: open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:53 ubuntuServer2 postfix/smtpd[19931]: error: open /opt/mailman/core/var/data/postfix_lmtp: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: error: open /opt/mailman/core/var/data/postfix_domains: No such file or directory Jul 12 13:48:54 ubuntuServer2 postfix/smtpd[19932]: error: open /opt/mailman/core/var/data/postfix_lmtp: No such file or directory Any thoughts on what the problem is? Have I missed a step?

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

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

2 years, 9 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]

4 months, 3 weeks

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

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

5 years, 5 months

Mailman-users search results for query "Postorius"