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

[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, 8 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, 8 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, 11 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

7 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, 8 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

4 months, 2 weeks

[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

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

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

7 months, 1 week

[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

10 months, 2 weeks

Search results for query "sapiro"