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

[MM3-users] Re: integrating mm3 with postfix / lmtp

by Fabian A. Santiago

On October 25, 2017 9:13:20 PM EDT, Mark Sapiro <mark(a)msapiro.net> wrote: >On 10/25/2017 05:41 PM, Fabian A. Santiago wrote: >> >> No to the domains part and I think virtual alias maps is needed: >> >> mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx >in BOTH virtual_mailbox_domains and relay_domains >> Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not >list domain xxx in BOTH virtual_mailbox_domains and relay_domains >> Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: >reject: RCPT from >pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 ><test123@xxx>: Recipient address rejected: User unknown in virtual >mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP >helo=<[10.0.0.29]> > >(above slightly sanitized for return to the list) > >The issue here is your list domain cannot be a virtual_mailbox_domain >or >a virtual_alias_domain. > >I have the same issue on mail.python.org where we have both Mailman 2 >and Mailman 3 lists @python.org. and python.org is a >virtual_alias_domain. > >I have a group of MRs for a branch that implements "alias_domains" to >deal with this. > >Basically it works by creating another (virtual_alias_maps) >postfix_vmap >mapping to map list addresses @python.org to addresses @x.python.org. >Then the postfix_domains and postfix_lmtp maps have the x.python.org >domain and there is a patch to mailman/runners/lmtp.py to map the >x.python.org domain back to python.org. > >The various MRs are ><https://gitlab.com/mailman/mailman/merge_requests/202> for the core, ><https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the >REST bindings used by Postorius and ><https://gitlab.com/mailman/postorius/merge_requests/186> to be able to >set an alias_domain via Postorius. > >That's not all implemented at mail.python.org. What's there is the >basic >Postfix config, a bash script the generate the new mappings from the >old >and a simple patch to mailman/runners/lmtp.py. > >So, the bottom line is it can be done and it's in process, but it won't >really be supported until Mailman 3.2. In the mean time, you just need >to have a separate domain for your lists that isn't a virtual_*_domain. Ok thanks. At least I have a clear answer now. Any ETA on 3.2 in mind yet? -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

7 years, 10 months

[MM3-users] Re: Sending a message to a subscription applicant when a subscription request is made

by Allan Hansen

Much appreciated, Mark. We'll go with (a.), as it's a one-liner as I expected, and it does not require me to change the policy. I'll just need to make some adjustments to the template contents. Yours, Allan On 3/28/23, 11:29, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: On 3/28/23 10:45, Allan Hansen wrote: > > a. That we change the lines in the Python program in our installation that send 'list:admin:action:subscribe' to the list admins to instead send the template to the applying subscriber. This patch will do that --- a/src/mailman/app/subscriptions.py +++ b/src/mailman/app/subscriptions.py @@ -338,7 +338,7 @@ class SubscriptionWorkflow(_SubscriptionWorkflowCommon): # This message should appear to come from the <list>-owner so as # to avoid any useless bounce processing. msg = UserNotification( - self.mlist.owner_address, self.mlist.owner_address, + self.address.email, self.mlist.owner_address, subject, text, self.mlist.preferred_language) msg.send(self.mlist) # The workflow must stop running here. Watch for wrapped lines. Note that this only works if Admin immed notify is Yes. > b. That we change the lines in the Python program in our installation that send 'list:user:action:subscribe' to the subscriber with an unverified address to always do this, even when the incoming address has already been verified. I think this patch will do it, but needs testing --- a/src/mailman/app/subscriptions.py +++ b/src/mailman/app/subscriptions.py @@ -285,7 +285,7 @@ class SubscriptionWorkflow(_SubscriptionWorkflowCommon): # If we do not need the user's confirmation, then skip to the # moderation checks. if self.mlist.subscription_policy is SubscriptionPolicy.moderate: - self.push('moderation_checks') + self.push('send_confirmation') return # If the subscription has been pre-confirmed, then we can skip the # confirmation check can be skipped. If moderator approval is Again watch for wrapped lines. -- Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/NNMWW4PW55H4OLA3NTAKZLRNIEV2HHUA/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

2 years, 5 months

[MM3-users] Re: Permission denied for fulltext_index

by Jan Eden

On 2022-11-30 10:22, Mark Sapiro wrote: > On 11/30/22 08:41, Jan Eden via Mailman-users wrote: > > > > Changing the PATH value to a full path (/opt/mailman/fulltext_index) > > and restarting mailman-web generates a different error: > > > Yes, it should be a full path. I encountered yet another problem with emails not getting archived anymore: > ERROR 2022-12-01 09:18:00,111 1337915 hyperkitty.views.mailman Access to the archiving API endpoint was forbidden from IP XXX.XXX.XXX.XXX, your MAILMAN_ARCHIVER_FROM setting may be misconfigured where XXX.XXX.XXX.XXX is my server's public IP. This was probably caused by the switch to uwsgi_pass/a file socket, and could be fixed by adding MAILMAN_ARCHIVER_FROM = ('XXX.XXX.XXX.XXX', '::1') to /etc/mailman3/settings.py. > > > ERROR 2022-11-30 16:38:37,953 1028315 django.request Internal Server Error: /archives/list/testing@lists.eden.one/thread/T6MCILAVQYV5QIOGHJB3JNJ26Z7E2Z35/reattach-suggest > > > Traceback (most recent call last): > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner > > > response = get_response(request) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response > > > response = wrapped_callback(request, *callback_args, **callback_kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner > > > return func(request, *args, **kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py", line 454, in reattach_suggest > > > sugg_thread = msg.object.thread > > > AttributeError: 'NoneType' object has no attribute 'thread' > > > This says that searching the archive for this list for messages matching the > current message subject returns None. It is probably a bug that we don't > test for this, but what exactly are you doing? > See the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > for the only way I've been able to create an error like this. There are currently 5 (test) threads in the archive. After changing the PATH in the HAYSTACK_CONNECTIONS dict to /opt/mailman/fulltext_index, and fixing the issue with MAILMAN_ARCHIVER_FROM above, /opt/mailman/web/logs/mailmanweb.log does not display new error messages, but I do not get any suggestions for reattaching threads, and a search for a specific thread subject ("Third test") does not return any results. So reattachment works in principle, but the suggest/search function does not. - Jan

2 years, 9 months

[MM3-users] Re: Errors while importing mm2 list archives - SOLVED

by Odhiambo Washington

On Tue, Dec 20, 2022 at 8:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/20/22 06:48, Odhiambo Washington wrote: > > > > There is a WARNING on > > > https://docs.list.org/en/latest/install/virtualenv.html#virtualenv-install > > which says one must create the config file as /etc/mailman3/mailman.cfg > > How to force mailman to read that file is something I haven't understood, > > but turns out to be what has taken me days trying to get things right. > > > If you run the `mailman` command without any -C option, it will look for > a config in /etc/mailman3/mailman.cfg > In my case, running `mailman` without any arguments just makes it grok :) (venv) [mailman@gw ~/mm]$ mailman info GNU Mailman 3.3.7 (Tom Sawyer) Python 3.9.15 (main, Dec 6 2022, 09:25:59) [Clang 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a *config file: /opt/mailman/mm/mailman.cfg* db url: mysql+pymysql://mailman_user:XXXXXXXX@localhost /mailman3db?charset=utf8mb4&use_unicode=1 devmode: DISABLED REST root url: https://localhost:8001/3.1/ REST credentials: restadmin:restpass (venv) [mailman@gw ~/mm]$ mailman Usage: mailman [OPTIONS] COMMAND [ARGS]... The GNU Mailman mailing list management system Copyright 1998-2018 by the Free Software Foundation, Inc. http://www.list.org Options: --version Show the version and exit. --run-as-root Running mailman commands as root is not recommended and mailman will refuse to run as root unless this option is specified. -C, --config FILE Configuration file to use. If not given, the environment variable MAILMAN_CONFIG_FILE is consulted and used if set. If neither are given, a default configuration file is loaded. -h, --help Show this message and exit. .... > Ultimately, when I did the import, there was only one email from the > > archives that failed to be imported - which I honestly don't mind, but > > maybe there is a solution for this > > "'utf-8' codec can't encode character '\udcae' in position 331: > surrogates > > not allowed" ?? > > > If you provide a copy of that message from the mbox, either on the list > or to me directly, I'll investigate. > A mbox file containing that email and the associated thread can be downloaded from here: https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 8 months

[MM3-users] Re: Turn off social logins?

by Abhilash Raj

This is kind of a top-post, because I am not sure which message should my reply quote. Please excuse that part. My thinking on this topic resonates with what Steve said, I don't think we should be forcing the Mailman Administrators to handle username passwords. Dare I say that most social auth providers have more incentive and money to keep their database secure than Mailman Administrators. Having said that, it doesn't have to be either or between "social logins enabled by default" and "I don't want to see a Facebook button". I have actually thought about this before, but never have been able to get to it. I opened an issue too but can't find it right now. Anyway, so the idea is that most social providers need some soft of configuration from the Admin. Today, we enable them by default, but they don't work by default. I think we could make both sides happy if we were to just not show the social providers that aren't configured. What do others think? Only two providers that I know of in Mailman's default list, which don't need any configuration, are Fedora and OpenID. I am happy to remove OpenID from default since I have never been able to actually get that to work. I am okay with removing Fedora too, which is a special case in Mailman 3 because of fedoralists.org being the first customer for Mailman 3 and Hyperkitty. I don't have cycles to do that myself right now, so I would encourage people to step up to tackle this. I would obviously help them out with any Python, Mailman or Django related questions they might have. Now, about the ease of being able to disable social logins, I think it should be possible to disable social logins with just a boolean flag in settings. Why haven't we done it yet? We didn't need to. What we provided was a **sample configuration**, with a huge emphasis on sample. We weren't maintaining it as an official set of configurations, but just something that one could use as a starting point. But that obviously didn't happen since people just downloaded and used it, some of which is ofc my own fault since the official docs doesn't say that what precisely you should be worried about changing from the sample. The beauty (and ugliness) of Django's settings.py is that it is Python. We can disable social login if your CPU heats up[1], or if the stock price of the company goes below (or above? :P) a threshold, or heck, if the network firewall detects a packet heading out to their servers. How Django's configuration works has been left kind-of open by the Django devs themselves, making every downstream project handle their own use case separately. We chose to just go with what was provided out of box, but that doesn't mean we can't do any better. We can do ini-style configs, it gets a tad bit complicated when there are unknown Python data structures that can't easily be represented in ini-style. We could do YAML, which supports more complicated data structures (nested maps and lists). OR, we could do JSON, but I find that less human readable. Next topic, people worrying about customizing settings in settings_local.py and worrying about not getting newer updates. Isn't this how rest of the packaging and configuration world works? If you customize the `/etc/postfix/main.cf` you don't get the updates to default config (apt asks you, but you will choose not to update with your custom settings, right?) when you upgrade your postfix package from Debian and you need to pull in any new settings that package supports manually. I have been (silently) working[2] on making the `mailman_suite` project a Python package (mailman3-web), like the Debian Maintainers did. That would be the right place to put whatever configuration logic we want to expose to our users. We can move to a model where you'd import all the settings from `mailman3_web.settings.base` and then customize all the fields that you do care about. But there will be downsides to it, like us updating a setting that changes the behavior of an already working site, and we can sure document those changes in release notes in big bold letters, but I still worry there will be people running `pip install -U` without thinking what does that even mean. I don't know what should we do? What do other people managing configurations do? Maybe Debian Maintainers can chime in here? [1]: https://xkcd.com/1172/ [2]: https://gitlab.com/maxking/mailman-suite/commits/master On Fri, Feb 15, 2019, at 8:43 AM, Mark Sapiro wrote: > On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > > Torge Riedel writes: > > > > > - there is a way to do this now via settings_local.py, but feels > > > a little bit risky if default configuration changes on update of > > > mailman > > > > This should not be true. If it is, we need to fix that. Will check. > > > It is more or less true. The issue is that unlike mm_cfg.py and > Defaults.py in Mailman 2.1, the recommended way to set up Django in > Mailman 3 is to point Django at settings.py for the default config, and > the last thing in settings.py is > > try: > from settings_local import * > except ImportError: > pass > > Thus,the only way settings_local.py can change something like > INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which > leads to the possibility of INSTALLED_APPS changing in settings.py and > those changes not being picked up in settings_local.py. > > The way around this is to remove the import of settings_local from > settings.py and then put > > from settings import * > > at the beginning of settings_local.py and then point Django at > settings_local rather than settings. > > Then you can do things like > > try: > INSTALLED_APPS.remove('allauth.socialaccount.providers.google') > except ValueError: > pass > > in settings_local.py except there are still issues because, e.g., > INSTALLED_APPS is defined as a tuple (immutable) and not a list in > settings.py. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

6 years, 7 months

[MM3-users] Re: Default values for lists in Mailman 3

by Markus Grandpré

Thank you very much for your answer. Best regards, Markus Am 19.09.24 um 22:03 schrieb Mark Sapiro: > On 9/19/24 05:46, Markus Grandpré wrote: >> Dear list, >> >> I would like to activate the invitation setting for all lists as >> default. In Mailman 2.1 I have done this in the file </etc/mailman/ >> mm_cfg.py>: >> >> >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> >> >> How can I do this in Mailman 3? > > There is a draft merge request at https://gitlab.com/mailman/ > postorius/-/merge_requests/930 which implements a framework for setting > Postorius defaults and creates a setting to set the default for pre- > verified on the mass subscription page. Once merged, this can easily be > extended to provide a default for Invitation. > > In the mean time, you can only do this by patching src/postorius/forms/ > list_forms.py like > ``` > --- a/src/postorius/forms/list_forms.py > +++ b/src/postorius/forms/list_forms.py > @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): > > invitation = forms.BooleanField( > label=_('Invitation'), > - initial=False, > + initial=True, > required=False, > help_text=_( > 'If checked, the other checkboxes are ignored and the > users will ' > ``` >> Can I also transfer other default values like: >> >> ... >> DEFAULT_SERVER_LANGUAGE = 'en' >> DEFAULT_SEND_REMINDERS = 1 >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> DEFAULT_PRIVATE_ROSTER = 2 >> DEFAULT_ARCHIVE = Off >> DEFAULT_ARCHIVE_PRIVATE = 1 >> ... >> >> from the very same configuration file to Mailman 3? Is there a >> documentation of the default values for lists in Mailman 3? > > This is done by creating a list style with the desired defaults. See > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/ > docs/styles.html for documentation of styles and see https://gitlab.com/ > mailman/example-mailman-plugin for an example of creating a plugin in > Mailman core to make a persistent style. > > There is no specific doc for the list settings. You need to look at > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/ > base.py for the various settings and https://gitlab.com/mailman/ > mailman/-/blob/master/src/mailman/styles/default.py to see which default > classes are applied for various styles. > -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

11 months, 3 weeks

[MM3-users] Re: Issues with @gmail.com addresses

by Allan Hansen

Once this gets handled, Mohsen, Google has another issue with list servers: If a subscriber who uses GMail posts a message to a list, then that subscriber will not get his/her own message from the server - Google eats it. All other subscribers will get it, but not the author. My subscribers run into this all the time and are up in arms over it. I tell them to complain to Google. Yours, Allan On 9/5/23, 13:18, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: 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 <mailto:xxxx@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 <mailto:mark@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 <mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/WZY5IC3OVHVBHIGDT4TE3EWSSGMF6CYI/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

2 years

[MM3-users] Re: spanish localization

by Victoriano Giralt

On Fri, 2021-02-12 at 09:04 +0100, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > On 11/2/21 20:15, Mark Sapiro wrote: > > On 2/11/21 3:47 AM, Guillermo Hernandez (Oldno7) via Mailman-users > > wrote: > > > I contributed in january to translate to spanish all the items > > > left in > > > Mailman Core, Django-mailman, HyperKitty and Postorius via > > > Weblate. I > > > thought they will be used in the next upgrade, but I cannot see > > > any > > > improvement and there are many words untranslated. > > > > The Spanish translations for Mailman core and HyperKitty are > > currently > > completely up to date with weblate. django-mailman3 differs in one > > string that was translated on Feb 10 and hasn't yet been merged. > > Postorius also differs in a few places from the Feb 10 version that > > hasn't yet been merged. > > Ok. Thanks for checking it. I put my little contribution in Weblate > and I like that it could be used by anyone. Actually, I was going to ask these same questions, because I dedicated some hours to get the Spanish translation nearly finished, it was kind of a "spiritual" need for me, being the person that seeded the efforts for Mailman i18n support back in the late '90s :-) :-) > I tried to run this using the same command as I did for the > "collectstatic" (that solved all my previous problems for the > upgrade) > and "migrate" runs but it shows me an error: > > su -m mailman3 -c "python3 manage.py compilemessages" > CommandError: This script should be run from the Django Git checkout > or your project or app tree, or with the settings module specified. I got this very same error, and was also confused, as manage.py runs at the project level, not application level. > I'm lost. Do not feel bad, Guillermo, an old time pythonist with message translations experience, that uses i18n for some of his applications, is also dazzled and confused :-) Confused-with-translations-ly, Victoriano. -- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

4 years, 7 months

[MM3-users] Re: user mail not accepted

by Christian Stalberg

From smtp.log Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'DATA' Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'QUIT' Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) connection lost Apr 26 00:17:39 2021 (807) Connection lost during _handle_client() Apr 26 00:18:11 2021 (809) <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> smtp to ncpoa(a)lists.ccalternatives.org for 83 recips, completed in 29.13376259803772 seconds Apr 26 00:18:11 2021 (809) <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> post to ncpoa(a)lists.ccalternatives.org from christian(a)ncboliviapartners.org, 5811 bytes Apr 26 00:18:11 2021 (809) <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> smtp to ncpoa(a)lists.ccalternatives.org for 1 recips, completed in 0.0420069694519043 seconds Apr 26 00:18:11 2021 (809) <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> post to ncpoa(a)lists.ccalternatives.org from ncpoa-bounces(a)lists.ccalternatives.org, 869 bytes Apr 26 11:52:22 2021 (819) <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in 0.22335004806518555 seconds Apr 26 11:52:22 2021 (819) <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> post to ssan(a)lists.ccalternatives.org from ssan-bounces(a)lists.ccalternatives.org, 765 bytes Apr 26 11:52:22 2021 (819) <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in 0.05862092971801758 seconds Apr 26 11:52:22 2021 (819) <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> post to ssan(a)lists.ccalternatives.org from noreply(a)lists.ccalternatives.org, 810 bytes Apr 26 11:55:22 2021 (819) <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in 0.1459965705871582 seconds Apr 26 11:55:22 2021 (819) <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> post to ssan(a)lists.ccalternatives.org from ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternatives.o rg, 1526 bytes Apr 26 12:01:30 2021 (817) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Apr 26 12:01:30 2021 (817) Peer: ('127.0.0.1', 38556) Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) handling connection Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'LHLO zarathustra.ccalternatives.org' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'MAIL FROM:<christian(a)sewagesludgeactionnetwork.com>' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) sender: christian(a)sewagesludgeactionnetwork.com Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'RCPT TO:<ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternativ es.org>' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) recip: ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternatives.o rg Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'DATA' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'QUIT' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) connection lost Apr 26 12:01:30 2021 (817) Connection lost during _handle_client() Apr 26 12:01:34 2021 (819) <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in 0.06680631637573242 seconds Apr 26 12:01:34 2021 (819) <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> post to ssan(a)lists.ccalternatives.org from noreply(a)lists.ccalternatives.org, 821 bytes Apr 26 12:01:34 2021 (819) <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in 0.04269862174987793 seconds Apr 26 12:01:34 2021 (819) <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> post to ssan(a)lists.ccalternatives.org from ssan-request(a)lists.ccalternatives.org, 1335 bytes Message sent that only the user receives: Return-Path: <christian(a)sewagesludgeactionnetwork.com> Delivered-To: ces(a)ecovillage.cc Received: from box.ecovillage.cc ([127.0.0.1]) by box.ecovillage.cc with LMTP id MDucNBythmCTSwAAMoO61A for <ces(a)ecovillage.cc>; Mon, 26 Apr 2021 05:07:56 -0700 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on box.ecovillage.cc X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain X-Spam-Score: -1.1 Received: from authenticated-user (box.ecovillage.cc [45.79.28.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by box.ecovillage.cc (Postfix) with ESMTPSA id 6EADF3E8CC for <ssan(a)lists.naturalintelligence.us>; Mon, 26 Apr 2021 05:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sewagesludgeactionnetwork.com; s=mail; t=1619438876; bh=1M7F/uIS0bNG6cWjecy/a9QjskrHVwJHkjWRv+ffpM4=; h=From:To:References:In-Reply-To:Subject:Date:From; b=jXOswVZgFeHBB+sjIDqVkNBQqIbfZCj9ZUfpVwl10NQEkGaoxckPHNOKT6x9zIqsW BZ7iZqqi2mWprVQ8LrK48Lp7gvCQ/ipqspMeLt3t+uljzTtryHmV6uJFEAU3hqM33Y nQqX6Z8la8Ko40F9Ayb4h4e/MOfPdA4nadgf5hZzt/DzPFZvzUbG3V8lWcHuyJNA2y SQkhbNubQ6iNEEB0SyBjoOjl3g3LVxjxY+9kMGGmX+1PFfW90CpDDShRmKkkscEWaA NiV0fX6U5LENBBnc6Q9ImLgXuaLdCqlBRBumJBk+eUUr007rpXXVAPck2NvUzGyM2v kNNGlT68hGzEg== From: <christian(a)sewagesludgeactionnetwork.com> To: <ssan(a)lists.naturalintelligence.us> References: In-Reply-To: Subject: How US chemical industry lobbying and cash defeated regulation in Trump era Date: Mon, 26 Apr 2021 05:07:37 -0700 Message-ID: <020501d73a94$cbe17440$63a45cc0$(a)sewagesludgeactionnetwork.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0206_01D73A5A.1F831170" Thread-Index: Adc6h7I/qzBKx1yOT6aPOuipppacoQACatZAAADW1wA= Content-Language: en-us How US chemical industry lobbying and cash defeated regulation in Trump era Industry's congressional allies defeated nearly all PFAS legislation while the Trump EPA killed, watered down or slowalked new rules https://www.theguardian.com/environment/2021/apr/26/us-chemical-companies-lo bbying-donation-defeated-regulation -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, April 26, 2021 2:05 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user mail not accepted On 4/26/21 5:16 AM, Christian Stalberg via Mailman-users wrote: > I have a user whose moderation rule is 'Accept immediately' yet when > they send a message for distribution to the list, they only receive it > and it is not distributed via the list. Logfile entries below. Please > advise. Btw I have another list on this same instance which is running fine. Thank you. > > [26/Apr/2021:12:06:25 +0000] "GET > /3.1/lists/ssan.lists.ccalternatives.org > HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:25 +0000] "POST > /3.1/members/find?list_id=ssan.lists.ccalternatives.org&subscriber=chr > istian %40sewagesludgeactionnetwork.com HTTP/1.1" 200 1257 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:25 +0000] "PATCH > /3.1/members/7186cd45bde34d4fa7e7b5ab36b97272 HTTP/1.1" 204 0 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan.lists.ccalternatives.org > HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "POST > /3.1/members/find?list_id=ssan.lists.ccalternatives.org&subscriber=chr > istian %40sewagesludgeactionnetwork.com HTTP/1.1" 200 1288 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan(a)lists.ccalternatives.org/requests/count?token_owner=mo > derato r HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan(a)lists.ccalternatives.org/held/count HTTP/1.1" 200 73 "-" > "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/members/7186cd45bde34d4fa7e7b5ab36b97272/preferences HTTP/1.1" > 200 295 "-" "GNU Mailman REST client v3.3.2" These entries don't tell anything about a post to the list. They are all from Mailman's REST API relating to Postorius interactions with core. However the absence of messages like Apr 26 07:32:39 2021 (17860) ACCEPT: <message_id> and Apr 26 07:32:41 2021 (17857) HyperKitty archived message <message_id> to https://example.com/archives/list/list_adderss/message/message_id_hash/ assuming you are looking at the correct time span, says there wasn't an accepted list post. Mailman's smtp.log may have more info, but the complete, raw message that the user receives may be more helpful. -- 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/

4 years, 4 months

[MM3-users] Re: Problems after upgrading from bullseye to bookworm

by Odhiambo Washington

The virtualenv documentation works just fine with Bookworm AFAICT. I didn't need to do anything out of the documentation in my test VM. On Tue, 27 Jun 2023, 18:04 Eggert Ehmke via Mailman-users, < mailman-users(a)mailman3.org> wrote: > Hello Mark, > > thank you. I did change that entries, and now my mailman runs fine on > Debian Bookworm. > > I did a complete reinstall of the venv directory to have a clean start. > Maybe this was not > needed. What's missing in the documentation: > -the directiories web/logs have to be created manually with the ownership > mailman. > -The debian package pkg-config must be installed. > -the package psycopg2-binary can/must be installed without version > restriction on > Bookworm > Maybe this info helps some other people. > > Cheers, Eggert > > Am Montag, 26. Juni 2023, 22:22:37 CEST schrieb Mark Sapiro: > > On 6/26/23 12:35 PM, Ken Alker wrote: > > > I'm brand new to this, so take this with a grain of sale, but, I had a > > > similar problem a few days ago, however, mine was "flufl.i18n>=3.2". > > > Perhaps the same thing is happening with flufl.lock (but that didn't > bite > > > me). > > > > > > I solved my problem by following this: > > > <https://gitlab.com/mailman/mailman/-/issues/1085> and, ultimately > > > modifying > > > > "$VENV_ROOT/lib/$PYVERSION/site-packages/mailman-3.3.8.egg-info/requires. > > > txt" per that thread (see > > > <https://gitlab.com/mailman/mailman/-/issues/1085#note_1442207929> by > > > Thomas Ward section called "The WORKAROUND"). Maybe you need to do the > > > same thing, but for flufl.lock. > > Yes, the same issue now affects flufl.lock as well as flufl.i18n. You > > will need to change both flufl.lock->flufl_lock and > flufl.i18n->flufl_i18n. > > > > ___________________________________________ > Mailman's content filtering has removed the > following MIME parts from this message. > > Replaced multipart/alternative part with first alternative. > _______________________________________________ > 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 odhiambo(a)gmail.com >

2 years, 2 months

Search results for query "sapiro"