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

[MM3-users] Re: configuring postfix local recipient table

by Mark Sapiro

On 4/29/25 00:17, Alexander Inzinger-Zrock via Mailman-users wrote: > [Status] > > Suggestion: > > It seems, we are wasting to much time with a probably messed up system. > I suggest, that i do as initially suggested [1] and start over with a > reinstall. > > Last idea before that would be to > > 1. delete the files: > > -rw-r--r-- 1 mailman mailman 0 Mar 21 11:58 postfix_domains > -rw-r--r-- 1 mailman mailman 12K Mar 24 11:44 postfix_domains.db > -rw-r--r-- 1 mailman mailman 0 Mar 21 11:58 postfix_lmtp > -rw-r--r-- 1 mailman mailman 12K Mar 24 11:44 postfix_lmtp.db > > 2. restart services > > 3. test if programms make new files > > 4. report to mailinglist > > Would that be of interest to someone? Yes. Also, is there anything in Mailman's logs from the time you ran `mailman aliases`? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 1 month

[MM3-users] Re: Time Zone Issue in Postorius

by Mark Sapiro

On 2/4/22 09:48, Andy Summers wrote: > Hello, > > I'm encountering an error that sounds similar to this previous thread: > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > I've tried setting my TIME_ZONE to 'UTC' in my settings.py and > settings_local.py files (and restarting Mailman), but when I check the > datetime for a held message in Postorius, the datetime seems to be > pushed +8 hours unexpectedly. > > My Postorius account time zone is set to "US/Pacific". The appropriate setting for Django is always `TIME_ZONE = 'UTC'`because the time passed from Mailman core is a naive datetime.datetime object and is actually UTC. This should then display the time in your account timezone since Postorius 1.3.4. See https://gitlab.com/mailman/postorius/-/merge_requests/531 If this isn't working in Postorius >=1.3.4, it's a Django issue. -- 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: Templates do not work

by Mark Sapiro

On 4/28/22 02:50, Eggert Ehmke wrote: > I created some templates in Postorius to get > personalized notifications when there are > moderator requests. The notifications I get seem to > be the standard texts. When I look into mailman/ > mm/var/templates > the directory is empty. Nevertheless, the templates I > create in Postorius seem to be stored (where?), they > just do not work. As Steve said the templates are stored in the database. I suspect the issue is and incorrect value for `POSTORIUS_TEMPLATE_BASE_URL` in your Django settings. This is used to construct the URI to retrieve the template. The URI is stored in the `template` table in the database. It is normally just `http(s)://host.name/` If this is the issue, after correcting the setting and restarting the web service, you will need to delete and re-enter the template in Postorius to correct the `template` table entry. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: combine postorius and hyperkitty into one Apache vhost

by Mark Sapiro

On 12/29/22 05:51, Wolfgang Rosenauer wrote: > Hi, > > I'm in the process to set up a new mailman3 site. > (Migrating from mailman2) > > There are RPMs for my distribution which integrate postorius and > hyperkitty with uwsgi. I think you'll be much happier if you don't use the distro's RPMs which are probably out of date and instead follow <https://docs.mailman3.org/en/latest/install/virtualenv.html>. Those instructions use uWSGI as a WSGI interface, but Gunicorn <https://gunicorn.org/> is what is used on the site supporting this list. The advantages of Gunicorn are it's already installed as a dependency of Mailman core, and it's what the Mailman developers are more familiar with. I'll work on updating <https://docs.mailman3.org/en/latest/install/virtualenv.html> to include Gunicorn as an alternative. -- 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: Internal Server Error, Need 2 values to unpack in for loop; got 1

by Mark Sapiro

On 7/11/24 11:06 AM, Elias Rudberg wrote: > Hello! > > I am using mailman3 (version 3.3.8) and it mostly works fine, but > sometimes (usually several times every day) the error below appears. > > Any suggestions for what could be done about this? ... > Here is what the error message looks like: > ------------------------------------------- > > [Django] ERROR (EXTERNAL IP): Internal Server Error: > /mailman3/postorius/lists/ > > Internal Server Error: /mailman3/postorius/lists/ > > ValueError at /postorius/lists/ > Need 2 values to unpack in for loop; got 1. Can you get the page at /mailman3/postorius/lists/ and /mailman3/postorius/lists/?all-lists If those are OK, look in your web server access logs for `GET /mailman3/postorius/lists/` messages with the same timestamp as those errors. Is there some bogus query fragment on those? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: Django Internal Server Error on held_messages

by Mark Sapiro

On 3/24/22 04:02, Hasan Berkay Çağır via Mailman-users wrote: > Hello, > > We've been running a Mailman3 instance with Debian 10's official package: > > Mailman Core Version: GNU Mailman 3.2.1 (La Villa Strangiato) > Mailman Core API Version: 3.0 > Mailman Core Python Version: 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] > > For some reason, and only on some lists, when we try to see held messages on Postorius, we get an error message "An error occurred while processing your request." and the following error email: > > """ > Internal Server Error: /postorius/lists/list.example.com/held_messages As Andrew suggests, you will probably find exceptions with tracebacks in Mailman core's mailman.log. This is probably /var/log/mailman/mailman.log in the Debian package. If you find such and you can't determine the problem from them, post one here. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: Error while Approving a Post Through Email

by Mark Sapiro

On 12/14/22 01:45, Stephen J. Turnbull wrote: > Alex A.J. writes: > > line 1132, in identify_record > > raise exc.UnknownHashError("hash could not be identified") > > passlib.exc.UnknownHashError: hash could not be identified > > Dec 13 17:01:41 2022 (2677611) SHUNTING: > > 1670931101.6040337+d5806b00b2b9d03f25db396639f66f3a26516178 > > This looks like maybe you have the wrong password? > > Maybe Mark or Abhilash has a more concrete suggestion, I've never used > the Approved header with Mailman 3. I don't have more time to look at this now, but I think it's a bug. This patch ``` --- a/src/mailman/rules/approved.py +++ b/src/mailman/rules/approved.py @@ -140,6 +140,7 @@ class Approved: mpw = mlist.moderator_password else: mpw = mlist.moderator_password.decode('utf-8') + mpw = config.password_context.encrypt(mpw) is_valid, new_hash = config.password_context.verify(password, mpw) if is_valid and new_hash: # Hash algorithm migration. ``` may fix it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

[MM3-users] Re: 404 on fresh install (Debian11)

by Mark Sapiro

On 3/23/23 08:42, Odhiambo Washington wrote: > On Thu, Mar 23, 2023 at 6:13 PM thomas--- via Mailman-users < > mailman-users(a)mailman3.org> wrote: > >> Thanks both of you. I didn't know Debian11 version is out of date. I will >> try using pip. >> > No. Debian 11 is _not_ out of date. It's just that the preferred and easy > to support installation method is using the virtualenv. The Debian stable mailman packages definitely ARE out of date. bullseye (stable) has Mailman core 3.3.3 and django-mailman3 1.3.5 (current releases are 3.3.8 and 1.3.9 respectively) It is unclear what Postorius and HyperKitty versions are in mailman3-web 0+20200530-2. bookworm (testing) and sid (unstable) do have current versions of Mailman core and django-mailman3 and possibly mailman3-web 0+20200530-2.1 has current Postorius and HyperKitty, but those are generally not the Debian packages that most users would install. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: Postfix SMTP REJECT non-subscribers

by Mark Sapiro

On 7/10/24 12:26 AM, Matthew Blissett via Mailman-users wrote: > > With Mailman 2, I have configuration and scripts to reject non-members > from posting to lists _during the SMTP connection_. This is better than > bouncing (no backscatter), better than discarding messages (the user > finds out) and better than moderation (spammy messages aren't forwarded > to external email systems). > > > The configuration and scripts are described here: > https://code.launchpad.net/~jimpop/mailman/check_subscriber > > > Is anything like this built-in to Mailman 3? I cannot find it in Gitlab. No. nothing similar is built in to Mailman 3, but it shouldn't be difficult to implement. It could be done with a milter as in the above implementation, or it could be done by modifying the _handle_RCPT function in mailman/runners/lmtp.py to check if the sender is a member of the recipient list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: mail stuck in "out" queue

by Mark Sapiro

On 12/10/24 07:44, pdw(a)mythic-beasts.com wrote: > > The messages were constantly re-appearing in the "out" queue with different file names (I assume they were going via the retry queue). First check to ensure there are no files in Mailman's var/templates/ directory that are not readable by the Mailman user. That can cause this issue. > After multiple restarts trying to get some debug information, the hard loop seems to have stopped recurring, and the messages are sat in the "shunt" queue. They've not been delivered to recipients, but they are in the hyperkitty archive. The shunted messages should have a SHUNTING entry with an exception and traceback in mailman.log. If there were files unreadable by Mailman in Mailman's var/templates/ directory and you have corrected that, you can move the shunted messages back to their original queue with `mailman unshunt`. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

Search results for query "sapiro"