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

[MM3-users] Re: Missing whitespace in postfix_vmap after mailman genaliases

by Mark Sapiro

On 9/19/20 3:05 PM, Wolfgang Bock via Mailman-users wrote: > > after creating a new list I got the following errormessage: > > mailman aliases -> postmap: warning: /var/lib/mailman3/data/postfix_vmap, > line 17: expected format: key whitespace value > > /var/lib/mailman3/data/postfix_vmap > # AUTOMATICALLY GENERATED BY MAILMAN ON 2020-09-19 07:44:34 > .... > xxxxxxxxxxx(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-bounces(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-bounces(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-confirm(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-confirm(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-join(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-join(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-leave(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-leave(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-owner(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-owner(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-request(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-request(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-subscribe(a)lists.xxxxxxxxxxxxxxxx.de > xxxxxxxxxxx-subscribe(a)xxxxxxxxxxxxx.de > xxxxxxxxxxx-unsubscribe@lists.xxxxxxxxxxxxxxxx.dexxxxxxxxxxx-unsubscribe@xxx > xxxxxxxxxx.de > > The last line in the left part contains 48 chars. It isn't clear what you really have, but I'm guessing that in each case except the last, what you show as two lines is actually a single line with whitespace between and the last line has no whitespace. This is <https://gitlab.com/mailman/mailman/-/issues/651>, fixed in Mailman 3.3.1 by <https://gitlab.com/mailman/mailman/-/merge_requests/576>. > I solved the problem by adding a whitespathe last line has no whitespace.ce in the last line and I made a > new postmap for postfix_vmap. > > But it would be better to solve the problem by changing the genaliases > process in the next update. Already fixed and released in the last update. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by Mark Sapiro

On 1/25/21 11:42 PM, David Partain via Mailman-users wrote: > Hi Gordon (and Mark)! > > I have the same issue, and have changed the configuration in /etc/mailman3/mailman-web.py to: > > DATABASES = { > 'default': { > 'ENGINE': 'django.db.backends.mysql', > 'NAME': 'mailman3web', > 'USER': 'mailman3web', > 'PASSWORD': 'xxxxxxxxxxxxxxxxxx', > 'HOST': 'localhost', > 'PORT': '', > 'OPTIONS': { > 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", > 'charset': 'utf8mb4', > }, > } > } > > and restarted stuff, but I cannot tell that it has changed anything. That should do it. I think the original message should have been saved as a queue entry in Mailman's var/archives/hyperkitty/spool/ directory. If this is the case, it would have been retried and produced the same error with each new post, and after you made the above change, it would have been archived and the errors stopped. > Do I need to do something with the database itself (which is somewhat outside my comfort zone...) to make this work? Are you saying you are still seeing these errors? If so, it may be a different error. What is the exact error message? We don't need all the Django stuff, just the part equivalent to > Internal Server Error: /mailman3/hyperkitty/api/mailman/archive > OperationalError at /hyperkitty/api/mailman/archive > (1366, "Incorrect string value: '\xF0\x9F\xA4\xA3\xF0\x9F...' for > column mailman3web.hyperkitty_email.content at row 1") from the OP. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: moderation notices for list-owner being redirected to mailman address

by Mark Sapiro

On 2/1/22 18:52, Philippe B wrote: > > But in a few very rare cases, at some point during the convoluted delivery path to the mailbox of the actual human owner of OURLIST, the recipient is changed from OURLIST-owner(a)OUR.DOMAIN to mailman(a)OUR.DOMAIN. ... > Received: from [172.17.0.2] (ec2-12-34-56-78.us-west-2.compute.amazonaws.com [12.34.56.78]) > by SMTP-SERVER.OUR.DOMAIN (Postfix) with ESMTP id 9E8DE207053B > for <mailman(a)OUR.DOMAIN>; Tue, 1 Feb 2022 07:10:51 -0800 (PST) > > DKIM-Filter: OpenDKIM Filter v2.11.0 SMTP-SERVER.OUR.DOMAIN 9E8DE207053B > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=OUR.DOMAIN; > s=unixmail; t=**********; > bh=*******************************************=; > h=Subject:From:To:Date:List-Id:List-Help:List-Owner:List-Subscribe: > List-Unsubscribe:From; > b=***************************************************************** > ****************************************************************** > ****************************************= > > Received: from SMTP-SERVER.OUR.DOMAIN (SMTP-SERVER.OUR.DOMAIN [6.7.8.9]) > by MAILMAN-SERVER.OUR.DOMAIN (Postfix) with ESMTP id B138C1A288F > for <OURLIST-owner(a)lists.OUR.DOMAIN>; Tue, 1 Feb 2022 07:10:49 -0800 (PST) The above is where the change occurs. The message is received by Postfix at MAILMAN-SERVER.OUR.DOMAIN for OURLIST-owner(a)lists.OUR.DOMAIN. Then a DKIM signature is added, presumably by `DKIM-Filter: OpenDKIM Filter v2.11.0` working on Postfix queue ID 9E8DE207053B on SMTP-SERVER.OUR.DOMAIN which is the message received from `[172.17.0.2] (ec2-12-34-56-78.us-west-2.compute.amazonaws.com [12.34.56.78])` with destination mailman(a)OUR.DOMAIN. It appears to me that the message is somehow relayed from SMTP-SERVER.OUR.DOMAIN to SMTP-SERVER.OUR.DOMAIN via `(ec2-12-34-56-78.us-west-2.compute.amazonaws.com [12.34.56.78])` and that that's where the change in recipient occurs. -- 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

[MM3-users] Re: I don't get my posts with Gmail

by Mark Sapiro

On 10/18/20 5:46 AM, Allan Hansen wrote: > I was pleased to see the advice below on how to get your own list messages sent from a Google client, as my subscribers complain about their messages going AWOL all the time. > Alas, it has the following note at the bottom: > > "I have tested this and while it seems to work, it doesn't. What the filter does is put a copy of the sent message in your inbox as it is sent so it appears that you received the list post, but the message in your inbox is the same message that's in your sent folder. It's not the message received from the list.” > > Do those messages really show up in the spam folder without this filter? (I don’t use Gmail). No, they do not. > If so, then the server is, indeed, sending the message to the mail client, and the mail client is doing the message ID linking locally, discarding the incoming duplicate. > Would a change in mail client solve that? This is a Google thing. It does not depend on the client. I.e., it is the same regardless of whether your client is Gmail's web mail or a Gmail phone app or some other imap or pop3 client accessing gmail. The message is sent from the list server to the recipient's gmail/googlemail MTA and that MTA determines the Message-ID is a dup of one in the sent folder and discards it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: Default values for lists in Mailman 3

by Mark Sapiro

On 9/30/24 02:17, Markus Grandpré wrote: > Dear Mark, dear list, > > in Menu "Mass Operations / Mass Subscription" I have set the default > value for checkbox "Invitation" in file > </usr/lib/python3/dist-packages/postorius/forms/list_forms.py> (on > Debian 12) as you had suggested: > > > invitation = forms.BooleanField( > label=_('Invitation'), > initial=True, > required=False, > help_text=_( > 'If checked, the other checkboxes are ignored and the users > will ' > 'be sent an invitation to join the list and will be > subscribed ' > 'upon acceptance thereof.' > ), > widget=forms.CheckboxInput(), > ) This is correct. > However, administrators of mailing lists on our Mailman3 demo system > report that the invitation is still sent, even if they have deactivated > the sending of the invitation via the “Invitation” checkbox. If the admin is unchecking the Invitation box but not checking the Pre Verified box, the user will still be sent an address confirmation request. Perhaps the admins are mistaking this for an invitation. It the desire is to immediately subscribe the user with no further interaction, in addition to the Invitation box being unchecked, all three of the Pre confirm, Pre approved and Pre verified boxes must be checked. You may wish to set the Pre Verified default to checked in a manner similar to the above, or with Postorius >=1.3.14 (not yet released) you will be able to add ``` POSTORIUS_DEFAULTS = { 'mass_subscription_pre_verify': True } ``` to your Django settings to accomplish this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 2 weeks

[MM3-users] Re: Server 500 error for just one list, just one page

by Mark Sapiro

On 6/28/20 4:05 PM, kelly.close(a)lrewater.com wrote: > I am having a curious problem with just ONE list management page for ONE list on my server. Every other list I've checked, and every other management page for this affected list, seem fine. But when I go to the Subscribers page for this one list I get a Server 500 error, and I can't find anything in the apache or mailman logs to give me a clue (granted I'm not sure I know for sure where all the different logs are). Neither do I, but you want to look in Mailman core's mailman.log and Django's log. mailman.log is in a directory with others including smtp.log and subscribe.log. If you don't know where to find that, look in the output from `mailman conf`. The first thing to look for is [mailman] layout: which will have a value like `fhs`, `dev`, `here` or `local`. then look at [paths.xxx] log_dir: where xxx is the layout value, and if that includes $var_dir, look at [paths.xxx] var_dir: For the Django log look in settings_local.py and settings.py or whatever they're called in your case for LOGGING['handlers']['file']['filename'] > So specifically this page: https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org… That page should be the same as <https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org…>. Can you go there? Where are you finding that link? What postorius version is this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

[MM3-users] Re: Upgrade Mailmam Core from

by Mark Sapiro

On 9/28/22 23:18, sascha.rissel(a)gmail.com wrote: > > After this, I deleted the venv again and startet anew, again. > But this time, I explicitly did (as Stephen suggested above) >> pip install wheel > prior to >> pip install wheel mailman psycopg2-binary\<2.9 > > This time, it ran through without errors, although "wheel" is also contained in the latter command. > Can you explain that? Apparently, if you run `pip install wheel mailman psycopg2-binary\<2.9` pip attempts to build `lazr.delegates` which is a `mailman` dependency before it fully installs `wheel`. Thus the need to `pip install wheel` first. However, with both `virtualenv 20.0.17/python 3.8.10` and `virtualenv 20.4.2/python 3.9.10` `virtualenv venv` installs `wheel` in site-packages in the venv as does `python3 -m virtualenv venv`, but `python3 -m venv venv` does not. But, at least in my case, with venv built with `python3 -m venv venv` and not containing `wheel` in `site-packages` `pip install wheel mailman psycopg2-binary\<2.9` runs without error. > Second question: > There is still no directory "/etc/mailman3" created, where I can create mailman.cfg in. > Does this maybe result from the fact that in first instance, I tried to install mailman3-full via "apt-get install" and removed it again via "apt-get remove"; with manually deleting /etc/mailman3 afterwards. > > Shall I create /etc/mailman3 manually and adding "mailman" system user permissions? Yes, as the doc says at https://docs.mailman3.org/en/latest/install/virtualenv.html#installing-mail…, "After this, create a configuration file at /etc/mailman3/mailman.cfg for Mailman Core:" -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

[MM3-users] Re: Moderation Action Changed After Import

by Mark Sapiro

> > I can't confirm what was set on the old MM2 list as it is no longer > accessible. I am just going on the word of the List Owner. My opinion is > that the moderation for those list members were set to Reject on the > previous MM2 list. I am mainly interested to see if you know of this > happening to anyone else and/or perhaps there is an existing bug that > could impact the moderation settings of imported MM2 lists. If you have the config.pck and any MM 2.1 installation, you can get all the info from the config.pck. For example > /path/tp/mm2.1/bin/dumpdb /path/to/config.pck|grep member_moderation_action will show the setting with 0 = Hold, 1 = Reject and 2= Discard. Finding which members are moderated is more difficult as there is a dictionary named user_options with keys = to email addresses and integer values and the integer is a bit field defined as follows (from Defaults.py) > # Bitfield for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set > # defaults for all new lists. > Digests = 0 # handled by other mechanism, doesn't need a flag. > DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() > DontReceiveOwnPosts = 2 # Non-digesters only > AcknowledgePosts = 4 > DisableMime = 8 # Digesters only > ConcealSubscription = 16 > SuppressPasswordReminder = 32 > ReceiveNonmatchingTopics = 64 > Moderate = 128 > DontReceiveDuplicates = 256 However, to address your concern, As far as I know, import21 is doing the right thing. If you want to send me the config.pck you imported, I can try to verify that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: REST API authorization failed

by Mark Sapiro

On 1/9/22 5:57 AM, Axel Rau wrote: >> >> Does the `mailman info` command report what you think for REST credentials? > yes. ... > I used curl: > - - - > (mailman_33) [root@lists5 /usr/local/mailman3]# curl -v -u restadmin:??? http://localhost:8001/3.1/lists > * Trying 127.0.0.1:8001... > * Connected to localhost (91.216.35.42) port 8001 (#0) > * Server auth using Basic with user 'restadmin' >> GET /3.1/lists HTTP/1.1 >> Host: localhost:8001 >> Authorization: Basic cmVzdGFkbWluOnc2cmtuQXpJZmVRc1o4WnlkMFpBcmNjcm55OA== >> User-Agent: curl/7.80.0 >> Accept: */* >> > * Mark bundle as not supporting multiuse > < HTTP/1.1 401 Unauthorized > < Server: gunicorn > < Date: Sun, 09 Jan 2022 13:51:43 GMT > < Connection: close > * Authentication problem. Ignoring this. > < www-authenticate: Basic realm="mailman3-rest",charset="utf-8" > < content-type: application/json > < vary: Accept > < content-length: 77 > < > * Closing connection 0 > {"title": "401 Unauthorized", "description": "REST API authorization failed“} > - - - > I see "Server: gunicorn“, does this mean, I must install gunicorn? As you later reported, gunicorn is installed. It is installed as a dependency of Mailman core to serve as the REST server which is what's going on here. It also may or may not be used as the wsgi server for Django depending on how you configured that, but this is independent. Anyway, the above is saying that restadmin:??? doesn't match what's configured in Mailman core and reported by `mailman info`. Please check carefully that these are the same in both mailman.cfg admin_pass and settings MAILMAN_REST_API_PASS. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

[MM3-users] Re: Held messages not delivered after approval

by Mark Sapiro

On 8/4/25 00:21, Krinetzki, Stephan wrote: >> >> And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful. > > If there were any. Maybe the "debug" level should be "info". But for which logs? The standard logging levels from lowest to highest are debug info warning error critical Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged. For every shunted message, a message like `SHUNTING: <file name without the .pck extention>` preceded by the exception and traceback is logged to error.log with level error. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py… > Maybe the restart at night after the lograte maybe the issue. As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g. ``` if queues empty: restart Mailman else: when in queue is empty, sigterm incoming runner when out queue is empty, stop Mailman when Mailman stopped, start Mailman ``` The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month, 1 week

Search results for query "sapiro"