Search results for "Postorius" - Mailman-users

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.

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

10 years, 1 month

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

6 years

Re: mail stuck in "out" queue

by Mark Sapiro

On 12/17/24 13:38, pdw(a)mythic-beasts.com wrote: > > I've now found the SHUNT entries and the exceptions seem related to restarting mailman (see below) so that much makes sense. > > unshunting does indeed restore them, but unfortunately they're now back in the looping state. This behavior always seems related to decorate being unable to get templates for for the message header/footer. Does this list define templates for list.member.regular.header or list.member.regular.footer in Postorius? To rule out a template retrieval issue as the cause, you could try this patch to skip decorating the message. ``` --- a/src/mailman/handlers/decorate.py +++ b/src/mailman/handlers/decorate.py @@ -40,6 +40,7 @@ alog = logging.getLogger('mailman.archiver') def process(mlist, msg, msgdata): """Decorate the message with headers and footers.""" + return # Digests and Mailman-craft messages should not get additional headers. if msgdata.get('isdigest') or msgdata.get('nodecorate'): return ``` If you apply that patch and the messages get delivered, albeit without the footer, the issue is definitely in retrieval of templates. You say you have removed the var/templates/list/LIST_ID/* templates, but is there still a var/templates/list/ and a var/templates/list/LIST_ID/ directory and are they searchable by the Mailman user? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 10 months

Re: Can't add emails to accept_these_nonmembers

by Stephen J. Turnbull

Ibiam Chihurumnaya via Mailman-users writes: > I had done the members part in the past, but the issue with it was > I wanted certain members to not receive messages from the list, but > only send to the list. As Mark explained, you can set those members to 'Default Processing' in the moderation option, and to 'No Mail' in the mail options. In that case they or list owners could reset them to receive mail. The alternative is to add the addresses one by one as non-members and set their moderation. In that case they cannot receive mail, although they may be able to subscribe themselves depending on list settings, or an administrator could subscribe them. In both cases the nonmember would remain unless removed by an administrator. In both cases, although you can add members with mass subscription, there are no "mass" operations to update the subscription option or to create non-members in Postorius, you need to do it one by one. You can automate that by using a loop over a list of addresses in Mailman shell, or if you expect to do it more than once, you could create a withlist script to use with the -r option. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

8 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)

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

3 years, 6 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] >

2 years

Re: Can't subscribe on new site/domain

by Flo

On 10/9/25 17:06, Stephen J. Turnbull wrote: > Odhiambo Washington via Mailman-users writes: > > > You can remedy that by wiping away the packages and installing MM3 > > by following the guide below: > > > > https://docs.mailman3.org/en/latest/install/virtualenv.html > > @Flo: It is possible to do this safely and preserve your existing > sites and lists. If we can't help you with your existing > installation, we can guide you through this process. The basic idea > is that because almost all the interesting data is in your database or > /etc/mailman3, you can just plug in the new Mailman system, point > things at the right places (probably the file system layout will > change so you'll need to change some things in mailman.cfg, > settings.py, and some related systems like logrotate and systemd). > Usually I avoid installing software directly as there is more maintenance effort than having installed it from OS-packages. In this case I see that I have permanently troubles with this software (OS-packages) so your suggestion is worth to consider. Is there a possibility to export all members including real names. It doesn't work with Postorius, yet, is there another possibility? If I have my user data exported, I could delete everything and start from scratch. Maybe this is the most reasonable ... Flo

1 year

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

5 years, 4 months

Mailman-users search results for query "Postorius"