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

[MM3-users] Re: mailman 3.x upgrade and downgrade

by Mark Sapiro

On 7/12/22 6:12 AM, skooperit(a)gmail.com wrote: > Hi all, > > I have a few contradictory questions. > > 1. How to upgrade the 3.x version? > > 2. Is it possible to migrate (downgrade) the lists from mailman 3.x to 2.1? > > 3. If so, what would be the best way to do that? > > > My mailing list server is running on a CenOS-7x with postgreSQL and the following mailman packages: > > django-mailman3 1.3.5 > mailman 3.3.2 > mailman-hyperkitty 1.1.0 > mailman-web 0.0.3 > mailmanclient 3.3.2 > postorius 1.3.3 > > We have ~200 lists with more than a decade of history. So you have installed Mailman 3, apparently following https://docs.mailman3.org/en/latest/install/virtualenv.html. There is a caveat. Current released versions of HyperKitty (I don't see your version above) don't work with mistune >= 2.0.0. This is https://gitlab.com/mailman/hyperkitty/-/issues/431, fixed by https://gitlab.com/mailman/hyperkitty/-/merge_requests/379 but not yet released. If your installed mistune is not 2.0.0rc1, you can work around this with this patch ``` --- a/hyperkitty/lib/renderer.py +++ b/hyperkitty/lib/renderer.py @@ -4,7 +4,7 @@ from django.conf import settings import mistune from mistune.plugins.extra import plugin_url -from mistune.scanner import escape_html, escape_url +from mistune.util import escape_html, escape_url class MyRenderer(mistune.HTMLRenderer): ``` Or you can downgrade mistune with ``` pip install mistune==2.0.0rc1 ``` in your virtualenv. To answer your questions, to migrate your lists, you use `mailman import21` and to migrate archives, `mailman-web hyperkitty_import`. Give these commands with the `--help` option for more info. Downgrading lists from Mailman 3 to Mailman 2.1 is not currently possible. There is no inverse to `mailman import21`. You can export a HyperKitty archive as a mbox to use as input to Mailman 2.1s bin/arch. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: old usernames appearing in mailman.log

by Mark Sapiro

On 6/25/23 11:04 AM, Ken Alker wrote: > > I've just taken on the project so I'm new to all of this, and one thing I noticed that caught my eye, and has left me curious, is that for the first a couple of seconds starting just after midnight every night (just after log rotation) mailman.log would have many (dozens, or hundreds) of lines entered in it just like this one: > > Jun 19 00:00:04 2023 (2266) 127.0.0.1 - - "GET /3.0/users/old-user(a)domain.tld HTTP/1.1" 404 58 > > where "old-user(a)domain.tld" is the email address of a user who either had unsubscribed or changed their email address (I don't know which, I just know they are no longer a member/subscriber to the list). Each successive entry in the log would have a different "old username" in it. I don't understand why these entries would be in the log and what they mean. Can someone shed some light on this for me? This is merely a question of curiosity, and not one of import. (Since migrating from 3.2.2 to 3.3.8 this behavior has stopped, be that GOOD or BAD.) This is the Django hyperkitty sync_mailman job which is one of the django admin jobs run daily. It goes through the HyperKitty 'sender' database table and tries to find the Mailman core user id for each sender address to add/update its mailman_id field with core's user_id. The 404s are addresses im HyperKitty's sender table for whih there is no corresponding Mailman user. There are multiple possible reasons for this. If the behavior has stopped it's probably because the periodic Django jobs are not being run - this is bad. -- 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: Block members from sending cc's and bcc's

by Mark Sapiro

On 10/20/25 17:50, Cathryn McGuire wrote: > > Me: We've changed from Accept Immediately to Default Processing. We'll investigate other settings that might be making all message Held. The important thing is the reason why the message is held. > More importantly, what are you trying to accomplish? I.e. what do you > want to happen in the following cases? > > Message To: the list, no Cc: -- Accepted > > Message To: the list, Cc: to other address (non-member) -- Hold for moderation. > Message To: the list, Cc: to a member's address –– Accepted I don't think you can accomplish this one. You can hold all messages with a Cc: header with header filter which is close to what you want, but this won't distinguish between members and nonmembers in the Cc: header. There are other cases you might want to address such as multiple values in To:, one of which is the list and another is a nonmember, but I don't think you can accomplish that either. The best you can do in this case is a header filter on To: with a pattern that matches multiple addresses and a hold action. Such a pattern might be something like .*?@[^,]*,.*@ which will match anything up to the first @ followed by anything up to a comma followed by anything up to another @. The idea is it will match anything with two or more strings containing @ and separated by a comma. > Message To: somewhere else, Cc: to the list -- Hold for moderation. > > Message To: elsewhere, Bcc: to the list (require explicit destination > will hold this one) -- Hold for moderation. -- 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: AttributeError: 'MailingList' object has no attribute 'get_requests_count'

by Mark Sapiro

On 10/25/20 8:22 AM, Shashikanth Komandoor wrote: > Hi Team, > > I am currently running Mailman 3 with version 3.3.2rc2 and in > built postfix version 2.10.1-6 on RHEL 7.5 with PostgreSQL 11.9 version > with default values. As of now, we don't have any lists and just installed > software components only. > > After the installation and configuration, I have tried > creating the domains and lists. I was successful in creating them but when > I tried to login and browse the lists using LDAP authentication, I am > getting the "Mailman REST API not available. Restart Mailman core". > > I see the below trace in the mailmansuite.log. > > *Traceback (most recent call last): File > "/var/lib/mailman/venv3/lib64/python3.6/site-packages/mailmanclient/restbase/base.py", > line 119, in __getattr__ return self._get(name) File > "/var/lib/mailman/venv3/lib64/python3.6/site-packages/mailmanclient/restbase/base.py", > line 86, in _get raise KeyError(key)KeyError: 'get_requests_count ... > > I don't see any error messages in the mailman.log. And I > also executed a few curl commands in getting the details of the lists > created and list info which I got their results successfully. > > Could you please guide where exactly I am missing or do I > need to make any changes in my customizations ? I think the issue is your mailmanclient is too old. The version of Postorius you are running requires mailmanclient >3.3.1 which is only available from GitLab <https://gitlab.com/mailman/mailmanclient>. What version of Postorius is this? It appears to be >1.3.3. If you install Postorius from unreleased code on GitLab, you have to install all of mailman, mailmanclient and django-mailman3 as well. -- 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: Error while Approving a Post Through Email

by Alex A.J.

Hi Mark, Thanks for the reply. Didn't set the moderator password for the list. I was using the same password used for logging in to the UI. Let me see if I can properly set it up as you mentioned. Thanks. Alex. On Thu, Dec 15, 2022 at 5:11 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/14/22 09:41, Mark Sapiro wrote: > > > > I don't have more time to look at this now, but I think it's a bug. This > > patch > > ``` > > --- a/src/mailman/rules/approved.py > > +++ b/src/mailman/rules/approved.py > > @@ -140,6 +140,7 @@ class Approved: > > mpw = mlist.moderator_password > > else: > > mpw = mlist.moderator_password.decode('utf-8') > > + mpw = config.password_context.encrypt(mpw) > > is_valid, new_hash = config.password_context.verify(password, > > mpw) > > if is_valid and new_hash: > > # Hash algorithm migration. > > ``` > > may fix it. > > > It is a bug, but that isn't the correct fix. The list's > moderator_password attribute should already be encrypted. The bug is we > don't catch the passlib.exc.UnknownHashError. > > It appears you either have not set the lists moderator_password or you > have not set it to a properly encrypted value. Did you set it and if so, > how? > > -- > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to malayalamtex(a)gmail.com >

3 years, 2 months

[MM3-users] Re: Random lmtp Timeout and Long Message Processing times

by Mark Sapiro

On 1/9/25 11:05, Taber, Douglas R via Mailman-users wrote: > Still stumped on this one, is there a way to increase the lmtp logging beyond debug? > > I’m trying to figure out what is causing the hang for incoming messages here: > > > Jan 09 13:38:32 2025 (342305) ('127.0.0.1', 48466) << b'250 OK' > > Jan 09 13:38:32 2025 (342305) _handle_client readline: b'RCPT TO:mailman@lists.renci.org<mailto:mailman@lists.renci.org>\r\n' > > Jan 09 13:38:32 2025 (342305) ('127.0.0.1', 48466) >> b'RCPT TO:mailman@lists.renci.org<mailto:mailman@lists.renci.org>' > > Jan 09 13:54:22 2025 (342305) ('127.0.0.1', 48466) recip: mailman(a)lists.renci.org<mailto:mailman@lists.renci.org> > > Jan 09 13:54:22 2025 (342305) ('127.0.0.1', 48466) << b'250 Ok' > > Jan 09 13:54:22 2025 (342305) ('127.0.0.1', 48466) EOF received > > Jan 09 13:54:22 2025 (342305) ('127.0.0.1', 48466) connection timeout > > It just hangs there until a timeout, then retries and immediately succeeds All those messages are actually logged by aiosmtpd which does the bulk of the work of lmtp runner. There are multiple modules involved here. Mailman's lmtp runner uses the aiosmtpd LMTP class which is a subclass of the aiosmtpd SMTP class which in turn is a subclass of asyncio.StreamReaderProtocol which is reading data from the socket connecting to the incoming MTA. It seems that after the MTA sends the `250 Ok` response to the `RCPT TO:` command the MTA closes the connection and asyncio.StreamReaderProtocol calls the eof_received method resulting in the `EOF received` log message and ultimately the timeout. Have you looked at the MTA logs? If there's not an answer there, that's where you should look to increase logging. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 1 month

[MM3-users] Re: New messages not being archived

by Mark Sapiro

On 7/8/21 2:01 PM, Sarah H wrote: > > here are the current configs and the files in spool. > > in var/archives/hyperkitty/spool/ > > -rw-rw---- 1 mailman mailman 5.9K Jul 8 13:55 1625777713.5186543+0b1e6ae782342e699116994a4cc5968e8e01701c.pck > -rw-rw---- 1 mailman mailman 5.8K Jul 8 13:55 1625777713.642453+2e79e4d69d3f91f72646af26822566116a98f92e.pck There should be errors in Mailman's mailman.log for these. You can see the actual message in the .pck by pointing `mailman qfile` at it. > mailman.cfg: > ... > [archiver.hyperkitty] > class: mailman_hyperkitty.Archiver > enable: yes > configuration: /etc/mailman3/mailman-hyperkitty.cfg OK > mailman-hyperkitty.cfg > > # This is the mailman extension configuration file to enable HyperKitty as an > # archiver. Remember to add the following lines in the mailman.cfg file: > # > # [archiver.hyperkitty] > # class: mailman_hyperkitty.Archiver > # enable: yes > # configuration: /path/to/here/mailman-hyperkitty.cfg > # > > [general] > > # This is your HyperKitty installation, preferably on the localhost. This > # address will be used by Mailman to forward incoming emails to HyperKitty > # for archiving. It does not need to be publicly available, in fact it's > # better if it is not. > # However, if your Mailman installation is accessed via HTTPS, the URL needs > # to match your SSL certificate (e.g. https://lists.example.com/hyperkitty) > base_url: https://lists.siteurl.org/archives/ I assume that you have the real URL to hyperkitty here. I'm not sure, but https might be an issue. > # Shared API key, must be the identical to the value in HyperKitty's > # settings. > api_key: thisisnotreallymykey > > settings.py > ... > MAILMAN_ARCHIVER_KEY = 'thisisnotreallymykey' OK It looks OK. You should now see log messages regarding the messages in var/archives/hyperkitty/spool/. They should help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: Moderate mails from owner

by Mark Sapiro

On 3/20/19 7:50 AM, Henrik Rasmussen wrote: > I assume this is by design, but is it correct that a list owner, who are not member, will always be allowed to post to the list, even though "Default action to take when a member posts to the list" and "Default action to take when a non-member posts to thelist" are both set to "Hold for moderation"? The owner is set as also moderator, by the way, which seems redundant. I have tried this in multiple ways: list with no members and owner X, post from X list with member Y and owner X, post from X list with member Y and owner X, moderator X, post from X In all three cases the post was held with reason "The message is not from a list member" and the expected notices were sent to the owner and poster. Note that the test for membership includes lots of addresses. The first group are the addresses in places defined by the config sender_headers in the [mailman] section which defaults to The From: header The envelope sender The Reply-To: header The Sender: header Then, for each address found, if the address is a member or if the address has a user record and any of the users addresses is a member, the post is considered to be from a member. However, this is apparently not relevant because both the Member and Non-Member actions are Hold. Thus, the post should be held unless it has an Approved: header with the list's moderator_password attribute if there is one, or it matches a Header filter rule with an accept action. What are the headers X-Mailman-Rule-Misses: and X-Mailman-Rule-Hits: in the message from the list? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

[MM3-users] Re: Imported Digest Settings

by Mark Sapiro

On 2/16/21 7:56 AM, Brian Carpenter wrote: > I am still seeing digest formatting issues with the import of Mailman 2 > lists into Mailman 3. I am running the latest stable version of Mailman > 3 core which is 3.3.3. This is what my client reported: > > >> For the last three REDACTED digests I have been getting unusual and >> unreadable characters? See example below. >> >>> Begin forwarded message: >>> >>> *From: *REDACTED >>> *Subject: *REDACTED*Digest, Vol 2453, Issue 2* >>> *Date: *February 13, 2021 at 12:30:24 AM PST >>> *To: *REDACTED@REDACTED >>> *Reply-To: *REDACTED@REDACTED >>> >>> �P*+]4�LaG@��[� S� XZ[ [�� \� �X�Z\��[ۜ� ‚] [� [�ܙ‚� � �X��ܚX�H ܈ ... > > So the questions I have are: > > 1. Why does the formatting of digests change for some members when > coming from MM2 to MM3? Could this be <https://gitlab.com/mailman/mailman/-/issues/473>? That should be fixed in Core 3.3.3. > 2. What proble does the above example reveal? Insufficient headers to begin to guess. > 3. What is the best approach to mitigate these issues? Depends what the issue is. The two most obvious approaches are upgrade to Mailman 3.3.3 if you aren't already there and switch from plain to MIME digests, but I would really like to see the full raw source of this digest messages to try to see if there is some other issue. > What I did: I had the client change the list member's digest setting > from plain-text to mime. Was that the right instruction to do? It will probably help, but if this is Mailman 3.3.3, there's still a bug somewhere that needs to be diagnosed and fixed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

[MM3-users] Re: missing graphics in Postorius

by Mark Sapiro

On 12/6/21 10:15 PM, David Newman wrote: > After installing MM3 on Debian 10 using the venv docs, no graphics > appear in the admin or list pages, just broken links. > > The mailmanweb log has lines like this: > > ERROR 2021-12-07 06:04:10,002 18262 django.security.DisallowedHost > Invalid HTTP_HOST header: '127.0.0.1'. You may need to add '127.0.0.1' > to ALLOWED_HOSTS. > > which is odd because there is the line for "localhost" in settings.py, > and /etc/hosts correctly ties this to 127.0.0.1. Add '127.0.0.1' to ALLOWED_HOSTS anyway. > There are entries like this in /var/log/nginx/error.log saying the files > just aren't there: > > 2021/12/06 22:00:30 [error] 18123#18123: *65 open() > "/opt/mailman/web/static/postorius/img/mailman_logo_small_trans.png" > failed (2: No such file or directory), client: x.x.x.x, server: > somehost.example.com, request: "GET > /static/postorius/img/mailman_logo_small_trans.png HTTP/2.0", host: > "somehost.example.com", referrer: > "https://somehost.example.com/mailman/lists/" > > (I've obfuscated names and addresses here, but "somehost.example.com" > refers to a valid FQDN in the log.) > > I thought I'd followed all the venv docs, but the > /opt/mailman/web/static/postorius directory doesn't exist. Did I miss > something? Assuming you have ``` STATIC_ROOT = '/opt/mailman/web/static' ``` in your /etc/mailman3/settings.py file, you may need to create that directory if it doesn't exist. You shouldn't need to manually create the /opt/mailman/web/static/postorius directory if the /opt/mailman/web/static directory exists and is writable/searchable by the Mailman user. That should enable ``` (venv)$ mailman-web collectstatic ``` to populate that directory. Be sure you've run all four commands at https://docs.mailman3.org/en/latest/install/virtualenv.html#run-database-mi… et seq. -- 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"