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

[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

6 years, 2 months

[MM3-users] Re: Incorrect error log message in OutgoingRunner._dispose()

by Mark Sapiro

On April 25, 2026 10:27:06 PM GMT+02:00, Craig Leres via Mailman-users <mailman-users(a)mailman3.org> wrote: > >One feature the existing mailman 2 lists uses that I can't get working with mailman 3 are templates. After using "mailman import21" I found files with names such as list:member:regular:footer.txt in the list tree. However they were ignored so I removed them I tried tried creating a template using the web postorius gui. When a message is injected, I see an error log from the out runner: Did you by chance run import21 as root or another non-mailman user resulting in template files unreadable by Mailman? > Apr 25 12:32:22 2026 (82977) Cannot connect to SMTP server 127.0.0.1 on port 25 This is a well known issue. See <https://gitlab.com/mailman/mailman/-/work_items/582> and related issues referenced therein. >Following the error message, the out runner goes cpu bound, creating and deleting queue files in queue/out with .pck and .bak extensions, very quickly. > >I updated the code to print the exception and it tells a completely different story: > > Apr 25 12:38:15 2026 (83339) Cannot connect to SMTP server 127.0.0.1 on port 25 (HTTPConnectionPool(host='localhost', port=8000): Max retries exceeded with url: /api/templates/list/test.example.com/list:member:regular:footer (Caused by NewConnectionError("HTTPConnection(host='localhost', port=8000): Failed to establish a new connection: [Errno 61] Connection refused"))) > >I'm using the default webservice port (8001) so I would not expect anything to ever be listening on 8000. The default web service port (Postorius and HyperKitty) is 8000. Port 8001 is Mailman core's rest api. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

3 months, 3 weeks

[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, 10 months

[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

1 year, 3 months

[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

10 years, 4 months

[MM3-users] Re: Upgrading packages

by Mark Sapiro

On 10/13/22 03:49, Eggert Ehmke wrote: > > pip install --upgrade git+https://gitlab.com/mailman/hyperkitty@master > > I noticed that mistune-2.0.0rc1 was upgraded to mistune-2.0.4. > > All packages were upgraded fine. I applied the patch to > venv/lib/python3.9/site-packages/hyperkitty/lib/renderer.py It shouldn't have been necessary to apply any patch. The head of the GitLab hyperkitty master branch is already compatible with mistune 2.0.4 > to change the mistune import line. When I run now > mailman-web migrate > I get: > *CommandError: Conflicting migrations detected; multiple leaf nodes in the migration > graph: (0017_auto_20220628_1132, 0018_alter_emailtemplate_language in postorius).* > *To fix them run 'python manage.py makemigrations --merge'* > > However, when I run the suggested command as: > $ python ./venv/lib/python3.9/site-packages/mailman_web/manage.py makemigrations -- > merge > No conflicts detected to merge. There's something strange here. If you look at the migrations at the head of the gitlab branch at https://gitlab.com/mailman/postorius/-/tree/master/src/postorius/migrations, you'll see that migration 17 is named 0017_alter_emailtemplate_language.py, not 0017_auto_20220628_1132. I suggest comparing the content of your postorius/migrations/ directory with the GitLab head and resolving any differences. > Can I just ignore this behavior? At the moment, I don't dare to carry out these steps on my > production system. Would be nice to shed some light on this. I'm guessing at some point you installed something which required you to manually make this migration and that produced this conflict. Do you have both 0017_alter_emailtemplate_language.py and 0017_auto_20220628_1132 in your postorius/migrations/ directory? If so, probably just removing 0017_auto_20220628_1132 will fix this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/21/20 9:38 AM, Ruth Ivimey-Cook wrote: > > > Problem is, if I do that (which I did in the beginning), the core rest > service listens on localhost / 127.0.0.1 (it obviously recognises that > as the , and so cannot be connected to by anything. That is why I set it > to 0.0.0.0 to begin with, and what the documentation implies (fairly > strongly) that this parameter is about. What documentation? I do understand what you are saying and I see the issue. I don't understand why it works for this poster <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> but maybe that's specific to Docker containers. > IMO, the hostname parameter needs to be split up into a "what address > should the rest of the world use to address me" and separately "what > address(es) should I listen on". Multiple listen addresses enable > multihomed hosts to get the right connectivity, too. Try something like this and let us know if it works? If so, we can do something like add a config setting for this. > --- a/src/mailman/rest/gunicorn.py > +++ b/src/mailman/rest/gunicorn.py > @@ -53,7 +53,7 @@ def make_gunicorn_server(): > # We load some options from config.webservice, while other extended options > # for gunicorn can be defined in configuration: section. We also load up > # some logging options since gunicorn sets up it's own loggers. > - host = config.webservice.hostname > + host = '0.0.0.0' > port = int(config.webservice.port) > log_path = os.path.join(config.LOG_DIR, config.logging.http['path']) > options = { -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 2 months

[MM3-users] Re: Mails are stuck in Mailman Pipeline Queue

by Mark Sapiro

On 3/26/22 10:28, Shashikanth Komandoor wrote: > Hi Team, > > We have restarted the services as well but no change. Odd. > We tried manually moving the pck file from pipeline queue to > out queue but the file disappeared from out queue but is not getting > delivered. This is expected because if the message hasn't been processed through the pipeline, it has no recipients in the metadata, so the outgoing runner delivered it to no one. Also, it skipped archiving and digesting. > We moved the pck file from pipeline queue to out queue with the > extension .bak still no use. Same as above. > Not sure what to try next. Please help. Mi first guess is the pipeline runner isn't running, but you restarted the services, presumably Mailman core, and that might fix it, but there are various ways the pipeline runner could have died that would cause the master to not restart it. You need to stop Mailman core and then start it rather than just restarting. That may help. Also look in mailman.log. Assuming the pipeline runner died at some point, there should be a log entry and possible an exception with traceback indicating why. You can see which runners are running with something like ``` ps -fwwA|grep runner=|sed s/.*runner=// ``` This should produce a list something like ``` archive:0:1 bounces:0:1 command:0:1 in:0:1 lmtp:0:1 nntp:0:1 out:0:1 pipeline:0:1 rest:0:1 retry:0:1 task:0:1 virgin:0:1 digest:0:1 rest:0:1 rest:0:1 ``` except depending on version, `task` may not be there. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

[MM3-users] Re: django-allauth failures, but only for some users (independent of browser?)

by Mark Sapiro

On 12/6/23 11:00, Jered Floyd wrote: > > These errors are generated to me as the admin, and in the elided environment section SITE_ID is indeed 0, but I'm at a loss to imagine why this happens only sometimes! For me, on a test installation with SITE_ID = 0, this only occurs at https://example.com/accounts/social/connections/ Other URLs such as https://example.com/accounts/password/change/ and https://example.com/accounts/email/ do not throw this exception. Here's the code: ``` def get_current(self, request=None): """ Return the current Site based on the SITE_ID in the project's settings. If SITE_ID isn't defined, return the site with domain matching request.get_host(). The ``Site`` object is cached the first time it's retrieved from the database. """ from django.conf import settings if getattr(settings, "SITE_ID", ""): site_id = settings.SITE_ID return self._get_site_by_id(site_id) elif request: return self._get_site_by_request(request) raise ImproperlyConfigured( 'You\'re using the Django "sites framework" without having ' "set the SITE_ID setting. Create a site in your database and " "set the SITE_ID setting or pass a request to " "Site.objects.get_current() to fix this error." ) ``` I tried patching it from ``` if getattr(settings, "SITE_ID", ""): ``` to ``` if getattr(settings, "SITE_ID", None) is not None: ``` but that's even worse. It throws a bunch of "django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist." errors. Somehow, get_current is being called without a request object in the cases where it fails. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

[MM3-users] Re: Can disabled users enable themself?

by Mark Sapiro

On 7/2/26 1:30 PM, Flo via Mailman-users wrote: > > Other than myself not being familiar with this interface it looks to me > that it doesn't meet my needs. That may not be the case. It depends on why the user's mail is bouncing. With verp probes enabled, when a user's bounce score reaches threshold, instead of disabling delivery, Mailman sends a probe message and only disables delivery if the probe bounces. The idea is if the user's MTA is bouncing the mail because of spam filtering or something similar, the probe will hopefully not bounce. There is another setting to disable attaching the bounce DSN to the probe in cast the bounce DSN itself contains things that cause the bounce. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.…>. > I have a low volume list with is only used occasionally. If bounces are > coming back on one occasion it should probe these addresses every other > month four times. This means after eight months it should be removed, if > no bounces appear anymore, it should be set back to normal. What are your list settings for bounce processing? With a list that apparently only gets one post in a few months, the default settings Bounce score threshold = 5 Bounce info stale after = 7d will not disable delivery for any one as disabling would require 5 bounces with no more than 7 days between any two bounces. For your above scenario, you might want something like Bounce score threshold = 4 Bounce info stale after = 60d -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month, 2 weeks

Search results for query "sapiro"