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

[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

11 months, 3 weeks

[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

7 years, 7 months

[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, 4 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.

2 years, 9 months

[MM3-users] Re: Mailman not able to process "big" requests

by Darren Smith

Our installation at https://lists.rootsweb.ancestry.com has around 33,000 lists and somewhere around 1.5 million members. We have lists with 5,000+ members. Note that I haven't tried any mass subscriptions. When we upgraded from mailman 2 to mailman 3, we used the old .pck files and ran the import on each of the lists. It did take about 6 weeks to do the full import all 33,000 lists. I'm not joking. As for sending messages - there isn't any problem sending that many messages out, but then we are also not trying to subscribe list members at the time. We are, though, in the process of importing the old archives from our old mailman 2 system. This doesn't seem to affect the rest of the system. We have seen some inefficiencies in the new system, such as the front page of postorius - loading all of the information for 200 lists (if the user set the "lists per page" to 200) was bringing down the system. We have our own metadata system to be able to search for lists by state/region/surname (ours is a genealogy mailing list system), so we had to replace the front page with our own "find a list" functionality. The other main problem was the page where a user can see what lists they subscribe to. That page was also a denial of service if the user had several hundred lists they are subscribed to. And for a genealogy mailing list system, this is common. We have actually ended up creating our own API layer (only accessible on the local machine) and make certain calls to it for the most painful of the issues. One of these days (when we get a moment to breathe) we are going to post some of our changes to the project so that we can ditch our own API and just use the internal REST API. To be fair, the inefficiencies are not necessarily with mailman or the rest API itself - but with Postorius making hundreds of calls to load a single page. Though if the API supported loading multiple lists at once instead of having to load them serially, that might help as well. So while we have not seen any timeout issues on the call to mass subscribe users, we HAVE found several other calls that are effectively a denial of service and have gotten around them ourselves, with plans to contribute to the project in the near future. -Darren On Tue, Apr 24, 2018 at 8:47 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 04/24/2018 12:36 AM, Abhilash Raj wrote: > > On Mon, Apr 23, 2018, at 10:41 PM, Jonas Felber wrote: > > >> We also have a problem with sending out emails to "large" (>50) groups, > >> as they seem to not getting sent out at all. Do you have any idea what > >> the problem here could be? > > > > Which MTA are you using? What do you see in mailman's logs and MTA's > logs? > > > > I haven't seen this kind of problem before with Mailman 3. This very > list is hosted using Mailman 3 and I believe has more than 50 subscribers. > > > Nor have I seen this issue. This list currently has 158 non-digest > members. There are several @python.org Mailman 3 lists with over 100 > non-digest members including the active yt-users(a)python.org list with > 301 members, and I have gotten no reports of an issue like this. > > Also, there are over 600 lists at <https://lists.fedoraproject.org/>, > and I don't think this is an issue there either. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

7 years

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

by Henrik Rasmussen

Thanks, Mark. @Abhilash, any chance for an update to Docker-mailman to fix these known issues soon? https://gitlab.com/mailman/mailman/issues/256 https://gitlab.com/mailman/mailman/issues/359 @Mark, Mark Sapiro wrote: >>> 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) >> >> 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 Isn't this a Mailman 2 command? What is the Mailman 3 equivalent? -- Henrik Rasmussen <her(a)adm.ku.dk> University of Copenhagen, Danmark

7 years, 7 months

[MM3-users] Re: How to fix: [Django] ERROR (EXTERNAL IP)

by Jigme Datse

On Fri, 1 Nov 2024 20:56:42 -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 11/1/24 20:14, Jigme Datse wrote: > > > > python venv/lib/python3.12/site-packages/mailman_web/manage.py > > migrate > > > > which *might* be the wrong manage.py but other than the change with > > the migrate command, without it looks to throw the same output. > > > > The Django log was at that time empty it's now attached (larger than > > I'd like). > > It is not necessary to post the entire log which repeats the same > ERROR and traceback over 300 times. The errors all seem to be > disallowed hosts. 321 from IP 45.79.102.219, 5 from > mail01.datsemultimedia.com and a few others. The PTR from IP > 45.79.102.219 is mail01.datsemultimedia.com and its A is > 45.79.102.219. Is this your server, if so add both 45.79.102.219 and > mail01.datsemultimedia.com to ALLOWED_HOSTS. > Thank you... I while helpful, I think I'll abandon this project... Appreciate the help.

6 months, 3 weeks

[MM3-users] Re: Mailman3-Web lots of database queries

by Stefan Tatschner

On Sun, 2018-11-18 at 14:38 -0800, Mark Sapiro wrote: > No. This is not normal. This is apparently coming from Django qcluster. > At least it is qcluster that uses the django_q_ormq table, but these > repeated queries are not normal, at least I don't see them in the sites > I administer. Thank you for the pointer to qcluster. I don't know so much about these web components and their relationships. According to the documentation [1] it seems that qcluster is not needed as long as cronjobs are configured. Since debian ships the entries in /etc/cron.d [2, 3] I disabled the qcluster components. Also there is a debian package issue; qcluster is started twice when using the provided service files: * the uwsgi script ini starts qcluster * the mailman3-qcluster service starts it as well I know the debian thing is out of scope here, I just want it documented somewhere. Stefan [1]: https://hyperkitty.readthedocs.io/en/latest/install.html#asynchronous-tasks [2]: https://gitlab.com/mailman/hyperkitty/blob/master/example_project/crontab [3]: https://salsa.debian.org/mailman-team/mailman-suite/blob/master/debian/mail…

6 years, 6 months

[MM3-users] Re: import21: ModuleNotFoundError: No module named 'Mailman'

by Christian Schwarz

On Sun, 2019-07-28 at 17:07 -0700, Mark Sapiro wrote: > As to how to proceed, there are a couple of ways. One is to fix import21 > so it ignores this issue. I just reported > <https://gitlab.com/mailman/mailman/issues/618> on this, but I'm not > sure how to fix it. I don't think it will work to try the pickle.load > and pass the ModuleNotFoundError exception because I think the rest of > the pickled data won't be returned. > > It looks like you still have the MM 2.1 installation, so you could use > either MM 2.1's bin/withlist or bin/config_list to set the list's > bounce_info to an empty dictionary. and then use the updated config.pck > for the import. > > This assumes that bounce_info is the issue. You can verify that there is > a non-empty bounce_info dictionary with either bin/withlist or bin/dumpdb. Indeed, bounce_info is not empty! I think I need more precise instructions on how to empty bounce_info using config_list, though.

5 years, 9 months

[MM3-users] Re: An archive/read-only list on a full setup?

by Andreas Schamanek

Thanks a lot, Mark! After some tests with a test setup I came to the conclusion that what you suggested was better than what I had so far (i.e. the empty Mailman list). So, I deleted the empty list, leaving only the Hyperkitty list. On Tue, 11 Apr 2023, at 11:22, Mark Sapiro wrote: > Since there is no Mailman list, attempts to post or reply directly from > HyperKitty will fail, ... Yep, I get a 404. Doesn't look nice but should be OK. Not many people will try, and the description of the list makes clear that it is only an archive. I have also added a Redirect on the webserver so that people who click [Manage subscription/this list] are redirected to the actual remote list. That helps, too. So, no fake list, and the link to subscribing still works. The particular list is low volume. So, it will take some time until I can report how well it worked out. But after my tests I am confident. Thanks again, -- -- Andreas :-)

2 years, 1 month

Search results for query "sapiro"