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

[MM3-users] Re: trying to clean up the "held messages" mess

by Mark Sapiro

On 5/28/21 12:37 AM, Bjoern Franke wrote: > Hi, > > I migrated a Mailman3 installation on Debian10 yesterday evening from > Debian packages to PIP (thanks to [1]). > > I think some bugs which existed before are now cleaned out, but mailman > still threw exceptions when trying to get the "held messages". What exceptions? Note that there is a lot of cleanup in the as yet unreleased core 3.3.5. You might consider installing that. To do so, in your virtualenv as the Mailman user do ``` pip install --upgrade git+https://gitlab.com/mailman/mailman ``` > The amount of held messages is now reduced, but e.g. a list with 120 > held messages before has till 59 held messages. And now I'm confused: > where are they? The held message entries are in the _request table with `request_type` = 1. For those entries, `key` is the message-id and `data_hash` is the `token` in the pended table and the `id` in the pended table is the `pended_id` of the related entries in the pendedkeyvalue table. The message itself is stored in the file system and is pointed to by the entry in the message table with the corresponding message-id. The exceptions you see are because entries are missing from the pended, pendedkeyvalue and/or message tables. -- 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: trying to clean up the "held messages" mess

by Mark Sapiro

On 5/28/21 11:32 AM, Bjoern Franke wrote: > > But since the upgrade from 3.2.1 to 3.3.x the list owners are spammed with > > ---- > some.listmember(a)domain.tld's subscription has been disabled on > nordwest(a)lists.ffnw.de due to their bounce score > exceeding the mailing list's bounce_score_threshold. This should really be better documented (sigh) Prior to Mailman 3.3.1, bounces were recorded but not processed. Beginning with Mailman 3.3.1, bounces are now properly processed. The issue is all those unprocessed bounces were still in the bounceevent table in the database and even though they were old and likely irrelevant, upon upgrade they were all processed resulting in many spurious disabling of delivery. This is disruptive, but is a one time thing and in your case is now done. For those who haven't yet upgraded, there are two ways to avoid this. The best way is before starting Mailman after upgrading, set ``` [mta] verp_probes: yes ``` in mailman.cfg to enable bounce probes. With probes enabled, users whose score reaches threshold are sent a probe message and their delivery is only disabled if the probe bounces which will only happen for currently undeliverable addresses. The other way is before starting Mailman after upgrading, run a database query similar to ``` UPDATE bounceevent SET processed = 1; ``` -- 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: Disabled by bounce

by Mark Sapiro

On 1/31/23 22:32, Allan Hansen wrote: > Hi all, > > Apparently Google just started to get very aggressive about DKIM settings. Some hundreds of my subscribers have had their subscriptions disabled because of Google's bounces. > > I tried to 'Enable' some of them, expecting that their bounce scores would be reset, but when I list the users, the bounce scores are still 5. > > Please advise. Will enabling them without the bounce score being reset just cause the server to disable them again. Yes, Google has started enforcing a policy which is effectively DMARC p=reject even for senders whose domains don't publish DMARC p=reject or quarantine. To avoid this issue, you may need to set DMARC Mitigate unconditionally to Yes as well as DMARC mitigation action to Replace From: with list address if it isn't already. As far as enabling without resetting the bounce score is concerned, I think you are correct that they will just be disabled again on the next bounce. This is a bug and should be fixed. However, all of the above can be avoided without any DMARC changes by enabling bounce probes. in the [mta] section of mailman.cfg, set ``` verp_probes: yes ``` Since the probe is sent From: the list's domain, it should pass googles SPF and DKIM checks and not bounce. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

[MM3-users] Re: To have mailman3 start at boot, trying to configure the systemd mailman3.service unit, but having issues

by Mark Sapiro

On 6/8/24 12:17 PM, Keith Christian wrote: ------------------------------------------------------------------------> Below in line B-6, systemd thinks mailman isn't running, but with the > "/opt/mailman3/venv/bin/mailman" commands, line B-2 says it is. > I could be misinterpreting the systemd output, however. Python not > happy about some directories. All of the systemctl status mailman3.service reports through E 24 are reporting the same failure from Jun 08 09:35:57. The "PermissionError: [Errno 13] Permission denied: '//var/templates'" is what it says. It is trying to create the absolute path /var/templates and user mailman3 doesn't have permission to create a templates/ directory in /var. I'm not sure why this is. It should be trying /opt/mailman3/mm/var/templates. What does ``` /opt/mailman3/venv/bin/mailman info ``` show for config file? Is it correct? Even if it is, you might create /opt/mailman/bin/mailman with appropriate permissions and content ``` #!/bin/bash unset PYTHONSTARTUP exec /opt/mailman/venv/bin/mailman \ -C "/etc/mailman3/mailman.cfg" \ $@ ``` or whatever the correct path to mailman.cfg is and use /opt/mailman/bin/mailman in the Exec* entries in your mailman3.service file or you could just add `-C "/etc/mailman3/mailman.cfg"` to the commands. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years

[MM3-users] Re: email command join - problem

by Mark Sapiro

On 5/27/21 7:43 AM, sky.x--- via Mailman-users wrote: > Hi All > > Im using Mailman core 3.3.4 on Ubuntu 20.04 with python 3.8 anf have this problem with email command join. > > When send command to ml-request@ > > join address=some.email(a)domain.com > > Response is: > Confirmation email sent to 3dsome.email(a)domain.com > > It add characters 3d to email and realy sent confirmation to it. There is apparently a bug in command processing. The issue here is your join command is getting quoted-printable encoded by your MUA so it looks like ``` join address=3dsome.email(a)domain.com ``` where the `=3d` is the quoted-printable encoding of `=`. We need to ensure that commands, are properly decoded. > Also help command for join return me > join [digest=<no|mime|plain>] [address=user(a)example.com] > > But digest doesnt work as after command > > join digest=no address=some.email(a)domain.com > > i get > > join bad argument: digest=no I think this is the same issue. I also think this is fixed by the fix for https://gitlab.com/mailman/mailman/-/issues/859 at https://gitlab.com/mailman/mailman/-/merge_requests/822. This fix decodes the message body including commands in the message body. Commands in the message Subject: were already properly decoded in Mailman core 3.3.4 except possibly if the Subject: contained non-ascii. -- 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: Mailman 3 stops delivering to a domain after too many bounces

by Mark Sapiro

On 7/12/22 12:34 AM, Julian Kippels wrote: > Hi, > > We have recently upgraded from Mailman 2 to Mailman 3. Since then I > have observed many user reports that mails to mailing lists don't reach > all members. My suspicion is that there are too many "dead" members on > those lists. This was not a problem on Mailman 2, but has become a > problem on Mailman 3. It seems to me that for example Mailman 3 sends > mails to the first 5 existing member addresses from domain A, then > encounters several (20 or so seems to be the threshold) "dead" member > addresses from domain A that generate a bounce and then does not even > attempt to reach the remaining 800 member adresses from domain A and > only sends to members on domain B and domain C. > > Is there a way to globaly ignore bounces and send out mails to all > members of a list, no matter what? Mailman's outgoing runner should not be quitting because of bounces at SMTP time. It seems like there may by some issue causing Mailman's outgoing runner to die. What's in Mailman's var/queue/shunt/ and Mailman's var/logs/mailman.log. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

[MM3-users] Re: About to Install MM3 -- Seeking clarification

by Mark Sapiro

On 1/2/23 03:54, Onyeibo Oku wrote: > > I pulled the plugs on uwsgi and installed Gunicorn. Gunicorn gave more > mileage but something is still not right. When I visit the mailmanweb > home with a browser, I see the following: > > "Server Error. An error occurred while processing your request." > > Mailmanweb and mailman3 services are running. I perused the log file > at /opt/mailman/web/logs/mailmanweb.log and found the following: > > > raise MailmanConnectionError( > mailmanclient.restbase.connection.MailmanConnectionError: ('Could not > connect to Mailman API: ', > 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'localhost\', > port=8001): Max retries exceeded with url: > /3.1/lists?advertised=true&count=0&page=1 (Caused by > NewConnectionError(\'<urllib3.connection.HTTPConnection object at > 0x7f7f4b128c40>: Failed to establish a new connection: [Errno 111] > 0x7f7f4b128c40>Connection refused\'))"))') Postorius is unable to connect to Mailman core's REST API. Are your settings for accessing Mailman's REST API correct? E.g., does MAILMAN_REST_API_URL = 'http://localhost:8001' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = 'restpass' match $ mailman info ... REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass Note the 3.1/ in REST root url is not included in MAILMAN_REST_API_URL. What do you get from, e.g. curl -urestadmin:restpass http://localhost:8001/3.1/lists It should return JSON with information about your lists. -- 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: redirecting -bounces replies

by Mark Sapiro

On 6/25/25 10:53, Hirayama, Pat wrote: > Thanks, Mark. > > I (finally) started working on this ... and in trying to implement your suggestion — ran into a problem, I think. > > The current postfix_vmap has entries like: > > list-bounces(a)lists.domain.info lmtp:[mailman-core]:24 This looks very strange. It should be something like ``` list-bounces(a)lists.domain.info list-bounces(a)alias.domain ``` where alias.domain is the configured alias domain for the mail host lists.domain.info. > So, when I try adding entries to a separate vmap file, like: > > list-bounces(a)lists.domain.info lmtp:[mailman-core]:24, user(a)gmail.com > > It only goes through normal bounce processing. > > If I do: > > list-bounces(a)lists.domain.info user(a)gmail.com, lmtp:[mailman-core]:24 > > Then it goes to the gmail address, and no bounce processing happens. The issue here is the value `lmtp:[mailman-core]:24` is completely wrong. It should be an email address with a syntactically valid domain name. The domain name isn't a real domain. It is only a name exposed to Postorius in the postfix_vmap and postfix_lmtp files. What do you have configured for the alias domain for the lists.domain.info domain? See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… If you have this properly configured, adding user(a)gmail.com in either order in postfix_vmap should work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 4 weeks

[MM3-users] Re: Handling of (un)subscribe mails for already (un)subscribed users

by Mark Sapiro

On 12/10/20 2:04 PM, Andreas Barth wrote: > * Mark Sapiro (mark(a)msapiro.net) [201210 22:51]: >> On 12/10/20 11:51 AM, Andreas Barth wrote: >>> Hi, >>> >>> I noticed that a mail to -subscribe for an already subscribed user >>> doesn't get any response (about line 225 in >>> mailman/src/mailman/app/subscriptions.py). Same but different for >>> unsubscribe for users not on the list. >> >> >> I tested and I see this, so there is a bug, but I don't know what the >> issue is. > > Ok, if you consider this a bug it makes sense to fix it upstream and > not just locally. > > > >> The code you point to should raise AlreadySubscribedError and >> <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m…> >> should catch it and report, but this doesn't seem to be happening.. > > Actually I don't see where it should send the mail in the code you > refered to, but I'm pretty new to mm3-code and the involved coding > guidelines. Ther code pointed to adds the error to `results` and returns ContinueProcessing.yes. The return is to mailman/runners/command.py which is ultimately responsible for returning `results` to the user in a `results of your email commands` message. The issue is the code at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/subscripti…> appears to not be executed as in my test at least, the workflow continued. > I would tend to add something along > msg = UserNotification( > self.mlist.owner_address, self.mlist.owner_address, > subject, text, self.mlist.preferred_language) > msg.send(self.mlist) > (with appropriate subject, ...) before > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/subscripti… > but of course that could be the wrong approach (but as > subscriptions.py is sending out mail at other places, that's my first > idea). Aside from the fact that this wouldn't work if that code isn't executed, sending that message at that point would not be appropriate if the subscription request originated from something other than an email command. I.e., if it's a web subscribe, the error should be reported in the web response, not in an email to the user who may not even be the one originating the request. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

[MM3-users] Re: Turn off social logins?

by Mark Sapiro

On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > Torge Riedel writes: > > > - there is a way to do this now via settings_local.py, but feels > > a little bit risky if default configuration changes on update of > > mailman > > This should not be true. If it is, we need to fix that. Will check. It is more or less true. The issue is that unlike mm_cfg.py and Defaults.py in Mailman 2.1, the recommended way to set up Django in Mailman 3 is to point Django at settings.py for the default config, and the last thing in settings.py is try: from settings_local import * except ImportError: pass Thus,the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py. The way around this is to remove the import of settings_local from settings.py and then put from settings import * at the beginning of settings_local.py and then point Django at settings_local rather than settings. Then you can do things like try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 4 months

Search results for query "sapiro"