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

[MM3-users] Re: DMARC DNS settings for MM3?

by Mark Sapiro

On 1/30/22 20:25, Jay Hamilton-Roth wrote: > Emails from our list are currently being blocked by Google & Yahoo because of the "Dmarc policy of the sender domain" (according to Google Postmaster). > > Our list doesn't do any munging for "Reply goes to list" and our DMARC Mitigations is set for "No DMARC mitigations" and we're not DMARC Mitigating unconditionally. > > Given this is our MM3 policy, it's not clear what the DMARC DNS policy should be for consistency (note: we currently don't have a DMARC DNS setting). > > MM3 documentation doesn't have enough info, and reading up on DMARC Records it's not clear if we should be: > > v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@ourdomain.com > > -or- > > v=DMARC1;p=quarantine;pct=100;ruf=mailto:postmaster@ourdomain.com > > -or something else- Have you seen https://wiki.list.org/DEV/DMARC ? Nothing you publish as a DMARC policy or SPF will affect the DMARC actions of recipient domains for list mail unless you set DMARC mitigations for your lists to make the mail be From: your domain. As long as you leave the From: intact, it is the DMARC policy of the From: domain that counts, and if you make any transformation at all to the message (content filtering, subject prefixing, munging Reply-To:, etc) you will break the From: domain's DKIM signature and DMARC will fail at the receiving MTA. As far as recommendations go, what we do for this list for example is we set DMARC mitigation action to Replace From with list address and DMARC Mitigate unconditionally to No. We publish SPF "v=spf1 mx a ~all" We publish DMARC "v=DMARC1\; p=none" and we DKIM sign all our outgoing mail. Our Python.org lists are similar except we publish DMARC "v=DMARC1\; p=none\; pct=100\; rua=mailto:rxxx@dmarc.postmarkapp.com\; sp=none\; aspf=r\;" because we've signed up with postmarkapp.com for their free reporting service. We do publish a DMARC policy and DKIM sign outgoing mail because we believe this helps mail delivery, but without DMARC mitigation action = Replace From with list address or Wrap the message ... it won't stop recipients from treating list mail as failing DMARC. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: hyperkitty failed to create a thread

by Mark Sapiro

On 2/11/19 10:01 AM, Abhilash Raj wrote: > > Please create a bug report at https://gitlab.com/mailman/hyperkitty/issues with the affected messages. > > It would help us recreate the problem if you could attach a raw messages in the issue. I am > assuming the messages aren't sensitive since the archive are open. Otherwise, feel free to omit > any sensitive information. > > I haven't looked at the threading code in HK since a long time, but my impression is that it > looks at the 'In-Reply-To' header to figure out if the current email is a response to a previous > email that it received. > > In some cases, the order of the incoming messages can cause this to break, like when the > reply comes in first and the original messages comes in later. I am not sure exactly what is > happening here, but looking at the raw messages should help us reproduce and possibly > fix the issue. I downloaded the February mbox from <https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/export/wlug@l…> and imported it to a test list with 'django-admin hyperkitty_import and see the same issue. Examination of the mbox shows for the first message Message-ID: < <SN6PR01MB4719346533C08BF4FF62B880C36C0(a)SN6PR01MB4719.prod.exchangelabs.com>> This will be wrapped, so here's an excerpt Message-ID: < <SN6....prod.exchangelabs.com>> Note the folding of the header and the double angle brackets. The next message has (again excerpted to avoid wrapping) Message-ID: < <BL0....prod.exchangelabs.com>> In-Reply-To: SN6....prod.exchangelabs.com Note again the doubling of the angle brackets in the Message-ID and the absence of angle brackets in the In-Reply-To: The Message-ID: and In-Reply-To: headers of subsequent messages have the same issues. In looking at other mboxes downloaded from Hyperkitty, I see that the absence of References: and the dropping of the angle brackets from In-Reply-To: seem to be usual, and importing such a mbox preserves the threading. However, the doubling of the angle brackets is not usual and is almost certainly the cause of the problem. Do you have any of the original messages? What do the headers look like in those? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 7 months

[MM3-users] Re: Upgrade

by Darren Smith

Boy howdy did that work... Thanks! On Mon, Apr 16, 2018 at 11:22 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 04/16/2018 10:12 AM, Darren Smith wrote: > > > "/opt/mailman3/conda/lib/python3.6/site-packages/ > sqlalchemy/engine/strategies.py", > > line 160, in create > > engineclass.__name__)) > > TypeError: Invalid argument(s) 'pool_pre_ping' sent to create_engine(), > > using configuration PGDialect_psycopg2/QueuePool/Engine. Please check > that > > the keyword arguments are appropriate for this combination of > components." > > > > Anyone able to point me where to go to look for a solution for this? > > > You need to update SQLAlchemy to >= 1.2 for this, but there is another > issue that requires at least 1.2.3 (current is 1.2.6) > > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

7 years, 4 months

[MM3-users] Re: Where does sender postorius@ come from?

by Jens Günther

Am 16.06.23 um 01:10 schrieb Mark Sapiro: > On 6/15/23 14:03, Jens Günther wrote: >> >> >> Am 15.06.23 um 00:34 schrieb Mark Sapiro: >>>> - Then I tried settings_local.py with: >>>> EMAIL_CONFIRMATION_FROM = 'myaddress(a)something.org' > > > Sorry, this is actually a different setting. There are actually two more > that control this. These are DEFAULT_FROM_EMAIL > <https://docs.djangoproject.com/en/4.2/ref/settings/#default-from-email> > and SERVER_EMAIL > <https://docs.djangoproject.com/en/4.2/ref/settings/#server-email>. Note > that the defaults mentioned in the Django docs are probably overridden > in your settings.py, but you should set them in settings_local.py Thank you Mark. I changed now DEFAULT_FROM_EMAIL to my address, restartet container and it works. Also it works if I delete the EMAIL_CONFIRMATION_FROM-line again and do not put the SERVER_EMAIL, at least for the password-reset. Can you tell the diffenrence between the 3? Would you recommend to set all 3 to my admin-mailaddress?

2 years, 2 months

[MM3-users] Re: Starting new thread in Postorius -> disappears

by Mark Sapiro

On 11/29/2017 05:05 PM, Cameron Smith wrote: > > On November 21, I sent the message below, as a part of this very thread, to Thor and cc’d the mailman 3 list. But the message never showed up in HyperKitty [1]. I don’t know if other list members received it in their email inboxes or not. Your post was received: Nov 21 14:31:20 mailman postfix/cleanup[15735]: 2B3798008D: message-id=<836BFAB0-4879-4EDF-9026-FEC17D4A2BEC(a)mail2.cetsi.com> Nov 21 14:31:20 mailman postfix/qmgr[20545]: 2B3798008D: from=<ccsmith(a)mail2.cetsi.com>, size=10048, nrcpt=1 (queue active) delivered to Mailman core: Nov 21 14:31:20 mailman postfix/lmtp[15737]: 2B3798008D: to=<mailman-users(a)mailman3.org>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.31, delays=0.28/0/0/0.02, dsn=2.0.0, status=sent (250 Ok) and immediately discarded: Nov 21 14:31:21 2017 (19106) DISCARD: <836BFAB0-4879-4EDF-9026-FEC17D4A2BEC(a)mail2.cetsi.com> > Thor obviously received the message (it was addressed to him directly), because he referenced it in a message that is in the archives [1]. However, I never received an email copy of his message from the list. Possibly you never received a list copy of his message because you were directly addressed and your list option "Receive list copies (possible duplicates)" is set to No. > So, what’s going on? As to why your post was discarded, unfortunately, the logs don't give more info. There are a couple of possibilities. If your post contained an attachment with Content=Type: application/subtype where sub-type doesn't contain 'signature' it would have been discarded by a header filter rule. Also it looks like you sent the message From: <ccsmith(a)mail2.cetsi.com>. If that is not an address on your <ccsmith(a)cetsi.com> account, it would have been discarded as a non-member post. > What baffles me is that more people are not complaining about this. Is it just that no one has noticed? Or is it some subtle misconfiguration in my system? And in Thor’s apparently. And maybe in the lists.mailman3.org system as well. I see nothing so far to indicate anything at lists.mailman3.org is broken in this respect. The only "unusual" thing is this is now a new thread <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>, but presumably that is because your post was in reply to your earlier post which wasn't archived. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 9 months

[MM3-users] Re: Mailman recovery test did not go as planned

by Mark Sapiro

On 8/5/22 09:38, bob B via Mailman-users wrote: > I have a test Mailman 3 environment. We are using docker, and we are running the database outside of docker in mysql. > I need to perform a DR recovery test. > > I shut down Mailman in docker (mailman-core & mailman-web, the only docker images I have running for Mailman). Does shutting down mailman-web also shut down Django qcluster? If not, this could be an issue. > While Mailman was stopped, I had our database team take a backup dump of the database. > I then restarted Mailman in docker. > I threw some more messages at a test list. > I validated that the new messages were delivered, and showed up in the archive. > I shut down Mailman again. > I had the database team restore the Mailman database from the backup. > I started Mailman > I logged into Mailman > I was expecting to see the messages in the archive prior to the backup and all the messages after the backup would be gone. I would expect that too. > When went into the list archive, I get a spinning icon and no messages showed up. I don't offhand know what the issue would be unless Django qcluster was running the whole time. > I quit, restarted my browser, and logged in again, and the same thing. > I then sent a test message to the list and the message was delivered to the list. > Then when I went to check the archive, the spinning icon was gone and that test message was there along with all the messages before the backup was taken. Possibly one of the Django periodic jobs, maybe cache_cleanup or daily_cleanup would fix it without a message. > Is this normal? After a restore did the new message cause a refresh of archived messages etc? > Is there a way to do this without sending a message to a list after a restoration of the database? > > Are there better steps I should take when restoring the database? I don't know what better you could do as far as the save and restore are concerned as long as shutting down mailman-web stops qcluster. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

[MM3-users] Re: MM3 not starting afte an upgrade

by Mark Sapiro

On 7/23/20 4:35 AM, Gelpi Andrea wrote: > Hi, > to day in a Debian system I upgraded some packages. > > After the MM3 doesn't start anymore. ... > MM3 on start up says: > > Jul 23 13:29:39 posta mailman3[2608]: Traceback (most recent call last): > Jul 23 13:29:39 posta mailman3[2608]: File "/usr/bin/mailman", line > 11, in <module> > Jul 23 13:29:39 posta mailman3[2608]: > load_entry_point('mailman==3.2.1', 'console_scripts', 'mailman')() > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ > Jul 23 13:29:39 posta mailman3[2608]: return self.main(*args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 717, in main > Jul 23 13:29:39 posta mailman3[2608]: rv = self.invoke(ctx) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/bin/mailman.py", line 69, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return super().invoke(ctx) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return > _process_result(sub_ctx.command.invoke(sub_ctx)) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return > ctx.invoke(self.callback, **ctx.params) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return callback(*args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func > Jul 23 13:29:39 posta mailman3[2608]: return > f(get_current_context(), *args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/commands/cli_control.py", line > 81, in start > Jul 23 13:29:39 posta mailman3[2608]: status, lock = master_state() > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/bin/master.py", line 104, in > master_state > Jul 23 13:29:39 posta mailman3[2608]: os.kill(pid, 0) > Jul 23 13:29:39 posta mailman3[2608]: PermissionError: [Errno 1] > Operation not permitted I think you have a stale lock issue and the master is trying to determine if the process that set it still exists. Remove Mailman's var/locks/master.lck* -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

[MM3-users] Re: moderation notices for list-owner being redirected to mailman address

by Mark Sapiro

On 2/3/22 18:55, Philippe B wrote: > Yes, we understand that those logs are normal. And indeed we have a list called "mailman"... Could that be confusing the software somewhere?? I doubt it. Note that the log excerpt posted at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… only shows the handling of a message sent from snap_wl-bounces+mailman=caltech.edu(a)caltech.edu. The envelope sender is VERPed and indicates that this message was intentionally sent to mailman(a)caltech.edu. I.e., when the `snap_wl` list created this message it intended it to go to mailman(a)caltech.edu. > The thing is that we have a pretty convoluted setup for handling mailing lists messages, but it's always the same for all messages. That's why we don't understand why only a small fraction of all the moderation messages get misdelivered at random times for random lists. > > I think what Dan was getting at is: Are there any other logs that would show us how a message that: > > a) was accepted by Postfix on the Mailman server for local delivery to list-owner(a)lists.caltech.edu; > > b) was therefore piped into the Mailman software; But according to the header excerpt I quote at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… it isn't sent directly from Postfix to Mailman's LMTP runner. It gets there via `ec2-12-34-56-78.us-west-2.compute.amazonaws.com` I think that's where the issue occurs. It appears that isn't even on the Mailman host, the no Mailman logging is going to help. > c) came out of that processing as needing to be now delivered (remotely) to mailman(a)caltech.edu, rather than the actual address of the owner of the original list? > > Or maybe we can turn on more verbose logging or something? > PS: Not to confuse things (because it doesn't apply in my example), but what happens when a list has no owner and a message is sent to list-owner? Mail to list-owner is resent by Mailman to the list owners and moderators. If there are no owners or moderators the message goes to the configured site_owner https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/owner… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: hyperkitty won't list more than 5 posts and shows empty grey Activity Summary box

by Mark Sapiro

On 08/09/2017 12:56 PM, cyp(a)trojina.si wrote: > Thanks for the quick and helpful reply. (However, please note that until now I was under the impression that there had been no response yet to my question, since my post appears to indicate having 0 comments at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/2017/8/) Yes, I see that. It was apparently an issue with caching. I recently enabled memcached on the server for django and apparently there was an issue with that. I just did what @abompard suggested at <https://gitlab.com/mailman/hyperkitty/issues/131#note_30244378> and that seems to have fixed it, at least for the moment. > Yes, the one-liner did indeed help the "More ..." problem. :) > > As for the bar graph, it's showing a bar now, probably correct. But I have not seen anything about django cronjobs in the MM3 documentation, haven't set any up, can't find any in our (Ubuntu 16.04) system and haven't done anything to fix this in-between (although I have restarted mailman-core and mailman-suite a few times). Could you point me in the right direction? This is what I have in Mailman's crontab on lists.mailman3.org > @hourly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs hourly > @daily /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs daily > @weekly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs weekly > @monthly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs monthly > @yearly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs yearly > 0,15,30,45 * * * * /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs quarter_hourly > * * * * * /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs minutely > > # Send periodic digests. > # I like 03:30 so they go overnight, but since we're 'global' and on UTC, > # maybe 07:30 is good. > 30 7 * * * /opt/mailman/mailman-bundler/bin/mailman digests --send I don't recall exactly where I saw that that was needed, but you can find it (except for the periodic digests bit) at <http://docs.list.org/en/latest/config-web.html#scheduled-tasks-required>. Note that that suggests a system crontab with the web server user rather than the 'mailman' user's crontab. -- 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

[MM3-users] Re: Mailman3 not working following distribution upgrade from Debian 10 to 11.

by Mark Sapiro

On 2/18/22 11:28, gordon(a)dickens.com wrote: > Thanks Mark! > > Here is the Traceback from the error: > > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 34, in inner > response = get_response(request) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 115, in _get_response > response = self.process_exception_by_middleware(e, request) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 113, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 71, in view > return self.dispatch(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/generic.py", line 74, in dispatch > return super(MailingListView, self).dispatch(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 97, in dispatch > return handler(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/list.py", line 326, in get > primary_email = set_preferred(request.user, mm_user) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/utils.py", line 64, in set_preferred > primary_email = EmailAddress.objects.get_primary(user) > File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/managers.py", line 30, in get_primary > return self.get(user=user, primary=True) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/manager.py", line 82, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/query.py", line 419, in get > raise self.model.MultipleObjectsReturned( > > Exception Type: MultipleObjectsReturned at /mailman3/lists/testing.dickens.com/ > Exception Value: get() returned more than one EmailAddress -- it returned 3!\ Thank you for this info. I've never seen this exact issue. What you have is a Django User with more than one primary email address. It may be you. Go to the Django web admin UI at https://host2.mailhub4u.com/admin/account/emailaddress/?q=gordon where you should see multiple email addresses for user `gordon`, three of which are primary. Go to each address and uncheck primary for all but one of them. If it's not you, see the Mult_primary script at https://gitlab.com/mailman/django-mailman3/-/issues/53#note_842641913 to find who, but this script would need to be modified for other than a postgresql database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

Search results for query "sapiro"