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

[MM3-users] Re: The msgtext argument in 'self._connection.sendmail(envsender, recipients, msgtext)' is supposed to be a string containing only ascii characters.

by Mark Sapiro

On 10/03/2017 12:54 AM, Henrik Rasmussen wrote: > Hi Mark. > > This was originally from another thread https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…, but as it isn't related to the problem in the thread, I'll split it in another thread. > > On 09/29/2017 05:46 AM 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) >>> 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. > > [root@lstapp01pl ~]# docker exec -it mailman-core mailman qfile var/queue/shunt/1506287488.0529234+cbf8a31cad265a40a18e8955be0c9ad8b48a1b66.pck > [----- start pickle -----] > <----- start object 1 -----> > Traceback (most recent call last): > File "/usr/local/bin/mailman", line 11, in <module> > sys.exit(main()) > File "/usr/local/lib/python3.6/site-packages/mailman/bin/mailman.py", line 100, in main > args.func(args) > File "/usr/local/lib/python3.6/site-packages/mailman/commands/cli_qfile.py", line 81, in process > printer.pprint(obj) > File "/usr/local/lib/python3.6/pprint.py", line 139, in pprint > self._format(object, self._stream, 0, 0, {}, 0) > File "/usr/local/lib/python3.6/pprint.py", line 176, in _format > stream.write(rep) > UnicodeEncodeError: 'utf-8' codec can't encode character '\udcea' in position 3025: surrogates not allowed And I have an MR to defend against this. See all of the following: <https://gitlab.com/mailman/mailman/issues/406> <https://gitlab.com/mailman/mailman/merge_requests/322> <https://gitlab.com/mailman/mailman/issues/410> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 1 month

[MM3-users] Re: Hyperkitty no longer archiving

by Hirayama, Pat

Thank you, Mark! > -----Original Message----- > From: Mark Sapiro <mark(a)msapiro.net> > Sent: Tuesday, November 22, 2022 3:37 PM > To: mailman-users(a)mailman3.org > Subject: [MM3-users] Re: Hyperkitty no longer archiving > <snip> > > Does that directory also contain __init__.py (probably empty)? It should. > That was it! No __init__.py in /opt/mailman/mailman-suite/mailman-suite_project. Creating an empty file there and restarting the containers caused hyperkitty to start archiving all of the queued messages. Thank you for your time, and Happy Thanksgiving! -p > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering Fred Hutchinson Cancer Center O 206.667.4856 phirayam(a)fredhutch.org

2 years, 11 months

[MM3-users] Re: Configure MM3 with separate IMAP Mailserver

by Mark Sapiro

On 1/2/23 11:18, Clemens Leider wrote: > Hi Mark, much appreciated! This is for sending messages, right? How about the recieving part…I read different things around that i need multiple mailboxes created, postfix installed, relays, ASMTPDirect etc…can you guide me a bit here, please? I havent found that one instruction that would solve this for me until now. Would just like to avoid to have to administer my own mailserver locally, if i have a perfectly configured one with my provider. CL Yes, what I posted is for outgoing mail from Mailman. Incoming mail is much more difficult. There are threads on this in the archives of this list. E.g., <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> The incoming MTA needs to relay the mail to Mailman's LMTP server for every address - that's 9 addresses per list. An example postfix transport_maps for one list is: ``` list(a)example.com lmtp:[127.0.0.1]:8024 list-bounces(a)example.com lmtp:[127.0.0.1]:8024 list-confirm(a)example.com lmtp:[127.0.0.1]:8024 list-join(a)example.com lmtp:[127.0.0.1]:8024 list-leave(a)example.com lmtp:[127.0.0.1]:8024 list-owner(a)example.com lmtp:[127.0.0.1]:8024 list-request(a)example.com lmtp:[127.0.0.1]:8024 list-subscribe(a)example.com lmtp:[127.0.0.1]:8024 list-unsubscribe(a)example.com lmtp:[127.0.0.1]:8024 ``` This relays mail to those addresses to Mailman's LMTP server listening on the localhost, port 8024. If you could arrange for the external IMAP server to do that, that would work, but I suspect you don't have access to even try. For MM 2.1 which is different in that it doesn't use LMTP in this way, some people have used fetchmail <https://www.fetchmail.info/> to do things like this. This requires setting up mailboxes on the remote server to receive the mail and using fetchmail to retrieve that mail and relay it to Mailman. The issues with this are keeping the remote mailboxes and fetchmail in sync with Mailman as lists are created and removed. Another possibility is to have all your lists in a dedicated domain and configure the remote MTA to forward all mail to that domain to the Mailman host and then configure an MTA on the Mailman host to simply relay all mail to Mailman via LMTP. -- 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

[MM3-users] Re: moving lists to another server

by Mark Sapiro

On 11/21/23 04:32, Odhiambo Washington wrote: > > I tested the above out of curiosity. It failed. There are 9 lists in the > setup, but I am only interested in 1. > > ``` > (venv) mailman@debian12:~$ mailman-web shell > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] > Type 'copyright', 'credits' or 'license' for more information > IPython 8.17.2 -- An enhanced Interactive Python. Type '?' for help. > > In [1]: from hyperkitty.lib.compat import get_list_by_name > > In [2]: mlist = get_list_by_name('list_name_only', 'list_domain') You can't use literally ('list_name_only', 'list_domain'). If the list of interest is for example alist(a)example.com, the above should be mlist = get_list_by_name('alist', 'example.com') ... > Was I supposed to substitute something for the real listname of the list I > wanted? Yes. > Another thing - totally unrelated - that surprised me: > While using the commented-out block below, I could not click and get > anything beyond http://http://list.name/mailman3 as anything to do with > /postorius/xxxxx gave "Page not found" error. > However, with the second config block that uses the UNIX socket, I am able > to access everything > > ``` > #<IfModule mod_proxy.c> > # ProxyPreserveHost On > # ProxyPass "/mailman3" "http://127.0.0.1:8010/mailman3" > # ProxyPass "/archives" "http://127.0.0.1:8010/archives" > # ProxyPass "/accounts" "http://127.0.0.1:8010/accounts" > # ProxyPass "/admin" "http://127.0.0.1:8010/admin" > # ProxyPass "/user-profile" "http://127.0.0.1:8010/user-profile" > # </IfModule> > > ProxyPassMatch ^/static/ ! > ProxyPassMatch ^/favicon.ico ! > ProxyPass / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/ > ProxyPassReverse / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/ > ``` > > Why is it that the UNIX socket option worked flawlessly while the other > option failed??? The first option does not have ProxyPass for urls matching /postorius or /hyperkitty so such urls don't work. The second option passes everything (ProxyPass / ) to uwsgi via the socket so all urls that uwsgi can handle will work. You could do something similar with the first option with simply ProxyPass "/" "http://127.0.0.1:8010/" assuming uwsgi is listening on port 8010. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: List in list, mutiple reply-to addresses

by Stefan Bauer

That is already set. No change. This completely removes the reply-to: header and sets the iu-all list-address as new and only reply-to. Am Mi., 24. Nov. 2021 um 04:18 Uhr schrieb Mark Sapiro <mark(a)msapiro.net>: > On 11/23/21 2:24 AM, Stefan Bauer wrote: > > Unfurtunately, this completely removes the reply-to: header and sets the > > list-address as a new and only reply-to. > > Set Settings -> Alter Messages -> Reply goes to list to No Munging > in addition to First strip reply to = Yes > > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

3 years, 11 months

[MM3-users] Re: Docker Support Sucks

by Mark Sapiro

On 7/21/20 5:40 PM, Brian Carpenter wrote: > Ok, now that I got that out of the way. Maybe I can get some help here for a Docker Installation of Mailman 3. Abhilash (@maxking) is one person and he has a $DayJob. We're all doing the best we can. > I updated a Maxking's Docker installation to Postorius 1.3.3. It made my client's list unusable to a continual stream of removals due to ghost bounce processes. This is not a Docker issue per se. It is a consequence of upgrading Mailman core to 3.3.1+ and processing many old, stale, previously unprocessed bounces. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> > So, I want to totally move away from the use of Docker (mainly because I have found it buggy and the support is simply lacking) and install Mailman 3 for this client from source. However I need to get an export of their list members. But of course, I can't. Rest API times out and I don't know how to apply the instructions I was given to fix it and I don't have days to way for one. So please help. > > I increased the gunicorn workers to 4, hoping that would allow me to do the CSV export. No. So was given these instructions: > > ### > The issues seems to be due to timeout not due to high load. You want to increase the timeout for gunicorn and you can do that by specifying a gunicorn.ini config file: > > [webservice] > configuration: /path/to/gunicorn.cfg > > and then in the gunicorn.cfg you can add > > [gunicorn] > timeout = 90 > graceful_timeout = 30 > ### > > I applied the above changes to /opt/mailman/core/mailman-extra.cfg and created the gunicorn.cfg file. Restarted the docker container (mailman-core) and no access to Postorius due to no REST api. > > After restarting docker-mailman, I can't access Postorius due to the following error: > > ERROR 2020-07-20 20:16:27,351 15 postorius Mailman REST API not available Is Mailman core running? If not, whats in core's mailman.log as to why not? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

[MM3-users] Re: User settings triggers error

by Mark Sapiro

On 6/16/20 10:34 AM, Mark Dadgar wrote: > If one of my users (including admin) goes to their user drop-down in the upper-right of Postorius and clicks Mailman Settings, it triggers an error: > > > > Here’s the error log: > > Internal Server Error: /mailman3/postorius/accounts/subscriptions/ > > KeyError at /postorius/accounts/subscriptions/ > 'file' The KeyError is bogus. It is an error that occurs in Django's logging when trying to log the real error. > Request Method: GET > Request URL: https://mail.pdc-racing.net/mailman3/postorius/accounts/subscriptions/ ... > Traceback: > > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner > 34. response = get_response(request) > > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response > 115. response = self.process_exception_by_middleware(e, request) > > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response > 113. response = wrapped_callback(request, *callback_args, **callback_kwargs) > > File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py" in _wrapped_view > 21. return view_func(request, *args, **kwargs) > > File "/usr/lib/python3/dist-packages/postorius/views/user.py" in user_subscriptions > 307. memberships = [m for m in mm_user.subscriptions] Here we're trying to grt all the user's subscriptions. Se we call mailmanclient for that. > File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/user.py" in subscriptions > 62. for address in self.addresses: client is getting all the user's addresses > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/base.py" in __iter__ > 221. for entry in self.rest_data: It got the addresses and is now iterating over them. > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/base.py" in rest_data > 197. response, content = self._connection.call(self._url) Which calls the REST API > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call > 99. raise HTTPError(url, response.status, content, response, None) And gets a 500 from core. > During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred: Which we aren't interested in. The next step is to look in core's mailman.log to see what the rest call was and the exception and hopefully traceback the caused the 500 response. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: Mass unverified subscriptions end up as pending user confirmation instead.

by Mark Sapiro

On 2/25/20 2:34 PM, hansen(a)rc.org wrote: > After mass subscribing with these settings: > > Pre confirm: Yes, Pre approved: Yes, Pre Verified (sic): No > > the addresses appeared in the list's 'Pending user confirmation' list. They were pre-confirmed. > The addresses did not appear in the Django Admin's non-verified addresses list. They were not verified. It is actually pending verification, not confirmation. Postorius can't tell the difference. It only knows that it's waiting for some action either by a moderator (pending approval) or the user (pending confirmation or verification, but just called 'confirmation') This verification is for Mailman core to verify it's a valid address that the user wants to use with this mailman installation. Once this address is verified, it can be subscribed to other lists without further verification. This has nothing to do with Django verified addresses which are addresses associated with Django log-in that have been verified to Django. > Also why does Postorius lists just 'Pending Approval' and 'Pending Confirmation' but not 'Pending Verification'? As I said, it doesn't know the difference between 'Pending Confirmation' and 'Pending Verification'. You should note that the user you subscribed in this way received a 'verification' request like > Email Address Registration Confirmation > > Hello, this is the GNU Mailman server at example.com. > > We have received a registration request for the email address > > user(a)example.org > > Before you can start using GNU Mailman at this site, you must first confirm > that this is your email address. You can do this by replying to this message, > keeping the Subject header intact. > > If you do not wish to register this email address, simply disregard this > message. If you think you are being maliciously subscribed to the list, or > have any other questions, you may contact > > listname-owner(a)example.com and not a subscription confirmation request. Also, if any of the addresses had been already verified, they would have been subscribed immediately without confirmation or approval. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: Delete a single email or thread from hyperkitty archive

by Abhilash Raj

On Fri, Jun 21, 2019, at 2:07 PM, Mark Sapiro wrote: > On 6/21/19 6:54 AM, andrew.bernard(a)gmail.com wrote: > > How can one do this? Raw database access gets you involved in all the usual foreign key constraints. > > > In the HyperKitty thread view there is a link to "Delete this thread". > In the message view there is a link to "Delete this message". Do note that this option is only visible to "Superuser" in Django, i.e. Admin accounts. > > -- > 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 > 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)

6 years, 4 months

[MM3-users] Re: list footer web customization procedure

by Mark Sapiro

On 12/17/21 2:15 PM, dancab(a)caltech.edu wrote: > Thank you. Should I be able to see the specific cache creation and expiration dates in the file_cache table of the database? Once I run the command you mentioned, should I then see that table cleared? > > MySQL [mailman3_prod]> select id, created_on, expires_on from file_cache; Yes. Also, you can see the file_id, and the key is the URL the template was retrieved from. The file_id is a 64 byte hex hash of the key and points to the cached content. If the file_id is, e.g., e4ff6a68a78b7ca911d5b16271980fa0cb816938fa187ec0f62bae707e541de0, the content it stored at /e4/ff/e4ff6a68a78b7ca911d5b16271980fa0cb816938fa187ec0f62bae707e541de0 relative to the cache_dir setting (or whatever it was when the content was stored). > +----+---------------------+---------------------+ > | id | created_on | expires_on | > +----+---------------------+---------------------+ > | 1 | 2021-03-03 23:02:48 | 2021-03-10 23:02:48 | > | 2 | 2021-03-03 23:42:49 | 2021-03-10 23:42:49 | > | 4 | 2021-03-05 21:13:07 | 2021-03-12 21:13:07 | > | 6 | 2021-03-05 22:30:33 | 2021-03-12 22:30:33 | > | 7 | 2021-11-23 00:11:23 | 2021-11-30 00:11:23 | > | 11 | 2021-11-23 23:09:36 | 2021-11-30 23:09:36 | > | 12 | 2021-11-23 23:23:28 | 2021-11-30 23:23:28 | > | 13 | 2021-11-23 23:48:51 | 2021-11-30 23:48:51 | > | 14 | 2021-11-23 23:53:30 | 2021-11-30 23:53:30 | > | 15 | 2021-11-24 00:03:40 | 2021-12-01 00:03:40 | > | 16 | 2021-11-24 00:14:03 | 2021-12-01 00:14:03 | > | 17 | 2021-11-30 22:50:14 | 2021-12-07 22:50:14 | > | 18 | 2021-12-01 15:57:48 | 2021-12-08 15:57:48 | > | 19 | 2021-12-01 15:57:48 | 2021-12-08 15:57:48 | > | 20 | 2021-12-01 17:01:09 | 2021-12-08 17:01:09 | > | 21 | 2021-12-01 17:41:42 | 2021-12-08 17:41:42 | > | 22 | 2021-12-02 23:09:58 | 2021-12-09 23:09:58 | > | 23 | 2021-12-03 22:52:10 | 2021-12-10 22:52:10 | > | 24 | 2021-12-04 02:54:06 | 2021-12-11 02:54:06 | > | 27 | 2021-12-08 14:28:41 | 2021-12-15 14:28:41 | > | 29 | 2021-12-10 17:43:16 | 2021-12-17 17:43:16 | > | 30 | 2021-12-11 02:00:04 | 2021-12-18 02:00:04 | > | 31 | 2021-12-13 09:02:44 | 2021-12-20 09:02:44 | > | 33 | 2021-12-16 20:07:11 | 2021-12-17 20:07:11 | > | 35 | 2021-12-17 19:21:19 | 2021-12-18 19:21:19 | > +----+---------------------+---------------------+ > 25 rows in set (0.001 sec) It is not clear to me why you have long expired entries in the file_cache table. The task runner should have expunged those. -- 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

Search results for query "sapiro"