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

[MM3-users] Re: OS upgrade - anything to take care of?

by Mark Sapiro

On 5/13/21 11:28 AM, Ruth Ivimey-Cook wrote: > Mark, > > While the venv will to a degree isolate you, my experience of the > upgrade from 18 to 20 was that python3.6 was uninstalled and 3.8 > installed. In this scenario, the mailman3 installation is subsequently > broken because there is no python to run. Yes, I overlooked some aspects of virtualenv. Actually, the Python in the virtualenv is mostly symlinks to the Python it was built with, so whether it continues to work after a Python upgrade depends on what the symlinks are and how the Python upgrade installs. > It *is* possible to reinstall python3.6 after the dist upgrade is > complete, and I would presume that after doing so mailman3 would > probably resume ok. In my case I decided to continue using 3.8, which > meant, in essence, rebuilding my mailman3 install -- not fun given my > state of knowledge. > > I would therefore appreciate some guidance on performing the upgrade > from 3.6 to 3.8 with the minimum of fuss. > > [I am not sure, but it could be possible to install python3.8 while > using Ubuntu 18, so that the dist upgrade never breaks anything. Worth > exploring.] I haven't tested any of this, but I suspect if Python is for example, /usr/bin/python3.6 and /usr/lib/python3.6 the upgrade removes those and installs /usr/bin/python3.8 and /usr/lib/python3.8, that you could just create symlinks from /usr/bin/python3.6 and /usr/lib/python3.6 to /usr/bin/python3.8 and /usr/lib/python3.8 respectively and it would work. On the other hand, if the symlinks in the venv are to things like /usr/bin/python3 and /usr/lib/python3 which used to point to 3.6 versions and after upgrade point to 3.8 versions, it should just work. As far as installing Python3.8 on Ubuntu 18.04 goes, the machine I'm typing this on is Ubuntu 18.04 and has 6 different Python3 versions mark@msapiro:~$ /usr/bin/python3.5 --version Python 3.5.2 mark@msapiro:~$ /usr/bin/python3.6 --version Python 3.6.9 mark@msapiro:~$ /usr/local/bin/python3.6 --version Python 3.6.12 mark@msapiro:~$ /usr/local/bin/python3.7 --version Python 3.7.9 mark@msapiro:~$ /usr/local/bin/python3.8 --version Python 3.8.7 mark@msapiro:~$ /usr/local/bin/python3.9 --version Python 3.9.1 and /usr/bin/python3 is a symlink to /usr/bin/python3.6 and /usr/local/bin/python3 is a symlink to /usr/local/bin/python3.9, so take your pick... -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: Timeout error on anonymous subscribe

by Mark Sapiro

On 10/23/24 23:36, vogt(a)spamcop.net wrote: > > I have tried anything I could think of but I cannot reproduce the issue using curl as user mailman (or any other for that matter) > > Going directly for localhost:8000, using some or all of the headers I can capture with tcpdump: > > ``` > $ curl -v -H 'Accept-Encoding: gzip, deflate' -H 'Connection: Keep-Alive' -H 'Host: lists.example.org' -A 'python-requests/2.32.3' http://localhost:8000/mailman3/api/templates/list/community.lists.example.c… > ``` > > as well as going through the local httpd: > > ``` > $ curl -v --http1.1 -H 'Accept-Encoding: gzip, deflate' -H 'Connection: Keep-Alive' -H 'Host: lists.example.org' -A 'python-requests/2.32.3' https://lists.example.org/mailman3/api/templates/list/community.lists.examp… > ``` > > Running tcpdump during those runs shows me it's sending the same headers as mailman does. Thus on http protocol level it's the same, but still the server returns immediately. > > What I have just noticed is that the Date header in the delayed response is the "late" time. I have even compared tcp headers from either capture. They look identical down to the frame sizes. > > The only difference the last times is that with curl, the server side sends the ACK for the request and milliseconds later a PSH,ACK with the response headers. When it comes internally from mailman it sends the ACK for the request and then 5 seconds later it sends the PSH,ACK with the response headers. I'm unable to explain what's going on. You could try one more thing in an attempt to duplicate this outside of Mailman. Invoke the same python3 that Mailman does - this may be in a venv or the system python3. If in a venv, you don't need to activate the venv, just run venv/bin/python. Then in response to Python's prompts do ``` >>> import requests >>> res = requests.get('https://lists.example.org/mailman3/api/templates/list/community.lists.examp…', timeout=5) ``` and see what that does? I think it should time out because this is exactly what Mailman core is doing tho get the template, and if it does, perhaps you can determine why from this simple example. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 3 months

[MM3-users] Re: list admin via email

by Mark Sapiro

On 10/28/21 9:33 AM, Christian Stalberg via Mailman-users wrote: > I'm unclear on how to approve via email a message sent to a list. > > As list owner you receive a 'requires approval' email. It then says: > > "If you reply to this message, keeping the Subject: header intact, Mailman > will discard the held message. Do this if the message is spam. If you > reply to this message and include an Approved: header with the list password > in it, the message will be approved for posting to the list. The Approved: > header can also appear in the first line of the body of the reply." > > Question: if I want to approve the message, where do I "...include an > Approved: header with the list password in it" ? First of all, the required password is the list's moderator password. If the list was imported from Mailman 2.1 and the list's moderator password was set there, it was imported. Otherwise, you must set one. You can't currently do this via postorius it has to be done via `mailman shell` or via the REST API. Via REST, something like ``` curl --user restadmin:restpass -X PATCH --data 'moderator_password=new_password' http://localhost:8001/3.1/lists/list.example.com/config ``` should do it. Via `mailman shell` you need to encrypt the password before setting it. e.g. ``` mailman shell -l list.example.com 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. The variable 'm' is the list.example.com mailing list >>> from mailman.config import config >>> m.moderator_password = config.password_context.encrypt('new_password').encode('utf-8') ``` That said, the message to which you refer has three MIME parts and what you quote is from the message/rfc822 part at the end and "reply to this message" means reply to the message in that part, not to the message you received. I.e you have to reply to the -request address with the appropriate `confirm <token>` in the Subject: Then if your MUA makes it easy, you can include the password as the value of an Approved: header in that reply. Otherwise, you can include ``` Approved: ... ``` as the first line of the plain text reply. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: Can't subscribe on new site/domain

by Flo

On 10/10/25 22:35, Mark Sapiro wrote: > On 10/10/25 12:15 PM, Flo via Mailman-users wrote: >> >> >> On 10/10/25 20:47, Mark Sapiro wrote: >>> >>> What do you get from the following database query >>> >>> SELECT * from django_mailman3_maildomain JOIN django_site ON site_id >>> = django_site.id; >>> >> >> A while ago I have done a bit of database programming, however here I >> am lost, please help, where should I place this query to get a result? > > > I think you said your database is sqlite. If so, in the Debian package > it is probably at /var/lib/mailman/data/mailman.db. You can point the > sqlite3 command at the database and issue the query at the prompt. > :/var/lib/mailman3/data# sqlite3 mailman.db SQLite version 3.46.1 2024-08-13 09:16:08 Enter ".help" for usage hints. sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON site_id = django_site.id; Parse error: no such table: django_mailman3_maildomain sqlite> Flo

4 months, 1 week

[MM3-users] Re: Mailman 3.2.0 Hyperkitty fulltext index error

by Mark Sapiro

On 7/12/18 7:34 AM, Marvin Gülker wrote: > Hi, > > I've just upgraded to Mailman 3.2.0 (finally everything Python 3 now, > thanks!) and it appears to work. However, there's a repeating error > message in mailman-suite's logfile for Hyperkitty that looks like this: > > ERROR 2018-07-12 14:28:33,895 2742 hyperkitty.lib.utils Failed to update the fulltext index: ord() expected a character, but string of length 0 found > Traceback (most recent call last): > File "/home/mailman/env3/lib/python3.5/site-packages/hyperkitty/lib/utils.py", line 179, in run_with_lock > fn(*args, **kwargs) > File "/home/mailman/env3/lib/python3.5/site-packages/hyperkitty/search_indexes.py", line 115, in update_index > update_cmd.update_backend("hyperkitty", "default") > File "/home/mailman/env3/lib/python3.5/site-packages/haystack/management/commands/update_index.py", line 276, in update_backend > last_max_pk=max_pk) > File "/home/mailman/env3/lib/python3.5/site-packages/haystack/management/commands/update_index.py", line 97, in do_update > backend.update(index, current_qs, commit=commit) > File "/home/mailman/env3/lib/python3.5/site-packages/haystack/backends/whoosh_backend.py", line 178, in update > self.setup() > File "/home/mailman/env3/lib/python3.5/site-packages/haystack/backends/whoosh_backend.py", line 126, in setup > self.index = self.storage.open_index(schema=self.schema) > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/filedb/filestore.py", line 176, in open_index > return indexclass(self, schema=schema, indexname=indexname) > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/index.py", line 421, in __init__ > TOC.read(self.storage, self.indexname, schema=self._schema) > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/index.py", line 632, in read > check_size("int", _INT_SIZE) > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/index.py", line 626, in check_size > sz = stream.read_varint() > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/filedb/structfile.py", line 191, in read_varint > return read_varint(self.read) > File "/home/mailman/env3/lib/python3.5/site-packages/whoosh/util/varints.py", line 102, in read_varint > b = ord(readfn(1)) > TypeError: ord() expected a character, but string of length 0 found > > The error repeats every minute, so I suppose it comes from the minutely > cronjob. This cronjob looks like this: This is due the the change from Python 2.7 to Python 3. The existing search index is not compatible with Python 3 whoosh. I fixed this by deleting all the files in the index directory which is defined as PATH in HAYSTACK_CONNECTIONS in your settings and running 'django_admin update_index', but just running 'django_admin rebuild_index' should do it. -- 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: Error while running mailman-web compilemessages

by Prasanth Nair

Thanks Steve. On Wed, 20 Jul 2022 at 15:39, Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/20/22 06:16, Prasanth Nair wrote: > > Hello, > > > > I'm in the process of installing a Mailman3 server. I get the following > > error messages when I run the command 'mailman-web compilemessages'. It > was > > working fine before and noticed this recently. Can someone suggest a > > solution to solve this issue, please? > > > This is a bug in the Arabic localization in django-extensions 3.2.0. See > https://github.com/django-extensions/django-extensions/issues/1744 > > If you aren't concerned about Arabic, just ignore those messages. > > > > > -- > 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, 7 months

[MM3-users] Re: mail stuck in "out" queue

by Mark Sapiro

On 6/15/20 8:47 AM, rongxinliu(a)cs50.harvard.edu wrote: > > We tried deleting this mailing list and recreating a new one, but no luck. We also tried restarting mailman, and the issue persists. When looking at the mailman.log, messages sent to this problematic mailing list are accepted and archived successfully without a noticeable issue. > > In the smtp.log, also no errors are found except one line "Connection lost during _handle_client()", but this is true for all other mailing lists. Yes, that's normal. ... > However, the mailing list having issue will just stop at: > ....... > Jun 15 14:04:29 2020 (23) Connection lost during _handle_client() There are a couple of things. The post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… includes the log message: Jun 09 17:36:31 2020 (82) Cannot connect to SMTP server postfix on port 25 This is strange as it says that Mailman is trying to connect to hostname `postfix`. Is this actually a legitimate host name on the Mailman server that Mailman can connect to? However, it doesn't seem that this is the issue as that name comes from the smtp_host setting in the [mta] section of the configuration and is global so if it were wrong, it would affect all lists. The fact that there is nothing after "Connection lost during _handle_client()" message means only that the message wasn't successfully delivered. A database issue seems unlikely. Set [logging.smtp] level: debug in mailman.cfg and see if the increased logging helps. It seems to me that the most likely issue is a list member whose address in an smtp RCPT TO command causes some issue with the MTA. Does the MTA actually see a connect and commands for the delivery attempt. I'm also confused by > The out-runner keeps creating new .pck and .bak files endlessly whenever an email gets sent to this mailing list. Mailman should create a .pck in the out queue. Then the out runner processes it and renames it as a .bak during processing for recovery purposes and when done processing removes the .bak. If in the process it encounters retryable errors for one or more recipients, it will remove the successful and perm failure recips from the metadata and queue the message in the retry queue. It should never be just requeueing the message in the out queue. -- 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: External MTA incoming mail: configuration

by Mark Sapiro

On 7/30/24 11:18, Roland Giesler via Mailman-users wrote: > > Now, lists.fast.za.net is the mailman server. The docs say that mailman > passes these on to the MTA. However, the MTA (postfix) on > box2.gtahardware.co.za has the following setting in it main.cf: The docs are badly worded. "but also will be passed to the MTA to identify the Mailman host." means passed manually in the MTA's configuration. > virtual_transport=lmtp:[127.0.0.1]:10025 You should not be using virtual_transport. You should be using transport_maps. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… > If I reply to a signup confirmation email for example, the mail is > received and processed by box2.gtahardware.co.za, and it is not passed > on to the mailman server. It appears you have a situation where the MX for the Mailman domains is not the Mailman server. You need to configure the MTA on box2.gtahardware.co.za to relay Mailman's mail to the mailman server. You can to this by configuring that MTA to use transport_maps, etc as if it were the Mailman server. In order to get Mailman's generated files on the other server, you need to create a process to do that. When Mailman makes changes by adding or deleting lists or when it is started, it updates the postfix_lmtp and postfix_domains files and calls a command (normally postmap) to update the corresponding .db files. The command can be set by setting `postmap_command` in the `[postfix]` section in mailman.cfg. You can set this to a process which accepts a file name argument and then runs postmap on the file and rsyncs the file and it's .db to the other server. > So what is meant by "but also will be passed to the MTA to identify the > Mailman host" in the docs? As I said, that's badly worded it means 'passed manually to the MTA's config'. > If I change the config of the MTA (postfix) to be > "virtual_transport=lmtp:[lists.fast.za.net]:8024", I assume the incoming > mail will be forwarded, but how does postfix know that only the mailman > emails should be forwarded and not all the other mail that the server at > box2.gtahardware.co.za receives? Using transport_maps you can forward only list mail. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

[MM3-users] Re: mailman findmember runs very slow

by Wong, Wesley

Thanks for the fix, Mark. I tested the fix and query times are now under 2 s. wesley ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Saturday, July 13, 2024 4:36 PM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: mailman findmember runs very slow Wong, Wesley wrote: > Hi, I am noticing a performance issue with Mailman 3 when using the "mailman findmember" CLI command to search for email address or name. A fix has now been committed for the next release. See https://gitlab.com/mailman/mailman/-/merge_requests/1239<https://gitlab.com/mailman/mailman/-/merge_requests/1239> -- 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/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> This message sent to wesley.wong(a)anderson.ucla.edu

1 year, 7 months

[MM3-users] Re: mailman import21 passwords

by Mark Sapiro

On 9/16/24 18:18, Sam Darwin via Mailman-users wrote: > >> inherently not secure > > The passwords were good enough for mailman2. If a mailman2 instance has been in production for 20 years and users aren't complaining about security, maybe it's not a show stopper There are regular complaints dating back at least to <https://bugs.launchpad.net/mailman/+bug/265179> about passwords mailed in the clear. > The point is to make the upgrade seamless. That means... being able to say that everyone gets to keep their user account and password. To be able to easily tell the users "Your account is still the same. Just log in. Change your password when you like." But is it "the same"? What about an import of two lists with members which are the same person, but with possibly separate email addresses and/or passwords? Do we really want to create multiple Django users, or let the user create one Django user with multiple addresses? > In the current context, passwords are associated with django accounts rather than mailman-core accounts. So this is about creating django users. > >> creating a django user is "expensive". "poor performance" > > I didn't follow what that means. What is expensive? What is poor performance? I pointed to <https://mail.python.org/archives/list/mailman-developers@python.org/thread/…> which discusses the performance issue as a reason for dropping the import of MM 2.1 passwords. > Creating new django accounts en masse would be a one-time operation. It doesn't matter if it's slow, or expensive, since it only happens once. While probably not typical, mail.python.org currently has (still) 209 MM 2.1 lists with 40261 unique member addresses. Creating 40261 Django users, even just one time would probably be painful. > And it would be optional. With the --django-accounts flag. Or another separate script. Then you can tell users "Your account is the same as before. A transparent upgrade. Just log in". I really don't understand why telling the user that she has an account and she can just log in with one of the N MM 2.1 passwords she had on the N MM 2.1 lists or get a reset email if she doesn't know or remember the password(s) is any easier for the user than telling her to go to ... and sign up. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

Search results for query "sapiro"