Search results for "Postorius" - Mailman-users

Re: Postorius: Dropdown menus problem

by thor.rustad＠gmail.com

I'll add some additional information. Chrome inspect to the rescue :-) I don't know what it means. Is it Nginx that needs configuration? Could it be because I still lack the certificate for https? Refused to execute script from 'https://myserver/static/postorius/libs/jquery/jquery-1.11.3.min.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled. myserver/:1 Refused to execute script from 'https://myserver/static/postorius/libs/bootstrap/js/bootstrap.min.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled. myserver/:1 Refused to execute script from 'https://myserver/static/django-mailman3/js/main.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled. myserver/:1 Refused to execute script from 'https://myserver/static/postorius/js/script.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled. -rw-r--r-- 1 ubuntu ubuntu 95957 Dec 1 16:18 jquery-1.11.3.min.js

7 years, 9 months

Re: Mailman installation results in KeyError: 'env_py'

by Simon Hanna

>Thanks. Applying this patch makes it work. Now I've got a different >problem, though. I can't get it to connect to Postfix for sending >emails it appears. After I created a superuser account using > > $ python manage.py createsuperuser > >as described on <http://postorius.readthedocs.io/en/latest/setup.html>, >I tried to login using this credentials into Postorius. It then >reported >it sent a confirmation email to me (for an account I created on >commandline?!), but Postfix' logs reveal that it didn't; there's not >even a sign of an attempted delivery in /var/log/mail.log. I've >configured the Postfix configuration in mailman.cfg like this: > >mailman-suite's settings.py contains: > > # Change this when you have a real email backend > EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' > EMAIL_HOST = 'localhost' > EMAIL_PORT = 25 > There is a second occurrence of EMAIL_BACKEND in the settings file. Try commenting it, or setting DEBUG to True IIRC I have created an issue for that on gitlab. The email you are referring to, is sent by Postorius aka Django and not Mailman. So you won't find it in the logs of Mailman. The email is being sent by the library that Postorius uses for authentication and user management. I'll see if there is a switch to autoconfirm such accounts. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years, 10 months

Re: Remove login from list subscription page

by Mark Sapiro

On 3/1/22 12:23, bob B via Mailman-users wrote: > Is there any way to easily remove the login button for the List subscription page? 99% of our list do not use archiving, and log-in just confuses users so We would like for them just to be able to sign up to be on the list. You would need to patch postorius/templates/postorius/lists/summary.html Something like this would do what I think you want. ``` --- a/src/postorius/templates/postorius/lists/summary.html +++ b/src/postorius/templates/postorius/lists/summary.html @@ -101,20 +101,9 @@ {% endif %} {% else %} <div> - <h2>{% trans 'Subscription / Unsubscription' %}</h2> - <p>{% blocktrans %} - To subscribe or unsubscribe from this list, please log in first. - If you have not previously logged in, you may need to set up an account - with the appropriate email address. - {% endblocktrans %}</p> - <p><a href="{% url LOGIN_URL %}?next={{ next|default:request.path|urlencode }}" class="btn btn-primary">{% trans 'Log In' %}</a></p> - </div> - <hr /> - <div> - <p> + <h2>{% trans 'Subscription' %}</h2> {% blocktrans %} - You can also subscribe without creating an account. - If you wish to do so, please use the form below. + To subscribe to this list, please use the form below. {% endblocktrans%} </p> <form action="{% url 'list_anonymous_subscribe' list.list_id %}" ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

Howto: Mass import of nonmembers in several lists?

by Paul Paulchen

Hi MM3 community, got a, perhaps easy question. Following situation, got 8 lists and up to 20 nonmember users missing to the list. The massimport with postorius is only for members, as far as I can use it (Postorius Version 1.3.4). So without adding all nonmembers with postorius step by step 8x20 times, there is an easier way to do it. I thought so, because the import21 command did this as well when we migrated to mailman3. I read about the command "mailman addmembers" https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d… I am guessing, that I need to create a file like in the example of the addmembers, adding all my nonmember users with their email addy. But how can I add/ tell the command in this massimport that the new members are nonmembers in the existing lists?! Hope I explained my case properly. I appreciate your responds! Thanks in advance. - Paul

3 years, 8 months

Re: Separating Lists by Domain

by Johannes Winter

Am Mon, 24 Dec 2018 00:41:43 -0000 schrieb brian(a)emwd.com: > I have successfully setup a second domain with my Mailman3 setup. I > also created a list using the second domain. So I have two domains > with one list each. The issue I see at this point is all of the lists > are shown via Postorius regardless of the list domain used. Is it > possible to have only the lists to show that are part of the domain > being used to access? For example: > > http://domaina.com/postorius/lists/ > > Only listnames(a)domaina.com show up. > > http://domainb.com/postorius/lists/ > Only listnames(a)domainb.com show up. > > Right now both domaina AND domainb lists showup regardless of the > domain being used to access Postorius. The same goes for Hyperkitty > as well. Hi Brian, I once asked a similar question: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… Best regards, Johannes

6 years, 8 months

Re: Rolling releases for Container Images and Funding Campaign for Mailman

by Abhilash Raj

On Sun, Nov 12, 2017, at 08:06 AM, Simon Hanna wrote: > > >>> These images are built using git-heads *only* if they are passing our > >>> test suite and are re-generated weekly. You should be aware that while > >>> all these components are tested with their individual test suites, their > >>> combination might sometimes not be stable. This will get you > >>> updates/bug-fixes much faster :) > >> This contradicts what you said in my merge request for Postorius > >> https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 > >> > >> You either use released versions, or make sure that the master branches > >> are always compatible. You can't have both with the current development > >> model. > > Not exactly, I still believe all our git-heads should be compatible with > > released (i.e. stable) versions of dependencies, regardless of the fact > > that we maintain those dependencies. > > > > Also, there is at least one test per-project which tests with git-heads > > of dependencies we maintain, so that we know if we make any incompatible > > changes. > > > > I am not sure what in the current development model prevents us > > to do both? > > > > The story for container images is different than testing with git-heads. > > We need better integration testing for the entire suite to be stable in > > conjunction, rather than independently. In fact, containers might be the > > perfect way to actually do the integration testing. > Scenario: Core changes something about rest that is backwards > incompatible. The change is commited to master. Since your containers > use the master branches, all future builds will fail until mailmanclient > and postorius/hyperkitty. Yes, that is a totally possible scenario. But, given that kind of testing we currently do, this scenario can happen not only to git-heads but also releases. That is what I am trying to build using container images. The fact that I *announced* and *released* these rolling images for public use, is only because people asked for it before. These images come with a fair amount of warning that, right now, they can break! > If you want to always have Postorius (and others) compatible with the > latest release of master, development for Postorius will be a Pain, > because you can't use the master branch of mailman for testing and quick > changes. Also your containers and all integration tests that can be done > with them will always fail. It would most definitely be a pain if we were to break REST API frequently, but that is quite rare. Given that in future API will be consumed by not just us, it is important to keep this assumption true. Another wishful project I have is to be able to "map" the REST API and monitor for changes; it'd also help us with lemme (the authenticating/authorization proxy for Core). And yes, container images will fail, and that's the point! I want them to fail so that releases don't :) Rolling images are meant to bring a faster feedback-loop from users who are OK with rare occasional breaking and want to help test the software, something like public-beta releases. > Until you fix Postorius and the other clients... So why not just have > the master branches always compatible and make life easier for > developers. Incompatible changes are released only with major version upgrades, so it is not going to happen with everyone, unless they choose to use the git-heads and get themselves into it. > I don't see a good reason why you want to do it the other way round... > > Any bug in core that affects Postorius will also just remain there until > you release a new version of core. > > If you really really want to have it your way, there have to be more > frequent releases. Yes, we definitely don't want to say "use new beta-quality container images or stone age stable release". Going forward, we will have more frequent releases too :) > >>> - Improve the container images to work with new micro-services > >>> architecture, > >>> to achieve scaling and redundancy in services. > >> The current bottleneck is the rest api from core. IMO bulk actions, > >> filtering and sorting should be added there before trying to have > >> multiple postorius/hyperkitty instances serving the same core... > > I didn't say they will be served from the same core ;-) > > > > Yes, the Core's API can be further improved to be more efficient. But > > that > > doesn't prevent us from scaling. I understand there are issues around > > multiple > > instances of containers, but I have ideas to get around most of them. > I just don't want that people that have issues with big installations > get the answer: > We know of that issue, please deploy Mailman on X containers/machines as > a workaround Containers are just an easy way to scale, given that we already have them, it'd be fun to see if I can make multiple instances run in parallel. Given that _most_ parts store their data in a data store (database, redis etc), it shouldn't be too difficult. There will be quirks with logging, queues in Core and hence held message views in Postorius, but apart from that, I think everything else can be served using any random instance of Core/Postorius/Hyperkitty. We can most definitely run multiple instances of Hyperkitty, which I feel will be more used than any other part of UI. If we partition the data smartly, we could do the same with Core. Again, these are just theories and needs much more testing and some changes in components themselves! This would most definitely increase the availability and auto-scaling. Making Core's API more efficient would definitely be a good thing and we do intend to do that in future. But, this would still be relevant if we had an efficient REST API, it's not a band-aid to the actual problem :) -- Abhilash Raj maxking(a)asynchronous.in

7 years, 10 months

Error -- postorius Un-handled exception

by Stephen J. Turnbull

Mark writes: > # tail -f /opt/mailman/web/logs/mailmanweb.log > File > "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", > line 160, in call > raise HTTPError(params.get('url'), response.status_code, > urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server > Error"} > ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server > Error: /postorius/lists/testing.example.com/ I don't recall seeing this one before, maybe Mark S has some idea. Try running all the system initializations with "mailman info" and "mailman conf". This often will elicit errors if the system is messed up. More likely to get this error would be "mailman withlist $LIST" (maybe you need an '-l' option to specify the list, I forget). If that doesn't elicit the error, then check that Mailman's runners are running with ps. Since it's Debian, I guess they should be running as the 'list' user. Are Mailman's files and directories owned by 'list' or sometimes 'www-data' for log files? The log is saying that when Postorius tried to look up that list, it tried to call out to Mailman core via HTTP to the API to get the information and that access failed with HTTP status 500. I think the actual error is likely to be reported in mailman.log (or it might be in error.log, "grep '05:41:46' *.log" in Mailman's log directory will probably find it). I'm pretty sure there will be relevant log entries, probably a matching traceback. You might also try grepping in your SQL DB logs for that timestamp. > And the Mailman log is a mystery to me, It's hard to get good exception reporting when you have multiple layers in the stack, and some of them are separated by TCP/IP connections. You'll have to correlate across logs by timestamp. > and no error is reported in the Nginx log ... Right, this is happening far far away from nginx, much farther down the stack. Steve

1 year, 7 months

New subscribed (by invitation) user: no password received in invitation/welcome e-mail. Postorius sign up / password reset broken

by Stephen J. Turnbull

^m'e via Mailman-users writes: > I migrated form MM2.1 to MM3.3.10 on Debian Trixie (mariadb > backend) -- I know that's a bit unorthodox to ask here for help on > a non venv-based installation, We appreciate your courtesy, but this is inaccurate. If you install a distro-packaged Mailman and it doesn't do the basic stuff such as "start" or "respond to web requests" out of the box, that's a distro problem. (That includes any features missing because of the inevitable lag in distro packaging.) On the other hand, if you have a misconception (see Issue #1) or if Mailman is basically working but doing a particular weird thing (in your opinion, and that's Issue #2), asking here is the right thing to do. Distro maintainers are frequently experts in packaging but ordinary users of their package without expertise in troubleshooting the package, and usually zero interest in educating users. That is what we are here for! And, obviously, "real" bugs may manifest first in a distro package. > but hopefully I'll first gain a bit of insight of MM3 in order to > formulate a more precise request to Debian maintainers. I don't think these are Mailman issues, and quite likely they're not Debian issues. > ## Issue #1. > > A newly invited (from Postorius mass subscription page) and > confirmed user doesn't get any password in their invitation/welcome > e-mail. The invitation/welcome emails usually don't know if the user is verified, and they are otherwise not personalized, so sending a one-time password (OTP) at that time would be a lot more complicated than it's worth. Also, many users may prefer to NOT set a password at all. For example, if you configure the Gmail socialauth plugin, a Gmail user can log in without doing the OTP dance. (I think we still require the dance to verify the address, because socialauth is hard and the burden is small. And if 'confirm' is set in the list preferences, you have to either log in to Postorius to subscribe, or do the dance for an email subscription.) Because Mailman 3 has a model of a user with multiple addresses and subscriptions, the burden of using the reset password dance for the initial setting of a password is considered very small (it usually is done once during the user's association with the Mailman instance, if at all). So that's the way we do it. > ## Issue #2 > > Anyway, if that new user asks for a password reset on Postorius they get > > "Server error > An error occurred while processing your request." This appears to be an MTA misconfiguration, either in Mailman or possibly in the MTA: > File "/usr/lib/python3.13/smtplib.py", line 861, in sendmail > self.ehlo_or_helo_if_needed() Mailman tried to connect to a mail server. > File "/usr/lib/python3.13/smtplib.py", line 365, in send > raise SMTPServerDisconnected('please run connect() first') > smtplib.SMTPServerDisconnected: please run connect() first It failed. Twp possibilities off hand: (1) The server expects authenticated and/or encrypted email (SASL and TLS), but Mailman is not configured to do that. (2) A typo in the server IP or hostname. There are all sorts of other reasons why a server might refuse a connection, but we'd need a lot more information to diagnose. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

2 weeks, 2 days

Re: New subscribed (by invitation) user: no password received in invitation/welcome e-mail. Postorius sign up / password reset broken

by Marco Emilio Poleggi

Thanks Steve. Yeah, indeed, it was a stupid configuration error. So, while investigating malformed-url errors (https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…, I had set mistakenly in `/etc/mailman3/mailman-web.py`: EMAIL_HOST = '' Of course, then how can Postorius contact my SMTP!? Bah, tweaking stuff uncritically is always Bad Thing (TM), dumb me. Everything looks OK now. The workflow is clear: the new user can get their password via the reset page and then go through with e-mail verification, etc. [*] I had meanwhile disabled unused apps to reduce attack surface and noise. Cheers, -- Marco On 2025-08-29 19:42, Stephen J. Turnbull wrote: > ^m'e via Mailman-users writes: > > > I migrated form MM2.1 to MM3.3.10 on Debian Trixie (mariadb > > backend) -- I know that's a bit unorthodox to ask here for help on > > a non venv-based installation, > > We appreciate your courtesy, but this is inaccurate. If you install > a distro-packaged Mailman and it doesn't do the basic stuff such as > "start" or "respond to web requests" out of the box, that's a distro > problem. (That includes any features missing because of the > inevitable lag in distro packaging.) > > On the other hand, if you have a misconception (see Issue #1) or if > Mailman is basically working but doing a particular weird thing (in > your opinion, and that's Issue #2), asking here is the right thing to > do. Distro maintainers are frequently experts in packaging but > ordinary users of their package without expertise in troubleshooting > the package, and usually zero interest in educating users. That is > what we are here for! > > And, obviously, "real" bugs may manifest first in a distro package. > > > but hopefully I'll first gain a bit of insight of MM3 in order to > > formulate a more precise request to Debian maintainers. > > I don't think these are Mailman issues, and quite likely they're not > Debian issues. > > > ## Issue #1. > > > > A newly invited (from Postorius mass subscription page) and > > confirmed user doesn't get any password in their invitation/welcome > > e-mail. > > The invitation/welcome emails usually don't know if the user is > verified, and they are otherwise not personalized, so sending a > one-time password (OTP) at that time would be a lot more complicated > than it's worth. Also, many users may prefer to NOT set a password at > all. For example, if you configure the Gmail socialauth plugin, a > Gmail user can log in without doing the OTP dance. (I think we still > require the dance to verify the address, because socialauth is hard > and the burden is small. And if 'confirm' is set in the list > preferences, you have to either log in to Postorius to subscribe, or > do the dance for an email subscription.) > > Because Mailman 3 has a model of a user with multiple addresses and > subscriptions, the burden of using the reset password dance for the > initial setting of a password is considered very small (it usually is > done once during the user's association with the Mailman instance, if > at all). So that's the way we do it. > > > ## Issue #2 > > > > Anyway, if that new user asks for a password reset on Postorius they get > > > > "Server error > > An error occurred while processing your request." > > This appears to be an MTA misconfiguration, either in Mailman or > possibly in the MTA: > > > File "/usr/lib/python3.13/smtplib.py", line 861, in sendmail > > self.ehlo_or_helo_if_needed() > > Mailman tried to connect to a mail server. > > > File "/usr/lib/python3.13/smtplib.py", line 365, in send > > raise SMTPServerDisconnected('please run connect() first') > > smtplib.SMTPServerDisconnected: please run connect() first > > It failed. > > Twp possibilities off hand: (1) The server expects authenticated > and/or encrypted email (SASL and TLS), but Mailman is not configured > to do that. (2) A typo in the server IP or hostname. > > There are all sorts of other reasons why a server might refuse a > connection, but we'd need a lot more information to diagnose. > > Steve > ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: application/pgp-keys Name: OpenPGP_0xC366FCF67CDBD9F9.asc

2 weeks, 2 days

Re: postorius configuration of the from-part

by Mark Sapiro

On 11/12/19 2:27 PM, Wolfgang Bock via Mailman-users wrote: > > Hello, > > can someone give me an advice how I can configure in the > postorius-menues the view of the from-part of my list-member like in > this mailinglist: > > Wolfgang Bock_via Mailman-users_ <mailman-users(a)mailman3.org> The above is the result of Settings -> DMARC Mitigatations -> DMARC mitigation action = "Replace From: with list address" You can apply that to only messages From: a domain the publishes a DMARC policy of reject or quarantine or to all messages depending on DMARC Mitigate unconditionally. > case 1 reply goes to the list or to the member > case 2 reply goes only to the list The DMARC Mitigatations settings are independent of the various reply settings on the Alter Messages tab. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

Mailman-users search results for query "Postorius"