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

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Mark Sapiro

On 1/24/22 15:06, Mark Sapiro wrote: > On 1/18/22 06:24, Stephan Krinetzki wrote: >> Hello, >> >> We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is >> installed in a venv and deployed using Apache and uwsgi. This works >> quite well so far, only withheld messages cause us a problem: If we >> try to approve them via Postorius, the message is delivered to the >> list immediately, but the success message in Postorius takes a long >> time - on average the process hangs for three minutes until the >> message is no longer displayed. We have already adjusted the timeout >> in gunicorn.cfg, but this does not improve the situation. Are there >> any tips on how we can speed up the REST API? Or is it even a >> configuration error? > > > There are two steps in handling the POST for a held message. The first > step is accepting, rejecting or discarding the message. This is > happening immediately. > > The second step is handling the poster's moderation action based on the > choice from the Set member moderation dropdown in the view of the held > message. This is processed by the code at > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…>. > If no selection has been made, the default value POSTed for > moderation_choice is `no-action` and that code is skipped. If it is one > of the choices `Hold for moderation`, `Reject (with notification)`, > `Discard (no notification)`, `Accept immediately (bypass other rules)` > or `Default processing` that is processed. So presumably a selection has > been made and processing is stuck on getting the member or setting the > member's moderation action. > > Possibly the logs of your database manager will have information. > Some additional info. By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?. Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: New Mailman 3 installation issues

by Mark Sapiro

On 5/19/21 1:26 PM, Sarah H wrote: > I think you've just hit the nail on the head as far as my biggest issue with this project. The documentation lays out an install method that should be roughly followable for anyone (though it needs a bit of fine tuning here and there) and then the rest of the configuration guide and documentation assumes that you have installed the software in a completely different way and doesn't work the same as the guide laid out. Because virtually all that documentation was written by different people and long before the https://docs.mailman3.org/en/latest/install/virtualenv.html was added. > The documentation should be uniform, if you want users to install it one way then write the guide and documentation so that's the "default". Sure present alternatives or notes "if you've installed via git, your commands will look like this xxx" but ultimately the biggest issue I've had with getting this deployed is inconsistent or lacking documentation. I'm not trying to make excuses. I know the docs need improvement, but we are a very small, all volunteer project doing the best we can. If you feel you can offer improvements to the documentation, we'd love to have your help. You are more than welcome to submit merge requests to update the docs. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Importing archive from mm21

by Mark Sapiro

On 11/27/23 13:01, Lars Bjørndal wrote: > I imported an archive from a list created in September 2013 with the > following command: > > mailman-web hyperkitty_import -l annonsering(a)hodr.no --since 2013-09-01 <mbox file> If it's a new list with no current archive, I typically don't use --since. If there might be messages in the archive, I normally use something like `--since 1970-01-01` just to be sure I get everything. > No errors reported. And this should have imported all messages with Date: header dates >= 2013-09-01 plus any without Date: headers. > I then did > > mailman-web update_index_one_list annonsering(a)hodr.no > > No, when I go to https://hodr.no/archives/list/annonsering@hodr.no/, I > cannot choose mails earlier than January 2023. > > What's the problem, do you think? The messages are there. I went to https://hodr.no/archives/list/annonsering@hodr.no/ and only saw messages from 2023, but then I went to https://hodr.no/archives/list/annonsering@hodr.no/latest?count=200&page=2 and started seeing all the messages even at https://hodr.no/archives/list/annonsering@hodr.no/. What do you see now? I also note your pages seem to be missing the styling as the references to the styles, etc at https://hodr.no/static/* all return 404. Is the issue fixed for you now? I don't understand what caused the issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years

[MM3-users] Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 02:59 PM, Darren Smith wrote: > Well, using the mailman shell we were able to find the request that was > causing the problem - it was apparently a spam message that had some > chinese characters in it. I am trying to duplicate this issue in a test environment. I can create a message with an invalid RFC 2047 encoded subject, i.e., Subject: =?gb2312?Q?=ff=fe=de=21=a2?= and send it to a list where it gets held, but I don't get a 500 in postorius and I see the held message with a raw (not decoded) header. I think there were some recent changes that affect this. I'll look some more. > We used the shell to delete the held request... > > And postorius is still giving me an error 500. > > If I'm not mistaken the held messages are kept in .pck files - do you know > if when postorius asks for held messages through the API, does mailman go > to the database or to the .pck? I would actually suspect the latter, or > removing the request should have fixed the problem. They were held in .pck files in Mailman 2.1, but not in Mailman 3. They should just be in the database and deleting them via mailman shell should delete them as long as you quit the shell or commit(). -- 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: mass subscribers disablement!?

by Mark Sapiro

On 10/22/21 2:07 PM, Christian Stalberg via Mailman-users wrote: > I added the additional hosts to ALLOWED HOSTS in settings_local.py and > mailman is distributing mail to subscribers again. However, I then received > many emails of valid users subscriptions being disabled. What would cause > that? Did you just upgrade Mailman core from a version <=3.3.0 to one >=3.3.1? If so, see https://lists.mailman3.org/archives/list/mailman-users(a)mailman3.org/threa… > Can subscriber management be done via command line? See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d… for description of the available mailman subcommands. If you are interested in re-enabling delivery for members whose delivery is disabled by bounce, you can do this fairly easily in an interactive `mailman shell` session. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d… Something like the following session: ``` $ bin/mailman shell Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> lm = getUtility(IListManager) >>> for mlist in lm.mailing_lists: ... for member in mlist.members.members: ... if member.delivery_status == DeliveryStatus.by_bounces: ... member.preferences.delivery_status = DeliveryStatus.enabled ... print("Re-enabled delivery for bouncing member {} on list {}" ... .format(member.address.email, mlist.list_name)) ... <print output here> >>> commit() >>> exit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: Installed from Howto_Install_Mailman3_On_Debian10, web not quite working

by Mark Sapiro

On 5/7/23 10:51, Volkmar Grote wrote: > thanks for the quick reply. > I am one step closer to a solution, > "http://127.0.0.1:8000/postorius/lists/?all-lists#" seems to work now. > I get the functionality, but it looks ugly w/o any graphics, for which I > get yet another, slightly similar, error message: >> >> >> Page not found (404) >> >> Request Method: GET >> Request URL: >> http://127.0.0.1:8000/static/postorius/img/mailman_logo_small_trans.png >> >> ... > > Nginx, /etc/nginx/conf.d/me.domain.de.conf >> server { >> listen 80; >> listen [::]:80; >> >> server_name me.domain.de; >> ... >> location /static/ { >> alias /opt/mailman/mm/static/; >> } > > Again, many thanks in advance for any clue The above in nginx is correct, but you aren't getting the static files via nginx. You need to go to a URL like http://me.domain.de/postorius/lists/. Going to http://127.0.0.1:8000/postorius/lists/ goes directly to your wsgi server and doesn't involve nginx at all. You need to go to port 80 where nginx is listening and nginx then proxys requests to 127.0.0.1:8000. Do you also have location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } in /etc/nginx/conf.d/me.domain.de.conf. You need that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

[MM3-users] Re: statistics monitoring for Mailman3

by Mark Sapiro

On 3/15/21 12:39 PM, Mohsen Masoudfar wrote: > Hi Mark, > > Thanks again for the nice Python script. There is an issue with outlook.com. They add a '^M' (carriage Return) before msgid!! > Here is part of the log that shows that. This is not in every log, though. I updated the get_log_data function (please see below), I believe it is not the smartest solution, but it seems to be working for me. Does the script with your change produce a different result than the original? This has nothing to do with outlook.com per se. It only has to do with the length of the log message. Further, I do not think there are actually newlines in these log messages. I think that is just an artifact of how you are viewing the log. > Mar 14 12:53:21 2021 (11701) > <MN2PR20MB324587763E970CC56351F8C5B66D9(a)MN2PR20MB3245.namprd20.prod.outlook.com> smtp to testlist3(a)newlistserv.aaas.org for 1 recips, completed in 0.013000726699829102 seconds I suspect if you do ``` grep namprd20.prod.outlook.com /path/to/var/logs/smtp.log ``` The result will be lines like ``` > Mar 14 12:53:21 2021 (11701) <MN2PR20MB324587763E970CC56351F8C5B66D9(a)MN2PR20MB3245.namprd20.prod.outlook.com> smtp to testlist3(a)newlistserv.aaas.org for 1 recips, completed in 0.013000726699829102 seconds ``` whereas if they are really split, the result would be ``` > <MN2PR20MB324587763E970CC56351F8C5B66D9(a)MN2PR20MB3245.namprd20.prod.outlook.com> smtp to testlist3(a)newlistserv.aaas.org for 1 recips, completed in 0.013000726699829102 seconds ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

[MM3-users] Re: Issues with cross posted emails after upgrading to mailman 3.3.6

by Mark Sapiro

On 11/4/21 1:02 AM, Simon Coggins wrote: > > All I’m doing is literally appending a subset of a hash of the mailing list rcpt address to the front of the message-id, so that if it gets moderated, each instance of the email has a different message-id and each moderation action has it’s own copy of the email to operate on. This seems to have gotten us out of the immediate issues. But I’m eager to find a better solution that might be more permanent. As you have seen, this is new in 3.3.5. I recognize this is a problem. Previously, attempts to accept the message on the second and subsequent lists would throw an uncaught exception - see https://gitlab.com/mailman/mailman/-/issues/914 and this was a fix for that. Please file an issue for this at https://gitlab.com/mailman/mailman/-/issues and I will try to find a better solution. Your approach of munging Message-IDs will create other issues. Consider a post to a list with direct CC to userx. userx replies-all to the message received directly. the In-Reply-To of this reply is the unmunged Message-ID which will affect threading in the archives and other recipient's MUAs. I realize this is preferable to losing the message, but I hope we can do better. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: No emails distributed after mail received for a new list following https://docs.list.org/en/latest/install/virtualenv.html on new mailman3 Debian 12 installation

by Mark Sapiro

On March 26, 2025 3:28:27 AM GMT+07:00, Philip Bondi <pjbondi(a)systemdatabase.com> wrote: > >My list is named ebill. An email was received for the DL, but not distributed. Can you advise how to troubleshoot from here? > >Mar 25 15:23:04 shackleton12 postfix/smtpd[247708]: connect from smtprelay0015.hostedemail.com[216.40.44.15] >Mar 25 15:23:04 shackleton12 postfix/smtpd[247708]: Anonymous TLS connection established from smtprelay0015.hostedemail.com[216.40.44.15]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256 >Mar 25 15:23:04 shackleton12 postfix/smtpd[247708]: 3CD47189B: client=smtprelay0015.hostedemail.com[216.40.44.15] >Mar 25 15:23:04 shackleton12 postfix/cleanup[247722]: 3CD47189B: message-id=<a7aee014-f200-4bd4-bbc4-bc9f37abb6df(a)systemdatabase.com> >Mar 25 15:23:04 shackleton12 postfix/qmgr[241822]: 3CD47189B: from=<pjbondi(a)systemdatabase.com>, size=3238, nrcpt=1 (queue active) >Mar 25 15:23:04 shackleton12 postfix/smtpd[247708]: disconnect from smtprelay0015.hostedemail.com[216.40.44.15] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 >Mar 25 15:23:04 shackleton12 postfix/lmtp[247723]: 3CD47189B: to=<ebill(a)systemdatabase.ca>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.29, delays=0.06/0.03/0.02/0.19, dsn=2.0.0, status=sent (250 Ok) >Mar 25 15:23:04 shackleton12 postfix/qmgr[241822]: 3CD47189B: removed The above says the message was successfully delivered to Mailman's LMTP runner. Is it queued in one of Mailman's queue/* queued? Check mailman.log for info. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

8 months, 2 weeks

[MM3-users] Re: disable body transcoding

by Mark Sapiro

On 9/22/21 9:02 AM, Markus Schaaf wrote: > Hi, > > I have disabled all message modifications and filtering from within the > webUI, and created empty header and footer template files. Still, some > list messages get their body encoding changed to base64, breaking DKIM. > What can I do to prevent this? (I'm a newbie to mailman3, so please give > somewhat complete commands. I have read other threads with similar > questions, but did not understand some shortened configuration commands.) This is probably due to the message body charset being utf-8. The Python email library used by Mailman encodes utf-8 message bodies as base64. There are no configuration settings in Mailman to avoid this. Calling email.charset.add_charset('utf-8') at some point in Mailman's processing might avoid this. E.g. ``` --- a/src/mailman/handlers/validate_authenticity.py +++ b/src/mailman/handlers/validate_authenticity.py @@ -23,6 +23,7 @@ import logging from authheaders import authenticate_message from authres import AuthenticationResultsHeader, SyntaxError from dns.resolver import Timeout +from email.charset import add_charset from itertools import chain from mailman.config import config from mailman.core.i18n import _ @@ -121,5 +122,7 @@ class ValidateAuthenticity: def process(self, mlist, msg, msgdata): """See `IHandler`.""" + # Try to avoid base64 encoding of utf-8. + add_charset('utf-8') if config.arc_enabled: authenticate(msg, msgdata) ``` Note this is just a guess and could be a disaster so test it before trying it in production. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Search results for query "sapiro"