Search results for "Postorius" - Mailman-users

Re: mailman admin (django) interface does not work anymore after deleting website example.com

by Torge Riedel

Am 10.03.19 um 16:44 schrieb Mark Sapiro: > On 3/10/19 8:18 AM, Torge Riedel wrote: >> I deleted the existing "example.com" and added a new one >> "lists.mydomain.de". >> >> Now the admin (django) interface always gives "An error occurred while >> processing your request". After one of the first navigation clicks I saw >> a message that "site with id 1 is missing". > > In your Django settings your have > > SITE_ID = 1 > > which pointed to the example.com domain you deleted. > > You need to override this in settings_local.py. Probably > > SITE_ID = 2 > > but if that doesn't work, try '0' > Ah, thank you Mark. That makes a kind of sense. I changed the database directly to fix it. And renamed example.com to lists.mydomain.de. Now the error is gone. I'm wondering why the initial database set up of postorius (?) adds "example.com". Is there a way to directly add my domain instead? Somewhere in settings_local.py?

6 years, 10 months

New messages not being archived

by Sarah H

I have 2 active lists that are properly mailing out and working, plus an admin testing list that is as well. The list info pane correctly shows the mail volume and the imported archives from the previous 2.1 installation are present for both active lists. None of the 3 lists are generating new entries in the archive, all 3 are set up with default settings except 1 active and admin are set to private. I know that hyperkitty is showing some new content as admin was created in postorius and the list is present in hyperkitty and working in mailman. None of the logs show anything of note, mailmanweb.log has no new entries since it caused a serious issue when I changed the domain, uwsgi-error is the same and uwsgi.log has proper access logs. When trying to add a new thread via the hyperkitty interface I can see the email go through the maillog, I get the email with the entered content and everything else works, it just doesn't add a new thread to the archive. The installation is set up with the default settings from the virtualenv installation guide. Any assistance would be appreciated.

4 years, 6 months

Re: duplicate SITE_IDs and broken /postorius/lists/ display; Mailman Client

by Stanisław Findeisen

On Thu, Mar 24, 2022 at 09:27:06PM -0700, Mark Sapiro wrote: > The issue is client.create_domain doesn't support setting a Web Host. Web Hosts are the sites in the django_site table and SITE_ID is the id of > the table entry. See `sites` in the Django admin UI. > > So when you create a domain with client.create_domain it gets arbitrarily assigned to a `site` Ok thanks, this is good to know. How about mailing list creation using Mailman Client, like this? domains = client.domains domains = list(filter(lambda x: (domain_name == x.mail_host), domains)) # .. check if domains is a singleton list .. domain1 = domains[0] domain1.create_list(list_name, style_name=style_name) Do you know of any quirks/deficiencies related to this kind of code? This code is taken from mailman3-utils: https://github.com/sfindeisen/mailman3-utils , a set of scripts I stitched together to facilitate common Mailman3 operations on the command-line. Most importantly this can apply the (currently hardcoded) set of list settings uniformly across the different lists (and different domains). (I realize part of this overlaps with the mailman command, especially in the local setting.) Thanks Stanisław

3 years, 10 months

Re: Dump/restore users (with passwords) via API

by Abhilash Raj

On Mon, Sep 17, 2018, at 12:15 PM, Dmitry Makovey wrote: > We are trying to dump/restore users using API calls and it seems that > API allows us to dump password hashes (a good thing), but then API does > not allow to insert users back using saved password hashes - only > cleartext passwords. I'd say that is intentional. You don't want people to be setting up hashes as passwords. > Aside from create_user is there any other way to > create users/change their password? Not that I know of, not using the API atleast. You could potentially use the low level API that inserts records in the database or use SQL to dump and restore that data. What do you use the Core's user/password for? Currently, the user passwords are basically just a carry-over from Mailman2 and there shouldn't be any use for it. I have been considering removing that completely have Postorius do all the authentication/authorization. Email based authentication should rely on more reliable identities like email signatures, intead of having to send cleartext passwords over email. -- thanks, Abhilash Raj (maxking)

7 years, 4 months

Re: Mailman web interface / uwsgi

by Stephen J. Turnbull

Mark Sapiro writes: > On 11/27/22 00:19, Jan Eden via Mailman-users wrote: > > > > I see. But the mailman.cfg is placed in /etc/mailman3, and this file > > also belongs to the core, doesn't it? In any case, I changed the > > configuration parameter for [archiver.hyperkitty] as you suggested and > > all settings are in one place now. > > In that case, it's probably just an oversight. Yes, I think that's what's going on. There's been quite a bit of simplification and unification of the Django configuration over time, which is ongoing and not 100% reflected in all documentation. Because of the way most Linux distros work (and I think it's probably true for *BSD and other POSIX systems), it makes sense to put users' site configurations in /etc. I don't see a particular reason why with the current relatively small set of config files we'd want to put HyperKitty or Postorius files elsewhere than /etc/mailman3 (although it might make sense to have more separation given the existence of EMWD's Affinity etc). Steve

3 years, 2 months

Re: One-click unsubscribe?

by Stephen J. Turnbull

Jered Floyd writes: > > As I discovered (to my chagrin) Mailman's current simple RFC > > 2369 List-Unsubscribe field doesn't, even for personalized lists where > > there might be a personalized link in the footer. > > My understanding from up-thread is that the RFC 2369 headers are > added pre-personalization. They are. It would also be trivial to personalize them; they just aren't. > If we add a timestamp to the encrypted token I suggest there should > be a pretty broad window allowed (i.e. several months). I guess it would be a matter of keeping 2 tokens in the database. > > Safety would suggest adding a random nonce and that would need to > > be saved in the database.) > > Do you just mean a salt? Or are you suggesting adding a > per-subscription nonce stored in the DB? (In which case, that could > simply be the URI token...) Per-subscription and it would be the URI token. > I agree with your analysis, but this would be a very specialized > attack, especially if we don't provide direct feedback on if the > request was successful (which we are not required to do). I think we do need to provide feedback, at least when the request fails due to an expired token. > I have trouble constructing a practical threat here I don't know if there's a practical threat. I don't think the known plaintext attack on the key is practical if we use a key dedicated to this purpose. You'd need at least a large university's collection of tokens, and what could you do with it that would be worth the effort? The DOS attack is practical if encryption is expensive enough. But storing the token would make that a single database lookup. > and I think the encrypted tuple, or a plaintext tuple and truncated > HMAC (like how SRS works) would be sufficient. Checking the encrypted tuple is cheaper and simpler. > The real risk without a per-subscription random unique identifier > would be a replay attack -- the user is unsubscribed multiple > times? That feels outside of the threat model. The identifier has to be unique to the subscription. If there are multiple valid unsubscriptions, the later ones won't have an existing subscription to unsubscribe. That does argue for the nonce -- that would stop the attack in the case where the user resubscribes. > > And you could combine the two strategies which would allow sites that > > don't use Postorius to configure the reverse proxy, while sites that > > do would get it for "free" since we'd configure Postorius to do it. > > I hadn't considered this -- I definitely like this approach because it > means the same function need not be implemented twice, differently. OK, that's part of the design we'll start with. > guess the big question is now just what the simplest content of the URI > should be. I think there should be just an opaque token plus an optional expiration date for sites paranoid enough to have a rotation policy for the keys. We need to do some thinking about how to implement "several months validity" in case of a sudden key change. The expiration date is irrelevant to the implementation of 8058, it's just for the benefit of the user (and data collection for how old the token is, I guess). This is shaping up pretty well, I think. > The Internet is an increasingly hostile place. True enough. > Regardless, not something we can do much about. There's hope. When Yahoo! and AOL broke the Internet in 2014 by setting p=reject DMARC policies, the Ministry of Education issued "administrative guidance" that *yahoo.* addresses should not be used for school business, and my university sent them all to spam. ;-) Including yahoo.jp which did not have a p=reject policy. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 month, 3 weeks

Re: proper update procedure for MM3 docker containers

by Fabian A. Santiago

On 2018-08-06 12:24 PM, Abhilash Raj wrote: > On Mon, Aug 6, 2018, at 6:28 AM, Fabian A. Santiago wrote: >> Hello, >> >> Can someone remind me of the proper / best way to update my docker >> containers for MM3 / postorius based on maxking's images? Thanks. >> >> and this for both the stable and rolling releases. > > Well, the process is fairly straightforward, when moving form an older > to a newer release, > > Stop and remove the container ($docker-compose stop, $docker-compose > rm) and then start the new ones ($ docker compose up -d). > > That should be all! > >> >> -- >> Fabian S. >> >> OpenPGP: >> >> 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key) >> >> *** >> >> 0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be retired, still >> valid) >> _______________________________________________ >> 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/ thank you. -- Fabian S. OpenPGP: 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key) *** 0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be retired, still valid)

7 years, 5 months

Re: General question mailman3: message sender acceptance "always"

by Mark Sapiro

On 10/23/23 09:08, Wikinaut wrote: >>> In the Postorius held messages view, click on the message's subject to >> open a dialog showing the messages content > > Dear Mark, sorry: > How should I know this? Well, the subject of the message in the held messages view looks like a link. Maybe click it once to see what it does. > I'd rather prefer to have these both changes: > > i) relabel the existing one od three buttons from "accept" to "accept once" ; and > ii) add a fourth button "accept all messages from this sender (i.e. add to white list)" That wouldn't include options like "discard further posts from this user", "reject further posts from this user" and perhaps other possibilities. If I were going to do anything, it would probably be adding a line above the list of held messages saying something like "Click the message's subject for more options." -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 3 months

Re: lists.mailman3.org web site.

by Barry Warsaw

On Aug 30, 2016, at 12:01 AM, Mark Sapiro wrote: >Django Allauth is now properly configured and working on >lists.mailman3.org. You can log in by email/password as noted above or via >OAuth2 with a GitHub, GitLab, Google or Facebook identity. > >If you are an existing user, in order to use one of the OAuth2 providers, you >must first log in with email and password and go to the Account Connections >tab in your account settings and add the 3rd party account(s) you wish. This works pretty great. I tried it with my GitHub and GitLab accounts and was easily able to associate those with my Postorius and HK accounts. I didn't try FB or Google, but I guess those would work the same way. I'll miss Persona but I think this is an entirely acceptable alternative, with plenty of choice for folks wanting to control which authority they delegate to. I'd mildly like to see Launchpad support, but I understand 1) it's a minority platform; 2) it only supports OAuth 1. Thanks to the developers for adding this support and to Mark for enabling it. Cheers, -Barry

9 years, 4 months

Re: mailman-suite: Error 500 on Lists /setting/ pages

by Mark Sapiro

On 11/18/20 8:43 AM, ljsbw-it(a)riseup.net wrote: > I just installed Mailman3 (mailman-suite) on my Server following these instructions: https://lab.uberspace.de/guide_mailman-3.html Please see <https://wiki.list.org/x/12812344> > and everything works fine so far. I can create lists, subscribe people and send mails through lists but when I click the settings button and get redirected to /postorius/lists/listname/settings/ i get an Error 500 message. I couldn't find anything in the logs except the uwsgi log: > [pid: 20568|app: 0|req: 62/62] 100.64.115.1 () {48 vars in 1052 bytes} [Wed Nov 18 16:27:59 2020] GET /postorius/lists/listname/settings/ => generated 1102 bytes in 1438 msecs (HTTP/1.1 500) 6 headers in 209 bytes (1 switches on core 0) I think that uwsgi log message just refers to the delivery of the error page to your browser. What other logs are you looking at? There should be something in Mailman core's mailman.log or the Django log whose location is defined in settings(-local).py, probably mailman-suite/logs/mailmansuite.log. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

Mailman-users search results for query "Postorius"