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

[MM3-users] Re: Backups & disaster recovery of mailman3

by Mark Sapiro

On 3/7/21 11:07 AM, David Partain via Mailman-users wrote: > Hi, > > So now I have a running mailman3 installation. Whew... > > Is there documentation of things like thorough backups and disaster recovery? I haven't yet found it. > > Backups: Obviously, I understand that I need to have datbase (mysql, in my case) dumps, and I'll have file system backups onto something that our IT folks will backup. Is there more I should think of? No, backing up the database with dumps and backing up Mailman's var/ directory and the various settings and mailman.cfg files should be sufficient. Backing up the entire Mailman installation might be useful should you need to restore it on a new server. > Disaster recovery: So, let's say my server (which is cloud-y) gets trashed and I need to get mailman back on a new server. Is this process described somewhere? I don't think so, but assuming you get all the Mailman pieces together on the new server, loading the database from a backup dump and restoring the var/ directory and the various settings and mailman.cfg files 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

5 years, 3 months

[MM3-users] Re: Problem with Gmail; bulk email

by Mark Sapiro

On 5/8/23 21:35, Lars Bjørndal wrote: > Does someone have tips in how to solve the problem? Look at the log: > mai 09 06:16:52 dalen.lamasti.net postfix/smtp[2174424]: 8163214C1740: to=<example(a)gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[142.250.157.27]:25, delay=50885, delays=50875/0.04/6.5/3.7, dsn=4.7.28, status=deferred (host alt1.gmail-smtp-in.l.google.com[142.250.157.27] said: 421-4.7.28 [185.181.61.11 15] Our system has detected an unusual rate of 421-4.7.28 unsolicited mail originating from your IP address. To protect our 421-4.7.28 users from spam, mail sent from your IP address has been temporarily 421-4.7.28 rate limited. Please visit 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to 421 4.7.28 review our Bulk Email Senders Guidelines. 14-20020a63184e000000b00519f8ebcc5esi643336pgy.121 - gsmtp (in reply to end of DATA command)) First of all, that's just throttling/greylisting/whatever. It's a temp fail and your MTA should retry and the mail should ultimately be accepted. Was your server sending an unusual amount of mail to google users, perhaps an unusually large amount of traffic on a list? I'm only guessing, but I suspect this problem may go away after google gets more experience with your mail, but in any case, it should only result in delayed mail delivery. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

[MM3-users] Re: After server upgrade debian 11→12 and reinstalling everything in (venv), I got this error when accessing → mailman3/lists

by Mark Sapiro

On 8/16/25 8:14 PM, Wikinaut wrote: > and mails appear not to be processed any more. > > One mail came through, but look to the third lien of the footer, some variables are not replaced by their values: > > berlin mailing list -- berlin(a)xxxxx.de > To unsubscribe send an email to berlin-leave(a)xxxxx.de > %(web_page_url)slistinfo/%(_internal_name)s This line is from a msg_footer imported from Mailman 2.1 by 'mailman import21'. The substitutions are not replaced because they are MM 2.1 syntax which MM 3 doesn't recognize. If you have Mailman core >=3.3.10 and have set the Base Url parameter for the domain, you can replace that line in the template with simply $mailinglist_url If your Mailman core is older, you need to hardcode that as something like https://example.com/mailman3/lists/$list_id I'm only guessing here, but I suspect that you have some directories/files in the /opt/mailman/mm/var/templates/ hierarchy with mode and ownership such that they aren't readable by 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

10 months, 1 week

[MM3-users] Re: Installation Wooes

by Mark Sapiro

On 5/3/20 7:14 PM, Samir Faci wrote: > > Here's my next question. Hopefully this isn't off topic, but trying to get > postfix to work with mailman and I keep on getting relay denied issues. ... > These are the changes I have in postfix that seem relevant. > > /etc/postfix/master.cf > > mailman unix - n n - - pipe > flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py > ${nexthop} ${user} postfix-to-mailman.py is Mailman 2.1 only. It doesn't work with Mailman3. > /etc/postfix/main.cf > > compatibility_level = 2 > > recipient_delimiter = + > unknown_local_recipient_reject_code = 550 > owner_request_special = no > transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp > local_recipient_maps = $alias_maps hash:/var/lib/mailman3/data/postfix_lmtp > relay_domains = hash:/var/lib/mailman3/data/postfix_domains These mostly have to do with delivery of mail to Mailman rather than from Mailman. > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated > defer_unauth_destination > myhostname = lists.domain.org > mydestination = $myhostname, localhost.localdomain, localhost, $mydomain, > lists.domain.org The entire output from `postconf -n` might be helpful. Also the postfix log messages for the the failed deliveries would be helpful. Can you send mail to csgeek(a)domain.com in other ways, e.g. mutt or mail or sendmail? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Mark Sapiro

On 7/25/20 6:36 AM, Odhiambo Washington wrote: > I decided to try this again, on FreeBSD-12.1 > > I still decided to follow > https://wiki.list.org/DOC/Mailman%203%20installation%20experience which I > know is not the main documentation, but I find the process easier to follow. > I am also taking notes to see if I could share if I manage to succeed. This > is important for me because Python-2.7 is being removed from FreeBSD in Dec > 2020. I need to bail > out of mailman-2.x before that happens so I am trying my hand again om MM3. > I have failed before :-) Even if it's not in FreeBSD, you can download Python 2.1.18 from <https://www.python.org/downloads/release/python-2718/> and install it. > (venv) [root@gw /opt/mailman/mm]# pip install flufl.lock ... > Even after the 'pip install flufl.lock' it still doesn't find it! This is a packaging glitch with the flufl modules. Remove and reinstall them. pip uninstall flufl.bounce flufl.i18n flufl.lock pip install flufl.bounce flufl.i18n flufl.lock -- 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: [Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/

by Mark Sapiro

On 5/18/21 7:28 PM, Mark Dadgar wrote: > > I had actually done this but checked the Users section and had overlooked the Email Addresses section. It was as you suggested - duplicate emails differing only in case. > > Given that there was only one user account, how does this happen? List subscription without associated user account creation with slightly different case? First, the Django users are separate from Mailman core users and don't have anything directly to do with list subscriptions. As far as how there got to be one User in Django with two EmailAddresses differing only in case, that's probably a bug in Django allauth. The page at accounts/email/ doesn't allow adding an address that differs only in case from an existing address, but possibly adding via a social auth provider bypasses that check. I couldn't find an issue at https://github.com/pennersr/django-allauth/issues but that doesn't mean there isn't one. In case you haven't done it, I think just deleting one of the addresses (the non-primary one) in Django's Email Addresses section will solve your issue. -- 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: Trouble importing a Mailman 3 Postgres database into a new Mailman 3 instance (Docker)

by Mark Sapiro

On 7/22/22 04:52, skenny(a)scss.tcd.ie wrote: > Thanks Mark, that didn't work out I'm afraid. This is what happened when I tried importing without deleting/recreating mailmandb: > > I imported the datatase using a psql command in the database container, and then ran "manage.py migrate", which I think does the same thing as the Django admin command with argument "migrate" (?). It reports "No migrations to apply." > > In the web interface the lists appear, but without any members, and as before when I the restart the core and web containers, they die after 15 seconds with the error messages as printed below. > > (As I mentioned earlier, removing the newly minted mailmandb database and then creating a new blank one, and importing into that does work well (c.f. Stephen Turnbull's remarks above)). My point was after you remove the newly minted mailmandb database and then create a new blank one, and import into that, you should then run `manage.py migrate` to apply any new migrations to the imported database. -- 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: Mailing list welcome message won't update

by Mark Sapiro

On 1/14/25 20:51, via Mailman-users wrote: > > "list:user:notice:welcome.bk" has the wrong welcome message. (I renamed it to back it up before correcting the welcome message) > "list:user:notice:welcome" and "list:user:notice:welcome.txt" has the identical correct welcome message. > > I removed "list:user:notice:welcome.bk". > > Now I have: > > -rwxr--r-- 1 list list 0 Oct 10 2018 list:member:generic:footer.txt* > -rwxr--r-- 1 list list 0 Mar 30 2021 list:member:regular:footer* > -rwxr--r-- 1 list list 507 Jan 9 01:35 list:user:notice:welcome* > -rwxr--r-- 1 list list 506 Jan 15 04:45 list:user:notice:welcome.txt* > > I restarted mailman3.service, mailman3-web and nginx.service. > > Tested and issue still persisted.... If list:user:notice:welcome and list:user:notice:welcome.txt have the identical content, why aren't they the same size? In any case, you can remove both list:user:notice:welcome and list:member:regular:footer as the won't be used in any case. As Steve suggests check that the `list` user:group has search and read access to all the superordinate directories. Is there anything relevant in mailman.log? -- 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

[MM3-users] Re: Hyperkitty 403 Forbidden Error

by Mark Sapiro

On 6/24/20 7:28 AM, kelly.close(a)lrewater.com wrote: > Hi Mark - could you elaborate on this just a little? One of the things I did try was to include the https:// prefix in my base URL setting and it did not affect the issue. Is there a different way to use an https scheme in the base_url setting than just adding the 's'? I tried every combination I could think of for that setting, restarting both mailman and apache2 between each try I think, but maybe I missed something. ~Kelly I don't know what the issue was in your case, but if it was fixed by changing the Appache config to not redirect http to https for requests from localhost, it should be fixed by just going to https in the first place unless there is some certificate issue at play. The relevant settings for this list are: mailman-hyperkitty.cfg: [general] base_url: https://lists.mailman3.org/archives api_key: xxx settings_local.py: MAILMAN_ARCHIVER_KEY = 'xxx' ALLOWED_HOSTS = ['localhost', '127.0.0.1', 'lists.mailman3.org', 'mail.mailman3.org', 'mailman.iad1.psf.io', 'mail.falconframework.org', '104.239.228.201', ] (I'm sure the above is overkill, but ...) MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1', '::ffff:127.0.0.1', '104.239.228.201', ) ACCOUNT_DEFAULT_HTTP_PROTOCOL = 'https' -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

[MM3-users] Re: Problems after Upgrade

by Mark Sapiro

On 10/30/22 12:24, Jeff wrote: > > When I run the command: > > mailman-web compress > > I get the following error: > > traceback (most recent call last): > File "bin/mailman-web", line 8, in <module> > sys.exit(main()) > File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman_web/manage.py", line 37, in main > execute_from_command_line(sys.argv) > File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line > utility.execute() > File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 440, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 279, in fetch_command > klass = load_command_class(app_name, subcommand) > File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 49, in load_command_class > return module.Command() > File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/base.py", line 274, in __init__ > raise TypeError("requires_system_checks must be a list or tuple.") > TypeError: requires_system_checks must be a list or tuple. > > I have not been able to fix this and would appreciate any assistance. This is a bug in Django 4.1. See https://github.com/painless-software/django-probes/issues/24. Downgrading Django<4.1 should avoid 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, 7 months

Search results for query "sapiro"