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

[MM3-users] Re: Internal Server Error: Reattach this thread

by Mark Sapiro

On 10/26/22 02:29, cold00water(a)gmail.com wrote: > I have only tested the operation on the web screen. What exactly did you do to test this? > I ran c, but it doesn't work because of another error. > > $ python test_thread.py > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/tests/views/test_thread.py", line 29, in <module> > from django.contrib.auth.models import User > File "/opt/mailman/venv/lib/python3.10/site-packages/django/contrib/auth/models.py", line 2, in <module> > from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager > File "/opt/mailman/venv/lib/python3.10/site-packages/django/contrib/auth/base_user.py", line 47, in <module> > class AbstractBaseUser(models.Model): > File "/opt/mailman/venv/lib/python3.10/site-packages/django/db/models/base.py", line 107, in __new__ > app_config = apps.get_containing_app_config(module) > File "/opt/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 252, in get_containing_app_config > self.check_apps_ready() > File "/opt/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 134, in check_apps_ready > settings.INSTALLED_APPS > File "/opt/mailman/venv/lib/python3.10/site-packages/django/conf/__init__.py", line 76, in __getattr__ > self._setup(name) > File "/opt/mailman/venv/lib/python3.10/site-packages/django/conf/__init__.py", line 57, in _setup > raise ImproperlyConfigured( > django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings. > > > Please tell me how to test. You need to get the source. E.g., git clone https://gitlab.com/mailman/hyperkitty.git This will create a `hyperkitty` directory in the current directory. Then you can test with tox. Ensure you have tox and then something like tox -e py310-django32 -- hyperkitty/tests/views/test_thread.py will run those tests. You can probably also test with `pytest`, but when I tried that I ran into issues with Django not finding settings. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

[MM3-users] Re: Specifying hold reason: non-member, header filter number/regex

by Mark Sapiro

On 3/16/21 9:17 AM, Duane Raymond wrote: > Hi, > > Unlike in mm2, I'm finding in mm3 that is not obvious when non-member is trying to post to the list when their subject line also has a header-filter match. All it lists is that the posting has matched a header rule (which isn't quite accurate as it is a non-member) and even when it matches a header rule it doesn't say which one (which is a noted issues in the file mailman/chains/headers.py). This is because in the chain of rules being tested for the post, the header matching rules are tested before non-member moderation. > Anyone else noticed the same and have a solution? > > The relevant list setting is:: > Message Acceptance > Default action to take when a non-member posts to the list: Hold for moderation > > Should I be editing mailman/chains/headers.py or perhaps another python file in that firstory to make the hold reason more explicit? It is actually two problems I wish to solve: > 1. Show when the message is held because it is a posting by a non-member (or a moderated member, etc) For this one, member moderation holds come before header matches, so I think your issue is only for non-members. If you want that check to come first reorder these lines <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/chains/builtin…> so the non-member moderation check comes before header matching. > 2. Show what specific header filter has caused the message to be held so I know why and/or can debug the regex to be more/less specific. You've seen the code and the comments in mailman/chains/headers.py. We would welcome a merge request to implement this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: SPF check fails for lists subdomain

by Mark Sapiro

On 1/4/23 11:39, Jan Eden via Mailman-users wrote: > Hi, > > my question is not related to Mailman directly, apologies for using this > list. I configured the DNS records for my base domain and my lists > subdomain identically (the DMARC policy records are also identical, but > not listed here): > > MX @ mail.eden.one > TXT @ "v=spf1 mx ~all" > MX lists mail.eden.one > TXT lists "v=spf1 mx ~all" > > A mail 123.123.123.123 > > But both Yahoo and Google report different SPF results for the two domains: > > <policy_published> > <domain>eden.one</domain> > <adkim>s</adkim> > <aspf>s</aspf> > quarantine > <pct>75</pct> > </policy_published> > <record> > <row> > <source_ip>123.123.123.123</source_ip> > <count>3</count> > <policy_evaluated> > <disposition>none</disposition> > <dkim>pass</dkim> > <spf>pass</spf> > </policy_evaluated> > </row> > > <policy_published> > <domain>lists.eden.one</domain> > <adkim>s</adkim> > <aspf>s</aspf> > quarantine > <pct>75</pct> > </policy_published> > <record> > <row> > <source_ip>123.123.123.123</source_ip> > <count>2</count> > <policy_evaluated> > <disposition>none</disposition> > <dkim>pass</dkim> > <spf>fail</spf> > </policy_evaluated> > </row> > > What could possibly cause this difference? The SPF test also fails for a > different base domain with the same MX and SPF records. Your spf for lists.mail.eden.one specifies its MX which is also lists.mail.eden.one, however mail from that domain arrives from IP 123.123.123.123 and presumably an rDNS lookup returns mail.eden.one which is not lists.mail.eden.one, thus the failure. Add the IP 123.123.123.123 to the spf and drop the MX since it doesn't work TXT lists "v=spf1 123.123.123.123 ~all" -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 5 months

[MM3-users] Re: Template's encoding setup

by Mark Sapiro

On 9/15/19 3:33 AM, Ugnius S wrote: > > This noticed only on HTML text messages. If message comes in HTML the > header does not add extra <enter> new line, new paragraph > and footer as well. For example if message body has no additional, list's > decorated message looks next: > > TEST HEADER > _____________________Hello, > > text text text, pictures, text > > regards > Ugnius____________________ > TEST FOOTER > > I have tried to add more empty lines in "The footer for a regular > (non-digest) message.", but mailman removes these empty lines. > Work around is put dot "." and then several empty lines. The stripping of leading whitespace from templates created in Postorius is <https://gitlab.com/mailman/postorius/issues/301> to be fixed by <https://gitlab.com/mailman/postorius/merge_requests/434> > Mark, I have found Your post about HTML headers and footers: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > YES, that works good, I have tested it, but only in cases if message comes > in HTML. If sender sends plain text message, > mailman adds footer with all HTML code: > > __________________ > LIST NAME > > Could it be possible that decorate.py would recognise message and if it > has HTML text body, then just would add header/footer and if not (if > message body is plain text) , then would strip header/footer "html to plain > text" may removing html code from it? As it says in the post you reference: message and digest footers and headers are always added either to a MIME text/plain message body or as separate MIME text/plain parts. HTML tags will just be displayed as plain text and will not be rendered as HTML. Also see <https://wiki.list.org/x/4030707>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

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

by Mark Sapiro

On 2/2/22 16:17, dancab(a)caltech.edu wrote: > Mark, please correct if I'm wrong but is the log data below produced by LMTP via Mailman core? Yes, indirectly. Mailman's LMTP runner which receives messages form the MTA via LMTP uses aiosmtpd.controller.Controller and aiosmtpd.lmtp.LMTP classes to create the actual LMTP server and it is those classes that write those log messages. > This is from the Mailman smtp.log file. Could this somehow be an issue with how we've configured Mailman for LMTP? > > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'LHLO aeedf7ad9f48.caltech.edu' > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'MAIL FROM:<snap_wl-bounces+mailman=caltech.edu(a)caltech.edu> SIZE=4289' > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) sender: snap_wl-bounces+mailman=caltech.edu(a)caltech.edu > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'RCPT TO:<mailman(a)lists.caltech.edu>' > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) recip: mailman(a)lists.caltech.edu > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'DATA' > Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'QUIT' These are normal messages. They are also normally followed by two additional messages like Jan 30 22:04:10 2022 (1329492) ('127.0.0.1', 34924) connection lost Jan 30 22:04:10 2022 (1329492) ('127.0.0.1', 34924) Connection lost during _handle_client() These are also normal and not a concern. Are you thinking there is an issue because of the presence of these messages or the content. The messages are normal. If you're concerned about the content, it appears there is a `mailman(a)caltech.edu` list and a `snap_wl(a)caltech.edu` list and the `snap_wl` list is sending something to the `mailman` list. This also seems OK and not at all relevant to the original issue in this thread. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

[MM3-users] Re: How to disable global templates for all lists

by Mark Sapiro

On 3/13/24 16:28, christopher.claus(a)tgcamberg1848.de wrote: > Hallo togeher, > > I´m using the docker version from maxking and mailman core-version 3.3.9. I was wondering why there were messages in the list with "non-configured" footers. I found the files >> > mailman-core:/opt/mailman# find / -name "*list:member:*" > /usr/lib/python3.11/site-packages/mailman/templates/de/list:member:generic:footer.txt > /usr/lib/python3.11/site-packages/mailman/templates/de/list:member:digest:masthead.txt > /usr/lib/python3.11/site-packages/mailman/templates/ca/list:member:generic:footer.txt > /usr/lib/python3.11/site-packages/mailman/templates/ca/list:member:digest:masthead.txt > /usr/lib/python3.11/site-packages/mailman/templates/nl/list:member:generic:footer.txt > > but I found no option to disable them. How can I disable these global list-configuration? First, those are only a few. The default English templates are templates/en/list:member:digest:masthead.txt templates/en/list:member:generic:footer.txt templates/en/list:member:digest:header.txt templates/en/list:member:regular:header.txt and there are translations of them in many more than the de, ca and nl languages. The default English list:member:digest:header.txt and list:member:regular:header.txt are empty so most languages do not translate them. You can't disable them other than removing them, but you don't want to do that as these are only used as fall back in cases where there is no list, domain or site specific template. If you have messages delivered that use one of the default templates, it's because you don't have a custom template that matches the context for that message. When a template is required, first the template table in the database is searched for a template matching the list, domain or site context. If no match is found, the file system is searched as described at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/i18n… -- 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: Hyperkitty_import.py Error

by Mark Sapiro

On 2/7/21 10:03 AM, Brian Carpenter wrote: > I am trying to import some old archives (going back to 2003) into a > Mailman 3 list. The import job is terminating very early in the process > with the following error: > > IndexError: string index out of range > > 1. Is there a way to fix a mbox file that is generating this type of error? Yes, but you need to understand what message is causing the error and why. The full traceback from the error can help. So can the script at <https://www.msapiro.net/scripts/check_hk_import>. > 2. If a message is causing this error, is there a way to import the rest > of the mbox file by importing messages after a certain date within the > mbox file? I know the --since flag should be able to do that but I am > unsure what the date/time format should be. There are things you can do. The --since date syntax is very flexible. It uses dateutil.parser.parse. See <https://dateutil.readthedocs.io/en/stable/parser.html#module-dateutil.parser> You can also just make a new mbox which deletes the messages up to and including the offending one or just delete/fix the offending message. hyperkitty_import won't re-import message that are already in the archive, and without a --since option won't import messages older than the newest in the existing archive. > 3. The --no-sync--mailman flag indicates the possibility of doing batch > imports. What are batch imports and how do you do them? Batch imports means running hyperkitty_import multiple times wiuth multiple mbox inputs (batches). It is only necessary to run the sync_mailman job once after all the imports are done (even if importing to multiple lists). I.e. specify --no-sync--mailman on all but the last import, or on all and then run sync_mailman after done. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

[MM3-users] Re: Installing MM3 requires Django<1.11

by Mark Sapiro

On 04/12/2017 02:22 AM, Henrik Rasmussen wrote: > Two questions regarding Mailman 3 installation: > > 1) > The Mail server setup at http://docs.mailman3.org/en/latest/devsetup.html#set-up-a-mail-server isn't described yet. Instead it refers to https://docs.djangoproject.com/en/1.10/topics/email/#topic-email-backends, but it doesn't say which file I have to change. That link doesn't belong there. Mailman doesn't use Django to send mail. > According to https://www.webforefront.com/django/setupdjangoemail.html the file is called settings.py, but the only settings.py I can find at this stage is the /opt/mailman/postorius/example_project/settings.py file. > > According to http://docs.mailman3.org/en/latest/devsetup.html#set-up-and-run-postorius, "Postorius and HyperKitty both come with example_project directories with basic configuration so you can try them out. For this tutorial, however, we'll be using a project that combines both instead.". > > In what file should I change the mail settings then? Nothing in <https://docs.djangoproject.com/en/1.10/topics/email/#topic-email-backends> or <https://www.webforefront.com/django/setupdjangoemail.html> is relevant to Mailman. A more appropriate discussion is at <http://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html> > 2) > While installing Hyperkitty*) I got the error message "Django 1.11rc1 is installed but Django<1.11 is required by {'django-haystack'}". > > As I have slavishly followed the installation guide including http://docs.mailman3.org/en/latest/devsetup.html#set-up-django-mailman3, I wonder why a non-supported Django version was installed. > > *) http://docs.mailman3.org/en/latest/devsetup.html#set-up-and-run-hyperkitty This is an issue. The various setup.py files for django-mailman3, hyperkitty and postorius all have Django>=1.8 as a requirement. Only postorius also has Django<1.11. django-mailman3 and hyperkitty should have that restriction too. I have submitted <https://gitlab.com/mailman/django-mailman3/issues/4> and <https://gitlab.com/mailman/hyperkitty/issues/128> for this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 2 months

[MM3-users] Re: hyperkitty threads by month question

by Mark Sapiro

On 7/26/24 18:53, Bryan Fields wrote: > On 7/26/24 4:01 PM, Mark Sapiro wrote: > >> If this returns just the one message_id, I would then >> >> DELETE FROM hyperkitty_thread WHERE id = 35670; >> DELETE FROM hyperkitty_email WHERE id = 150555; > > It's giving an error due to a fk constraint on another table. I'm not > familiar with the db structure enough to be certain how to clean/fix it. Yes, you need to do these first. DELETE FROM hyperkitty_favorite WHERE thread_id = 35670; DELETE FROM hyperkitty_tagging WHERE thread_id = 35670; DELETE FROM hyperkitty_lastview WHERE thread_id = 35670; DELETE FROM hyperkitty_vote WHERE email_id = 150555; Not all those will exist, but then you should be able to DELETE FROM hyperkitty_thread WHERE id = 35670; DELETE FROM hyperkitty_email WHERE id = 150555; > I'm actually thinking I need to fix the archive mbox, then delete them and > re-import them once they are cleaned. Actually, that would be safest. Fix the mbox, delete the entire archive and re-run the import. >> Also, FYI, assuming those messages with very old Date: headers had >> reasonable unix from dates, the hyperkitty/contrib/cleanarch3 script >> would fix them, except you have to get the script from >> https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/contrib/clea… >> or https://www.msapiro.net/scripts/cleanarch3 because the script in the >> latest release has a bug. > > I tried the dry run option on your script and it gave a bunch of output > for bad > dates. This was absent on the one shipping with the source. What's > interesting > is that pipermail seems to have no issue with this, detecting the date > correctly. If I recall correctly, pipermail checks date skew and 'fixes' the dates in the archive, but they remain off in the mbox. > https://mailman.nanog.org/pipermail/nanog/2000-January/137630.html > One other thing, I did notice a number of archives not showing up in > sequence > due to missing "In-Reply-To:" headers from the source. The first > message in > this is one like this, and pipermail in mmm2 seems to handle this by > referencing > the subject, > https://mailman.nanog.org/pipermail/nanog/2002-April/151325.html, > where as in hyperkitty it's an orphaned thread. Yes, HyperKitty does not do threading by subject matching. It only threads based on In-Reply-To: and absent In-Reply-To:, only the last entry in References: if any. > Is the archive tool in pipermail's import more robust in this manner? > I'd argue > it's common to have missing In-Reply-To: headers where the subject and time > would need to be used to infer the likely thread. I'll agree this is a > major > violation of the relevant RFC's to be missing this, but many MUA's (M$) are > famous for doing just this. Yes, it's arguably a defect in HyperKitty to not implement Jamie Zawinski's threading algorithm <https://www.jwz.org/doc/threading.html>, but it doesn't. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 3 weeks

[MM3-users] Re: Setting for archiving multi email domains?

by Mark Sapiro

On 3/5/21 10:19 AM, Duane Raymond wrote: > fairsayforum.com = mail site domain (working fine for lists, archives and web) > > > alias_database = hash:/etc/aliases > alias_maps = hash:/etc/aliases > always_add_missing_headers = yes > append_dot_mydomain = no > biff = no > compatibility_level = 2 > default_destination_concurrency_limit = 15 > default_destination_recipient_limit = 30 > delay_warning_time = 1h > header_checks = regexp:/etc/postfix/header_checks > inet_interfaces = all > inet_protocols = all > local_recipient_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp > mailbox_size_limit = 0 > milter_default_action = accept > milter_protocol = 2 > mydestination = $myhostname, mail.fairsayforum.com, localhost.fairsayforum.com, localhost > myhostname = mail.fairsayforum.com > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 > myorigin = /etc/mailname > non_smtpd_milters = inet:localhost:8892 > owner_request_special = no > readme_directory = no > recipient_delimiter = + > relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains > relayhost = > smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache > smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) > smtpd_milters = inet:localhost:8892 > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination > smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem > smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key > smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache > smtpd_use_tls = yes > transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp > unknown_local_recipient_reject_code = 550 And previously > > <test(a)oldlist.com> (expanded from <test(a)emaillistA.com>): host > oldlisthost.com[ip] said: 550 5.1.1 > <test(a)oldlist.com>: Recipient address rejected: User unknown in > virtual alias table (in reply to RCPT TO command) > > But I can't find oldlist.com in the configuration settings. It was set as an alias for emaillistA.com domain, but was removed. Have you removed the alias domain from the emaillistA.com domain and similarly for the others and then regenerated the maps with `mailman aliases` or `mailman start -g`after removing the alias domains. Also, I'm confused about "User unknown in virtual alias table" since there are no virtual_alias_domains in your Postfix main.cf. Have you reloaded Postfix since updating main.cf? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

Search results for query "sapiro"