Search results for "Postorius" - Mailman-users

Re: Verification Failed Error

by Abhilash Raj

On Thu, Dec 20, 2018, at 4:05 PM, brian(a)emwd.com wrote: > Abhilash Raj wrote: > > It should be pointing to Exim running on host, so > > > > EMAIL_HOST = 172.19.199.1 > > That fixed the network not found error. Thank you for your help there. > > Now I am back to the verification error: > > "smtplib.SMTPRecipientsRefused: {'brian(a)emwd.com': (550, b'Verification > failed for <postorius(a)host.name.com>\nUnknown user\nSender verify > failed')}" > > I am at a lost on how to get exim to allow mail sent from > postorius(a)host.name.com. Obviously host.name.com is the mm3 domain that > I am using. A quick search says that Exim is trying to verify that `postorius(a)host.name.com` is a real mailbox (which I am assuming it is not), and rejecting the email coming from Postorius. You probably have verify = sender somewhere in your exim.conf, which is causing this. You can either modify the DEFAULT_FROM_EMAIL in your settings_local.py so that it is a real address that Exim can verify, or, you can remove verify = sender from your Exim configuration. 2nd option might not be the best if you want to properly combat spam. Exim experts would be able to help you better with this. > > Brian > _______________________________________________ > 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)

7 years, 10 months

Re: Postorius Suggestion: Give owner a view of all users of all owned lists

by Andreas Vetter

Stephen, after thinking a lot about it, I came up with this. Stephen J. Turnbull wrote: > Andreas Vetter writes: > > A list of all addresses subscribed to all lists owned by the logged > > in person. > > This is starting to take a better form. It's still very specialized, > so I'm starting to wonder if trying to add it to Postorius is a great > idea. Of course if people are coming in over the network, you don't > want to reproduce all the authentication and authorization logic > implemented in Django and Postorius. That may as well be done in > Django, and if you're doing Django it may as well be Postorius too. > > But if you're in a single sign-on environment so presence in the > network implies strong authentication, you will get more flexibility > from local scripts using mailmanclient, or if you're confident in > security access to the REST API directly. Just putting that out for > your consideration, since implementing what is taking shape here would > take quite some time as the folks skilled with Postorius are not so > active these days. I agree, this is very special. In our case we will cook it down to a very special solution providing owners with the info they need. Based on that, they can use the unchanged postorius for (un-)subscribing. > > Owner is the primary target group for that. But since it should be > > a tool for managing subscriptions in a simple way, it might also be > > of interest for superusers. For me as a superuser it would make > > life easier. > > [...] > > > Ah, I see the problem and agree: So, the presentation should have a > > sorted and searchable list of addresses and a Button next to each > > address, maybe labeled "Subscriptions". > > Looking at your description above, for superusers that is basically > the Users tab, though. Users are identified by primary address, and > you'd not see alternate addresses in the list. But presumably your > internal users use their @your.org addresses as primary. Can you make > clear what could be more streamlined for your use cases as superuser? > I give one example below, maybe that's what you're mostly interested > in. > > The caveats about access to User objects still apply for owners, so > even if they look the same (which is a good UX idea if owner > functionality is a subset of superuser functionality, also they might > even be able to share the basic page templates), the implementation is > going to be rather different. I suspect you superusers would be quite > frustrated if using the "subscribe all these lists" functionality > meant you couldn't get at the User object without going to a different > page. > > I do see one weird thing: you can't manipulate subscription itself > from the User page as seen by the superuser from that list, only > toggle moderation and delivery mode. I guess that's reasonable for a > lot of use cases, though. I've never wanted to do a subscribe or > unsubscribe from there. I always have a long list of users to > subscribe to specific lists, never a list of lists a specific user > should belong to, We have a list for almost every working group and have scripts reading members from there and putting them together in the higher level lists. People can be in more than one working group list. Users come, stay some years and go, so mass (un-)subscription is used for single addresses usually. But if the owner forgets to delete someone from a list, the person is still in one of the higher "automatic" lists. So an overview would have been nice. The "(un-)subscribe all" buttons are not really needed in our use case. We run about 300 lists. For a superuser this is a lot, given the fact there is no filtering in the table of lists. A owner wants to see in an address view all his lists. A superuser does not, because it would be too much unrelevant information (e.g all 200 research lists, when user is in finance). As a superuser I could need in the users view: - clicking on a list name to manage the list - unsubscribe button > > The presentation given when above "Subscriptions" Button is clicked > > should contain the address as kind of Headline. Then a table of > > all lists of the logged in owner and next to each mailing list an > > indication, if the address is subscribed or not and a Button to > > toggle subscription/unsubscription. May be a single Toggle Button > > or (maybe better) two buttons, a suscribe and a unsubscribe button, > > where one is greyed out. > > This would not work with the current User page as presented to a > superuser, that's true. The current presentation is quite suited to > its purpose, with sections for Addresses, Subscriptions, Ownership, > and Delete User in that order. But especially for superusers, there > are plenty of sites with thousands, even tens of thousands of lists, > and even a paged or scrollable presentation would be awful UI, and the > potential for a disastrous mistake using "do all" is high. I agree. So I think superusers "users view" and owners "addresses view" should be different things. > > In addition my owners would like to have a "unsubscribe from all my > > lists" button. And a "subscribe to all my lists" button. This might > > be visually nicer, when having the two-button approach above. > > I wonder if your owners really want "subscribe all". "Unsubscribe > all" does make sense for separations, of course, and they wouldn't > necessarily be terminations. It would be useful in an internal > transfer where "delete user" is not a solution. But in my experience > specialized channels tend to proliferate but the same people are > likely to be running them as run the department-wide lisst. Yes, "subscribe all" is usually not wanted, I just mentioned it for symmetry. Since we populate higher lists with members from lower lists by script, we would not strictly need "unsubscribe all" as long as the owner knows which lists are populated automatic. We currently hide that info in the short description of the list. Everything very special, I agree. > > In our case we would want to (un-)subscribe the address in a "do > > it, don't ask anyone" fashion, but maybe this is not a good idea in > > general. What do you think? > > I think we would implement it similarly to the mass subscribe for > multiple addresses case, where the list owner can decide how much > bureaucracy to require of the subscriber. You'd want to be careful to > make sure address verification is done at most once (for your use > case, probably not at all). And there would be some things that could > be done to arrange that most lists would have sensible defaults. Yes, this is and was a problem for us. We imported many lists from mailman2. Some settings have to be changed after migration, and a mailman config command to set settings for lists would be great. Or a way to permanently create new list styles. > > Yes, I agree, but policy here is to get rid of subdomains, and that > > falls on our feet now. > > Well, once we figure out how to implement domain ownership, it > wouldn't be hard to adapt that technology to "departments" that are > administratively distinct but share mail and/or web domains. The main > problem would be deciding whether and how to nest them. Superuser > > domain owner > list owner > moderator is pretty obvious, but how > "department owner" would fit in is less so. I already had this wo possibilities here (at different times): In fact a department owner could own several domains. The department research (as opposed to e.g. administration) could contain biology.example.org and physics.example.org) Would it harm to be owner of several domains? Or it could be the other way round (physics.uni.edu has a theory department and an experiment department, each having chairs with the list owners). So there is no single way. Department owner and domain owner seem to be roles on the same level with different funcionality. Superuser has to decide how to use it. -- Mit freundlichen Gruessen, Andreas Vetter

1 year, 7 months

Re: Converting discussion list to read-only list (settings)

by Mark Sapiro

On 10/14/19 12:06 AM, Paul Arenson wrote: > Mark Sapiro wrote: > >> If by "read only" you mean the "Announce only mailing list style" as >> opposed to the "Ordinary discussion mailing list style" the only >> difference is that for the Announce only style the list attribute >> allow_list_posts is False and for the Discussion style, it's True. >> >> This is the setting in Postorius -> Settings -> Alter Messages -> >> Include the list post header an all it does is include or not include >> the List-Post: header in mail from the list. > > Ok...there is no specific setting I see "allow_list_posts" but you wrote "Include the list post header " later on. So i set THAT one to NO? allow_list_posts is the name of the attribute in Mailman core. It is exposed in Postorius as "Include the list post header". I.e., they are the same thing. Note however that unless your users are using MUAs to reply by email and their MUAs offer a "reply-list" function for replies to mailing list posts, this setting will make no difference. It is the presence of the List-Post: header in the message that allows the MUA to offer/process the "reply-list" function. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

Re: Installed from Howto_Install_Mailman3_On_Debian10, web not quite working

by Mark Sapiro

On 5/7/23 10:51, Volkmar Grote wrote: > thanks for the quick reply. > I am one step closer to a solution, > "http://127.0.0.1:8000/postorius/lists/?all-lists#" seems to work now. > I get the functionality, but it looks ugly w/o any graphics, for which I > get yet another, slightly similar, error message: >> >> >> Page not found (404) >> >> Request Method: GET >> Request URL: >> http://127.0.0.1:8000/static/postorius/img/mailman_logo_small_trans.png >> >> ... > > Nginx, /etc/nginx/conf.d/me.domain.de.conf >> server { >> listen 80; >> listen [::]:80; >> >> server_name me.domain.de; >> ... >> location /static/ { >> alias /opt/mailman/mm/static/; >> } > > Again, many thanks in advance for any clue The above in nginx is correct, but you aren't getting the static files via nginx. You need to go to a URL like http://me.domain.de/postorius/lists/. Going to http://127.0.0.1:8000/postorius/lists/ goes directly to your wsgi server and doesn't involve nginx at all. You need to go to port 80 where nginx is listening and nginx then proxys requests to 127.0.0.1:8000. Do you also have location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } in /etc/nginx/conf.d/me.domain.de.conf. You need that. -- 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

Re: Postorius no connection to REST API

by Stephen J. Turnbull

Hi, Richard, I don't recall the details, so I could be way off base, but this > [Sun Aug 15 09:19:52.318582 2021] [core:notice] > [pid 19706:tid 140315143705728] > AH00094: Command line: '/usr/sbin/apache2' > [Sun Aug 15 09:19:52.732381 2021] [proxy_http:error] > [pid 19707:tid 140314912167680] (20014) > Internal error (specific information not available): > client 37.201.214.82:9292] AH01102: > error reading status line from remote server 127.0.0.1:8000 indicates that Apache's (?) proxy_http server expects to find something that isn't there running on the same host on port 8000. Since it's not "refused connection" or similar, evidently it's connecting (presumably to Mailman core's REST API) but not getting the "status line" (greeting?) it expects. Now, for a proxy to know what status line to expect, either it's speaking a well-known protocol (such as SMTP or HTTP), or it's part of the same application suite. But Mailman is neither. So I suspect you have your proxy configured to proxy Apache to Mailman instead of the other way round. Or maybe it's proxying from client 37.201.214.82 to Mailman, but it should be proxying from client to Apache. I guess the latter is more plausible, in the former there'd be some kind of triangular relationship among client, Apache, and Mailman, which doesn't fit the model of "proxy". Is either possible? HTH, but if it doesn't ring a bell, say so and we'll try something else. Steve

5 years, 2 months

Re: Emergency moderation and clearing out a lot of held messages

by Stephen J. Turnbull

Dan Caballero writes: > We're running Mailman in AWS using and RDS MySQL database. It seems > to take unusually long to approve or discard even a few messages. I assume you are use Postorius for this? > What should be a normal response time for processing as few as 10 > messages? I don't know about MySQL/Maria. All of the production instances I have access to are backed by PostgreSQL. Response using Postorius is not instantaneous, but 2-3 seconds is maximum. Also, I don't think I've seen multiple messages with the same treatment in visit in many months (maybe a year), but I don't recall those "feeling" longer than a single message request. > I've done some testing in the pass running Mailman3 in a Docker > container and using a local instance of MariaDB. Even in that > situation I still found the processing slow. I guess since you talk about "10 at once" you have a much larger lists and/or much larger user databases and/or heavier traffic per user and/or more "spam". It would help to know what the scale of your Mailman installation is in those dimensions. I don't think Mailman's Python code is likely to be the bottleneck, rather it's probably database queries. Have you looked at MySQL's logs for queries related to those operations? Steve

4 years

Re: sqlite3 Database "read only" error on mailman_sync job

by Abhilash Raj

On Wed, Sep 4, 2019, at 2:05 PM, Ugnius S wrote: > > I have installed using documentation. My linux distribution version has no full package available. I have installed step by step: > $ sudo pip3 install mailman > $ sudo pip3 install postorius > $ sudo pip3 install hyperkitty > $ sudo pip3 install mailman-hyperkitty > And of course all mandatory components... Everything without errors, I can drop db files and I can download mailman-suite again and start from empty page again. But it will not guarantee that DB will not become READ ONLY again. Here should be logic. No developing support here? Could you be running two separate processes such that the database is locked by one and so other finds it as READ Only? When you find a read only database, can you check if it is open in some other process? > > > > 2019-09-03, an, 19:36 Abhilash Raj <maxking(a)asynchronous.in> rašė: >> >> >> On Sun, Sep 1, 2019, at 3:22 AM,ugniusviln(a)gmail.com wrote: >> > Hi. All the project installation is under the same user / path and >> > it works. Archiving working as well, (just one remark: no matter what >> > to set in postorius, hyperkitty shows list as public) >> > I have found work around - it is possible to change list as private in >> > "admin" page. >> > I started to get issues with runjobs after I have created couple of >> > new lists with "no archive" option. >> >> How did you install all these components. It seems there the installation is broken in weird ways. >> >> > >> > If as owner user from project home I run: >> > >> > django-admin mailman_sync >> > >> > Traceback (most recent call last): >> > File >> > "/home/user/.local/lib/python3.5/site-packages/django/db/backends/utils.py", >> > line 84, in _execute >> > return self.cursor.execute(sql, params) >> > File >> > "/home/user/.local/lib/python3.5/site-packages/django/db/backends/sqlite3/base.py", >> > line 383, in execute >> > return Database.Cursor.execute(self, query, params) >> > sqlite3.OperationalError: attempt to write a readonly database >> > >> > "django-admin runjob sync_mailman " - makes read only errors as well. >> > "django-admin runjob new_lists_from_mailman" >> > django.db.utils.OperationalError: attempt to write a readonly database >> > END TRACEBACK >> > >> > I did not find information how to fix this. It was worked without errors >> > before. >> > I noticed, that if I stop mailman, "django-admin mailman_sync" starts >> > to work. >> > If I start "mailman start", then "django-admin mailman_sync" failing >> > again. >> > I did not check other jobs, but I think what is related to database, >> > will get errors. >> > Seems mailman locking the database. It is not a file permissions issue. >> > Mailman db location is: /project_directory/var/data/mailman.db >> > >> > if to rename /project_directory/var/data/mailman.db to something, >> > mailman creates database file size 0, django-admin runjobs start >> > working, but of course postorius stops working. I did it for testing. >> > I have returned this database file back, postorius started to work >> > again, but django-admin runjobs does not work, error: "database read >> > only". >> > Please help me how to fix this issue. >> > _______________________________________________ >> > 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) -- thanks, Abhilash Raj (maxking)

7 years, 2 months

Re: Error when click on mailing list: An error occurred while processing your request.

by Mark Sapiro

On 7/14/24 21:40, adam.heathcote(a)utas.edu.au wrote: > Hi Mark, > > Sorry about the delay in replying. > > You're correct, I am clicking on the list in the Mailing List view. > > Navigating to the list URL directly while not logged in produces the same error and even produces the error when a different user is logged in. Now it's my turn to apologize. I've been traveling. In your original post you wrote "I've tried removing it and reimporting it to no avail." What exactly does this mean. You removed the list how? Then you reran the import21. Was the list broken at that point, or only after removing the old owners and adding yourself? What if you try the following steps in order and try to view the list in Postorius after each step. - remove the list with `mailman remove list(a)example.com` and recreate it with `mailman create list(a)example.com` - run `mailman import21 list(a)example.com path/to/config.pck` - in Postorius, add yourself as owner. - in Postorius, delete one of the other owners. - repeat the deletion and viewing the list for the other unwanted owners one at a time. If the view throws the error at some point, after which step? -- 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: Postorius claims 2 messages held when there are none - out of sync

by Ken Alker

--On Monday, June 26, 2023 5:26 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/26/23 4:19 PM, Ken Alker wrote: >> >> What else is stored in /var/messages, if not archives? I see 4711 >> messages in that directory (which I presume would be as many messages >> are in the archive database). If there is a write-up on this, feel >> free to point me to it. I found >> <https://docs.mailman3.org/projects/mailman/en/latest/build/lib/mailman/ >> model/docs/messagestore.html> but this isn't really answering my >> question. > > > These are probably artifacts from your old Debian package. There have > been issues in the past with handled messages not being removed from the > message store. See https://gitlab.com/mailman/mailman/-/issues/257 > > This was fixed in 3.3.5 and the task runner implemented in 3.3.5 removes > orphaned messages from the message store, but if they are still > referenced in pendings they won't be deleted. So is the only thing stored in var/messages/ the held messages, and nothing more? Is there an outline as to how to clean up the var/messages hierarchy? (I assume one has to be careful not to remove current held messages and maybe old ones that have not been processed; or maybe "old ones" can all be assumed orphaned, and thus, removed w/o concern?)

3 years, 4 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Brian Carpenter

On 2/13/21 11:39 AM, Stephen J. Turnbull wrote: > Brian Carpenter writes: > > > I think treating all disabled options the same is short-sighted. They > > are all not the same. > > > > -- Some list members will disable their subscription for good reasons > > and will be really upset if a List Owner renables it through ignorance. > > So it is important to know a disable member is done by the member > > itself. > > This is true in principle, but (1) I don't think that the user cares; > if they're looking at it, they know whether they want enabled or > disabled, how it got that way doesn't matter to them, and (2) I can't > see why an admin would disable delivery except on request from a user, > so I can't see why an admin would reenable except on request from a > user. The only case I can see would be a mass reenabling, but that's > not going to happen in the future (I hope). > > > -- Some mailing lists will have multiple list owners managing them. So > > it is important for one List Owner to know when a subscription has been > > disabled by the actions of another List Owner. > > I don't see why, see above. > > > -- A List Owner may not know that some of his List Members are bouncing > > messages for various reasons, so reviewing their Membership roster, they > > see that they have some list members disabled due to bounces and can > > then address those particular problematic members. > > This query is an important use case. But it's the only one, I think, > unless you really have List Owners arbitrarily disabling members' > subscriptions. And if you're thinking about reenabling from that > page, I think you need a lot more information. For example, if the > admin disabled, you need to know if that was a user request or > something else (what?). If bounce disabled, you want to know what the > bounce was ("no such mailbox"? probably not a good candidate for > reenabling), and when (5 minutes ago? ditto). I guess you could just > reenable and see what happens, but that could be risky (eg, sending > mail to non-existent users is frowned upon by some providers). > > > @Abhilash, I highly recommend that you contact me off list about getting > > access to Affinity so you can see what I am talking about. I would love > > to show you what I have done for Member Management. I offered the same > > to Steve but he never was interested in taking a look. > > It's not that I lack interest, it's that life got in the way. > Unfortunately, until I get enough time (man-weeks, I've never worked > on Postorius and very little in Django) to work on Postorius, or > somebody else starts to do it, a look at Affinity is low priority. > Also, it's pretty clear that a quick look isn't going to be very > helpful. The Mailman developers know what Mailman 2 looks like. I > think the benefits to a hands-on admin are pretty obvious vs the > current Postorius, as are Web 2.0 improvments like sorting on the > options. The more subtle improvements you've made are going to > require a guided tour and/or some study to identify and understand. > > Aside: I have to assume that Postorius is aimed at the kind of > subscriber that most of us are, and that list administration was > something of an afterthought, and assumed to be mostly hands-off. > That's the only rationale I can come up with for the design where > list admins need to go to the individual pages to see user options -- > it was easier to reuse the user option page and just give the admin > permission to access and change it, than to provide a (sortable) list > with user details. > > Steve > _______________________________________________ > 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/ I was going to respond in detail but it will be an effort in futility. My opinions are DEFINITELY not valued by you and that is your right as it my right to leave Postorius behind, permanently. Moving to my own interface was one of the best decisions I made and that decision continues to be shown to be a great one when I read threads like this. -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 9 months

Mailman-users search results for query "Postorius"