Search results for "Postorius" - Mailman-users

Django site - how to create programmatically - new install

by daniel.botting＠codethink.co.uk

Hi all, I've mainly setup mailman3 to replace our mailman 2.1 install using Ansible, a point I could do with some assistance on is setting the fqdn used programmatically. I've been doing alot of reading before creating this thread. To create a domain I currently navigate to: https://serverfqdn.com/postorius/domains/ and click 'Add Domain'. I believe this is setting the name of the Django site, please accept my apologies if I'm wrong and the SITE_ID=1 is then used, I am only planning to use one domain only. I'm using Postgres and when I check the contents of the Django_mailman3_maildomain table as below afterwards: mailman3web=# TABLE django_mailman3_maildomain; id | mail_domain | site_id ----+--------------------------------------+--------- 1 | mailman3-test2.guest.codethink.co.uk | 1 Many thanks Daniel

3 years, 2 months

Re: mail host choices when creating a new list

by Abhilash Raj

Hi Andrew, On Tue, Oct 24, 2017, at 11:58 AM, Andrew Hodder wrote: > Hi! > > So, I'm trying to create a new list and pick one of the other mail > domains > we have configured (from the django admin panel), yet in the "Create New > List" page in postorius, I see only a single option (the first domain > we'd > added/set as the default) in the drop-down under "Mail Host". Am I > missing > somewhere else I need to add alternative mail domains to? Thanks in > advance! Yes, you can add new 'Web Hosts' from the Django's Admin console (admin/django_mailman3/maildomain/). Note that you need to be a superuser to do this. -- Abhilash Raj maxking(a)asynchronous.in

8 years, 1 month

Re: Changing subscription address

by Abhilash Raj

> On Mar 20, 2021, at 4:36 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Abhilash Raj writes: > >>> There does need to be a way to revert each option to inherit, and >>> there currently doesn't seem to be one. The 'Preferences' interface I >>> described in the previous post doesn't provide it either. I will >>> think about that. >> >> The implementation of this isn’t very difficult, but the UX of this is >> something I don’t know how to implement in that page to be very >> honest. > > Oh, I can play Liz Warren on that one! :-) "I have a plan for that." > >> We do already have ability to switch from an explicit address to Primary >> Address subscription. I would imagine it would be more than just a >> button, but more like a dropdown to choose an email or primary address >> and switch all subscriptions to that. > > Allan's situation is that for some reason he has a lot of users (or at > least suspects he does) who would be happy to have only one address > that there's only one place to change, but for some reason that > address is copied to (not inherited by) each of several subscriptions. This is a common situation actually, given that Postorius until recently only allowed subscribing individual addresses. Also, any subscriptions imported from Mailman 2.1 are also subscribed as address. > > We should address that, because I'm pretty sure his suspicion is > correct. For example, until I changed one of them -- and got two > emails about it for my discard pile :-) -- all of my python.org > Mailman 3 subscriptions were explicit. I still have about 8 to > go. :-) +1 >> This is how Core actually does work[1] if you subscribe via Email >> and you already have a primary address. It will lookup a user using >> the address and if the address is the primary address of the user, >> it will subscribe the primary address. > > If you say so, I guess it's true. Nevertheless, both Allan and I have > observed users with only one address, with that address subscribed > literally each time to several (~10) lists. Well a couple of stars have to align for it to work unfortunately. I realized that Core will use the primary address if you *already* have one set during email -join command processing. Add to that you can’t set an address as primary using just email commands, you end up with what you are seeing. Also, like I mentioned above, imported subscriptions are always address based. Another thing I thought I should clarify is that when I said subscribed via Primary Address in this or previous emails, I really meant that the User was subscribed and subscription inherits whatever the primary address of the user is. As opposed to explicit address itself (which could also be the email address currently set as primary address). > >> However, if it isn’t the primary address, and this is a new address, it will >> subscribe the address instead of user because the address isn’t >> verified at this point and hence can’t be a primary address. We could >> extend the subscription workflow to add an additional step to set this >> address as primary and subscribe the primary address. > > Yes, please, I think. Users who don't want this for subscriptions to > the primary address are going to be (rare) edge cases. If we need an > additional attribute on the user to handle the case of an unverified > primary address, I think that's an acceptable cost. Note that to > "claim" this User as her own, she has to verify that address. And if > she *can* verify that address, we can't stop her from doing so, we can > just make it more annoying. We don’t necessarily need the flag on user to set an unverified primary address, we might be able to get away without that. We could set the address as primary *after* we verify it. We always verify addresses regardless of the choice of the subscription mode (user or address). > >> Postorius has the full ability to define its own workflow because >> REST API provides full expression capability and doesn’t enforce >> anything. Previous versions didn’t had support for subscribing as >> Primary Address, but that has since changed and is the default one >> in the dropdown. >> >> This is for authenticated subscription, the anonymous subscribe works >> similar to email -join command. Mass-subscribe is probably working the >> same way. > > All of these should unify all subscriptions-by-this-address to one > User, in my opinion. +1 > >> Like mentioned above, it should be possible to do what you suggest. I >> am getting into the implementation details here, but the Subscription >> workflow would need an additional flag that would verify an address >> and use the flag to determine if it should subscribe the address or >> addresses’s user if an address is provided to the workflow. > > I don't think so. Just do the lookup, if it succeeds and matches > primary address, use inherit. If it doesn't succeed, create a User > and use inherit. If it does succeed, and doesn't match, use the > explicit address. Right now, P is explicit about it. You can choose if you want Primary Address or one of the explicit addresses added to your account. The primary address is the pre-selected choice, so if you go and just click on subscribe button, you get the primary address being subscribed. If you choose the explicit address then we subscribe the explicit address. Is that something you think needs modifying? The email join command does the first part you suggested, (if the lookup succeed and matches primary address, use inherit) but doesn’t do the second part (it will create a user, add the address to it and then use the address to subscribe). We can and should fix that. > It seems to me that this flag would be impractical for email > subscriptions (email commands with parameters are generally beyond the > kind of user this is most important for) or mass subscriptions (how > does the list owner know what the user wants?) anyway. If somebody > really wants all their subscriptions via primary address to be copies > of the primary address rather than user, I'm sorry, but they'll have > to deal with that. I can't imagine that it's the usual case, and > there's an easy workaround: make your primary address something other > than your usual subscription address! The flag I was talking was not really a user visible one but just thinking code flow. It might have to be a flag in API though to differentiate between the “verify this address and subscribe it” vs “verify this address, set it to primary and subscribe the User” cases. I agree that in situations where we just have an address to subscribe and no user exists, we create a user, add the address and verify and set it to primary and then use inherit. This should apply to, mass subscribe, anonymous subscribe and -join command. > If you disagree with me about the relative burden, then maybe we > shouldn't do this at all, but I'm pretty sure this is something we > should either do for all subscriptions, or for none. No, I think it shouldn’t be a big burden. > >> Primary Address is also an attribute of the Mailman User, so it >> should be possible for an admin to set that for a user if the user >> doesn’t have an account. When they sign up, they’d be able to >> manage and update accordingly. > > True, but AIUI Allan has a *lot* of users and on average they're > relatively needy compared to, say, my user population. The point of > his request is to smooth workflows for admins with user populations > where the admin *wants* to do many things for their users, or to have > smooth user workflows when they teach their users to do it for > themselves. That's why I'm focusing on the "I have one address and if > it changes I want to change it once" case. Makes sense. -- thanks, Abhilash Raj (maxking)

4 years, 9 months

Re: list of subscribers

by Simon Hanna

On 02/06/2018 09:13 PM, Peter Münster wrote: > On Tue, Feb 06 2018, Simon Hanna wrote: > >>> user = User.objects.get(email = ...) >>> if user is found then >>> print next to email address: user.first_name + user.last_name >>> >> Yeah, that way you make quite a lot of database queries. > Is this a problem? Let's say, only moderators can see such a list. And I > guess, that they won't do it so often, that the server crashes... > > Could you please show me, where I should add these 3 lines, so that I can > patch my local mailman installation? > > TIA, You will need to patch the list_member_view in views/list.py to pass along all relevant information to the template which is templates/postorius/lists/members.html

7 years, 10 months

Re: sending messages in response to posts from non-members

by David Bremner

Mark Sapiro <mark(a)msapiro.net> writes: > 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? It was the latter, and your suggestion for existing lists seems to have worked. Thanks, David

3 years, 9 months

Hiding the "subscribe without creating an account"

by Ben Sturmfels

Hi Folks, My Mailman3 installation is receiving a trickle of fake registrations, for which it then attempts to send a "Your confirmation is needed to join..." email, which typically bounce. I suspect these are coming from the "subscribe without creating an account" form on the list summary page. I notice that lists.mailman3.org doesn't show this form at all - you have to create an account to subscribe: https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ compared to mine with: https://lists.softwarefreedom.com.au/postorius/lists/free-software-melb.lis… Is there a configuration option that does this, or was it a custom change made in the templates? Was the change made to reduce fake registrations? Did it work? Regards, Ben -- Ben Sturmfels Sturm Software Engineering www.sturm.com.au +61 3 9024 2467

1 year, 5 months

Re: cron error - /opt/mailman/venv/bin/mailman-web runjobs daily

by Stephen J. Turnbull

Mark Sapiro writes: > You can't have two accounts in Postorius/Django with the same email > address. But why would you want to? There should be no problem with > a single Django user being subscribed to a list with more than one > role. I for one am uncomfortable having the superuser role being used by an ordinary user account, for several reasons. I'm pretty sure that is what Odhiambo was concerned about. I will have similar concerns about the domain user role when we implement it. The preference for a single email address across roles is harder for me to understand. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

4 months

[MM3-users]Re: Is it possible to grant all users the ability to Create List

by Simon Hanna

On 05/27/2016 04:43 PM, knox(a)sgi.com wrote: > Hello, > > Our company is evaluating mailman3 as an option for company internal list serving. > One of the requirements is that anyone with access to the list server be allowed to create and manage lists. > Is this possible? If so, how? Is there a "create list" role that can be added for all registered users? Currently the only way to do so, would be to grant them django superuser permissions. This would require the use of local accounts. This would allow users to also manage domains (create, modify, delete) I went ahead and created the following feature request. Please add any information that you think is relevant. https://gitlab.com/mailman/postorius/issues/133

9 years, 6 months

Re: Importing mailman 2 shows member's "Moderation Action" = "Default processing". But new members show = "None". Why

by Mark Sapiro

On 5/29/23 10:45, mrl(a)psfc.mit.edu wrote: > Thanks. Although IMHO I would prefer that the display show the actual action, and adding with a red asterisk to denote that it's the list default. It's a somewhat simple fix, although I've omitted the asterisk, because it's not important to me that it's the list default. Something like: I plan no further changes beyond <https://gitlab.com/mailman/postorius/-/merge_requests/811>, but if you were to submit a merge request, we'd consider it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/

by Mark Dadgar

I have a user attempting to access the list archives and he’s generating this login error. I have verified that he does have a django account. I’ve never seen this one before and I didn’t find anything relevant in the lit archives. Any ideas what’s going on here? - Mark ----- mark(a)pdc-racing.net | 408-348-2878 ----------------------------------------------- From: noreply(a)pdc-racing.net Subject: [Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/ Date: May 18, 2021 at 2:38:20 PM PDT To: mark(a)pdc-racing.net Internal Server Error: /accounts/login/ MultipleObjectsReturned at /accounts/login/ get() returned more than one EmailAddress -- it returned 2! Request Method: POST Request URL: https://mail.pdc-racing.net/accounts/login/ Django Version: 3.0.12 Python Executable: /opt/mailman/mm/venv/bin/python Python Version: 3.8.5 Python Path: ['/opt/mailman/mm', '/opt/mailman/mm/', '/opt/mailman/mm/bin', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/opt/mailman/mm/venv/lib/python3.8/site-packages'] Server time: Tue, 18 May 2021 14:38:20 -0700 Installed Applications: ('hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount') Installed Middleware: ('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware') Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/decorators/debug.py", line 76, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 146, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 74, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 102, in post response = self.form_valid(form) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 159, in form_valid return form.login(self.request, redirect_url=success_url) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/forms.py", line 195, in login ret = perform_login( File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/utils.py", line 174, in perform_login if not _has_verified_for_login(user, email): File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/utils.py", line 134, in _has_verified_for_login emailaddress = EmailAddress.objects.get_for_user(user, email) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/managers.py", line 54, in get_for_user ret = self.get(user=user, email__iexact=email) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/query.py", line 419, in get raise self.model.MultipleObjectsReturned( Exception Type: MultipleObjectsReturned at /accounts/login/ Exception Value: get() returned more than one EmailAddress -- it returned 2! Request information: USER: AnonymousUser

4 years, 7 months

Mailman-users search results for query "Postorius"