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

[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, 6 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

6 years, 8 months

[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, 1 month

[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

[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

4 years, 8 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 month

[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, 2 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

2 years, 8 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

5 years

[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

3 years, 2 months

Search results for query "sapiro"