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

[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

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

2 years, 7 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, 11 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

6 years

[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/ >

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

6 years, 4 months

[MM3-users] Re: message duplication and an NNTP related error

by Mark Sapiro

On 2/23/26 13:56, Laurens Kils-Huetten wrote: > > I have recently installed mailman3 on a Debian trixie system. How? By following <https://docs.mailman3.org/en/latest/install/virtualenv.html>, installing Debian packages or ?? > While I managed to set up most of it (the mailing lists, postorius and > also a working gateway to our inn2 news server) I'm seeing a weird > duplication of messages, that seems to be related to the error > messages posted below. What is the result from the command `mailman conf -s nntp`? What are all the settings for the list at Settings->Newsgroup Gateway in Postorius? > When I switch off gating to nntp the duplication stops. Also only mail > messages are duplicated, not the postings on the news server. > > Any pointers as to what to look into, or how to remedy this problem > are greatly appreciated :) > > Thanks, > > Laurens > > here come the error logs: > Feb 23 20:39:08 2026 (2776528) ACCEPT: <e4938b85cbd75c0b04867514fc0b8ad9(a)betola.de> > Feb 23 20:39:10 2026 (2776528) ACCEPT: <e4938b85cbd75c0b04867514fc0b8ad9(a)betola.de> The above duplicate post comes before the following error, so I don't think the error is related to the duplication. > Feb 23 20:39:12 2026 (2776530) <e4938b85cbd75c0b04867514fc0b8ad9(a)betola.de> NNTP error for test(a)grenzland.club > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/runners/nntp.py", line 94, in _dispose > conn.post(fp) > ~~~~~~~~~^^^^ > File "/usr/lib/python3/dist-packages/nntplib/__init__.py", line 916, in post > return self._post('POST', data) > ~~~~~~~~~~^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/nntplib/__init__.py", line 909, in _post > return self._getresp() > ~~~~~~~~~~~~~^^ > File "/usr/lib/python3/dist-packages/nntplib/__init__.py", line 492, in _getresp > raise NNTPTemporaryError(resp) > nntplib.NNTPTemporaryError: 441 Can't set system Injection-Info header field This is a response from your nntp server. Note: the above traceback indicates that this nntplib is standard-nntplib from PyPI which is normally only installed if Python is 3.13. If this is Python 3.13 and you have installed Mailman from other than the head of the gitlab branch, see <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

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

4 years, 6 months

[MM3-users] Re: UnpicklingError on mailman lists command

by Mark Sapiro

On 8/4/21 2:15 PM, Bryan Loniewski wrote: > Based on your import21 comments, I'm realizing the issue may be caused by multiple runs of import21. I have been (although I've stopped it for some time now) running import21 nightly to sync up my Mailman3 list data with Mailman2. I've been doing the same for archiving as well. import21 was never intended to be run more than once for a particular list. > I've noticed now that some lists have duplicate acceptable alias entries (looks to be like <number of aliases> x <number of import21 runs>) and the same goes for *_these_nonmembers entries. That's not surprising. There may be other attributes that are duplicated or otherwise corrupted from running import21 multiple times. > Is this a symptom of running the old(er) import21 command pre-3.3.2? Will the 3.3.2 import21 work as expected w/out the duplications if I was to clear out the appropriate lists col data (i.e., is it okay to run import21 multiple times)? I tried to figure out if there were any other duplicative data, but did not come across any. Is there more that I'm missing? I don't think the 3.3.2 changes to import21 will avoid the duplications. I think there will be other issues as well. For example, if there are changes in membership or ownership on the 2.1 list import21 will probably pick up the additions but not the deletions. The intended use of import21 is for a one time migration of a MM 2.1 list to MM 3. It is not intended to somehow sync parallel MM 2.1 and MM 3 lists. If the idea is to run import21 to create a test MM 3 list while still running the MM 2.1 list in production, I would suggest to run import21 once and then when ready for the final migration, delete the MM 3 list, create a new, 'empty' list and run import21 on that. As far as hyperkitty_import is concerned, it can be run multiple times. If --since is not specified, it will only consider messages newer than the newest in the existing archive, and in any case will skip duplicate Message-IDs. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: reset bounce-scores?

by Mark Sapiro

On 10/3/24 01:15, IEM Network Operation Center (IOhannes m zmölnig) wrote: > i'm running a mailman-3.3.8 instance, and would like to reset the > bounce-score for a (number of) user(s). > i searched the internet and this list's archives, but haven't found > anything useful so far. > > due to a misconfiguration of our universities reverse DNS lookup, the > bounce score of some users has rocketed in the last days - some users > have already been unsubscribed because of that. > > could anybody please share how i can reset the bounce score? First of all, there are 3 categories of affected list members - those who are already unsubscribed, those who are still members but have delivery disabled by bounce, and those with delivery enabled but with bounce score > 0. For those that have been unsubscribed, you just have to re-subscribe them. For those that have delivery enabled but a non-zero bounce score, you may not need to do anything because they are presumably not currently bouncing so eventually the old bounce info will become stale and be ignored, but to guard against spurious bounces that may result in disabling, e.g.from an over aggressive user's spam filter, you can add `verp_probes: yes` to the `[mta]` section of mailman.cfg. The effect of this is when a members bounce score reaches threshold the score is reset and a special probe message is sent and delivery is disabled only if the probe bounces. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs… That leaves those with delivery disabled by bounce. Assuming you want to enable delivery for all members of all lists with delivery disabled by bounce, the following `mailman shell` interaction will do it. ``` $ 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. >>> for mlist in getUtility(IListManager): ... for member in mlist.members.members: ... if member.delivery_status == DeliveryStatus.by_bounces: ... member.preferences.delivery_status = DeliveryStatus.enabled ... >>> commit() >>> ``` Watch out for a possible wrapped line above. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 8 months

Search results for query "sapiro"