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/26/22 00:11, Stephan Krinetzki wrote: > > After we enabled the "slow query log", we got in the postgresql database the following output: > > 2022-01-25 12:49:41.538 CET [16126] LOG: unexpected EOF on client connection with an open transaction > 2022-01-25 15:34:36.047 CET [16864] LOG: duration: 30760.028 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > 2022-01-25 15:34:36.047 CET [3900] LOG: duration: 9372.471 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > 2022-01-25 16:42:07.243 CET [3900] LOG: unexpected EOF on client connection with an open transaction > > Pretty sounds like a database problem? The unexpected EOF is because the gunicorn worker timed out and was killed. There are two `DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX` transactions because the first one timed out. These came from https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.… The `accept` action is processed and ultimately we get to https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.… and that in turn is doing the DELETE at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/pending.… There must be some kind of database locking causing this, but I have no clue as to what it might be. If you haven't done so, I would stop all the mailman services and the database server and then start them again. I don't know if that would help, but it might. > sometimes the log (mailmansuite.log) show us this error That too is from the gunicorn worker timing out and being killed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

[MM3-users] Re: unique key violation because of case sensitivity of email address

by Mark Sapiro

On 6/15/24 11:47, Jörg Schulz wrote: > After updating to the most recent version of mailman-web, the migrations > script issued an error: > > > Apply all migrations: account, admin, auth, contenttypes, > django_mailman3, django_q, hyperkitty, postorius, sessions, sites, > socialaccount > mailman-web | Running migrations: > mailman-web | Traceback (most recent call last): > mailman-web | File > "/usr/lib/python3.12/site-packages/django/db/backends/utils.py", line > 89, in _execute > mailman-web | return self.cursor.execute(sql, params) > mailman-web | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mailman-web | psycopg2.errors.UniqueViolation: duplicate key value > violates unique constraint > "account_emailaddress_user_id_email_987c8728_uniq" > mailman-web | DETAIL: Key (user_id, email)=(27, > John.Doe(a)mynicedomain.de) already exists. > mailman-web |(...) Presumably you upgraded django-allauth to a version >=0.62. Beginnin then, email addresses were no longer stored case-sensitively and the migration was dealing with that. There were other issues when addresses were store case sensitively. See https://github.com/pennersr/django-allauth/issues/3019 > Digging into the db, I found the duplicate to result from a duplicate > entry using john.doe(a)mynicedomain.de > > > Obviously, the process that originally created the entry, took case > sensitivity literally which doesn't seem to be the case any longer for > the migration script. > > I fixed this by removing one of the duplicates hoping no further errors > will come up.... > > > What would have been the better approach? Removing one of the duplicates is the solution, and beginning with django-allauth>=0.62, duplicates should no longer occur. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 4 months

[MM3-users] Re: Single-Sign-out for List member

by Mark Sapiro

On 8/13/20 7:45 PM, Stephen J. Turnbull wrote: > > That said, I have some ideas for how to make this safe for corporate > Germany, specifically, keep a database of user-specific OTKs. (These > could be time-limited -- with the server returning a "use a more > recent message's URL message -- or permanent.) For the usera/userb > reasons Mark gives, and the preview-url reason you give, this is > *still* not going to be safe for discussion lists. But if the From: > is <noreply(a)DeutscheKompany.co.de>, so you have to shoulder surf and > have a photographic memory to get the user's unsubscribe URL, it > should be reasonably secure for announce lists and newsletters. I have experience with a one way email newsletter from Constant Contact. These have a link to unsubscribe and also a link to forward the email to someone else. We ultimately added our own ``` If you want to forward this email, please press the Constant Contact "Forward this email" link below. If you use your "forward" button, you might be unsubscribed. ``` note just above those links because people were forwarding the mail and getting unsubscribed when the person they forwarded it to clicked the unsubscribe link. The real pain is once a user is unsubscribed in this way, the mailing manager can't add her back. She has to personally deal with Constant Contact do get them to remove her from their "do not mail this address" list. FWIW, our note seems to help reduce if not eliminate the problem. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

[MM3-users] Re: Mailman Core 3.3.2 is now out

by Mark Sapiro

On 11/22/20 1:22 AM, Torge Riedel wrote: > > I like to ask what to do with other packages when upgrading mailman. I > noted, that after upgrading mailman, all requirements are fulfilled, but > a lot updates are available: > > (venv) mailman@basis2:~/core$ pip3 list --outdated > Package Version Latest Type > ------------------- ------- ------ ----- > aiosmtpd 1.2 1.2.2 sdist > alembic 1.4.2 1.4.3 wheel > atpublic 1.0 2.1.1 sdist > dkimpy 1.0.4 1.0.5 sdist > dnspython 1.16.0 2.0.0 wheel > flufl.i18n 2.0.2 3.1.3 sdist > flufl.lock 3.2 5.0.3 sdist > idna 2.9 2.10 wheel > importlib-metadata 1.6.1 2.0.0 wheel > importlib-resources 2.0.1 3.3.0 wheel > passlib 1.7.2 1.7.4 wheel > PyMySQL 0.9.3 0.10.1 wheel > requests 2.23.0 2.25.0 wheel > SQLAlchemy 1.3.17 1.3.20 wheel > urllib3 1.25.9 1.26.2 wheel > zipp 3.1.0 3.4.0 wheel > zope.component 4.6.1 4.6.2 wheel > zope.event 4.4 4.5.0 wheel > zope.interface 5.1.0 5.2.0 wheel > > Should I update them (regularly) or may I break something in mailman? In some cases and at some times, Mailman itself specifies a version <= something for a dependency. There have been issues where an upgraded dependency is not compatible with current Mailman. You can look at the install_requires section of setup.py to see if there are any specific version requirements, but this is not fool proof. For example, flufl.lock 5.0 broke Mailman core (See https://gitlab.com/mailman/mailman/-/issues/754) This was fixed in core version 3.3.2. Thus, If Mailman is working with the set of installed dependencies that you have and all of them satisfy >= requirements in setup.py, it's probably safest to leave them as is. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: Change digest frequency and default threshold

by Mark Sapiro

On 10/12/2018 03:46 AM, Henrik Rasmussen wrote: > > As of /opt/mailman/core/var/queue/digest/ and /opt/mailman/core/var/queue/shunt/ no, but there is three files in /opt/mailman/core/var/queue/bad/ > > -rw-rw---- 1 root root 398 Oct 10 14:42 1539175326.8246331+4b7e80db0d22f01c2d4363e323320fcd34560657.psv > -rw-rw---- 1 root root 398 Oct 11 12:11 1539252672.3947155+ae2631d9f6514d74c77a38f09f821ee71515f9d9.psv > -rw-rw---- 1 root root 398 Oct 11 12:24 1539253469.5928977+15b0842462ddd3abcac8d688e5bbb195b07409bc.psv > > They seems to be binary, ... They are Python pickles. The fact that they are owned by 'root' probably means 'mailman digest' was run as 'root'. it should be run as 'mailman'. The files are preserved 'unparseable' queue files - probably unparseable because they can't be read because of the permissions error. You can view them with 'mailman qfile'. I expect this will show an 'empty' message and metadata containing in this case listid: 'test.lists.example.com' digest_path: '/opt/mailman/var/lists/test.lists.example.com/digest.1.9.mmdf' volume: 1 digest_number: 9 and a few other things like version and _parsemsg This is the 'digest' queue entry that tells DigestRunner to produce digests from the file in digest_path. > It seem to say PermissionError: [Errno 13] Permission denied, but inside the container, the directoried in /opt/mailman/var/queue is The permissions error is possibly on these files: -rw-rw---- 1 100 nogroup 103433 Oct 10 14:36 digest.1.7.mmdf -rw-rw---- 1 100 nogroup 155540 Oct 11 11:29 digest.1.8.mmdf -rw-rw---- 1 100 nogroup 104002 Oct 11 12:21 digest.1.9.mmdf or on the digest queue entries and it is because 'mailman digests' is not being run as the mailman user. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

[MM3-users] Re: Installation Wooes

by Mark Sapiro

On 5/3/20 8:13 PM, Samir Faci wrote: > > Postfix Failed Logs. > > May 4 03:07:36 lists postfix/smtpd[1968155]: disconnect from > unknown[198.199.98.177] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 > May 4 03:07:36 lists postfix/smtpd[1968155]: connect from > unknown[198.199.98.177] > May 4 03:07:36 lists postfix/smtpd[1968155]: 745B31473C6: > client=unknown[198.199.98.177] > May 4 03:07:36 lists postfix/cleanup[1968158]: 745B31473C6: > message-id=<158856165549.136760.840427238489827082@lists> > May 4 03:07:36 lists postfix/qmgr[1964759]: 745B31473C6: > from=<booh-bounces(a)lists.domain.org So mailman and Postfix are on different machines. That may complicate things, but > <mailto:booh-bounces@lists.domain.org>>, size=5474, nrcpt=1 (queue active) > May 4 03:07:36 lists postfix/smtpd[1968155]: disconnect from > unknown[198.199.98.177] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 > May 4 03:07:36 lists postfix/lmtp[1968159]: 745B31473C6: > to=<booh-owner(a)lists.domain.org <mailto:booh-owner@lists.domain.org>>, > relay=lists.domain.org <http://lists.domain.org>[198.199.98.177]:8024, > delay=0.03, delays=0/0/0/0.02, dsn=2.0.0, status=sent (250 Ok) This was a successful delivery. > May 4 03:07:36 lists postfix/qmgr[1964759]: 745B31473C6: removed > May 4 03:07:38 lists postfix/smtpd[1968155]: connect from > unknown[198.199.98.177] > May 4 03:07:38 lists postfix/smtpd[1968155]: NOQUEUE: reject: RCPT from > unknown[198.199.98.177]: 554 5.7.1 <csgeek(a)domain.com > <mailto:csgeek@domain.com>>: Relay access denied; > from=<booh-bounces+csgeek=domain.com(a)lists.domain.org > <mailto:domain.com@lists.domain.org>> to=<csgeek(a)domain.com > <mailto:csgeek@domain.com>> proto=ESMTP helo=<[127.0.1.1]> You are sending from a remote machine 198.199.98.177 to a presumably remote domain domain.com so relay access is denied as it should be. You need to add 198.199.98.177 to mynetworks in Postfix. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Updating from Ubuntu-20.04 LTE installation

by Mark Sapiro

On 5/23/20 7:02 PM, Peter Adebahr via Mailman-users wrote: > > Our installation was done by "apt-get install" in Ubuntu 20, thus still > running MM 3.2.2 (and python 3.8.2). > > Do you have any advise, how to upgrade from there to your current > version? I know this might be a bit dangerous, but with today's VMs the > risk is much less than it used to be: It shouldn't be difficult, but I can't give you details because I don't know exactly how the Debian/Ubuntu package installs things. Also I don't know whether "current version" refers to the 3.3.1 release or the head of the https://gitlab.com/mailman/mailman master branch. > Do you think it would be possible, just to replace the code and library > parts, keeping the database and config files as is? Yes. It should be fairly straightforward. You first need to find where the Mailman Core package is. You should be able to just replace the contents of the `mailman` package directory with ours. You may be able to do this via pip pip install --upgrade mailman globally or within Mailman's virtualenv if it is installed in a virtualenv. However, there are caveats. There are Debian patches at <https://sources.debian.org/patches/mailman3/3.2.2-1/>. The big `0002` patch replaces importlib_resources with importlib.resources because importlib_resources is not available in Debian. Most of the patches apply to tests, and for the actual working code, we fixed this differently as of Mailman 3.3.1, so I don't think you need the Debian patches. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Adding members to a mailman3 mailing list

by Mark Sapiro

On 10/15/20 2:07 AM, Onyeibo Oku wrote: > > In the meantime, I moved to option #3 (recommended for production). > I hit a grey area when setting up the virtual environment. At > https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…, > I see: > > $ cd /opt/mailman > $ python3 -m venv venv > > The documentation imply that a 'user' creates the virtual environment > but is not explicit about that 'user'. The user can be any user you want. I use `mailman` on my production installations and `mark` on my development installation. The key is that user should be set as owner of /opt/mailman and then creating the venv and subsequent steps are all done as that user. > (1) Is it better to have a dedicated user (say 'mailman') then use that > while following the docs? I see a lot of docs referring to a 'mailman' > user. Installing mailman3 from distribution repository introduced a > 'mailman' user to my box (with special UID). There has to be reasons > for that. Yes, a dedicated Mailman user is best. > (2) Should the setup proceed with 'root'? (why do I get the feeling > that this is not the design?) No. setup should proceed as the Mailman user. > (3) How about using an already existing local user? What are the > implications? That's OK, but there are potential security implications due to the fact that the Mailman processes running as that user have access to all that user's non-mailman stuff. -- 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: Moderation -- implicit destination behavior

by Mark Sapiro

On 5/21/25 9:31 AM, Steve Bachinsky wrote: > Hi. We have noticed some posts being held for moderation (even though user has permission to post to list) and Mailman reports: > > moderation_reasons: ['Message has implicit destination’] > > The lists are configured for “require_explicit_destination”. However, the email address of the list is clearly in the CC: header of the email (no alias or subdomain). Is there some other reason why Mailman would hold an email for moderation with the reason of “implicit destination”? No. The rule looks at all the addresses in To:, Cc:, Resent-To: and Resent-Cc: headers using standard Python email library methods, lower cases them any if any lc address matches the list posting address or an acceptable_alias, the rule misses, i.e. doesn't hold the message. There is no other reason. > This moderation is not consistent for same list and poster. The emails come from a large domain with multiple load-balancing email servers. I suspect that it may be something with one or more of the servers being misconfigured, but unable to see anything obvious from the headers and confused why Mailman states the reason to be implicit destination when that does not seem to be the cause. I'm sorry, but I have no idea why this is happening. If the headers of the held message contain the explicit address, I have no clue as to why it is held for that reason. Maybe there is some other reason why the message is held, and the reason is misstated, but I don't know how that could happen. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 months, 1 week

[MM3-users]Re: Subscribing via email

by Mark Sapiro

On 04/19/2016 11:31 AM, Andrew Hodgson wrote: > Hi, > > I subscribed to this list the other day via email, and I didn't get any email back suggesting I was subscribed. I logged in today via Google accounts, and it said I was subscribed to the list, but all the options for receiving list traffic, my own posts etc weren't filled in - I had to fill them in manually. 1 - You should have received a list welcome message and a 'results of your email commands' message in response to your email subscribe request. I'm Ccing you directly as it appears you can't get any list mail[1]. Visit <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/> to see the aechives. 2 - The non-filling in of your options is a known issue. See <https://gitlab.com/mailman/mailman/issues/187>. Basically, you get 'default' settings, but they aren't explicitly set for your subscription by the Mailman core. [1] Here's a log message: Apr 6 23:42:22 mailman postfix/smtp[6809]: A9C9B800D9: to=<andrew(a)hodgsonfamily.org>, relay=hodgsonfamily-org.mail.protection.outlook.com[213.199.154.23]:25, delay=5.5, delays=0.05/0.05/0.29/5.1, dsn=5.7.606, status=bounced (host hodgsonfamily-org.mail.protection.outlook.com[213.199.154.23] said: 550 5.7.606 Access denied, banned sending IP [104.239.228.201]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526653 (AS16012609) (in reply to RCPT TO command)) I have just now gone to https://sender.office.com/ and gone through the delisting process with this result: "Your IP 104.239.228.201 was successfully delisted. This may take up to 30 minutes to take effect." -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 6 months

Search results for query "sapiro"