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

[MM3-users] Re: Member Issue Discovered

by Mark Sapiro

On 10/19/20 12:03 PM, Brian Carpenter wrote: > Hi Everyone, > > If I subscribed to a MM3 list with barn(a)emwd.com with the name of Barn > Quilter. It shows up in the member roster. So far, so good. I then > unsubscribe barn(a)emwd.com. It no longer shows up in the member roster. > So far so good. I then resubscribe barn(a)emwd.com with either no name or > Barn User and it shows up in the member roster as barn(a)emwd.com with the > name of Barn Quilter. Is this a known bug and has been fixed with the > latest release? I suppose it could be considered a bug, but what's happening is your initial subscribe created a user and and address and set the user's preferred address to the created address. It also set the display_name of the address and it subscribed the user to the list or possibly the address to the list depending on what actually did the subscribe. When the user/address was unsubscribed, it is removed from the list's membership and the list was removed from the user's memberships, but the user and address still existed. Then when you resubscribed, the existing user/address was made a member of the list, but not updated so the "new" display_name was ignored. I think this is also the case if the original address had no display_name. You could say this is a bug and the display_name associated with this new subscription should replace the prior one, but what if that address was subscribed to other lists and didn't want the display_name changed on those lists. Ideally (perhaps) there could be multiple address records with the same email address and different display_names, but address records are keyed by email address, so this can't be. One workaround would be for a user who wanted to have an address with different display_names for different lists to have multiple addresses like address+list1(a)example.com, address+list2(a)example.com, etc. Is this really an issue that should be fixed or just a curiosity? -- 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: Implicit Destination Meaning

by Mark Sapiro

On 2/8/21 6:41 PM, Brian Carpenter wrote: > I just migrated a MM2 list to MM3. The client had no problem sending > posts to his list with MM2. However when he posted to his MM3 list, it > showed up in the moderation queue: > > ============ > Your mail to 'dogs(a)lists.redacted.org' with the subject > > mailing list changes > > Is being held until the list moderator can review it for approval. > > The message is being held because: > > Message has implicit destination > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. > =========== > > Is there a List Setting somewhere that needs to be adjusted to allow > this sender to post without moderation? There are a few things going on here. First, the list setting is require_explicit_destination. This is in Postorius under Settings -> Message Acceptance. If this is False or No, the implicit destination rule will never hit, but clearly it is Yes/True and should have been imported from the 2.1 list so it was probably True there too. When True, it means the list posting address or an acceptable alias must be explicitly addressed (in To:, Cc:, Resent-To: or Resent-Cc: of the post. An acceptable alias is a literal address or pattern matching addresses. These are also in Settings -> Message Acceptance and should have been imported from MM 2.1. For example, if the list's posting address is list(a)example.com, but you can also post to list(a)lists.example.com, list(a)lists.example.com should be in acceptable aliases. The most likely explanation here is that the post is being sent to a subdomain which is not the list's canonical posting address or vice versa. The reason this worked in MM 2.1 but not in MM 3 is in MM 2.1 if the list name matched, the check passed even if the domains didn't, but that is not the case in MM 3. The solution is to add the 'other' addresses to Acceptable aliases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

[MM3-users] Re: Only held_messages for 1 (of 3) list has "Mailman REST API not available" message.

by Mark Sapiro

On 1/7/22 4:51 AM, Duane Raymond wrote: > Thanks Mark. > > This sounds like a database problem. What's in Mailman >> core's var/logs/mailman.log ? > > > In the var/logs/mailman.log there was a permission error for the messages/ > store folders. I noticed that some of the mm file and directories were > owned by root vs 'mailman' user (what Brian uses when he set up the mm3 > server). So after resetting all to mailman (I believe others use 'list') `list` is used by the Debian/Ubuntu packages. We recommend `mailman`. These ownership issues are often caused by running Mailman core as `root`. This causes certain things to be created/owned by `root` and when Mailman core is later run as `mailman`, it can't access these things. To guard against this, Mailman core >=3.3.5 will refuse to run Mailman as `root` unless a `--run_as_root` option is specified. > Now I get the error below with the error from mailman.log. ... > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/post_moderation.py", > line 77, in _make_resource > resource['msg'] = msg.as_string() > AttributeError: 'NoneType' object has no attribute 'as_string' This is https://gitlab.com/mailman/mailman/-/issues/856, fixed in Mailman 3.3.5 by https://gitlab.com/mailman/mailman/-/merge_requests/819. You can apply this patch to avoid the issue. ``` --- a/src/mailman/rest/post_moderation.py +++ b/src/mailman/rest/post_moderation.py @@ -74,7 +74,15 @@ class _HeldMessageBase(_ModerationBase): # resource. XXX See LP: #967954 key = resource.pop('key') msg = getUtility(IMessageStore).get_message_by_id(key) - resource['msg'] = msg.as_string() + if msg is None: + resource['msg'] = """\ +Subject: Message content lost +Message-ID: {} + +This held message has been lost. +""".format(key) + else: + resource['msg'] = msg.as_string() # Some of the _mod_* keys we want to rename and place into the JSON # resource. Others we can drop. Since we're mutating the dictionary, # we need to make a copy of the keys. When you port this to Python 3, ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Mark Sapiro

On 1/30/22 08:22, Jacob Sievert via Mailman-users wrote: >> Yes they should. This is >> https://gitlab.com/mailman/mailman/-/issues/257 fixed in Mailman core >> 3.3.5. Also in Mailman 3.3.5 is a new Task runner that runs periodic >> tasks, one of which is to remove orphaned pendings. > Hmm our running system right now already was on 3.3.5 since a few days > after release. > But maybe all of those were still from before. Task runner cleans some things, but not all. ...>> # Prior to Mailman 3.3.5, some tokens for user confirmations were >> pended with >> # too long a lifetime. This script removes those pendings based on >> when they >> # were pended and the configured pending_request_life rather than their >> # expiration. > With the script we went down to around 16k entries in pendedkeyvalue > removed were the following: > expunged 6932 orphaned pended held messages When a message is held, two tokens are pended; one for the moderator and one for the user. Notification to the user doesn't currently include the user's token or instructions on removing the held post; that needs to be done, but the token is pended anyway. Prior to 3.3.5, when a held message was handled, the moderator's token was removed, but not the user's. That's what these are. > expunged 254 expired held messages > expunged 21 expired (un)subscription confirmations Prior to 3.3.5, some things were pended with excessively long lifetimes. The script expires these based on 3 days for user confirmations and 180 days for moderator actions. The above were older than that. > This shows that there were a lot of things in an unfinished state to my > understanding in our system. > For a time this system was running with less RAM than it should have > had. So maybe some of the problems came from there. These were all problems with pre 3.3.5 Mailman, not specific to your system. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

[MM3-users] Re: Hyperkitty is not archiving due to 405 error - GET instead of POST

by Mark Sapiro

On 2/12/24 8:46 AM, Matthias via Mailman-users wrote: > Hi there, > > I am running mailman3 on Debian 12 - latest package (GNU Mailman 3.3.8 (Tom Sawyer)). > Message handling in general is working fine, but as soon as a message is released, archiving with Hyperkitty is not working, due to a 405 error: > --- > Feb 11 16:18:48 2024 (3479662) HyperKitty failure on http://lists.domain.tld/mailman3/hyperkitty/api/mailman/archive: (405) > Feb 11 16:18:48 2024 (3479662) Could not archive the message with id <170766472771.3479669.4791049109141956450(a)otherdomain.tld> > Feb 11 16:18:48 2024 (3479662) archiving failed, re-queuing (mailing-list jahrgang.domain.tld, message <170766472771.3479669.4791049109141956450(a)otherdomain.tld>) > Feb 11 16:18:48 2024 (3479662) Exception in the HyperKitty archiver: > Feb 11 16:18:48 2024 (3479662) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 158, in _archive_message > url = self._send_message(mlist, msg) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 228, in _send_message > raise ValueError(result.text) > ValueError > --- I would expect to see the text from the requests.post result here. > > When tracing this back, even the frontend Nginx server receives a get in his logs, hence I assume that hyperkitty is really creating a GET instead of a POST request? > --- > 217.72.204.162 - - [11/Feb/2024:16:18:48 +0100] "GET /mailman3/hyperkitty/api/mailman/archive HTTP/1.1" 405 0 "-" "python-requests/2.28.1" I don't know what's going on here. The code is doing a POST <https://gitlab.com/mailman/mailman-hyperkitty/-/blob/master/mailman_hyperki…>. If in fact HyperKitty is seeing a GET and therefore returning a 405, that explains the above traceback, but I don't know why that would be. You could always try adding additional logging to mailman_hyperkitty/__init__.py to log the entire result, but I suspect the issue is that there is a redirect somewhere in the path from the configured HyperKitty base_url (see mailman_hyperkitty.cfg) and the actual HyperKitty API that is redirecting the POST to a GET and also dropping the POST data. -- 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: spf/dkim/dmarc

by Odhiambo Washington

Domain vs subdomain. At least I never mentioned subdomain. On Wed, May 17, 2023, 21:50 Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/17/23 07:20, Odhiambo Washington wrote: > > > > You can only have 1 SPF record. > > For a domain. But as Jeremy Stanley noted, mail.ccalternatives.org and > lists.ccalternatives.org are different domains and it is fine for each > to have its own spf record. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to odhiambo(a)gmail.com >

2 years, 5 months

[MM3-users] Re: HTML header / footer template

by Mark Sapiro

On 06/18/2018 02:33 AM, Asaf Ohayon wrote: > I understand Mailman 3 doesn't want to support HTML Emails, > This is perfectly legitimate, sadly however, This is a requirement of my client, > Which is in this case the Ministry of Education of Israel. Mailman does support HTML email. Just adjust content filtering to not remove HTML and not collapse alternatives. What Mailman does not support (and which I think is what you want) is the addition of headers and footers either as text/html parts or inserted into text/html message bodies. The former would be fairly easy. Look at mailman/handlers/decorate.py. If the messages you are decorating are text/html or multipart/alternative or something more complex, the header and footer are going to be separate MIME parts anyway, so where we have > if len(footer) > 0: > mimeftr = MIMEText( > footer.encode(lcset, errors='replace'), 'plain', lcset) > mimeftr['Content-Disposition'] = 'inline' > payload.append(mimeftr) > if len(header) > 0: > mimehdr = MIMEText( > header.encode(lcset, errors='replace'), 'plain', lcset) > mimehdr['Content-Disposition'] = 'inline' > payload.insert(0, mimehdr) in two different places, just change the 'plain' arguments to 'html' and then the headers and footers will be added as text/html and can include html tags to be rendered. On the other hand, if what you want is to insert headers and footers at the beginning and end of an existing HTML body part, We will not make Mailman do that because it is very difficult to do it right. This is because just prepending or appending some additional HTML to an existing HTML part gives unpredictable results. You need to actually parse or render the existing HTML to determine how to add your additions and in complex cases even that may not render as you wish in all various MUA renderings. If you want to try for HTML what decorate does for simple plain text, you can try it and you may find it works for you, but it is way to fragile for a Mailman feature. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 4 months

[MM3-users] Re: Mailman do not honor non-members moderation setting sometimes

by Mark Sapiro

On 6/16/20 1:28 AM, Alan So wrote: > Some of our users reported that their list do not honor the nonmembers moderation setting sometimes. We were not able to repeat the issue consistently earlier. Luckily, we found the following way to repeat the issue: > > 1) Create a new list with user(a)example.com as owner. (Ordinary disussion mailing list style) > 2) Change the list Settings -> Message Acceptance -> Default action to take when a non-member posts to the list: Discard > 3) Add a non-member user(a)example.com and change the moderation setting to Hold for Moderation > 4) Send an email to the list using user(a)example.com. > > The message is discarded instead of being held. The above can also be repeated with the list setting Default action to take when a non-member posts to the list: Accept immediately. The message sent from user(a)example.com is accepted instead of being held. So, it looks like that the non-members moderation setting is ignored for this case. > > Further study indicate that the issue did not happen if the owner is set to user(a)example.com *after* adding the non-member. It looks like that we can avoid the issue during list creation. However, the issue can also be triggered through other ways such as adding the non-member as member and remove. There are also ways to resolve the issue by removing all corresponding member, non-member, owner setting and add them back in the following order: non-member, owner. However, it does not always work and so I do not go into the detail at this moment to complicate the issue. This is a known issue. See <https://gitlab.com/mailman/mailman/-/issues/659#note_270261964>. When the same user/address has both non-member and owner roles, setting moderation for the non-member in Postorius actually sets moderation for the owner which is meaningless because the owner role is never checked for moderation. Since the reference above is obscure, I have created https://gitlab.com/mailman/postorius/-/issues/436 for 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, 4 months

[MM3-users] Re: share directories between postfix and mailman 3

by Mark Sapiro

On 1/22/24 13:05, Thomas Schachtner via Mailman-users wrote: > Hi there, > > But that's not the full deal. Postfix needs access to some hashed > configuration files containing the transport maps and the domains of the > mailman installation, and mailman needs the contents of the postfix > configuration file. Why do you think Mailman needs the contents of the postfix configuration file.. I don't think so. > As a quick and dirty solution, I've established a process which > periodically copies the /var/lib/mailman3 directory from the mailman box > to the postfix box using rsync. It appears you are using the Debian/Ubuntu package or at least have configured `layout: fhs` in the `[mailman]` section of mailman.cfg. This is OK, but in any case, all Postfix needs is /var/lib/mailman3/data/*. > But I would like to have a more professional solution, like a directly > shared directory between both. > I did not yet find any suggestions on how to achieve this. Are there any > best practices recommendations? > I already tried sharing the directories using sshfs, but that did not work. > > I connected the remote directory postfix.example.com:/var/lib/mailman3 > to my local directory /var/lib/mailman3 using > > sshfs root@postfix.example.com:/var/lib/mailman3 /var/lib/mailman3 I would suggest the opposite. I.e. on the postfix machine ``` sshfs user@mailman_machine:/var/lib/mailman3/data /var/lib/mailman3/data ``` > This seemed to work pretty fine, as all files and directories seemed to > be available, but when starting mailman 3, the following error message > was shown: > FileExistsError: A race condition might have happened. /var/lib/mailman3 > actually exists and is not a directory. > > Any idea why this message is shown? Possibly because the uid and gid of /var/lib/mailman3 on the postfix machine do not map to the appropriate Mailman uid and gid on the mailman machine. > So, is it a bad idea to use sshfs? If you do it the other way, it might work. -- 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: Hyperkitty performance problem

by Mark Sapiro

On 12/28/24 05:19, monochromec via Mailman-users wrote: > Following the root cause analysis which Tobias started all those weeks ago we (the admin team behind the installation) are still struggling with the following phenomenon: messages on average take more than 24 hours to be processed, more precisely, the average lifetime of a pickled message object in `/var/lib/mailman3/queue/pipeline` clocks in at around 26 hours). This issue is with Mailman core's pipeline runner. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/8-mil… for an overview of message handling and queues in Mailman core. It seems that the pipeline runner(s) are taking an inordinately long time to process a message through the pipeline of handlers causing the pipeline queue to become backlogged. > Couple of stats of the installation: standard installation from Bookworm OS repos, Hyperkitty as archiver and Postorius as web frontend as explained above, running Python 3.11.2 from the standard systemd service as packaged with the Bookworm deb file. All backends (Core + Hyperkitty) are supported by Postgres version 15+248. The MTA is a standard Postfix installation, again from OS packages. The primary support for Debian packages is Debian. See https://wiki.list.org/x/12812344 > The underlying VM has 7 cores with just under 24 GB of main memory. This production instance is handling less than 130 mailing list (MLs) with an average of less than 10 postings per day per ML. CPU core utilisation hovers around 50% with the lion share allocated to the four pipeline runners as part of the MM configuration. This is an average of less than 1 message per minute. Processing a message through the pipeline should take nowhere near a minute. Possibly there is an issue in the rfc_2369.py handler. This handler communicates with HyperKitty via mailman_hyperkitty to obtain values for the List-Archive: and Archived-At: headers added to the message. Possibly there is some configuration issue with mailman_hyperkitty that causes these queries to take a long time and possibly eventually time out. Are there any `Connection to HyperKitty failed:`, `HyperKitty failure on ...` or `Invalid response from HyperKitty` type messages in mailman.log? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 1 week

Search results for query "sapiro"