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

[MM3-users] Re: Message is received but is not sent out. Another, similar message, is processed fine.

by Mark Sapiro

On 6/26/23 11:00 PM, Allan Hansen wrote: > > I also see this in queue/shunt: > > mailman@list:~/var/queue/shunt$ ls -ltr > total 88 > -rw-rw---- 1 mailman mailman 7168 Feb 17 23:03 1676703781.903885+fdcba88c680f50a0799c672cd0abe82e4bfe19b3.pck > -rw-rw---- 1 mailman mailman 19821 Apr 2 07:08 1680444501.0831451+e110b8c5c20ba3f87c1cea1c5f38e74a6cf8f1c5.pck > -rw-rw---- 1 mailman mailman 19489 Jun 18 11:52 1687114364.41209+1684717da96ff76d1ce773a0cf39c5f8b63e9078.pck > -rw-rw---- 1 mailman mailman 20274 Jun 18 19:01 1687140067.64057+7f77c1ebca490831f58ef9cfde06109081a4e7d6.pck > -rw-rw---- 1 mailman mailman 20085 Jun 26 17:18 1687825091.8457294+478565324778f2eb6f0fecaeccbd29596edaef53.pck > > The three last entries coincide with the captured messages. I suggest you examine those with `mailman qfile` and remove any irrelevant or duplicate messages. If you have mailman.log from Feb or Apr, you could find the error that caused the shunting and maybe fix it. > Finally, in the captured message source (the last which was Cc'd to me) I do see this: > > Content-Type: text/plain; charset="iso-8859-8-i" > > Which matches the complaint in the mailman log. If you want to fix and unshunt any of these, you could do, e.g., in `mailman shell` (watch out for wrapped lines) ``` >>> import pickle >>> file = '1687114364.41209+1684717da96ff76d1ce773a0cf39c5f8b63e9078.pck' >>> with open(file, 'rb') as fp: ... msg = pickle.load(fp) ... msgdata = pickle.load(fp) ... >>> msg.replace_header('Content-Type', 'text/plain; charset="iso-8859-8"') >>> with open('/path/to/.pck/file', 'wb') as fp: ... pickle.dump(msg, fp) ... pickle.dump(msgdata, fp) ... >>> ``` > Another difference: > The posted message shows > Content-Transfer-Encoding: base64 > The shunted message shows > Content-Transfer-Encoding: quoted-printable That's not important. > My question thus changes to: > > a. Should she be doing something special when sending to the lists? Get her mail client to send utf-8 or iso-8859-8 encoded messages, not iso-8859-8-i. > b. If not, is my setup in need of change? See Steve's reply. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

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

[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

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

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

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

2 years, 2 months

[MM3-users] Re: upgrading in FreeBSD 13.1-p7: problem with aiosmtpd and lmtp runner

by Mark Sapiro

Guillermo Hernandez (Oldno7) wrote: > I thought I said it: I reboot this server everyday at 06:40 CEST time. > That's why I'm sure it's not an undetected problem for weeks. The lists > in this last upgraded server are with daily traffic. I'm suscribed to all. I've looked at this a bit further. Prior to Mailman core 3.3.4 we required aiosmtpd>=1.1. In 3.3.4 we required aiosmtpd>=1.4.1 and now we require aiosmtpd>=1.4.3. The code in aiosmtpd that triggers the issue in the socket module was added in aiosmtpd==1.3.1. So it is likely that your prior Mailman core version was <3.3.4 and your aiosmtpd dependency was <1.3.1, so the Mailman upgrade would also have upgraded aiosmtpd to a version which triggered the socket issue.

3 years, 1 month

[MM3-users] Re: Sort Lists in Postorious

by Simon Coggins

A feature request to this for me would be to search the lists. We have over 200 lists and it's hard to find the one you need to work on as an admin :) Sent from my iPhone On 1 Dec 2021, at 08:45, Mark Sapiro <mark(a)msapiro.net> wrote: On 11/30/21 1:26 PM, Jonathan Wright via Mailman-users wrote: > Is there a way to sort the lists displayed on the main page of Postorious? They are sorted alphabetically by list name. There's not an option for another sequence. -- 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/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>

4 years, 5 months

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Mark Sapiro

On 7/26/20 9:12 AM, Odhiambo Washington wrote: > On Sun, 26 Jul 2020 at 18:48, Mark Sapiro <mark(a)msapiro.net> wrote: > >> On 7/26/20 3:15 AM, Odhiambo Washington wrote: >> >>> There is still some confusion on my part about the directives in the file >>> so allow me to seek some clarifications. >>> >>> The following are the contents of a file I have created and placed in my >>> Apache Includes/ directory. >>> I was hoping that with it, I can now access http://lists.my.server/mm3 >> and >>> get the UI. >>> >>> <CUT> >>> >>> # Global section >>> WSGIDaemonProcess mailman-web display-name=mailman-web >>> maximum-requests=1000 umask=0002 user=mailman3 \ >>> group=mailman3 >>> >> python-path=/opt/mailman/mm/venv/lib/python3.7/site-packages:/opt/mailman/mm/venv/lib/python3.7 >>> \ >>> python-home=/opt/mailman/mm/venv home=/opt/mailman/mm/var >>> WSGIRestrictSignal Off >>> >>> <VirtualHost *:80> >>> ServerName lists.my.server >>> ServerAdmin odhiambo(a)gmail.com >>> >>> # (I'm not sure that WSGIRestrictSignal Off is required, but it was in >> the >>> # provided example so I kept it. I also made changes to WSGIDaemonProcess >>> # based on my own mod_wsgi experience elsewhere.) >>> >>> ErrorLog /var/log/myserver-error.log >>> LogLevel debug >>> >>> # This goes in the VirtualHost block for the domain. >>> >>> # Mailman 3 stuff >>> Alias /static "/var/spool/mailman-web/static" *<----- Where is this >>> directory supposed to be and what/who creates it and with what >> permissions?* >> >> >> It is created/updated by the mailman-post-update script based on CONFDIR >> and STATIC_DIR. >> > > The fact that I have run the mailman-post-update script and these > directories aren't created means there is a problem in my setup, yes? If your mailman-post-update script is essentially the same as <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…> and it ran successfully, it would have created opt/mailman/mm/static and populated it. What was the output when you ran it? > Yes, I have these files: > (venv) [root@gw /opt/mailman/mm]# ls -al /opt/mailman/mm/settings* > -rw-r--r-- 1 mailman3 wheel 15518 Jul 25 14:34 > /opt/mailman/mm/settings.py > -rw-r--r-- 1 mailman3 wheel 15773 Jul 26 10:33 > /opt/mailman/mm/settings_local.py Is there an empty /opt/mailman/mm/__init__.py file? > PS: I made my /opt/mailman to be owned by mailman3:wheel because of a > confusion with the instructions at some point in the reading > of some documentation previously (in my previous attempt last year!) and > had noted that in my NOTES. I'll change this once things get clear for me. > Also, the fact that one of the init scripts > <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…> > in your "reflection" page was calling sudo :) It does `sudo -u $USER ...` so that it runs Mailman as the Mailman user as it should. Have you set USER=mailman3 in yours? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 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, 10 months

Search results for query "sapiro"