Search results for "Postorius" - Mailman-users

Re: Mailman 3 Social Auth Configuration

by Mark Sapiro

On 10/12/2016 08:09 PM, emonical(a)misfitlabs.org wrote: > > I am a new Mailman 3 user and have just gotten an environment configured using the Mailman bundler. The setup is almost complete, but, there's still Persona authorization. Mailman bundler installs the latest releases from PyPI, but those are behind the latest development branches. > I was reading the your setup here from (https://wiki.list.org/DOC/Mailman%203%20installation%20experience) and was wondering if someone might have some insight as to how to remove the Persona log in to keep it locked down entirely to localized user registration. With the latest gitlab branches, you will have Django Allauth. This includes login by verified email and password, and if you choose to not use any of the supported Oauth2 providers, that will be the only method. To do this without waiting for the Mailman 3.1 release and an updated bundler, you will need to install the latest master branches from <https://gitlab.com/groups/mailman> for Mailman, Postorius, HyperKitty, MailmanClient, django-mailman3 and HyperKitty - Mailman plugin. The wiki article <https://gitlab.com/groups/mailman> will give some insight into the process, but it isn't fully current. I will be updating it. Meanwhile, ask your specific questions here and we will try to help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 1 month

Problems after update to mailman 3.3.7

by Guillermo Hernandez (Oldno7)

I've getting the most strange behaviour after update to last releases. In one of my mailman3 servers, the messages doesnt reach for some lists (the five last ones) the update have not showed any error but in the var/data for the lmtp and vmap postfix files mailman does not create aliases for that last 5 lists. Any message addressed to them is returned with a "no such user" error. If I create a new list the system or restart mailman runners it shows this error: Generating MTA alias maps /usr/local/lib/python3.9/site-packages/pymysql/connections.py:799: UserWarning: Previous unbuffered result was left incomplete warnings.warn("Previous unbuffered result was left incomplete") I did a CHECK TABLE on mailinglists table but all seems ok. I tried reinstalling PyMySQL, but has no effect. (well, I tried reinstalling all) It seems to me that something is preventing creation of that aliases, an then the that last five lists are unreachable. I have no clue of what to do now and I'm driving crazy. Some direction to look for will be much apreciated. Thanks in advance. P.S.: I can access via postorius/hyperkitty to the archives of the lists that are unreacheable. -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

1 year, 11 months

Re: lists.mailman3.org web site.

by Mark Sapiro

On 08/27/2016 09:15 PM, Mark Sapiro wrote: > I have just upgraded the lists.mailman3.org Mailman 3 installation to > the heads of the GitLab mailman* branches. A major change is the switch > from Persona to Django Allauth. This requires some configuration which > isn't yet complete. Hopefully it will all be working very soon. > > In the mean time if you want to log in to Hyperkitty/Postorius you > should be able to log in with your email address. The first time you do > this, Mailman probably won't even know your password so you'll have to > request a reset. Once you have reset your password, you should be able > to log in. > > I hope to have several social auth choices working very soon. Update: 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. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 2 months

Re: Mailman3 don't work if aliases are enabled

by Mark Sapiro

On 10/9/20 3:37 PM, Massimo Zappalà wrote: > > If I try to uncomment the last two rows in main.cf > virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_emails.cf, mysql:/etc/postfix/mysql_virtual_alias_maps.cf > virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf > The aliases and email messeges works fine but the mailman3's mailinglist don't work. > > How can I solve this? I'm not certain about this. The Postfix log entries for the failed delivery to Mailman may help, but I think you deed to configure an alias domain or domains for your list domain(s). The alias domain is not a real domain and is not in DNS. it is any unused domain name and will be known only to Postfix. I typically use x.example.com where example.com is the real list domain. You can set the alias domain for the real domain in the domains view in Postorius. Then you need to add `hash:/var/lib/mailman3/data/postfix_vmap` to your main.cf virtual_alias_maps setting and run Mailman's `mailman aliases` command to generate the proper /var/lib/mailman3/data/postfix_* files. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>. You may also need to set relay_domains = hash:/var/lib/mailman3/data/postfix_domains -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

Re: [Mailman-Developers] How to know the URLs for CURL while getting or modifying the data of mailman 3

by Shashikanth Komandoor

Stephen, Thank you for your response. I am sorry for getting confused between two lists mailman-users and mailman-developers. Developers may be busy and my question may be basic but still there is a space for more politeness at your end to advice me. Apart from that, you have given a lot much of useful information which is really and honestly helpful for me to the maximum extent. Now I shall take the help of members of mailman-users only. @mailman-users@mailman3.org <mailman-users(a)mailman3.org>, Team, I have installed Mailman Version 3.3 and running in production. Our development team developed another application which requires the access of the REST API and do changes over the MM3 DB automatically without manual intervention. That application would be connecting to REST API over http or https protocol To achieve this I have enabled the REST API to run at all the IP addresses of my MM3 Server by editing the mailman/src/mailman/config/schema.cfg file. I was able to run few commands like creation of domains, lists, list configuration changes for testing using the CURL (GET, POST, PATCH, DELTE) and got succeeded. But for every operation I need to write a different URL for CURL command to work. Out of many operations I require, addition of members to a list and removal of members from a list are most important tasks. So, I request herewith, from the URL https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/rest.html, I could see many URLs but they are executed at python prompt (>>>) only. I require URLs usable at the CURL command. Is there any way I could generate the URLs or any where documented regarding the URLs usable with CURL for the addition and removal of subscribers ? On Sat, Apr 25, 2020 at 8:04 PM Stephen J. Turnbull < turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > Shashi, > > This whole thread is off-topic for the developers list. This list is > for development of Mailman, not for teaching people to use it. Read > the whole recommended documentation before you ask busy developers to > tutor you in very basic things. There's a mailman-users(a)mailman3.org > list for users to help each other. All of the Mailman developers who > might be willing to answer your questions are there as well, but there > are also many experienced users, some of whom have experimented with > the REST API who will also help. Please reply there for further > help. (Reply-To is set.) > > That said, there are plenty of URLs in the API documentation. Here's > a hint: search for "dump_json". That function takes an URL. You may > want https: instead of http: in your URLs, and you may need to change > the port from 9001, depending on the configuration of your REST > server. Try it with simple GET requests for information first, such > as for domains or lists. You can also do these requests with an > ordinary web browser, though I don't know what it will do with the > JSON-formatted reply. > > If you don't have domains and lists configured, I suppose the > informational requests will come back as empty JSON objects. It > should be safe to make them. You can either use Postorius to > bootstrap a few example domains, lists, and users, or (the hard way) > figure out how to POST appropriate requests. I don't recommend trying > to update the backend DBMS by hand; the schema is quite complicated. > I don't know how to use curl to update Mailman's databases. That > requires a POST request which I have never done with curl. The POST > request needs to be valid JSON. > > The more I think about this, the less I think your idea of using curl > is worthwhile, because formatting JSON requests by hand is going to be > a real annoyance and a great way to mess up your database with > spurious information. You're really going to want programmatic > support for this. But that's already all available in Python in the > Mailman system. > > It's up to you, but I feel a responsibility to warn you that using > curl is not going to be simpler than learning enough Python to do > these things. > > Regards, > -- Thanks & Regards, Shashi Kanth.K 9052671936

4 years, 7 months

Re: hello， Discussion on how to subscribe to the mailing list

by Stephen J. Turnbull

Mark Sapiro writes: > On 1/16/23 18:55, 朱超 wrote: > > Hi, When I subscribe the email list in Subscription Policy is > > confirm, Some problems happen in here： > > 1.Some mail mua reject send the confirm the message, because the > > length of recipient is too long. for exmaple: > > requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain, > > and the mail mua reject to modify about this. > > The default English template says in part: > > Before you can start using GNU Mailman at this site, you must first > confirm that this is your email address. You can do this by replying to > this message. > > Or you should include the following line -- and only the following > line -- in a message to $request_email: > > confirm $token > > I.e. It gives an alternative method if `reply` doesn't work. You can > provide a custom version of this template with different wording if you > think you can improve it. The problem is the reply address, though. Changing the template to suggest only the "confirm $token" in body method doesn't help people who hit R expecting that should work, especially since many "user fiendly" (misspelling intentional) MUAs don't display the address. Avoiding that requires code changes, I guess? > > 2.It is inconvenient for users to use. Many people will > > mistakenly think that after clicking the subscribe button, it > > will be successful, and they will not process the email. > step, you can set Subscription Policy to Open, but then anyone can > maliciously subscribe third parties to the list. *Please* do not do this if your server is exposed to the Internet. There are bots that search for such servers, and sell lists of them to people who want to DOS mailboxes. You may find yourself banned across the Internet. The only real alternative to confirmation is approval by moderators. I believe Mailman 3 offers that alternative as Mailman 2 did, can't check at the moment. > > Regarding the discussion on the subscription method of the > > mailing list, should we consider optimizing the subscription > > method of the mailing list, for example: > > 1. use the method of sending a verification code to subscribe by > > email，When you receive the verification code sent by the > > mailing list and fill it in again, you can subscribe > > successfully。 > > How is this different from the present method. Just wording. I think they are thinking of the "invite" option that was provided in Mailman 2 mass subscribe (again, I think Mailman 3 retains it but I never ever used it so I don't recall for sure). But it doesn't make sense for a user-initiated interaction. > If you want, you can make > a custom template and include something like: > > Alternatively, you can confirm by going to the URL > > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token If I understand the OP's PoV correctly, I think I would change the list information page to say "Send a personal invitation to join the list to [email address here]. If you aren't a subscriber, you can invite yourself." And change the word "confirm" in the confirmation template to "subscribe". > We don't include that in the default template because Mailman core > doesn't know if you even have a web UI or how to access it if you > do. We should fix that, at least if the web interface is Postorius (wishlist, assigned to me): https://gitlab.com/mailman/mailman/-/issues/1055 @mark https://gitlab.com/mailman/mailman/-/issues/901 Maybe we can close this? I'm not sure why it was left open since there's no action proposed for Mailman improvement. > > 2. use the email to send a connection to confirm the > > subscription，People click the link to be redirected to a > > confirmation page to subscribe to the email。 > > See above. Indeed, AFAICS almost everything the OP is suggesting amounts to an identical procedure as far as the Mailman server is concerned, it's just described to the subscriber differently. The one exception is the suggestion to eliminate the confirmation step, and while that is supported, it's quite likely to cause problems for third parties and eventually for the Mailman site unless you have an alternative ground source of truth such as an employee database. Steve

1 year, 10 months

Re: Question about whitlisting a domain for specific mailing list

by Zaheer Abbas

Thanks, Mark & Odhiambo for providing options for the solution. I will try the 'postorius header filters' hacky way as it's more suitable to my requirement, however, if it didn't work as expected, then filtration through exim filter is also an acceptable option. Thanks again for the quick response. On Thu, Mar 30, 2023 at 8:58 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/30/23 11:07, Odhiambo Washington wrote: > > So the MTA option that doesn't involve any regex is better than no? > > Partly it's a matter of taste and possibly a matter of necessity. I.e. a > list admin can do this with header filters and may not have access to > the MTA config. > > Also, it's not clear to me that doing this in Postfix is less > complicated than understanding a regex. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to zaheer.psg(a)gmail.com >

1 year, 7 months

Re: How to store additional information about lists?

by Andreas Barth

* Stephen J. Turnbull (turnbull.stephen.fw(a)u.tsukuba.ac.jp) [210530 09:19]: > Mark Sapiro writes: > > On 5/29/21 7:31 PM, Stephen J. Turnbull wrote: > > > > Membership adapter is a Mailman 2 feature that allowed use of an > > > external membership database (such as a corporate LDAP system). I > > > thought it was ported to Mailman 3 but maybe not. > > > Actually, it's not quite that simple. Mailman 2.1 defines a > > MemberAdaptor class, [...]. > > The Mailman 3 analog of this is the IMember interface defined in > > mailman/interfaces/member.py and implemented in mailman/model/member.py > > OK, but for Andi it is "simple" in the sense that he doesn't have an > existing MemberAdapter, so the plan is "Implement the IMember interface". Not sure if this is the right approach, or if it wouldn't be more appropriate to "just" replace the dependency on allauth in postorius, and do all the magic in the frontend only (because that's where people actually subscribe). Whoever subscribes by mail needs some admin action, or some cron job, or is unsupported - for my case the main interface is the web interface, not the email commands. That of course would imply that e.g. cleaning up mailing lists happens by a cron job with rest, but why not? Andi

3 years, 5 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

On Fri, Feb 12, 2021, at 8:52 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > The is definitely a bug, caused due to the fact that "Delivery Status" field > > only has two options, "Enabled" and "Disabled". Internally, this field can > > have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), > > "by_admin" (means disabled by admin) and "by_bounces" (means > > disabled due to bounces). So, when the value of the field is among > > the last two options, it appears as "unset" with no options selected, > > which unfortunately is also how it looks by default since all options > > are "unset" from start. > > > > The "fix" for this issue would be simply adding a new choice to the > > delivery_status field with a caveat that it is only a Readonly option to > > I don't see why most users would care (there will always be somebody > who cares "just because", of course). For those who don't care, I > expect it will be confusing. I think it's better just to treat all of > the disabled settings as just "disabled" in the UI for members. I don't have any strong opinions on treating all disabled options as just disabled for the user. Would List admins be interested in knowing more details about that or should it be the same for them? I feel they might be interested in such details. Brian mentioned that Affinity actually details explicit value of the delivery_status, so maybe it is useful for them? > > > We could also go a step further and show it on the List's info page > > when their delivery is disabled due to excessive bounce and allow > > the them to re-enable it themselves without admin intervention. > > This is probably a good idea, but in a situation where we know the > problem is excessive bouncing we should caution them that there is > almost certainly a probably with delivery *to their specific address* > and that Mailman and the admins *can do nothing about that*, so if > that isn't fixed they'll just get disabled again. I suppose it would > be good to add that frequently these are due to occasional problems > like disk full that "management" at their site normally takes care of, > so there's little if any harm to just reenabling. Yeah, a link to an FAQ entry in documentation perhaps? I am thinking that most addresses disabled due to bounces would really either be spam subscriptions or abandoned/invalid email addresses that once were working. There would be few with problems with delivery which would want to re-enable as soon as they can, but definitely letting them know that there is an issue with delivery is a good idea. > > > to the list's info page, but I guess that is the first place you'd go to > > debug when you get an email that your delivery was disabled? > > Surely we can help them go directly there? I guess yes, but that brings up the whole discussion about how does Core know about the URLs. Custom templates can help get there easily, but that will not solve the problem, only put the onus on list/server admins to set that on a per-installation basis. Although, we can add "Goto your list subscriptions to re-enable" your subscription. Maybe even a new email command that allows re-enabling subscription without logging into P? > > > https://gitlab.com/mailman/postorius/-/issues/470 > > > > I don't know if there are any downsides to letting users re-enable > > their delivery on their own. > > I don't see any myself. Maybe if the list is planning a surprise > party for them? ;-) Oh just Ban them in that case ;-) > There is a specific downside, which is that if you only allow them to > reenable if they disabled it themselves, you have to show them the > other cases. I was initially thinking that maybe we can disable changing the delivery status if it was disabled by an admin ("by_admin" value), but AFAIK, there is really no way to even set that right now and no real use case for that has come up, so I am going to punt on that idea until someone really asks for it with a valid use case ;-) -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Re: Verification emails 'helo' rejected

by Greg Newby

Definitely it's venv. It might be that mailman-web.py is an artifact of an earlier attempt with Ubuntu packages, since settings.py and mailman-web.py are quite similar. I do have the other config files you mention, all under /etc/mailman3/ Thanks for any further thoughts... ~ Greg On Wed, Oct 16, 2024 at 3:47 AM Odhiambo Washington <odhiambo(a)gmail.com> wrote: > > > On Wed, Oct 16, 2024 at 8:15 AM Greg Newby via Mailman-users < > mailman-users(a)mailman3.org> wrote: > >> Thanks for this, Odhiambo. Unfortunately it doesn't address my situation. >> See below: >> >> >> >> On Tue, Oct 15, 2024 at 3:21 AM Odhiambo Washington <odhiambo(a)gmail.com> >> wrote: >> >> > >> > >> > On Mon, Oct 14, 2024 at 10:43 PM Greg Newby via Mailman-users < >> > mailman-users(a)mailman3.org> wrote: >> > >> >> Hi friends. >> >> >> >> I'm now getting a 500 server error upon signing up a new username on >> the >> >> web-based front end. The username is created in the back end, but the >> >> verification email does not get sent. >> >> >> >> This is GNU Mailman 3.3.9 (Tom Sawyer), venv, Ubuntu 24.04LTS, >> PostgreSQL, >> >> Postfix >> >> >> >> Here are the corresponding logfile entries from mailmanweb.log: >> >> smtplib.SMTPRecipientsRefused: {'redacted(a)gmail.com': (504, b'5.5.2 >> >> <mail>: >> >> Helo command rejected: need fully-qualified hostname')} >> >> >> >> and from mail.log: >> >> Oct 14 12:06:26 domain postfix/smtpd[722764]: NOQUEUE: reject: RCPT >> from >> >> localhost[127.0.0.1]: 504 5.5.2 <mail>: Helo command rejected: need >> >> fully-qualified hostname; from=<root(a)lists.domain.tld> >> to=<root@localhost >> >> > >> >> proto=ESMTP helo=<mail> >> >> >> > >> >> ^^^^ Note the problem isn't the "From:" address. That is being correctly >> configured from mailman-web.py and settings.py via the variables below. >> >> The problem is it's going "To:" root@localhost. I don't know why this is >> happening - shouldn't it be going to redacted(a)gmail.com? >> >> Also, based on settings below shouldn't this be From: >> postorius(a)lists.domain.tld >> not From: root(a)lists.domain.tld? >> >> More: >> >> >> >> > >> >> lists.domain.tld is the domain for Mailman3. I don't know why it's >> trying >> >> to send email from root@. >> >> >> >> I've seen places where 'localhost' appears in the Mailman settings >> >> (settings.py, mailman.cfg, mailman-web.py), and tried changing them to >> the >> >> host's FQDN and restarting mailman3 and mailman3-web, but the problem >> >> persists. >> >> >> > >> > Find and fix these values to what they should be as explained. >> > >> > # The sender of emails from Django such as address confirmation >> requests. >> > # Set this to a valid email address. >> > DEFAULT_FROM_EMAIL = 'johndoe(a)domain.name' >> > >> > # The sender of error messages from Django. Set this to a valid email >> > # address. >> > SERVER_EMAIL = 'johndoe(a)domain.name' >> > >> > I use listmaster(a)lists.domain.name in my servers. >> > >> >> In the default files via the venv installation, these were already set >> properly: >> >> EMAILNAME='lists.domain.tld' <-- I set this myself >> >> These were default in settings.py and mailman-web.py: >> DEFAULT_FROM_EMAIL = 'postorius@{}'.format(EMAILNAME) >> SERVER_EMAIL = 'root@{}'.format(EMAILNAME) >> > > For the venv installation, I rarely hear a mention of mailman-web.py. > I only know about settings.py, mailman,cfg and mailman-hyperkitty.cfg > files in /etc/mailman3/ > > Are you really using the venv install? > > -- > 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, 1 week

Mailman-users search results for query "Postorius"