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

[MM3-users] Re: Mailman and Postfix Conflicting Information

by Mark Sapiro

On 2/6/26 09:00, dap1--- via Mailman-users wrote: > I've been going in circles between mailman and postfix trying to get things working. My current condition is that either mailman is putting incoming mail in the bit bucket or postfix is not sending incoming mail to mailman. What does your mail.log say? There should be an entry like ... postfix/lmtp ... to=<lllllllllll(a)gmail.com>, relay=127.0.0.1[127.0.0.1]:8024 ... for mail to the list. > According to the postfix forum my mailman configuration is messed up but it was auto generated by the installer. Supposedly these entries should not be in /opt/mailman/mm/var/data/postfix_lmtp or rather transport_maps and/or local_recipient_maps. > > # Aliases which are visible only in the @gmail.com domain. > lllllllllll(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-bounces(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-confirm(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-join(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-leave(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-owner(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-request(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-subscribe(a)gmail.com lmtp:[127.0.0.1]:8024 > lllllllllll-unsubscribe(a)gmail.com lmtp:[127.0.0.1]:8024 > > And relay_domains shouldn't have this entry either in /opt/mailman/mm/var/data/postfix_domains in relay_domains: > > gmail.com gmail.com > > Clearly my postfix configuration is messed up but since this was all auto generated I don't know what to do. I think the Postfix people are confused by the fact that your list domain is gmail.com and expect gmail.com mail to be delivered to Google, not Mailman. What you post above seems OK to me for what you are trying to do. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 weeks, 5 days

[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

5 years, 5 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

5 years

[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

4 years

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

1 year, 4 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, 7 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

3 months, 2 weeks

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

[MM3-users] Re: Mailman and Postfix Conflicting Information

by Mark Sapiro

On 2/6/26 10:49, dap1--- via Mailman-users wrote: > mailman.log > > Feb 06 10:33:50 2026 (137333) ACCEPT: <ed25cdc2-81ea-4e9a-a9f3-03e5aab685ff(a)myisp.net> Mailman Accepted the message. > Feb 06 10:33:53 2026 (137328) HyperKitty archived message <ed25cdc2-81ea-4e9a-a9f3-03e5aab685ff(a)myisp.net> to https: > //gmail.com/archives/list/llllllllll(a)gmail.com/message/DVXWCJVGONYAXYHWSYKVZJABR3OG5SDT/ And HyperKitty archived it. > smtp.log > > Feb 06 10:33:49 2026 (137334) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) > Feb 06 10:33:49 2026 (137334) Peer: ('127.0.0.1', 34218) > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) handling connection > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'LHLO dap002.localdomain' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'MAIL FROM:<uuuu(a)myisp.net> SIZE=10502' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) sender: uuuu(a)myisp.net > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'RCPT TO:<lllllllll(a)gmail.com>' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) recip: clllllllll(a)gmail.com > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'DATA' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'QUIT' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) connection lost > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) Connection lost during _handle_client() > > Hmmmm. Connection lost? Those Connection lost messages are normal and expected as a result of the QUIT command. However, missing are messages like smtp to lllllllll(a)gmail.com for nn recips, completed in nn.nn seconds post to lllllllll(a)gmail.com from uuuu(a)myisp.net, nnn bytes Is Mailman's out runner running? Are messages queued in Mailman's var/queue/out/ directory? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 weeks, 5 days

Search results for query "sapiro"