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

[MM3-users] Re: Moderate mails from owner

by Mark Sapiro

On 3/20/19 7:50 AM, Henrik Rasmussen wrote: > I assume this is by design, but is it correct that a list owner, who are not member, will always be allowed to post to the list, even though "Default action to take when a member posts to the list" and "Default action to take when a non-member posts to thelist" are both set to "Hold for moderation"? The owner is set as also moderator, by the way, which seems redundant. I have tried this in multiple ways: list with no members and owner X, post from X list with member Y and owner X, post from X list with member Y and owner X, moderator X, post from X In all three cases the post was held with reason "The message is not from a list member" and the expected notices were sent to the owner and poster. Note that the test for membership includes lots of addresses. The first group are the addresses in places defined by the config sender_headers in the [mailman] section which defaults to The From: header The envelope sender The Reply-To: header The Sender: header Then, for each address found, if the address is a member or if the address has a user record and any of the users addresses is a member, the post is considered to be from a member. However, this is apparently not relevant because both the Member and Non-Member actions are Hold. Thus, the post should be held unless it has an Approved: header with the list's moderator_password attribute if there is one, or it matches a Header filter rule with an accept action. What are the headers X-Mailman-Rule-Misses: and X-Mailman-Rule-Hits: in the message from the list? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 1 month

[MM3-users] Re: Imported Digest Settings

by Mark Sapiro

On 2/16/21 7:56 AM, Brian Carpenter wrote: > I am still seeing digest formatting issues with the import of Mailman 2 > lists into Mailman 3. I am running the latest stable version of Mailman > 3 core which is 3.3.3. This is what my client reported: > > >> For the last three REDACTED digests I have been getting unusual and >> unreadable characters? See example below. >> >>> Begin forwarded message: >>> >>> *From: *REDACTED >>> *Subject: *REDACTED*Digest, Vol 2453, Issue 2* >>> *Date: *February 13, 2021 at 12:30:24 AM PST >>> *To: *REDACTED@REDACTED >>> *Reply-To: *REDACTED@REDACTED >>> >>> �P*+]4�LaG@��[� S� XZ[ [�� \� �X�Z\��[ۜ� ‚] [� [�ܙ‚� � �X��ܚX�H ܈ ... > > So the questions I have are: > > 1. Why does the formatting of digests change for some members when > coming from MM2 to MM3? Could this be <https://gitlab.com/mailman/mailman/-/issues/473>? That should be fixed in Core 3.3.3. > 2. What proble does the above example reveal? Insufficient headers to begin to guess. > 3. What is the best approach to mitigate these issues? Depends what the issue is. The two most obvious approaches are upgrade to Mailman 3.3.3 if you aren't already there and switch from plain to MIME digests, but I would really like to see the full raw source of this digest messages to try to see if there is some other issue. > What I did: I had the client change the list member's digest setting > from plain-text to mime. Was that the right instruction to do? It will probably help, but if this is Mailman 3.3.3, there's still a bug somewhere that needs to be diagnosed and fixed. -- 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: missing graphics in Postorius

by Mark Sapiro

On 12/6/21 10:15 PM, David Newman wrote: > After installing MM3 on Debian 10 using the venv docs, no graphics > appear in the admin or list pages, just broken links. > > The mailmanweb log has lines like this: > > ERROR 2021-12-07 06:04:10,002 18262 django.security.DisallowedHost > Invalid HTTP_HOST header: '127.0.0.1'. You may need to add '127.0.0.1' > to ALLOWED_HOSTS. > > which is odd because there is the line for "localhost" in settings.py, > and /etc/hosts correctly ties this to 127.0.0.1. Add '127.0.0.1' to ALLOWED_HOSTS anyway. > There are entries like this in /var/log/nginx/error.log saying the files > just aren't there: > > 2021/12/06 22:00:30 [error] 18123#18123: *65 open() > "/opt/mailman/web/static/postorius/img/mailman_logo_small_trans.png" > failed (2: No such file or directory), client: x.x.x.x, server: > somehost.example.com, request: "GET > /static/postorius/img/mailman_logo_small_trans.png HTTP/2.0", host: > "somehost.example.com", referrer: > "https://somehost.example.com/mailman/lists/" > > (I've obfuscated names and addresses here, but "somehost.example.com" > refers to a valid FQDN in the log.) > > I thought I'd followed all the venv docs, but the > /opt/mailman/web/static/postorius directory doesn't exist. Did I miss > something? Assuming you have ``` STATIC_ROOT = '/opt/mailman/web/static' ``` in your /etc/mailman3/settings.py file, you may need to create that directory if it doesn't exist. You shouldn't need to manually create the /opt/mailman/web/static/postorius directory if the /opt/mailman/web/static directory exists and is writable/searchable by the Mailman user. That should enable ``` (venv)$ mailman-web collectstatic ``` to populate that directory. Be sure you've run all four commands at https://docs.mailman3.org/en/latest/install/virtualenv.html#run-database-mi… et seq. -- 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: Mailman sends Welcome emails, but does not send [List] postings emails

by Mark Sapiro

On 5/31/23 22:49, justfixit(a)marilynstrother.com wrote: > FWIW, looking back at this time period in mailman.log the only instances of "runner exiting" are in groups, at the times when I had manually issued "mailman restart" to try a few different debug logging options. I.e. there was no single / multiple record of "runner exiting" from e.g. an unexpected program fault. When you issued a restart and the logs show runners restarting, did all the runners restart or was one or more missing. If you grep the log for `runner started`, you should see groups of messages like Jun 01 08:00:27 2023 (21930) in runner started. Jun 01 08:00:27 2023 (21938) virgin runner started. Jun 01 08:00:28 2023 (21932) bounces runner started. Jun 01 08:00:28 2023 (21935) command runner started. Jun 01 08:00:28 2023 (21941) retry runner started. Jun 01 08:00:28 2023 (21934) archive runner started. Jun 01 08:00:28 2023 (21931) lmtp runner started. Jun 01 08:00:28 2023 (21942) pipeline runner started. Jun 01 08:00:29 2023 (21939) out runner started. Jun 01 08:00:29 2023 (21936) digest runner started. Jun 01 08:00:29 2023 (21937) nntp runner started. Jun 01 08:00:30 2023 (21940) task runner started. and if any runners are sliced, there will be multiple entries for that runner, one per slice. Also, because of the way the `rest` runner is run, it will be in the list on a start but not on a restart. If a runner had previously died so it was not running when you did the restart, it won't be started and will be missing from the above list. In order to restart runners which have died, you need to do `mailman stop` followed by `mailman start` as opposed to `mailman restart` -- 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: Can't post to my own list from HyperKitty

by Mark Sapiro

On 4/10/25 18:30, MegaBrutal via Mailman-users wrote: > > Thanks, I successfully removed my unwanted address, so it now doesn't > appear anywhere. (Looks like .remove(n) wasn't needed, it only gave an > exception, and the settings were saved even without commit() – which is > concerning because I would have assumed that I can cancel transactions by > omitting it.) As it says when you first invoke `mailman shell` Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. > However, the problem still persists: I can't post to the list from > HyperKitty. In this regard, nothing has changed since my original report. > I'm subscribed to the list with my primary, preferred address, which is the > GMail address right now. So your gmail.com address is a list member and your megabrutal.com address is only an owner. Is that correct? What if you add your megabrutal.com address as a list member - you can set delivery to disabled if you don't want it to get mail. Does that work? How are you logging in to the web UI. I am concerned, because if you are logging in to an account that has both addresses linked, you should see the ``` This message will be sent as: user(a)example.com Link another address ``` line below the text box in the message dialog and if you click on user(a)example.com, you should be able to pick the other address. Also, if you go to https://example.com/user-profile/ you should see a Primary email: and Other emails:. Do you see that? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

[MM3-users] Re: Not able to start mailman server

by Mark Sapiro

On 8/5/21 12:53 AM, Kartheek Reddy Bondugula wrote: > Hi, > > I am trying to setup postorius using this website - > > https://docs.mailman3.org/projects/mailman/en/release-3.0/src/mailman/docs/W... That documentation is out of date. Start at https://docs.mailman3.org/en/latest/ > I am trying to create a mailling list and it web interface for the users in my group > > The command 'pip install -e ./'(python3) runs successfully but still i am not able to start the server Is the result the same as in your post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…, i.e., /usr/local/Cellar/python(a)3.9/3.9.5/bin/python3.9: can't open file '/usr/local/opt/python(a)3.9/bin/master': [Errno 2] No such file or directory > my mailman info shows - > > GNU Mailman 3.3.5b1 (Tom Sawyer) > Python 3.9.5 (default, May 4 2021, 03:36:27) > [Clang 12.0.0 (clang-1200.0.32.29)] > config file: /Users/.../Documents/mailman/var/etc/mailman.cfg > db url: sqlite:////Users/.../Documents/mailman/var/data/mailman.db > devmode: DISABLED > REST root url: http://localhost:8001/3.1/ > REST credentials: restadmin:restpass We recommend following this guide https://docs.mailman3.org/en/latest/install/virtualenv.html What is the content of the /Users/.../Documents/mailman/var/etc/mailman.cfg file? The 'pip install -e ./' command should have created a bin/ directory containing both `mailman` and `master` executable files and this `mailman` command is the one you should be running. It appears the `mailman` command you are running is '/usr/local/opt/python(a)3.9/bin/mailman'. If that is in fact a symlink to a different bin/mailman file, there should also be a symlink from '/usr/local/opt/python(a)3.9/bin/master' to the existing bin/master or you should adjust your path. What do `which -a mailman` and `which -a master` show? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: Is there a reason not to implement the config_list command ?

by Mark Sapiro

On 6/10/18 11:54 PM, Asaf Ohayon wrote: > > Is it meant to be implemented ? > and if so, how is it recommended to do > (for someone new to mailman 3 programming) It depends what you are looking for. The Mailman 2.1 config_list command can do quite a lot. It has both an output (config dump) mode and an input (config load/alter/etc) mode. It would be a simple matter to implement a mailman sub-command to dump a list's config if all you want are list attributes and their values. If you want all the commentary that config_list produces, that is more difficult because config_list basically gets all that from the Mailman 2.1 web UI and in Mailman 3, the web UI is decoupled from the core and the core really knows nothing about it or if it even exists. You would need to get it from the various interface definitions in mailman/interfaces/mailinglist.py. For the input mode if all you wanted to support was input containing lines of the form attribute=value that wouldn't be too difficult to do, but config_list can to much more because it makes the list object available to the input script so the input script can do anything at all to the list. So, as I said, it depends on what config_list functionality you are looking for. If what you want is a way to configure a list for a particular "style", Mailman 3 has a concept of List Style to be applied when the list is created. See <http://mailman.readthedocs.io/en/latest/src/mailman/styles/docs/styles.html>. This, rather than config_list is intended to be the way to configure a particular list style. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 10 months

[MM3-users] Re: MM2 to MM3 on debian 10

by Mark Sapiro

On 4/27/20 8:26 AM, Gelpi Andrea wrote: > Hi, on a debian 10 with MM3 I'm trying to migrate form some old MM2 > mailing lists. I know that not all can work. > > In my old lists I have email and regular expressions in > reject_these_nonmembers and discard_these_nonmembers > > After importing the list all these email are in non member list. > > All these email have Delivery status enabled. Delivery status is not relevant for non-members and only has to do with receiving list posts in any case. What version of Mailman core is this? There have been changes in `mailman import21` that may affect this, but an address in `reject_these_nonmembers` should be imported as a non-member with a moderation action of `reject` and similarly for `discard`. Note that regexps in *_these_nonmembers should be imported into the MM 3 legacy *_these_nonmembers attributes. Some older versions of import21 also imported non-regexp addresses here, but that was wrong. > Does this mean that all of them will receive any message sent to the list? > The moderation rule is correct, but if I understood correct Delivery > status should be disabled. Delivery status is irrelevant for non-members. Only members are candidates for delivery. > For migration I followed this link > https://docs.mailman3.org/en/latest/migration.html > > To migrate archives it states to run > > python manage.py hyperkitty ... > > I cant' find a manage.py on debian 10 manage.py is a Django generic term for the Django admin command. You probably want something called django-admin or similar. > A search shows the only /usr/share/mailman3-web/manage.py exists. > > Is there any documentation specific for debian? That would be up to Debian. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

[MM3-users] Re: bulk deletion of messages from Hyperkitty

by Mark Sapiro

On 7/10/24 12:27 PM, Danil Smirnov via Mailman-users wrote: > > I'm aware of the tools you mentioned and they were properly used. Your issue is almost certainly caused by unescaped `From ` lines in message bodies and preprocessing the mbox with the hyperkitty/contrib/cleanarch3 script should fix those. > Please let us focus on the question I asked - how do we delete messages of > a particular date if there are too many of them so using Hyperkitty UI > isn't an option? You can do ``` DELETE FROM hyperkitty_email WHERE archived_date = <your datetime>; ``` but as you note there are entries in the hyperkitty_thread table that need to be removed too. So, before doing the above, maybe something like ``` DELETE FROM hyperkitty_thread WHERE id IN (SELECT thread_id FROM hyperkitty_email WHERE archived_date = <your datetime>); ``` but there are also possibly entries relating to these messages/threads in the hyperkitty_favorite, hyperkitty_tagging, hyperkitty_lastview and hyperkitty_vote tables. It seems unlikely that there would be such entries in your case, but if you are concerned about them, here in order are what you can do in the database. ``` DELETE FROM hyperkitty_favorite WHERE thread_id IN (SELECT id FROM hyperkitty_thread WHERE id IN (SELECT thread_id FROM hyperkitty_email WHERE archived_date = <your datetime>)); DELETE FROM hyperkitty_tagging WHERE thread_id IN (SELECT id FROM hyperkitty_thread WHERE id IN (SELECT thread_id FROM hyperkitty_email WHERE archived_date = <your datetime>)); DELETE FROM hyperkitty_lastview WHERE thread_id IN (SELECT id FROM hyperkitty_thread WHERE id IN (SELECT thread_id FROM hyperkitty_email WHERE archived_date = <your datetime>)); DELETE FROM hyperkitty_vote WHERE email_id IN (SELECT id FROM hyperkitty_email WHERE archived_date = <your datetime>); DELETE FROM hyperkitty_thread WHERE id IN (SELECT thread_id FROM hyperkitty_email WHERE archived_date = <your datetime>); DELETE FROM hyperkitty_email WHERE archived_date = <your datetime>; ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[MM3-users] Re: How to set the original sender to the Reply-To?

by Mark Sapiro

On 9/12/20 9:51 AM, Marcel Pietschmann wrote: > Hi everybody, > > I have a settings problem. Mailman adds the original sender to the Reply-To or Cc in the case where there's a reply to setting in force on the list. > > In my case, mailman sets the sender always to Cc. How can i change it? > > My settings: > Personalize = None > Anonymous list = No > Reply to list = No Munging > DMARC = Munge the From: header with list adress When DMARC is set to Munge From, Mailman puts the poster's address in either Cc: or Reply-To: to facilitate replying to the poster. The decision of which header to add the poster's address to is made to, as closely as possible for most MUAs, make the behavior of a 'reply' match the behavior when the From: is not munged. See the comments at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/dmarc…> for discussion of the goals for Munge From. The actual decision as to which header to use is at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/dmarc…>. That says that the original From is added to Cc: whenever Reply to list is other than No Munging. You say that you have Reply to list = No Munging which means the original From should be added to Reply-To: and not to Cc:, so I don't understand why it's added to Cc: in your case. I have tested locally and with Reply to list = No Munging, the original From: is added to Reply-To: and with Reply to list = Reply goes to list, the original From: is added to Cc: as expected. -- 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

Search results for query "sapiro"