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

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

5 years, 1 month

[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

1 year, 2 months

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

[MM3-users] Re: Block members from sending cc's and bcc's

by Mark Sapiro

On 11/6/25 16:21, Cathryn McGuire wrote: > Many of them say: > > 1. The message is being held because: > > Message has more than 1 recipients I don't know where in affinity you find this setting, but there is a setting for Maximum number of recipients which is set to one and that is exceeded. This setting may be intentional on your part. > Post to a moderated newsgroup gateway There are also settings for a newsgroup gateway. These settings should be Gateway to mail No Gateway to news No Linked Newsgroup empty Newsgroup moderation not moderated It appears in your case that Gateway to news is Yes and Newsgroup moderation is Moderated. > But there's no cc showing. Could be a bcc, but we wouldn't be able to tell. We don't think so, though. > > 2. The following are new today (makes us wonder if EMWD is working on something): > > The message is being held because: > > Header "neighbours > <neighbours(a)mailist.dunbar-vancouver.org>" matched a > header rule > > Saw the cc when we opened the message. Was the Cc: to <neighbours(a)mailist.dunbar-vancouver.org>? If so this is a match to your Cc: header filter, and the reason should be Header "cc: <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. If the reason was actually what is posted above with 'neighbors' rather than 'cc:', that's a problem with EMWD's Mailman core. -- 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

[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

3 years, 2 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, 10 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, 11 months

[MM3-users] Re: Postfix Hooks and Fetchmail

by Mark Sapiro

On 11/13/25 10:25, dap1--- via Mailman-users wrote: > I am not understanding the documentation. I already have this in my main.cf: > > transport_maps = hash:/opt/mailman/var/data/postfix_lmtp > local_recipient_maps = hash:/opt/mailman/var/data/postfix_lmtp > relay_domains = hash:/opt/mailman/var/data/postfix_domains > > What is not explained is where/how to add the alias_domain parameter. Does it go in /opt/mailman/var/data/postfix_domains? Is it added as a new domain or as an append to the existing domain line? The doc says in part "In order to enable this configuration, Mailman domains have an alias_domain attribute." In that sentence, `domains` is a link. did you follow it? In any case, the alias_domain is added to the existing ddddddddd.net entry at https://localhost/mailman3/domains/ or if you can't do that it is added to the domain table in the mailman database, e.g. UPDATE domain SET alias_domain = 'localhost' WHERE mail_host = 'ddddddddd.net'; After doing that, run `mailman aliases` to update the postfix files in /opt/mailman/mm/var/data including generating a new postfix_vmap file As far as Postfix is concerned, I don't know what's unclear about https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… but what you need to do is leave the current transport_maps and relay_domains as is, but add virtual_alias_maps = hash:/opt/mailman/var/data/postfix_vmap and as long as your list domain is only ddddddddd.net you can remove the local_recipient_maps setting, but see the note at the end of the https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… section. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month

Search results for query "sapiro"