Search results for "Postorius" - Mailman-users

Re: SMTPSenderRefused - howto enable STARTTLS for local mail drop

by Stefan Bauer

Hi Steve, thank you for your time. Thats it :) Works now. I had to set it in /etc/mailman3/mailman-web.py After first logon, django tries to send a mail to confirm email address. Nov 10 08:44:56 mal02 postfix/qmgr[2893767]: 9255C5E0BE2: from=<postorius(a)lists.mydomain.tld>, size=920, nrcpt=1 (queue active) Nov 10 08:44:56 mal02 postfix/smtpd[879486]: disconnect from localhost[::1] ehlo=2 *starttls=1* mail=1 rcpt=1 data=1 quit=1 commands=7 This now works with STARTTLS. Hoooray :) Am Di., 9. Nov. 2021 um 16:50 Uhr schrieb Stephen J. Turnbull < stephenjturnbull(a)gmail.com>: > Stefan Bauer writes: > > > No matter what i try, mailman still only connects without STARTTLS: > > Earlier you wrote: > > > SMTPSenderRefused at /accounts/login/(530, b'5.7.0 Must issue a > STARTTLS command first', 'postorius(a)lists.mydomain.tld') > > Request Method: POST > > Request URL: https://mm3.mydomain.tld/mailman3/accounts/login/ > > Django Version: 2.2.12 > > This looks like Django errors, not Postorius (Mailman). So this is > something Django is doing, not Mailman (including Postorius). I'm not > sure why Django is sending email (somebody made a password reset > request seems likely, but I'm not that familiar with Django authn > stuff). Anyway, if it's internal to Django, it would not consult > Mailman's configs. This recent StackOverflow seems relevant: > > > https://stackoverflow.com/questions/60025730/530-5-7-0-must-issue-a-starttl… > > HTH > > Steve > >

3 years

Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

On Fri, Feb 12, 2021, at 11:52 AM, Mark Sapiro wrote: > On 2/11/21 10:22 PM, hansen(a)rc.org wrote: > > I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing?? > > > I'm sorry about that. It's too late now, but the avoidance is discussed > at > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>. > > > > I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself. > > > > I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius? > > > If the user has a Django account, she can see all that info at (e.g. for > this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/> > She gets there from `Mailman settings` in the dropdown under her user > name. She can also get there via the `Manage Subscription` button on the > list's Info page. That takes her to `List-based preferences` for the > list. Any setting not selected there is inherited from the Address-based > preferences or Global Mailman preferences IIUC, I think what Allan is trying to point out is that if your account was disabled due to bounces, there is no real visual indication about that if you go to any of the Preferences pages (either, Global preferences, List based preferences of address based preferences). Even if you login as an admin and go to Member Option's view, you won't see any visual indication about the delivery being disabled. The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start. The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to see that delivery is disabled due to bounces and not choosable as a valid delivery_status value by user or admin when submitting the form. https://gitlab.com/mailman/postorius/-/issues/469 We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention. This would ofcourse show only when you log into your account and go to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled? https://gitlab.com/mailman/postorius/-/issues/470 I don't know if there are any downsides to letting users re-enable their delivery on their own. > > > > Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there. > > You've already reported this at > <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been > previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>. > > > > As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status). > > > I'm sorry you had to go through this. The potential issue and the > avoidances should be better documented. Unfortunately, they aren't. > > > > Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago: > > > > a. The ability of moderators to see the list membership (a bug). > > As I note above, this is a known issue. We are a small project with very > feew core developers, all of whom are volunteers. There is a merge > request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> > which purports to fix > <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see > from the comment thread, it is not complete and the author has > apparently disappeared. > > If you would like to take it over and address the deficiencies, we would > welcome that. > > > > b. The ability of members to change their addresses for all lists they are subscribed to. > > > Users can add addresses to their account and can then change their > subscribed address at (again, e.g. for this list) > <https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mai…> > (Get there via the `Manage Subscription` button on the list's Info > page.) > > If one is subscribed to lists via their `primary` address, one can go to > `E-mail Addresses` in their account settings and make a new address > `primary` and that will change all their subscriptions. > > > > and further, now: > > > > c. That when members go to look at their subscription info, they can actually see the settings. > > > They can if they go to `Mailman settings` in the dropdown or the `Manage > Subscription` button on the list's Info page and look at all the tabs. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Re: User management page [was: Changing subscription address]

by Stephen J. Turnbull

Abhilash Raj writes: > Typo :( Page in Postorius is what I meant to say. :D No problemo, mon, I just did it too -> > Is that necessarily required? Every user in Django has a corresponding > user in Core, but the converse isn’t true and I am not sure if that is even > required. I meant "accessed from Postorius or HyperKitty." :-) > You will be able to see: > - Does the user have a Django account? > - All Subscriptions for the User > - All addresses of the User > > You will be able to perform following actions: > - Add or remove a user’s address > - Verify or un-verify an address > - Set any address as primary for the user > - Update display name of the user > - Update address on any of the subscriptions I don't think we *need* a Django account for what I'm thinking of. I do think that creating the account on User access from Postorius might make the implementation logic simpler. > What I am on fence about: > - Provide a full blown preferences menu to the admin for that user. This > will also make the UI extremely complex to see and implement. Wait to decide on that until I have a mockup or maybe a full MR. > But, when you have an account in Django with a different email > (email2) and a different Mailman user (user2) and you add a second > email (email1) to your account and are able to prove ownership by > verifying the address, Django will ask Core to add that second address > (email1) to your Mailman user (user2) and absorb “user1”. This > process is already implemented. Good. > However, if two Django accounts are created for “user1” and “user2” > then situation becomes more tricky and currently we don’t have a > way to resolve that short of delete one of the accounts and add the > addresses to other account. Delete "that" and add its attributes to "this" is what I had in mind. Again, thanks for explaining the existing logic. Steve

3 years, 8 months

Re: mailman3 OWNERS_CAN_ENABLE_PERSONALIZATION option

by Henry S

Thanks Mark. That's exactly what I am looking for. On 3/12/2020 1:09 pm, Mark Sapiro wrote: > On 12/2/20 5:42 PM, Henry S via Mailman-users wrote: >> I am trying to change email "To" field to user's email instead of >> mailing list's email. e.g. "To: <user(a)gmail.com>" instead of "To: >> <mailman-users(a)mailman3.org>" > > In Postorius set Settings -> Alter Messages -> Personalize to Full. > > >> I looked around old mailman configs they mentioned about adding >> >> OWNERS_CAN_ENABLE_PERSONALIZATION option in mm_cfg.py >> >> is this feature still available in mailman3 ? Can I do it via Postorius >> or REST API? > > There is no setting in Mailman 3 to control the ability to set > personalization. It is always available. > >

3 years, 11 months

Re: Postorius 1.2.3 and MailmanClient 3.2.1 is now out

by Abhilash Raj

On Mon, Jan 28, 2019, at 2:39 PM, Jonas Meurer wrote: > Abhilash Raj: > > On Sat, Jan 26, 2019, at 5:10 AM, Jonas Meurer wrote: > >> Hey Abhilash, > >> > >> Thanks a lot for your work on mailman3! > >> > >> Abhilash Raj: > >>> I am very pleased to announce (a bit late) that Postorius 1.2.3 and MailmanClient 3.2.1 is now out. > >>> > >>> The full set of changelog can be found in the documentation[1][2]. The most notable feature that > >>> I can think of is non-member management in Postorius. > >>> > >>> New releases are available on PyPI[3][4]. > >> > >> For earlier releases, you provided GnuPG signature files to > >> cryptographically verify that the release files were not tampered with. > >> > >> I couldn't find such signature files for the two latest releases. Would > >> you mind adding them? When packaging for Debian, I prefer to check the > >> GnuPG signatures before uploading new releases. Also, the signature > >> files get uploaded to the Debian archive as well so they can be checked > >> by everybody. That way we can cryptographically proof that the Debian > >> package is based on the original tarball that got packaged and signed by > >> upstream. > > > > > > Ah, sorry about that. I completely forgot about that. > > > > I am not sure if I can upload signatures after uploading the tarballs, I'll try to find out if that is possible. > > Thanks a lot, that would be awesome. I'll wait for it before doing the > Debian package uploads. If it is not possible to upload signatures, I'll bump up patch versions and push out new tarballs with signatures. > > Just to let you know: we're close to soft freeze in Debian, so in order > to get those uploads into the next stable release (Buster), they'll have > to be uploaded rather soon. Can you give a rough estimate on how long do we have before the freeze? > The same holds for other pending releases of Mailman3 components: Just > in case you plan to do new upstream releases anytime soon, it's still > possible to upload them to Debian in time for Buster. I'll see if we can get other releases out too. Core doesn't yet have any backwards incompatible changes, so I might end up bumping minor version and doing a new release. Not sure much has changed in other components, but I can do a release if there are enough changes. -- thanks, Abhilash Raj (maxking)

5 years, 9 months

Re: Postorius web issues after upgrading mailman 3

by Mark Sapiro

On 10/19/21 2:33 AM, Tibor Molnar wrote: > /var/lib/mailman3/web/static/hyperkitty > > /usr/local/lib/python3.8/dist-packages/hyperkitty/static/hyperkitty If you examine the source of your HyperKitty pages that have the issue, what do you see for the hrefs in the `<link rel="stylesheet"` tags in the <head> section. Also, I don't know if it is significant or not, but https://docs.mailman3.org/en/latest/upgrade-3.2.html#post-upgrade says to run ``` (venv) $ mailman-web compress (venv) $ mailman-web collectstatic ``` I always run those in the other order. I suggest you do mailman-web collectstatic --clear mailman-web compress (or whatever your django admin command is) in that order and see if that helps. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

Re: Postorius is not working (throws "Error 500" suddenly after changing POSTORIUS_TEMPLATE_BASE_URL and changing back)

by Wikinaut

I could not fix the problem, apparently there is a mismatch somewhere now. sudo pip uninstall django-q Found existing installation: django-q 1.3.9 Uninstalling django-q-1.3.9: Would remove: /usr/local/lib/python3.9/dist-packages/CHANGELOG.md /usr/local/lib/python3.9/dist-packages/django_q-1.3.9.dist-info/* /usr/local/lib/python3.9/dist-packages/django_q/* Proceed (y/n)? n whereas dpkg -l | grep django-q: ii python3-django-q 1.2.1-1 /usr/lib/python3/dist-info: 4 drwxr-xr-x 8 root root 4096 21. Jun 2022 django_q 4 drwxr-xr-x 2 root root 4096 21. Jun 2022 django_q-1.2.1.egg-info sudo apt remove python3-django-q the following packet will be REMOVED: mailman3-full mailman3-web python3-django-hyperkitty python3-django-q Continue [Y/n] n What to do? I don't want to remove mailman3, I just want to bring the 1.2.1-1 to 1.3.9...

1 year, 1 month

[MM3-users]Re: Installation issues

by Hellings Simon (EAST KENT HOSPITALS UNIVERSITY NHS FOUNDATION TRUST)

Hi Simon I have tried to re-install MM3 this morning but am now facing a different error message: Output from DJANGO log as follows: ERROR Internal Server Error: /mailman3/lists/ Traceback (most recent call last): File "/opt/mailman/mailman-bundler/eggs/Django-1.8.12-py2.7.egg/django/core/ha ndlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/vi ews/list.py", line 511, in list_index lists = sorted(List.objects.all(only_public=only_public), File "/opt/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/mo dels.py", line 144, in all objects = getattr(get_client(), self.resource_name_plural) File "/opt/mailman/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanc lient/_client.py", line 158, in lists response, content = self._connection.call('lists') File "/opt/mailman/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanc lient/_client.py", line 105, in call response, content = Http().request(url, method, data, headers) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1609, in request (response, content) = self._request(conn, authority, uri, request_uri, metho d, body, headers, redirections, cachekey) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1351, in _request (response, content) = self._conn_request(conn, request_uri, method, body, he aders) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1307, in _conn_request response = conn.getresponse() File "/usr/lib/python2.7/httplib.py", line 1051, in getresponse response.begin() File "/usr/lib/python2.7/httplib.py", line 415, in begin version, status, reason = self._read_status() File "/usr/lib/python2.7/httplib.py", line 379, in _read_status raise BadStatusLine(line) BadStatusLine: '' ERROR Internal Server Error: /mailman3/lists/ Traceback (most recent call last): File "/opt/mailman/mailman-bundler/eggs/Django-1.8.12-py2.7.egg/django/core/ha ndlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/vi ews/list.py", line 511, in list_index lists = sorted(List.objects.all(only_public=only_public), File "/opt/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/mo dels.py", line 144, in all objects = getattr(get_client(), self.resource_name_plural) File "/opt/mailman/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanc lient/_client.py", line 158, in lists response, content = self._connection.call('lists') File "/opt/mailman/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanc lient/_client.py", line 105, in call response, content = Http().request(url, method, data, headers) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1609, in request (response, content) = self._request(conn, authority, uri, request_uri, metho d, body, headers, redirections, cachekey) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1351, in _request (response, content) = self._conn_request(conn, request_uri, method, body, he aders) File "/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg/httplib2/__in it__.py", line 1307, in _conn_request response = conn.getresponse() File "/usr/lib/python2.7/httplib.py", line 1051, in getresponse response.begin() File "/usr/lib/python2.7/httplib.py", line 415, in begin version, status, reason = self._read_status() File "/usr/lib/python2.7/httplib.py", line 379, in _read_status raise BadStatusLine(line) BadStatusLine: '' [25/Apr/2016 06:21:10] "GET /mailman3/lists/ HTTP/1.1" 500 121854 Any ideas? Kind regards Simon ******************************************************************************************************************** This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere ********************************************************************************************************************

8 years, 7 months

Re: Postorius no connection to REST API

by Richard Rosner

Abhilash Raj wrote: > is the config to talk uwsgi protocol and you want to configure Web server to Proxy using the same protocol. You can find that in the uwsgi docs here: https://uwsgi-docs.readthedocs.io/en/latest/Apache.html You probably need an apache module to speak uwsgi, the docs should have the details. > Notice the URL is uwsgi:// instead of http://. > Other way is to configure uWSGI to speak HTTP, which can be done by replacing "uwsgi-socket" by "http-socket” in the uwsgi.ini configuration. This might be the easiest for you to try, do make sure to restart the mailman-web service after making the change in uwsgi.ini. Thanks, that already helped quite a bit. The website is now loading again, but unfortunately not much else. The site still shows no Connection to REST API.

3 years, 3 months

Re: How to change the language in mailman3

by Massimo Zappalà

Hi everyone, Mark thanks for the reply. My installation was done on Debian Buster by installing the mailman3-full package I can't find the path you indicated: > Mailman core in mailman/messages/ > Hyperkitty in hyperkitty/local/ > django-mailman3 in django-mailman3/local/ > postorius in postorius/local/ Maybe some packages are missing? > To set language for Django (i.e. hyperkitty and postorius) see > https://docs.djangoproject.com/en/3.0/topics/i18n/translation/#how-django-di.... What are the files to be edited? > For Mailman core, set [mailman] default_language: in mailman.cfg. Ok Done > You also need to (re)generate the .mo file which can be done with the > generate_mo.sh script. I can't find the script > For Django, you need to generate .mo files with > django_admin compilemessages Where should this be written? Thank you Max

4 years, 4 months

Mailman-users search results for query "Postorius"