Search results for "Postorius" - Mailman-users

can templates be html formatted?

by Stephen J. Turnbull

John Harrison via Mailman-users writes: > My goal here is to have as little friction as possible for > nontechies to join and participate in an email discussion list. So > that means > > - HTML Supporting HTML templates would be a lot of work, not only to design and implement, but it would also induce ongoing support requests. We have long resisted doing it for those reasons. > formatted hyperlinks in all emails including the welcome email > to subscribe, unsubscribe, see the archives, etc. Don't most modern email clients format email addresses as mailto: links and other URLs as links? I think for many of your members this is a cosmetic issue, not a "nothing to click" issue. The big problem with all those links is that the major clients have decided in their infinite wisdom that supporting RFC 2369 is not worth it. RFC 2369 provides for URLs to do all those functions, leaving it up to the client to format them nicely as buttons and menu items. This would be better because users would know where to look for them since they'd be formatted and located consistently (in each client, different clients would likely do things differently). > - no need for a password ever for anything they'd want to do. There is a plethora of "social authentication" (ie, use your Facebook, Google, Fedora, etc account to authenticate) available in Django. IIRC most of the more popular ones (eg, the ones just mentioned) are configured by default in the Mailman web applications. If not, that's easy to do. If you have a single-sign-on system for your website, it's simple to have the webserver pass those credentials to Postorius and HyperKitty. > - A simple click to subscribe, unsubscribe, see the archives. All > hyperlinks. One-click operations are frequently used to harrass people. There is a proposal for a standard way to support them more safely but it doesn't address the harassment problem completely. It's most attractive for marketing mailing lists. > I've been playing with the welcome template and it seems maybe this > can't do what I am looking for (html formatting). As with plain text, some clients will detect those and format HTML elements even though the mail is declared plain text. But this is really risky, and has become less and less common over the past few years. It would be possible to hack the sources to tell clients that the email is HTML, and then this would work. But I'm not interested in doing that, and definitely I'm not willing to support users of such a feature. > I'm wondering also why it's doing some sort of soft wrap with line > breaks which is breaking longer urls in the template. That's not Mailman, that's your client, I'm willing to bet. See the "Archived at:" URL from your post on Mailman Users copied below. There's a line break after "at:", but none in the URL which is 109 characters long. Also compare the URLs in the footer of the mail you'll receive through the list. If you see line breaks in any of these URLs, that's not Mailman. Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

11 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

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

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

1 year, 2 months

Re: Database deadlock when trying to delete a member.

by Abhilash Raj

Hi Simon, > On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote: > > Hi, > > I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns. > > After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning: > > DELETE FROM member WHERE member.id = 166814 > > If I try to run it manually I get the same issue, in psql it never returns. > mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; > [… 60 seconds passes…] > ^CCancel request sent > ERROR: canceling statement due to user request > CONTEXT: while deleting tuple (2998,72) in relation "member" > I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine. Are you able to retrieve that Member object using API? This[1] the Python code which would try to delete a Member object and I am assuming is being called from syncmembers command. I am not entire sure about what would cause the database to hang, if there was some database constraint that failed, I would imagine some error to be returned. [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… One thing you can try is see if you can unsubscribe the user using the API or `mailman shell` command. You can unsubscribe from API by calling a `DELETE` method at http://localhost:9001/3.1/members/<member_id> This would give us some indication about whether there is some bug in the implementation of syncmembers command or if there is something else going on. > > This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing. > > > Setup Details: > OS: Oracle Linux 7 (Redhat) > Installed using pip via virtualenv talking to a local pgsql database on the same box. > Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website. > > PIP Modules versions: > django-mailman3 1.3.5 > mailman 3.3.3 > mailman-hyperkitty 1.1.0 > mailmanclient 3.3.2 > postorius 1.3.4 > psycopg2-binary 2.8.5 What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently and is incompatible with Core right now. There are backwards incompatible changes which might need some changes in Core to add support. > > RPM packages: > postgresql12-12.6-1PGDG.rhel7.x86_64 > postgresql12-server-12.6-1PGDG.rhel7.x86_64 > postgresql12-libs-12.6-1PGDG.rhel7.x86_64 > postgresql12-devel-12.6-1PGDG.rhel7.x86_64 > > > -Simon > > > _______________________________________________ > 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)

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

10 years, 5 months

Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search

by Johannes Rohr

Hello everyone! below is a "permission denied" error I get when trying to perform a fulltext search. -------- Weitergeleitete Nachricht -------- Betreff: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search Datum: Mon, 23 Jan 2023 10:30:14 -0000 Von: johannes(a)rohr.org An: johannes(a)rohr.org Internal Server Error: /archives/search PermissionError at /archives/search [Errno 13] Permission denied: 'fulltext_index' Request Method: GET Request URL: http://lists.*****.org/archives/search?mlist=pinnwand%40lists.*****&q=medit… Django Version: 4.1.5 Python Executable: /opt/mailman/venv/bin/uwsgi Python Version: 3.10.6 Python Path: ['.', '', '/etc/mailman3', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/opt/mailman/venv/lib/python3.10/site-packages'] Server time: Mon, 23 Jan 2023 11:30:14 +0100 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/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/search.py", line 88, in search emails = paginate( File "/opt/mailman/venv/lib/python3.10/site-packages/django_mailman3/lib/paginator.py", line 71, in paginate objects = paginator.page(page_num) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 75, in page number = self.validate_number(number) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 53, in validate_number if number > self.num_pages: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 102, in num_pages if self.count == 0 and not self.allow_empty_first_page: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 96, in count return c() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 527, in count return len(self) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 82, in __len__ self._result_count = self.query.get_count() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 658, in get_count self.run() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 593, in run results = self.backend.search(final_query, **search_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 32, in wrapper return func(obj, query_string, *args, **kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 412, in search self.setup() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 133, in setup os.makedirs(self.path) File "/usr/lib/python3.10/os.py", line 225, in makedirs mkdir(name, mode) Exception Type: PermissionError at /archives/search Exception Value: [Errno 13] Permission denied: 'fulltext_index' Raised during: hyperkitty.views.search.search I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately. Thanks! Johannes

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

3 years, 5 months

Re: spanish localization

by Guillermo Hernandez (Oldno7)

On 13/2/21 9:04, Stephen J. Turnbull wrote: > Victoriano Giralt writes: > > > Thanks Stephen for reminding me that sometimes I write what looks like > > proper English on the surface, but the meaning of it comes from the > > deep corners of my mind in some long forgotten dialect :-) > > Your English is fine, it was just my lack of imagination: on February > 12, I couldn't conceive of February 3 being even a little "old"! But... here is a thing that I can not understand: If the source (the .po file) is from november 7th, it doesn't matter how many times you recompile it: the result will be the same. I did what Mark recommended. Before that: /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 8 12:00 . drwxr-xr-x 3 root wheel 512 Feb 8 12:00 .. -rw-r--r-- 1 root wheel 80700 Feb 3 02:47 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po Then... /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # msgfmt -o mailman.mo mailman.po And that is: the same .mo file just with different date /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 13 11:09 . drwxr-xr-x 3 root wheel 512 Feb 13 11:09 .. -rw-r--r-- 1 root wheel 80700 Feb 13 11:09 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po I'm not trying to diminish the effort and the excelent work that are indeed making all of you. I appreciate that so much. But is evident to me that something fails in the translation path chain of upgrades. If you access the postorius web to manage subscriptions you can see a full mixed language words. It's not a life or death item... but it has not to be that way as the terms, as far as I know, are 100% translated (at least in spanish). And the subscriptors complain. If that is not a thing that the release manager can do, well... We are stucked, isn't it? I don think it has to be a matter of "automate production of pip'able packages containing only new translations": a new version has just released and the localization languages, at least spanish, were not merged into it for the last Weblate updates. I will wait untill the next update, this thread is closed to me. Thanks, again, for all your good work. > > More important, as long as the .mo file is more recent than the .po > file, that's the best the release manager can do. I haven't been > involved in the release process, so I can't swear to it personally, > but if Mark says that new translations generate a merge request > automatically, and we make sure that the translations are merged > before release, I believe him. That's optimal as far I am concerned. > > Perhaps some enterprising soul would be willing to automate production > of pip'able packages containing only new translations, but without > that, I don't see how to beat our current procedures. (I wouldn't > want to use such a thing, though, I'd be too afraid that one day all > the translations would be replaced with Dril tweets!) > _______________________________________________ > 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/ >

5 years, 8 months

Re: Turn off social logins?

by Torge Riedel

Am 12.02.19 um 17:11 schrieb Stephen J. Turnbull: > Note: I've changed the order of sentences from Torge's post to fit my > responses. > > Torge Riedel writes: > > > I do agree, same here on my side. Lot's of my users are very > > "sensitive" to social media and don't want see them here. > > This is the first I've heard of this. Obviously it's fairly > widespread; *please* speak up if anyone have similar issues that we > haven't addressed. AFAIK all of the currently active Mailman > developers believe that social auth is a GoodThang[tm], so we're > unlikely to DTRT as you see it without your help. Well most of my users are 60+ so social media is some kind of a thing from hell for them ;-) I don't want to blame it, but to ensure acceptance in my scenario it is required to hide them somehow. > > > I need to migrate from mailman2 to mailman3 and was wondering why > > social accounts are enabled by default > > By default Mailman 3 is social media: you have a profile, you can be > searched in the indicies of the archives, and so on. The large auth > providers provide more secure authentication, and a lot of convenience > for users who have such accounts already. They also take some > administrative burden off the list and site managers when people lose > their passwords and forget what their subscription address is, and > similar scenarios. Clearly, these are not universally-valued > features, but I think that they justify the current defaults. Yes, this was a bit unprecise. For my feeling it is better to enable one after another, but it is ok for me to do it the other way. > > > and are difficult to disable. > > They're easy enough to disable (easy to recognize and just add a hash > character in front), since you have to edit settings_local.py to > install anyway. If you're using a packaged version and the package > configuration utility doesn't handle it, there's nothing we can do > about it. The distro will have to deal with that. > > It should be better documented, I imagine (haven't checked yet). > > > I propose something like an additional setting listing the enabled > > social accounts. > > Do you mean in the Postorius administration interface? If so, do you > want it by-site, by-domain, or by-list? ("You" is everybody who wants > to disable social auth, not just Torge!) > > If you mean in settings_local.py, I suggested something similar > earlier. It's not obvious it would be easy to do (sometimes these > things are order-dependent, though that's bad practice). Having the configuration in the UI would be the best solution. So not everything needs to be done by me. A first approach is the mentioned setting, which can be set to an empty value to overwrite the default. Without the risk to break something else. Just to repeat. > > > And if the admin is setting this to an empty value in the > > settings_local.py everything is disabled > > Because the settings are a Python module, this is the way > settings_local.py works anyway. That's why Mark suggested editing > INSTALLED_APPS. > > Thanks so far for going into the discussion.

7 years, 8 months

Mailman-users search results for query "Postorius"