Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Timeout in Postorius when trying to approve or reject moderated messages

by Sebastian Hagedorn

Am 27.08.20 um 18:05 schrieb Mark Sapiro: > On 8/27/20 8:07 AM, Sebastian Hagedorn wrote: >> >> Right now everything is running as root (except for Apache). I realized >> too late that I should've used a mailman user. Could that be the reason >> for the issue? > > Since you have determined it was a browser issue, that probably isn't > the reason, but running Mailman as root is a bad idea in general for > security reasons. Thanks, I'm aware, and I'm not going to on a production system. This installation is just a trial run. > I don't know if it's relevant or not, but I have just recently had > issues with Firefox not working properly on two different (not mailman) > web sites, and these issues were fixed by clearing cookies and cached > data from the affected sites and restarting Firefox. I can confirm that that worked in my case as well.

5 years, 1 month

[MM3-users] Re: cache files?

by Dave McGuire

On 7/12/21 10:45 PM, Mark Sapiro wrote: >> Hi folks. I'm seeing quite a few .css files, thousands of them >> totaling 600+MB, building up in /var/lib/mailman3/web/static/CACHE/css. >> Some of them date back to when I set up the mm3 instance a few years ago. >> >> Is this expected, or am I missing a cron job or something to clean >> them up? > > This is not expected. I don't see it on the instances I manage. > > In the `static` directory, I see > ``` > $ du -h -d 1 > 1.7M ./admin > 12K ./facebook > 68K ./django_extensions > 4.0K ./browserid > 68K ./django-mailman3 > 2.6M ./postorius > 12K ./paintstore > 1.6M ./rest_framework > 5.2M ./hyperkitty > 404K ./CACHE > 12M . > $ find -type f|wc > 401 401 18253 > ``` > > I think when you run the Django admin `collectstatic` command, you need > to specify the `--clear` option. Interesting, I know nothing of that command. Is that something that should be run periodically? Thanks, -Dave -- Dave McGuire, AK4HZ New Kensington, PA

4 years, 3 months

[MM3-users] Re: remove non members from a list

by Guillermo Hernandez (Oldno7)

On 6/8/21 19:33, Mark Sapiro wrote: > On 8/6/21 10:28 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > >> Thanks. Now it's no showing errors (and nothing at all) but >> apparently it does nothing. The non mebers of the list (the few that >> remains: I've been deleting one at a time from the web) aparently >> still are there.. >> >> Knowing the correct procedure will ease me to try tomorrow with a >> clean head. > > It doesn't report anything, and if you don't commit() or exit with > control-D, any changes will be rolled back. I think I did a typpo. (forgot to add "()" after the "commit" sentence). And exit with quit() maybe not helps. I've done it exactly as you wrote it and it worked like a charm. Thank you very very much > > What does > > list(m.nonmembers.members) > > show before doing the unsubscribe() and commit() and then what after? >

4 years, 2 months

[MM3-users] Re: Is logging.subscribe working in /etc/mailman.cfg?

by Alan So

Mark Sapiro wrote: > On 12/11/18 2:11 AM, ktso(a)cuhk.edu.hk wrote: > > I have put the following in /etc/mailman.cfg and restart mailman. An > > empty file can be created but nothing can be logged when admin or non-member > > subscribe/unsubscribe. Anything I have missed? So far I can only see log appear in > > mailman.log and smtp.log. Thanks. > > > > [logging.subscribe] > > path: subscribe.log > > level: debug > > The above is correct. As far as not seeing things in the log, very > little is logged in the subscribe log. Only (un)subscription requests > held for moderator approval and moderator approval of held unsubscribes > but not subscribes. > > In other words, unless your list's subscription police includes > 'moderate' nothing will be logged in subscribe.log. It looks like there is only a subscription policy but no unsubscription policy. I can't find anything even by exporting the settings using Python mailman client. Is it correct?

6 years, 10 months

[MM3-users] Re: Mailman web interface / uwsgi

by Jan Eden

On 2022-11-26 22:59, Mark Sapiro wrote: > > Another (unrelated) question: Why is mailman_hyperkitty.cfg placed in > > /opt/mailman/mm and not in /etc/mailman3 with the other configuration > > files when using the virtualenv installation instructions > > (https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… > > > mailman_hyperkitty and its mailman-hyperkitty.cfg are part of mailman core, > not mailman-web. If you want, you could put mailman-hyperkitty.cfg in > /etc/mailman3/ by putting > ``` > configuration: /etc/mailman3/mailman-hyperkitty.cfg > ``` > in the `[archiver.hyperkitty]` section of mailman.cfg, but as it really > belongs to core and not mailman-web we choose to put it in /opt/mailman/mm/. I see. But the mailman.cfg is placed in /etc/mailman3, and this file also belongs to the core, doesn't it? In any case, I changed the configuration parameter for [archiver.hyperkitty] as you suggested and all settings are in one place now. I will post two more questions to this list today, and promise to stop spamming you afterwards. :) Thanks again, Jan

2 years, 10 months

[MM3-users] Re: Sending to mangled 'From' addresses.

by Jeremy Stanley

On 2024-06-01 09:49:54 -0700 (-0700), Mark Sapiro wrote: [...] > If this is the result of a `reply` and not `reply-all` the client > is not behaving reasonably. [...] I haven't seen it with replies, but rather mail clients recording every address they see into their address book, and then when the user of such a client wants to send new mail to someone they start typing that person's name and their mail client happily auto-completes it with the mailing list's address instead of the intended personal address. This is one of the reasons we don't use DMARC mitigations for most of our lists, and instead we just try to make Mailman avoid altering anything in the message headers or body that might invalidate DKIM signatures (so no changing From or Reply-To, no adding list-specific subject prefixes, no appending list unsubscribe info to the end of messages...). It's an unfortunate trade-off, but some of our users do tend to get confused by address book pollution. -- Jeremy Stanley

1 year, 4 months

[MM3-users] Re: Uncaught runner exception: 'str' object has no attribute 'decode'

by Mark Sapiro

On 09/28/2017 06:11 AM, Henrik Rasmussen wrote: > Sep 25 07:20:57 2017 (35) Uncaught runner exception: 'str' object has no attribute 'decode' > Sep 25 07:20:57 2017 (35) Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/runners/pipeline.py", line 37, in _dispose > process(mlist, msg, msgdata, pipeline) > File "/usr/local/lib/python3.6/site-packages/mailman/core/pipelines.py", line 53, in process > handler.process(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/handlers/subject_prefix.py", line 174, in process > mlist, msgdata, subject, prefix, prefix_pattern, ws) > File "/usr/local/lib/python3.6/site-packages/mailman/handlers/subject_prefix.py", line 72, in all_same_charset > chunks.append(chunk.decode(charset)) > AttributeError: 'str' object has no attribute 'decode' > Sep 25 07:20:57 2017 (35) SHUNTING: 1506324057.584686+a13cc47dc1027a0cfb00c892396b3ba7efabb3dc This is <https://gitlab.com/mailman/mailman/issues/359> It is fixed in the current source by <https://gitlab.com/mailman/mailman/commit/e92359323cda1fb118415c2ccb6967979…>. > In addition, the log contains other trace backs that might or might not associate to this problem: > > Sep 24 21:11:27 2017 (34) Uncaught runner exception: 'ascii' codec can't encode character '\udcea' in position 3093: ordinal not in range(128) > Sep 24 21:11:28 2017 (34) Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/runners/outgoing.py", line 93, in _dispose > self._func(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/deliver.py", line 86, in deliver > refused = agent.deliver(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/bulk.py", line 101, in deliver > mlist, msg, msgdata, recipients) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/base.py", line 70, in _deliver_to_recipients > sender, sorted(recipients), msg.as_string()) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/connection.py", line 84, in sendmail > results = self._connection.sendmail(envsender, recipients, msgtext) > File "/usr/local/lib/python3.6/smtplib.py", line 855, in sendmail > msg = _fix_eols(msg).encode('ascii') > UnicodeEncodeError: 'ascii' codec can't encode character '\udcea' in position 3093: ordinal not in range(128) > Sep 24 21:11:28 2017 (34) SHUNTING: 1506287488.0529234+cbf8a31cad265a40a18e8955be0c9ad8b48a1b66 This may be a bug. The msgtext argument in 'self._connection.sendmail(envsender, recipients, msgtext)' is supposed to be a string containing only ascii characters. I'm interested in what's in Mailman's var/queue/shunt/1506287488.0529234+cbf8a31cad265a40a18e8955be0c9ad8b48a1b66.pck. You may be able to print the contents with Mailman's bin/mailman queue var/queue/shunt/1506287488.0529234+cbf8a31cad265a40a18e8955be0c9ad8b48a1b66.pck There shouldn't be raw unicodes like \udcea in the text of the message, but we should defend against that anyway. > Sep 25 07:20:57 2017 (35) Uncaught runner exception: 'str' object has no attribute 'decode' Same as above. > Sep 25 09:19:58 2017 (30) deque: do_confirm_verify > Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/app/workflow.py", line 69, in __next__ > return step() > File "/usr/local/lib/python3.6/site-packages/mailman/app/subscriptions.py", line 420, in _step_send_confirmation > raise StopIteration > StopIteration This is normal. It is not an issue. > Sep 26 09:21:07 2017 (36) deque: > Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/app/workflow.py", line 69, in __next__ > return step() > File "/usr/local/lib/python3.6/site-packages/mailman/app/subscriptions.py", line 217, in _step_sanity_checks > MemberRole.member) > mailman.interfaces.member.AlreadySubscribedError: sender(a)foo.bar is already a MemberRole.member of mailing list listname(a)listserver.foo.bar This appears to be an attempt to subscribe someone who's already a member. This should have resulted in an appropriate message to the attempted subscriber. > Sep 26 13:32:29 2017 (30) Uncaught runner exception: > Sep 26 13:32:29 2017 (30) Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/runners/command.py", line 196, in _dispose > mlist, msg, msgdata, parts, results) > File "/usr/local/lib/python3.6/site-packages/mailman/commands/eml_confirm.py", line 53, in process > mlist).confirm(token) > File "/usr/local/lib/python3.6/site-packages/mailman/app/subscriptions.py", line 540, in confirm > PendableUnsubscription.PEND_TYPE) > AssertionError I'm not sure about this one. a message has been sent to the LISTNAME-confirm address to confirm a subscription or unsubscription. The confirmation token exists but is neither a pending subscription or unsubscription token. > Sep 27 13:23:02 2017 (32) Uncaught runner exception: 'content-transfer-encoding' > Sep 27 13:23:02 2017 (32) Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/runners/outgoing.py", line 93, in _dispose > self._func(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/deliver.py", line 86, in deliver > refused = agent.deliver(mlist, msg, msgdata) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/bulk.py", line 101, in deliver > mlist, msg, msgdata, recipients) > File "/usr/local/lib/python3.6/site-packages/mailman/mta/base.py", line 70, in _deliver_to_recipients > sender, sorted(recipients), msg.as_string()) > File "/usr/local/lib/python3.6/email/message.py", line 158, in as_string > g.flatten(self, unixfrom=unixfrom) > File "/usr/local/lib/python3.6/email/generator.py", line 116, in flatten > self._write(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 181, in _write > self._dispatch(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 214, in _dispatch > meth(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 272, in _handle_multipart > g.flatten(part, unixfrom=False, linesep=self._NL) > File "/usr/local/lib/python3.6/email/generator.py", line 116, in flatten > self._write(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 181, in _write > self._dispatch(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 214, in _dispatch > meth(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 358, in _handle_message > g.flatten(msg.get_payload(0), unixfrom=False, linesep=self._NL) > File "/usr/local/lib/python3.6/email/generator.py", line 116, in flatten > self._write(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 189, in _write > msg.replace_header('content-transfer-encoding', munge_cte[0]) > File "/usr/local/lib/python3.6/email/message.py", line 558, in replace_header > raise KeyError(_name) > KeyError: 'content-transfer-encoding' > Sep 27 13:23:02 2017 (32) SHUNTING: 1506518582.300981+aa68949ca566c7170a81a0bd643cee803f29c312 As I said in a prior reply, this is <https://gitlab.com/mailman/mailman/issues/256>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years

[MM3-users] Re: Can't subscribe on new site/domain

by Flo

On 10/11/25 00:18, Mark Sapiro wrote: > On 10/10/25 1:47 PM, Flo via Mailman-users wrote: >> >> :/var/lib/mailman3/data# sqlite3 mailman.db >> SQLite version 3.46.1 2024-08-13 09:16:08 >> Enter ".help" for usage hints. >> sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON >> site_id = django_site.id; >> Parse error: no such table: django_mailman3_maildomain >> sqlite> > > Is there a second database? Something like mailmanweb.db. If so, use > that one. > I found it, it's in a different directory: /var/lib/mailman3/web# sqlite3 mailman3web.db SQLite version 3.46.1 2024-08-13 09:16:08 Enter ".help" for usage hints. sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON site_id = django_site.id; ... ... 8|lists.example.com|7|7|Lists of Example|lists.example.com sqlite> The two working domains are first (...) . The problematic domain (renamed to lists.example.com) appears when I create it in Postorius. For me the only conspicuous is that the numbers are 8|.|7|7 while at the other two entries they are the same for the whole line: 2|.|2|2 and 4|.|4|4 . Flo

2 weeks

[MM3-users] Re: Strange issue with bounce processing

by Brian Carpenter

On 12/25/20 10:07 PM, Mark Sapiro wrote: > On 12/25/20 6:36 PM, Brian Carpenter wrote: >> Dear List, >> >> First of all Merry Christmas to those of you that are observing it. >> >> I have an issue on one of my Mailman 3 servers. The bounce runner is not >> running, even after restarting mailman core. All the other runners are >> working fine. Here is the problem, after restarting it, a number of >> messages show up in queue/bounces from a single list. > > What happens if instead of restating core, you stop and then start it? Same behavior. > I don't really understand what's going on. The only messages which get > queued in queue/bounces/ are messages to the LIST-bounces address > delivered from the MTA, unless possibly they are somehow in queue/retry/ > and being retried. What do you see in the MTA logs? > The mail logs shows bounce notifications being sent out as per the list settings. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 9 months

[MM3-users] Unnecessary coded-words? [was: Shorted Subjects in Mailman]

by Stephen J. Turnbull

Mark Sapiro writes: > However, I did a test injecting directly to Mailman a message with > ``` > Subject: [SAV-LINUX] Notice from Sophos_Anti-Virus on server.example.com > [DEMO1] > ``` > on a German language test list with subject prefix [Janinsliste] and I > get the same result, I.e. the RFC 2047 encoded > ``` > Subject: > =?utf-8?q?=5BJaninsliste=5D=5BSAV-LINUX=5D_Notice_from_Sophos=5FAnti-Virus_on_server=2Eexample=2Ecom?= > ``` > so this is definitely a Mailman bug (or a bug in the underlying Python > email package. There seem to be other bugs here. First, I can't see any content-based reason for encoding this 100% ASCII content. I guess the list is set to always encode the subject prefix, and we just encode the whole field body if any part is encoded? Perhaps this is a quick workaround for the OP: set MIME-encoding for the subject prefix to "as needed". Second (and this is important because of RFC conformance!), the encoded word is over 75 characters. I've filed https://gitlab.com/mailman/mailman/-/issues/1021 for this.

3 years, 2 months

Search results for query "sapiro"