Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Mailman3 service on mailman-3.3.4 is not getting started

by Mark Sapiro

On 6/23/21 12:24 AM, Shashikanth Komandoor wrote: > Hi team, > > I am trying to install mailman 3.3.4, the currently available > latest version at > https://docs.mailman3.org/en/latest/install/virtualenv.html on RHEL 7.5. > > As part of the installation, I am not creating any user with the > name *mailman* and instead going with the *root* user only. Along with that > I am using the directory */var/lib/mailman* as the root directory. It is a very bad idea to run Mailman as root. If there were some vulnerability that would enable an exploit to run arbitrary code, you wouldn't want that code to run as root. ... > Now, the issue is while I am trying to start the service, it > is showing the below error and the status looks like as following: > > # systemctl start mailman3 > Job for mailman3.service failed because a configured resource limit was > exceeded. See "systemctl status mailman3.service" and "journalctl -xe" for > details. > > # systemctl status mailman3 > ● mailman3.service - GNU Mailing List Manager > Loaded: loaded (/etc/systemd/system/mailman3.service; disabled; vendor > preset: disabled) > Active: failed (Result: resources) since Wed 2021-06-23 12:51:27 IST; > 1min 7s ago > Process: 16277 ExecStart=/var/lib/mailman/venv/bin/mailman start > (code=exited, status=0/SUCCESS) > > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: os.execl(*execl_args) > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: File > "/usr/lib64/python3.6/os.py", line 527, in execl > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: execv(file, args) > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: TypeError: expected str, > bytes or os.PathLike object, not NoneType > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: Starting Mailman's master > runner > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: Generating MTA alias maps > Jun 23 12:51:27 psumm3.nic.in systemd[1]: PID file > /var/lib/mailman/var/master.pid not readable (yet?) after start. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: Failed to start GNU Mailing List > Manager. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: Unit mailman3.service entered > failed state. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: mailman3.service failed. > > I can't understand where the issue might be. What's in Mailman's mailman.log? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

[MM3-users] Re: DMARC Mitigation Wrap

by Mark Sapiro

On 1/26/20 4:43 PM, Allan Hansen wrote: > > MM3 has the option to wrap the main message with a wrap_message. It appears, however, that MM3 is oblivious to all my attempts to include whitespace, in this case a <cr>. When the enclosed message is automatically unwrapped by the receiving client, this causes the wrap and enclosed message's From: header to butt up against each other, which is rather ugly. I tried many tricks, but none worked, such as, <cr>, SPACE+, TAB+, <BLANKLINE>, SHIFT-RETURN, two RETURNS, \r\n and UTF-8 codes. They all either got ignored or copied as entered to the output message. Here’s an example. I just want to put a divider after the wrap_message main text. > > The From address of this message has been replaced with the list > address, while the From name has 'via list' appended. Please be > careful when using 'via list' addresses later for new emails, as they > will be sent to the whole list.\r\n -------------------------- > ----------------------------------------------------------------------\r\n > From: Allan Hansen <allan_hansen(a)icloud.com <mailto:allan_hansen@icloud.com>> > Subject: [Testlist] wrap with divider and BLANKLINE > > Which coding option am I missing? I have searched for one online. I assume you are entering your text in Postorius in the DMARC wrapped message text box. There are a number of things going on here. Postorius is wrapping and filling the text and stripping trailing whitespace. If you want more whitespace, I suggest following your text with one or more empty lines and a single dot as in The From address of this message has been replaced with the list address, while the From name has 'via list' appended. Please be careful when using 'via list' addresses later for new emails, as they will be sent to the whole list. ------------------------------------------------------------------- . In the above, the blank lines before and after the line of dashes will be preserved as will the final dot which should be unobtrusive enough. More importantly, the rendering of the received message is up to your mail client. Your's apparently begins the wrapped message immediately after the wrapper's text, but many will not do that. Unless you actually view the received message in every mail client used by your user's, you won't know what they actually see. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

[MM3-users] Re: templates

by Mark Sapiro

On 5/5/23 17:04, Christian via Mailman-users wrote: >>From bounce.log > > May 05 07:59:00 2023 (765) Member juliankrauspolk(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 07:59:00 2023 (765) Member juliankrauspolk(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:01:00 2023 (765) Member baronchadg(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 08:01:00 2023 (765) Member baronchadg(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:11:01 2023 (765) Member vortexanthony(a)hotmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 1. > May 05 08:13:01 2023 (765) Member alaitz.aritza(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 08:13:01 2023 (765) Member alaitz.aritza(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:15:01 2023 (765) Probe bounce received for member > juliankrauspolk(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:01 2023 (765) Disabling delivery for juliankrauspolk(a)gmail.com > on list degrowcali.lists.ccalternatives.org by bounce > May 05 08:15:02 2023 (765) Probe bounce received for member > alaitz.aritza(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:02 2023 (765) Disabling delivery for alaitz.aritza(a)gmail.com on > list degrowcali.lists.ccalternatives.org by bounce > May 05 08:15:02 2023 (765) Probe bounce received for member > baronchadg(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:02 2023 (765) Disabling delivery for baronchadg(a)gmail.com on > list degrowcali.lists.ccalternatives.org by bounce > May 05 08:17:02 2023 (765) Residual bounce received for member > juliankrauspolk(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:17:02 2023 (765) Residual bounce received for member > alaitz.aritza(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:17:02 2023 (765) Residual bounce received for member > baronchadg(a)gmail.com on list degrowcali.lists.ccalternatives.org. So some of your user's, but not 24, are bouncing. If your list's bounce processing settings have Notify owner on disable = Yes, the owner should receive a notice including the DSN. If Notify owner on bounce increment = Yes, the owner will also get notices when a user's score is incremented as for vortexanthony(a)hotmail.com above. This still doesn't answer the other users. Have you looked at the MTA logs? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 4 months

[MM3-users] Re: import21 caused a few mails to be sent out

by Mark Sapiro

On 6/2/24 7:57 AM, Marc SCHAEFER wrote: > Hello, > > After importing a (big > 3000 subscribers) list with import21, I noticed the > following: > > 36 mails went out from LIST-NAME-bounces to subscribers, but they > apparently all bounced. > > Could those be subscribers that Mailman2 saw bouncing and added > the appropriate flag, and Mailman3 sent a probe after the import21? These are probably not probes. They are probably Bounce disable warnings. > I checked for one of the e-mail address and: > > Mailman2: > - that e-mail has the [X] R flag for "noncourriel" (no delivery) > > Mailman3: > - that e-mail is Delivery mode Regular, Bounces to 0 import21 will set an imported members delivery_status to the corresponding MM 2.1 delivery_status. If an imported member's 2.1 delivery status is nomail with reason unknown, by_user, by_moderator or by bounces (in French these are ?, U, A, R respectively), the MM 3 delivery_status will be set accordingly. This is not Delivery Mode, it is Delivery status which is not shown on the membership list, but only by clicking the user's email in the membership list. > NB: in MM2 and MM3, all users are in Hold for moderation, that's > normal. > > In addition, there are a few mails in /var/lib/mailman/messages > for example that same user: one file, showing a bounce from a remote > server. > > So my questions: > > 1) is this behaviour to "probe" already disabled addresses normal, and > not "port over" the "don't deliver"? No, if a MM 2.1 user's delivery was disabled, it will be imported as such. > 2) why are those messages held in messages/ ? Bounce DSNs are saved in the message store (/var/lib/mailman/messages) so they can be attached to admin notifications. > 3) should I then, before running import21, clean the MM2 installation > of all those users with [X] R flag? If yes, is there > a simple command? That should not be necessary. MM 2.1 users with nomail "R" (in French) should be imported with delivery_status = DeliveryStatus.by_bounces and they should not be sent mail except for the periodic Bounce disable warnings which is probably what you are seeing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 3 months

[MM3-users] Re: Subscription issue with ghost confirmations

by Brian Carpenter

On 10/29/20 12:21 PM, Mark Sapiro wrote: > On 10/29/20 8:51 AM, Brian Carpenter wrote: >> On 10/29/20 11:33 AM, Mark Sapiro wrote: >>> The real question is if a user has a subscription waiting confirmation >>> and the policy is changed to moderate, is a second request rejected >>> because of the request waiting confirmation. If so, I think this is a >>> bug which should be fixed. >>> >> Do you think this is a bug with Mailman core or my system? > > If the current policy is moderate and the user has a prior request > waiting confirmation and a new request is rejected because of the prior > request waiting confirmation, I think that is a bug in core, but I don't > know if that is the case or not. I think it is a bug in Mailman 3 core. I am seeing the same behavior on my Postorius server. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 10 months

[MM3-users] Re: slow restart time for mailmanweb

by David Newman

On 12/28/21 1:20 PM, Mark Sapiro wrote: > It looks to me like the timeout is in stopping, not starting. What > happens if you separately > > systemctl stop mailmanweb > > and > > systemctl start mailmanweb Confirmed: root@myhost:/etc/mailman3# time systemctl stop mailmanweb real 1m30.239s user 0m0.010s sys 0m0.004s root@myhost:/etc/mailman3# time systemctl start mailmanweb real 0m0.012s user 0m0.011s sys 0m0.001s On 12/28/21 3:01 PM, Mark Sapiro wrote: > Is your /etc/systemd/system/mailmanweb.service the recommended one at > https://docs.mailman3.org/en/latest/install/virtualenv.html#automatically-s… Yes, modulo the use of MariaDB instead of PostgreSQL. > If so, try adding > > KillSignal=SIGQUIT > > to the Service section and see if that fixes it. root@myhost:/etc/mailman3# time systemctl restart mailmanweb real 0m1.026s user 0m0.008s sys 0m0.004s My limited understanding of SIGQUIT is that it dumps core, but 'find / -type f -name '*.core' did not return any core dumps from this event. Still unsure why the service hung on stop, but thanks! dn

3 years, 8 months

[MM3-users] Re: Notifying owners of membership changes but not moderators

by Perry Kollmorgen

Thanks Mark, I will give it a shot. — Perry > > On Nov 28, 2024 at 9:12 AM, <Mark Sapiro (mailto:mark@msapiro.net)> wrote: > > > > On 11/26/24 9:30 PM, Perry Kollmorgen wrote: > > For the code for moderators it currently only adds them: > > mailing_list.add_moderator(moderator.email, display_name=moderator.display_name) > > Would I need to add something similar which sets a delivery_status for the moderator added ? I think something like this ``` mailing_list.add_moderator(moderator.email, display_name=moderator.display_name) moderator = mailing_list._get_membership(moderator.email, 'moderator') prefs = moderator.preferences prefs['delivery_status'] = 'by_moderator' prefs.save() ``` -- 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 pcjkollmorgen(a)hotmail.com > >

9 months, 2 weeks

[MM3-users] Re: Mailman Header Behavior

by Samir Faci

Perfect, Thanks. Is there a way to set this as a default for all new lists being created? Still working on the new styles, I imagine that can be set there during the selection of the list type. -- Samir Faci On Fri, May 15, 2020 at 9:44 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/15/20 9:31 AM, Samir Faci wrote: > > > > Is there a way to force mailman to ensure that the list name shows up in > > the from field? > > In Postorius Settings -> DMARC Mitigations set DMARC mitigation action > to Replace From with list address and set DMARC Mitigate unconditionally > to Yes. > > -- > 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/ > -- Thank you Samir Faci https://keybase.io/csgeek

5 years, 3 months

[MM3-users] Re: moving lists to another server

by Mark Sapiro

On 11/17/23 00:51, Odhiambo Washington wrote: > I am scratching my head bald trying to figure out how to bring in this > other MM3 site and list into my existing server, especially with regard to > the DB backend. > > The list - let's call it users(a)domainX.name was using MySQL backend and > had a separate DB for Mailman core and Mailman web. > I believe combining these into one isn't a problem. But getting to merge > this DB into my current one is what I am not sure about. This is https://gitlab.com/mailman/postorius/-/issues/13 which is a real need, but doesn't yet exist. I think the easiest thing for the archives is to forget the Mailman web DB and just export the archive as a mbox from the other site (if it's large, exporting the entire archive will time out so you have to do it in pieces). Then you can use hyperkitty_import to import it. For the list data, it's probably easiest to just create the list manually and go through the settings in Postorius and make them match, although you could dump the mailinglist table entry where list_id = 'users(a)domainx.name' and load that, but you'd need to edit the id field in the dump to match the id on your server. That leaves the members. Doing this with a DB dump/load would be very complex because while the member table has a list_id field which is the id of the list's entry in the mailinglist table and can be used to select the relevant members, these records also link to entries in the address, preferences and user tables and matching them would be an issue. I think a custom script would be required. If I were doing this, I would make a separate database on my server with a copy of the data from the other server and then try to make a script that would extract data from the other database and add it to mine. Alternatively you could just dump the members from the other servers with the `mailman members` command perhaps separately for regular and the different digest types and then add them with the `mailman addmembers` command. This wouldn't get all their attributes, but it could work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[MM3-users] Re: Disable Sign-up per domain

by Mark Sapiro

On 7/31/25 17:54, Mark wrote: > > Thank you Mark. It's so close. After wrangling your solution a bit it's > working a treat on my test server (wrangled solution below) . > > When I add it to the production server (same OS, MM installation, etc) > I'm getting a "Bad gateway" error page and the log reports ... > > ... > raise self.model.DoesNotExist( > django.contrib.sites.models.Site.DoesNotExist: Site matching query does > not exist. That error will occur when settings.py contains SITE_ID = 0 and the host in the http request is not one of the hosts in the django_site table in the database or in Sites in the Django admin web UI. Is that possibly the case here? In any case, if the change to /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py that you report below is the only thing that changed from a working installation, I don't see how that can affect this. Is there a complete traceback preceding the log snippet you report. If so, what is it? > I cannot for the life of me get my head around that. I suspect it's > something to do with what you said -- "whatever is proxying to Django > setting the appropriate HTTP_HOST header." -- which I don't understand. This is in the configuration of the web server. It should be configured to pass the host of the incoming request to the proxy target in the HTTP_HOST header. In nginx this is `proxy_set_header Host $host;`. In apache it is `ProxyPreserveHost On`, but again the change to user_adapter shouldn't affect this. > Any additional advice gratefully received. > > > ================================== > /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py > ================================== > COMMENT OUT THESE 2 LINES... > > # def is_open_for_signup(self, req): > # return False > > REPLACE WITH THE FOLLOWING... > > def is_open_for_signup(self, req): > if req.META['HTTP_HOST'] == 'lists.mydomain.com': I had if req.META.HTTP_HOST == 'lists.mydomain.com': which as you discovered is wrong. What you have is correct. > return False > else: > return True And here I had return super().is_open_for_signup(self, req) which should return the is_open_for_signup result from allauth.account.adapter.DefaultAccountAdapter but since that result is an unconditional True, what you have is OK too. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month, 1 week

Search results for query "sapiro"