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

[MM3-users] Re: Missing Base64 encoding from control message reply

by Mark Sapiro

On 9/23/23 02:54, Jana Berger wrote: > > I have multiple control messages, all received from my instance which > all contain the "Content-Transfer-Encoding: base64" marker, their > contents is plain text (Content-Type: text/plain; charset="utf-8"), but > they are still encoded using base64. It seems you are saying these messages are valid. I.e. they specify "Content-Transfer-Encoding: base64" and the body is in fact base64 encoded. This is as they should be. > Of course that is not proof, but an indication that it is either done by > the mail server itself or widely across MUAs. As you say, this suggests that some MTA in the path to your user or the user's MUA is responsible for decoding the base64 encoded body but leaving the "Content-Transfer-Encoding: base64" header as is. > Global "Preferred language" is "English (USA)", which is not overridden > by the list in question. I have not changed the default encoding. Is > there a surefire way to detect this? > > My mailman.cfg has no section pertaining to encoding, and all related > files also do not mention encoding. The Subject: and body of these messages should be ascii, not utf-8 unless you have something like ``` [language.en] charset: utf-8 ``` in your mailman.cfg -- 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: Single Click Unsubscribe

by Mark Sapiro

On 1/25/24 15:21, olebra(a)samfundet.no wrote: > > To me, "subscribed messages" in the above means the policy applies to > everyone sending over 5k emails daily, whether for marketing or not. > > All the best, > Ole > > [0]: https://support.google.com/a/answer/81126 > _______________________________________________ > 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… You can always put something like the above "To unsubscribe ..." line in the lists footer as we do. Gmail's web UI renders that as a mailto: link. Further, at least in some cases, Gmail's web UI recognizes the List-Unsubscribe header in the message and provides it's own Unsubscribe buttons in the web UI. Granted, these aren't truly "one click" as they require confirmation, but that can be avoided by setting a list's unsubscribe_policy to `open`. Also granted that Gmail is the 900 pound gorilla here, but unsubscribe links that don't require confirmation are a bad idea. Even if the link contains some kind of encrypted data to ensure it can't be spoofed, there is still a danger if I forward list mail to a 3rd party and they click my unsubscribe link. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

[MM3-users] Re: Scheduled tasks

by Mark Sapiro

On 6/7/18 9:59 AM, Darren Smith wrote: > All, > > I am looking more through the documentation of the Mailman Suite here: > > https://media.readthedocs.org/pdf/gnu-mailman/latest/gnu-mailman.pdf > > In section 3.2.5 it talks about the scheduled tasks that need to be run to > do "specific routine functions" in hyperkitty. > > I installed through the easy install script found here: > > https://github.com/iomarmochtar/mailman3_ei/ > > However, I can't find anything in THAT documentation that talks about these > cron jobs, and in fact the Mailman Suite isn't installed through that > script. That is a third party project. If you have issues with it, you should take them up with @iomarmochtar. > Can someone point me to any other documentation about the tasks that need > to be run on a continual basis? The section 3.2.5 you refer to tells you what needs to be set up in cron. For a list of the jobs tat are run, use django-admin runjobs --list . Our hyperkitty installation seems to be > bogging down more and more, and I am hoping that it will be as simple as > just running some jobs that haven't been on our radar. what do you mean by 'bogging down'? If you aren't doing so, setting up qcluster as in section 3.2.3 may help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

[MM3-users] Re: 500 Internal Server Error on specific list pages

by Mark Sapiro

On 7/29/20 9:55 PM, Johnny Cison wrote: > I have a new Mailman 3 server set up and am having a strange issue with > just one particular list. > > Accessing the list's Info page URL or it's Archiving Settings page URL > returns a 500 Internal Server Error, but its other pages work correctly. > Also, the Info and Archiving pages on the other lists are working correctly. > > When I access the info page for the problem list, I get these errors in the > log: > > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line > 41, in inner > response = get_response(request) ...> line 103, in call > raise HTTPError(url, response.status, content, response, None) > HTTPError: HTTP Error 500: A server error occurred. Please contact the > administrator. > > > When I access the Archiving page in Settings, I get these: > > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line > 41, in inner ... > line 103, in call > raise HTTPError(url, response.status, content, response, None) > HTTPError: HTTP Error 500: A server error occurred. Please contact the > administrator. These messages are from Django's log. What's in Mailman's mailman.log? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: postfix malformed address with confirm replies

by Mark Sapiro

On 2/26/21 3:34 PM, Stephen Willey Mats Mats wrote: > > I’m getting bounces back from postfix (553 5.1.3 Error: malformed address) for my confirm replies. ... > I’m pretty sure I have all of the mailman settings in postix: > " > # Support the default VERP delimiter. > recipient_delimiter = + Yes, this is the relevant one and is correct. ... >> The mail system >> >> <matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu>: >> host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address >> (in reply to RCPT TO command) >> Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal >> X-Postfix-Queue-ID: E144B8BC3C5 >> X-Postfix-Sender: rfc822; stephen.s.w.matsmats(a)gmail.com >> Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST) >> >> Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu >> Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu >> Action: failed >> Status: 5.1.3 >> Remote-MTA: dns; 172.19.199.2 >> Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address I have no idea why Postfix is saying `matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu` is a malformed address, but this is a Postfix issue, not Mailman. Can you successfully post to `matsmats-mm3-test1 @mm3.aca-aws.s.uw.edu` how about a `help` command to `matsmats-mm3-test1-request(a)mm3.aca-aws.s.uw.edu` -- 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: problems installing mailman3 under gentoo and upgrading mailman2 to mailman3

by Mark Sapiro

On 3/13/21 7:08 PM, John Covici wrote: > On Sat, 13 Mar 2021 16:22:59 -0500, > Abhilash Raj wrote: >> >> My guess is that you updated the database (perhaps, by invoking the mailman >> command form 3.3.3) and then tried to start 3.3.2. In this case, Mailman comes >> up and sees a new revision for the database migration added from 3.3.3 but >> can’t find the same migration in its source (because it is 3.3.2). > > That is sort of what happened, except in the opposite direction, it > was from 3.3.3 to 3.3.2. My question is therefore, do I have to > update this alembic_version when I upgrade mailman to a newer version? > That is what I was getting at. Abhilash's conjecture is that the error was due to a Mailman version accessing a database that had been previously accessed by a newer version so that the version_num in the alembic_version table didn't exist in mailman/database/alembic/versions/. This normally would not occur on an upgrade of Mailman, but if you went from a gentoo Mailman core to a version obtained by pip, it's possible that the gentoo Mailman had an alembic version that wasn't known to the pip Mailman even though the pip Mailman was newer. -- 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: sending messages in response to posts from non-members

by Mark Sapiro

On 2/26/22 04:26, David Bremner wrote: > > I'd like to turn off the "bounce messages" sent by mailman to > non-members. My reasoning is that most such posts are spammers, and > often use forged return-paths / From's, so I end of sending steady > stream of backscatter to amazon.com etc... > > Is this configurable (without postorius) somehow? What exactly do you want? Do you want to discard without notice any nonmember posts or do you want to hold them but not send a notice of the hold to the poster? For the former, you want to set the list's default_nonmember_action to discard. For the latter you want to set the list's respond_to_post_requests to False. To make either of these settings the default for new lists, you'd need to patch mailman/styles/base.py. To set them for all lists you could do the following in `mailman shell` ``` $ bin/mailman shell Welcome to the GNU 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. >>> for mlist in getUtility(IListManager).mailing_lists: ... # Pick the appropriate one of the following. ... mlist.default_nonmember_action = Action.discard ... mlist.respond_to_post_requests = False ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: MM attaches mime-attachments to mail as text file since update to 3.3.8

by Mark Sapiro

On 1/17/23 23:45, Stefan Bauer wrote: > Dear Users & Developers, > > we're running MM3 on Ubuntu 22 and used the venv-installation method. > Last week we updated via¹ to > > Mailman Core-Version GNU Mailman 3.3.8 (Tom Sawyer) > Mailman Core API-Version 3.1 > Mailman Core Python-Version 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC > 11.3.0] > > and now mailman attaches mime-attachments to email as text-files. That > breaks many mails in our environment. > > For example: Now we have attachments like > > smime.p7s + ATT000001.txt as well as what looks like MM footers > "mailing list --- test@domain ... To unsubscripbe send an email to ..." > > How can we get the "old" processing back? I doubt this has anything to do with the upgrade per se. It has to do with MIME multipart (in this case, signed) messages and how MM headers/footers are added. The MM 2.1 FAQ article at <https://wiki.list.org/x/4030707> has some info on this. In order to say more, I would need to see the list's settings for Filter types, Filter extensions, Pass types, Pass extensions, Collapse alternatives and Convert html to plaintext and the complete MIME structure of the incoming message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 5 months

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

by Mark Sapiro

On 1/24/22 15:06, Mark Sapiro wrote: > On 1/18/22 06:24, Stephan Krinetzki wrote: >> Hello, >> >> We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is >> installed in a venv and deployed using Apache and uwsgi. This works >> quite well so far, only withheld messages cause us a problem: If we >> try to approve them via Postorius, the message is delivered to the >> list immediately, but the success message in Postorius takes a long >> time - on average the process hangs for three minutes until the >> message is no longer displayed. We have already adjusted the timeout >> in gunicorn.cfg, but this does not improve the situation. Are there >> any tips on how we can speed up the REST API? Or is it even a >> configuration error? > > > There are two steps in handling the POST for a held message. The first > step is accepting, rejecting or discarding the message. This is > happening immediately. > > The second step is handling the poster's moderation action based on the > choice from the Set member moderation dropdown in the view of the held > message. This is processed by the code at > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…>. > If no selection has been made, the default value POSTed for > moderation_choice is `no-action` and that code is skipped. If it is one > of the choices `Hold for moderation`, `Reject (with notification)`, > `Discard (no notification)`, `Accept immediately (bypass other rules)` > or `Default processing` that is processed. So presumably a selection has > been made and processing is stuck on getting the member or setting the > member's moderation action. > > Possibly the logs of your database manager will have information. > Some additional info. By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?. Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

[MM3-users] Re: New Mailman 3 installation issues

by Mark Sapiro

On 5/19/21 1:26 PM, Sarah H wrote: > I think you've just hit the nail on the head as far as my biggest issue with this project. The documentation lays out an install method that should be roughly followable for anyone (though it needs a bit of fine tuning here and there) and then the rest of the configuration guide and documentation assumes that you have installed the software in a completely different way and doesn't work the same as the guide laid out. Because virtually all that documentation was written by different people and long before the https://docs.mailman3.org/en/latest/install/virtualenv.html was added. > The documentation should be uniform, if you want users to install it one way then write the guide and documentation so that's the "default". Sure present alternatives or notes "if you've installed via git, your commands will look like this xxx" but ultimately the biggest issue I've had with getting this deployed is inconsistent or lacking documentation. I'm not trying to make excuses. I know the docs need improvement, but we are a very small, all volunteer project doing the best we can. If you feel you can offer improvements to the documentation, we'd love to have your help. You are more than welcome to submit merge requests to update the docs. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

Search results for query "sapiro"