Search results for "Postorius" - Mailman-users

Re: Changing subscription address

by Abhilash Raj

> On Mar 22, 2021, at 7:53 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Abhilash Raj writes: > >> Well a couple of stars have to align for it to work unfortunately. > > I'm not going to wait for the stars; I have backward-incompatible > surgery in mind. > >> Add to that you can’t set an address as primary using just email >> commands, you end up with what you are seeing. > > Right. The idea is that the first time an address is used, a User > will be created and that address will be primary for that User. When > the person wants to claim that address, they go to Postorius, create a > Postorius account, do the address verification dance and set > credentials, which links the Postorius account to the User via the > Address. > > This is why the ability to merge Users becomes an urgent need: people > who subscribe via email are going to end up with multiple Users. Well, it doesn’t change the situation much from status quo. You also have multiple users today, even if you subscribe via individual address since an address always has a User. And like we were discussing over on the other thread, when the owner decides to join in P and control both the addresses from single P account, we’ll merge both users. > >> 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). > > I'm not clear what you're saying. In general admins can't read your > mail, so they can't verify you on a mass subscribe or an import. What I meant was, we can set the address as primary after the verification dance with the user and then subscribe the primary address. The existing subscription workflow is a multi-step process that can be paused and resumed. We pause when we send out a confirmation email and then resume when that confirmation token is somehow processed via email or API. So, post receiving the confirmation and before actually subscribing, we can se the address as primary if the user doesn’t have one and subscribe user as inhert. We don’t do any of that if user already has chosen a primary address and it doesn’t match the current address. Also, mass-subscribe and import does allow you to verify an address by clicking this “Pre-verified” checkbox, which can be useful if you are migrating from a different service or you exported a list of users from somewhere you know to be valid. > >> 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? > > No. The option to set a subscription to the literal primary address > should still be available. I don't see a good reason to complicate > the UI logic by comparing primary to literal addresses just to remove > that one. I just want the primary address to be populated > automatically, and inherit-from-primary be the default subscription > address when the subscription address matches primary, *unless* the > subscriber explicitly chooses that literal address in Postorius. > > This is backward-incompatible, but I think it will be overwhelmingly > popular with new users and old. There would be no behavioral change for users using email commands. For those using P, I think will be able to manage and switch rather easily. > >> 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. > > I think that's all we need to do going forward. > > We do need a better UI for setting options (including address) for a > selection of subscriptions, but that's an independent task. > > Thanks for looking at this, Abhilash! Of course :) > > Steve -- thanks, Abhilash Raj (maxking)

3 years, 8 months

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

by Stephen J. Turnbull

Caballero, Danny (Dan) writes: > I don't understand. We have a single database configured for > everything. I don't recall reading anything in the set-up > documentation about using more than 1 database for Mailman3. I was trying to help localize the database request to one of the three major components: core, Postorius, HyperKitty. If you use the two- database scheme documented here: https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… knowing that database would at least identify whether the slowness is associated with core or with the web apps. The excruciating details: Conceptually, there are three separate databases: the one used by Mailman core to manage everything but authentication and archives, the one used by Django to manage authentication for HyperKitty and Postorius, and the one used by HyperKitty to manage archives. They don't share tables, and there are no name collisions for the tables so it doesn't really matter how the backend handles them. The two database configuration is not really a recommendation. I suppose the practice derives from an abundance of caution, as there are concepts like "User" that must be implemented in somewhat different ways across components (core doesn't authenticate users, while Postorius's primary function is authentication of users). I myself would worry that there might be name collisions among tables, which would cause mayhem, but that's probably excessive.

2 years

MM3 error on moderation request

by Odhiambo Washington

MM3 - 3.3.10, Postorius 1.3.13. After receiving the notification to attend to a moderation request: ``` At your convenience, visit https://mm3-lists.kictanet.or.ke/mm/lists/kictanet.lists.kictanet.or.ke/hel… to approve or deny the request(s). ``` Upon visiting the link I ended up with a server error. mailmanweb.log has the below to say: ``` [ERROR] [2024-10-10 12:29:15,905] [log] 809040 139858772735552 Internal Server Error: /mm/lists/kictanet.lists.kictanet.or.ke/held_messages Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1026, in find_library return parser.libraries[name] ~~~~~~~~~~~~~~~~^^^^^^ KeyError: 'humanize' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapper_view return view_func(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/auth/decorators.py", line 63, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/views/list.py", line 889, in list_moderation return render(request, 'postorius/lists/held_messages.html', context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py", line 61, in render_to_string template = get_template(template_name, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py", line 15, in get_template return engine.get_template(template_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/backends/django.py", line 33, in get_template return Template(self.engine.get_template(template_name), self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py", line 175, in get_template template, origin = self.find_template(template_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py", line 157, in find_template template = loader.get_template(name, skip=skip) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/cached.py", line 57, in get_template template = super().get_template(template_name, skip) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/base.py", line 28, in get_template return Template( ^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 154, in __init__ self.nodelist = self.compile_nodelist() ^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 200, in compile_nodelist return parser.parse() ^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 513, in parse raise self.error(token, e) File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 511, in parse compiled_result = compile_func(self, token) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader_tags.py", line 293, in do_extends nodelist = parser.parse() ^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 513, in parse raise self.error(token, e) File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 511, in parse compiled_result = compile_func(self, token) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1088, in load lib = find_library(parser, name) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1028, in find_library raise TemplateSyntaxError( django.template.exceptions.TemplateSyntaxError: 'humanize' is not a registered tag library. Must be one of: account admin_list admin_modify admin_urls allauth bootstrap_tags cache compress d_gravatar date_helpers debugger_tags decorate gravatar highlight highlighting hk_generic hk_haystack i18n indent_text l10n log markdown membership_helpers more_like_this nav_helpers p_gravatar pagination postorius_helpers rest_framework socialaccount static syntax_color tz widont [WARNING] [2024-10-10 12:29:16,384] [log] 809040 139858704070336 Not Found: /mc/compose ``` How to fix? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 month, 2 weeks

Re: Issues with @gmail.com addresses

by Mark Sapiro

On 9/5/23 12:59, Mohsen Masoudfar wrote: > Hi, > > since 8/1/2023 I get complains from users with @gmail.com addresses, that they are not getting any emails. > I checked the logs and I see that the emails are going out: > > to=<xxxx(a)gmail.com>, relay=email-smtp.us-east-1.amazonaws.com[35.169.171.20]:587, delay=0.46, delays=0.03/0.06/0.13/0.24, dsn=2.0.0, status=sent (250 Ok xxx ) > > But it seems the users are getting email delivered to them. > I’ve advised them to check their spam, promotions, and social folders and to add the list address to their email safe-senders lists, but still no success. > Is there any way to help this list members? Even though gmail publishes a DMARC policy of none, it has recently started enforcing a stricter policy for mail From: the gmail.com domain. You need to apply DMARC mitigations to mail From: the gmail.com domain. There are two ways to do this. One way is to set DMARC Mitigations -> DMARC Mitigate unconditionally to Yes (and set DMARC mitigation action appropriately) The other way requires upgrading Postorius and Mailman core to the heads of the GitLab branches (core=3.3.9b1, postorius=1.3.9b1). Doing this enables a DMARC Addresses setting which can be set to `^.*(a)gmail\.com$` to apply DMARC mitigatations to mail From: the gmail.com domain regardless of it's published policy. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

Rolling releases for Container Images and Funding Campaign for Mailman

by Abhilash Raj

Hi Everyone, As you all know I have been working on container images for Mailman 3. We now have a new "rolling" tag for both mailman-core and mailman-web images. These images have latest source installed for every Mailman component. You can find more information about them on the website [3]. New images are available on quay.io and, moving forward, the rest of the image builds will also be moved to Quay[4][5]. These images are built using git-heads *only* if they are passing our test suite and are re-generated weekly. You should be aware that while all these components are tested with their individual test suites, their combination might sometimes not be stable. This will get you updates/bug-fixes much faster :) As most of you already know, Mailman 3 is the new and improved version with extra features, better security and much better architecture. We released Mailman Suite 3.0 in April 2015 and have come a long ways since then. Mailman Suite 3.1, release May 2016, was aimed to provide feature-parity with Mailman 2.x series and we think we _almost_ hit that goal. Apart from no monthly password reminders, Mailman 3 has a much better Administrator/User interface, REST API for scripting, a really awesome archiver, support for multiple domains, support for external plugins, support for SSO/social login and so much more! I love working on Mailman and would enjoy being able to do so full time for next 6-8 weeks. Mailman 3 is not very far from becoming the default version everyone would use, but it still needs some work to get there. I need help from you, the users of Mailman, to get us there. If you or your organization would like to move to (or, already moved to) Mailman 3, I urge you to donate[1] to us. There are options to donate using Credit Card, Paypal, Bitcoin, Wire Transfer (of any currency), Check and money order. If this campaign succeeds, here is a road map of what I intend to get done: - Move Django apps(UI/Archiver) to Python 3 (or bilingual) - Fork `mailman import` command to provide an upgrade path to Mailman 3.x from Mailman 2.x - Fix MySQL compatibility in Core - Changes in Postorius: - Add support for missing options that are already exposed in Core’s API - e.g. Support for setting templates - Find the commonly used options that are not exposed in Core, add them to Core's API and add to Postorius - Add Admin Dashboard project from GSoC 2014 (maybe?) - Add better testing of container images and provide deployment instructions for Kubernetes & Docker Swarm - Improve the container images to work with new micro-services architecture, to achieve scaling and redundancy in services. - Administrator/User documentation for Postorius & Mailman - (optional) Fork [mmcli](https://github.com/rajeevs1992/mailmancli) project from Rajeev, fix if there is anything missing and add it as an additional command line tool to work with Mailman Core. Maybe pull it under Mailman umbrella. Except for these, if there is something more important that is preventing the adoption of Mailman 3 from your end, we can discuss them. I'd like to mention that I have been working on Mailman 3 for quite some time now and I intend to implement every single item on the list. You donations would help it get done much sooner, hopefully in time for 3.2 release schedule (at PyCon US 2018). You can follow the progress of this campaign here[2]. [1]: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=22 [2]: https://wiki.list.org/x/17892025 [3]: https://asynchronous.in/docker-mailman/#rolling-releases [4]: https://quay.io/repository/maxking/mailman-web [5]: https://quay.io/repository/maxking/mailman-core -- Abhilash Raj maxking(a)asynchronous.in

7 years

Re: Mailman3 is wrongly display name a list member

by Mark Sapiro

On 1/11/22 9:24 AM, Allan Hansen wrote: > Thank youi, Stephen. > > Oops. When I wrote below that I set the name 'B' in the account, I did describe it wrongly. Sorry. > The member just wants one name, 'A' for all her subsriptions. Somehow the 'B' got into the system when we upgraded from Mailman 2 to Mailman 3. > > I removed the address from all the lists, set the account display name to 'A' in Django, verified that she was not subscribed to any list at all, and then resubscribed her again as 'A'. In other words, no 'B' anywhere - straight 'A's. > Nevertheless, the new subscriptions still show up as 'B'. A user has a user record and one or more address records. Each of these has a display name. Removing users from lists does not remove these records. If you have recent Postorius, you should have a `users` item at the top of Postorius pages. Go there, find the user and click "Manage". You can change Display Name there. Otherwise, in `mailman shell` for example ``` >>> usr = getUtility(IUserManager).get_user('user(a)example.com') >>> usr.display_name = 'First Last' >>> for adr in usr.addresses: ... adr.display_name = 'First Last' ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

Re: Fwd: Re: Removing a mail addresses and users

by Abhilash Raj

On Sun, Jun 14, 2020, at 12:45 PM, Allan Hansen wrote: > All, > > Thank you for your thoughtful responses to my call for a removal of the > core vs. Django disconnect. From your responses it appears that my > suggestion my issues were caused by the Mailman Core was not based in > reality. Instead, the issue is how Postorius interacts with the Core. > My apologies for overreaching, as the cause of my issues is not an > issue to me. Keeping Core a simple list manager is fine, if Postorius > is easy to use and does the expected. > > As a Subscriber, you are able to do switch emails in subscriptions from > your options page. The URL to which is displayed in the List's Summary > page when you are logged in. Yes, it requires an approval if the list's > settings are set to moderate but that is going to be fixed, see this > issue[1]. It is quite simple IMO to fix this one, if someone wants to > take this up. > > Well, it’s more than that. Based on the current setup, I have asked my > subscribers who want to change their subscription addresses to: > a. Create an account if you do not already have one. > b. Go to the user profile page. > c. Select ‘E-mail Addresses’. > d. Add the new e-mail to the user profile. > e. Wait for the verification notice and verify the new address. > e1. If it does not show send email to hansen(a)rc.org > <mailto:hansen@rc.org> to get the email verified manually. > f. Sign in to the account again and to the user profile (or refresh > the page if not signed out). > g. Select the new address as the primary address. > h. Click on ‘Manage Lists’ > i. For each list you are subscribed to: > i1. Select the list > i2. Click ‘List Options Page.’ > i3. Pull down the ’Select Email’ menu. > i4 Select your new email. > i5. Press ‘Change email used for subscription. > i6. When the moderator contacts you, explain that you are just > changing your email. > i6.1. If the moderator is late, send a reminder or send email to > hansen(a)rc.org <mailto:hansen@rc.org> to bypass the moderator. So, a-f is something we still always want to keep since we aren't going to deal with un-verified email addresses. Now, Primary Address is something interesting in Mailman 3, which wasn't utilized until now in Postorius. I recently added a new feature to Postorius which allows users to subscribe via their Primary Address and it switches the delivery address when you switch your primary address. You can play with how it looks at https://lists.mailman3.org (Mailman instance serving this list) where you will see "Primary Address (myprimaryemail(a)example.com)" as an option when subscribing/switching address. This is still somewhat new feature and there are gaps to it, but it will grow over time. For example, as as admin, you can only subscribe a User's address and not their Primary Address (from Mass Subscription page, or through the CLI commands). As a User, you are able to switch to using your primary address and then every time you switch your primary address, all your subscription shifts to that new address without any extra steps. Also, I just created a fix for i6[1], so switching email addresses won't require approvals anymore. I am still debating if this should be configurable by list owners. [1]: https://gitlab.com/mailman/postorius/-/merge_requests/532 > > Most people choke on these instructions, so I have unfortunately > resorted to just asking them to subscribe the new address and forget > about the old. This is not good for our reputation when the old > addresses start bouncing. So, in more detail: > > I would like to ask my subscribers who want to change their address to: > a. Create an account if you did not already have one. > b. Go to the user profile page. > c. Select ‘E-mail Addresses’. > d. Select an existing address e-mail listed the user profile. > e. Press new button ‘Change address’. > f. When page refreshes, enter the new e-mail address. > g. Press ‘Apply.' > d. Wait for the verification notice. > d1. If it does not show send email to hansen(a)rc.org > <mailto:hansen@rc.org> to get the email verified manually. > > In other words, in addition to ‘Make Primary’ and ‘Re-send > Verification’ and ‘Remove’, another button says: ‘Change Address’ or’ > ‘Replace Address’ or some such. > > This button brings up another page that looks the same, but instead of > ‘Add E-mail Adress’ is says : Enter New E-mail Address’ > and instead of ‘Add E-mail’ is says: ‘Apply’. Then the page refreshes > back to the original page, but the new address is now > replacing the old address. Optionally, it can show the old address > still with a ‘pending change’ until verification. I am still thinking about a few implementation details of this one, I've created an issue[2] [2]: https://gitlab.com/mailman/postorius/-/issues/435 I am thinking we could minimize changes by retaining the same workflow for adding and verifying new address, but add a new workflow of some sort to switch subscriptions to a new address with a single button click. This should simplify the Loop of going to each option page and switching addresses. Finally, the old address can be removed. Another train of thought is that when you Delete your email address, you get an option to switch all the subscriptions on that address to some other address. I could do this by adding a page after you click on "Remove" button. Although, this would restrict the ability to switch subscriptions by only deleting the original one, which I don't want. Maybe I'll end up implementing both of these. What do others think about this? > > Further, when the new address is verified, all lists get updated with > the new address replacing the old > address and all settings associated with the old address are now > associated with the new address. No moderator or admin > involvement needed (other than d1). The fix[1] I mentioned above should already resolve this issue. > > You are able to sign in via web and manage your email and > subscriptions. The preferences also work exactly how you described > above where the lower level override the default and/or upper level > settings. > > To some extent that is true, Abhilash, and I appreciate that. The above > (address change) is a missing piece in that picture and I look forward > to seeing it added, if you have time. > > Yours, > > Allan Hansen > hansen(a)rc.org > > > > > > On Jun 14, 2020, at 0:19 , Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > > > Mark Sapiro writes: > > > >> Then the people who developed the web based management UI (Postorius) > >> and archive UI (HyperKitty) chose to develop those within a Django > >> framework and Django has its own concept of User separate from Mailman > >> Core and that is where the disconnect occurs. > >> > >> It's not that Mailman Core lacks what you want. It's that Django doesn't > >> use it. > > > > I think that's mostly right, in terms of the features that users miss. > > However, as far as I know, Mailman core does lack facilities for > > identification, authentication, and authorization of connections to > > the REST API. And that means that the front ends have to handle > > this. I would guess that's why the web interfaces are built around > > Django user authentication. > > > > I think it would be possible to have somewhat tighter integration > > between the Django "web users" and the Mailman core User objects, but > > it's not necessarily going to be trivial. > > > > I see that Abhilash is pretty optimistic, but I fear this this is > > going to be a long-tail situation where we're going to be seeing core > > user vs. web-gui user integration issues in 2030 (maybe by then only 1 > > every 450 days ;-). I have some ideas, maybe in a couple weeks I can > > sketch them out. > > > > 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/ > > _______________________________________________ > 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)

4 years, 5 months

Database running VERY hot

by Darren Smith

Hello all, We had an old installation of Mailman 2.1 across three servers with over 32,000 mailing lists on them. Due to circumstances beyond my control, we had to shut them down and quickly set up Mailman 3 on a new server. We have Mailman3 set up on a single server this time, as we were having problems with a 3-server setup and Hyperkitty and archives. Long story short, it is up and running, and our users are starting to come back. However, we do not have very many users hitting Postorius and Hyperkitty yet, and we are seeing a distressing number of 504 gateway timeouts. We noticed that there is a significant number of queries to the API whenever hitting Postorius's front page to load the mailing lists, and then on every load. It looks as if it makes a single call to the API to get information about a single list, and does this 10 times - once for each list - to render the page. This gets much worse when users set the view to 200 per page, as they are inclined to do with 32,000 mailing lists... What we've done, actually, is to override the front page and point the users to a different set of static pages where we have all of our lists categorized and searchable, and when they find the list they are looking for, we have a link back to postorius. It has taken a lot of the stress off of the server. However, I still see where the database at times can run VERY hot. We have set up this server to run with PostgreSQL. When I do a ps aux | grep postgres, I find a lot of processes that have been spawned to take care of mailman - a dozen or so. However, one of the threads is taking up about 85% of the load, another thread about 14%, and little dribbles here and there from the rest of the threads. Here are the questions: 1) Has anyone run into problems like these? I would think that maybe this is an issue having so many mailing lists, but honestly there aren't that many people using the system yet. It is going to ramp up as the users realize that we are live again, but we aren't getting that much traffic. 2) Is there any configuration that I can set, especially with regards to the database, so that it can be used more efficiently and not throttle through one or two threads? Please let me know what further information I can provide. Thanks in advance for any help or advice! Silas

6 years, 8 months

Re: Verification Failed Error

by Odhiambo Washington

Hi Abhilash, Can I use the instructions at https://github.com/maxking/docker-mailman with a MySQL database instead of PostgreSQL? I am looking at the following block in docker-compose.yaml: database: environment: POSTGRES_DB: mailmandb POSTGRES_USER: mailman POSTGRES_PASSWORD: mailmanpass restart: always image: postgres:9.6-alpine volumes: - /opt/mailman/database:/var/lib/postgresql/data networks: mailman: ipv4_address: 172.19.199.4 I'd like to change those to use MySQL. Maybe you should also add an example on the site for these?? On Fri, 21 Dec 2018 at 03:25, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > > 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) > _______________________________________________ > 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/ > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

5 years, 11 months

Re: Mailman3 not working following distribution upgrade from Debian 10 to 11.

by gordon＠dickens.com

Thanks Mark! Here is the Traceback from the error: Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/generic.py", line 74, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/list.py", line 326, in get primary_email = set_preferred(request.user, mm_user) File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/utils.py", line 64, in set_preferred primary_email = EmailAddress.objects.get_primary(user) File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/managers.py", line 30, in get_primary return self.get(user=user, primary=True) File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/query.py", line 419, in get raise self.model.MultipleObjectsReturned( Exception Type: MultipleObjectsReturned at /mailman3/lists/testing.dickens.com/ Exception Value: get() returned more than one EmailAddress -- it returned 3!\ Thanks for your help! Gordon

2 years, 9 months

Mailman-users search results for query "Postorius"