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

[MM3-users] Re: Which crontab?

by Pierre Abbat

On Monday, November 6, 2017 8:52:25 AM EST Mark Sapiro wrote: > It looks like your Mailman user is 'list'. That is the user that should > be running mailman commands. Thanks! There is indeed a user "list". On Monday, November 6, 2017 10:06:49 AM EST Mark Sapiro wrote: > This may be "off the wall" but is the mailman you installed perhaps a > Debian/Ubuntu Mailman 2.1 package? If so, you are reading the wrong docs > and posting to the wrong list. It's Mailman 3.1.0 installed with pip. Pierre -- li ze te'a ci vu'u ci bi'e te'a mu du li ci su'i ze te'a mu bi'e vu'u ci

8 years, 3 months

[MM3-users] Re: logrotate

by Mark Sapiro

Please don't hijack threads. Post a new topic as an original post, not as a reply to an old thread. On 5/2/23 15:45, Christian via Mailman-users wrote: > I noticed that my mailman logfiles are not being rotated. I followed the > instructions in > https://mail.python.org/archives/list/mailman-developers@python.org/message/ > FM3TSMQ63JR2KROJGOSPENODOOQVRYCL/ Those instructions are for Mailman 2.1. > Now when I try and run logrotate I get the following error > > root@zarathustra:/opt/mailman/mm/logs# logrotate /etc/logrotate.conf > error: stat of /opt/mailman/mm/logs/bounce.log failed: No such file or > directory > error: stat of /opt/mailman/mm/error.log failed: No such file or directory > error: stat of /opt/mailman/mm/mailman.log failed: No such file or > directory > error: stat of /opt/mailman/mm/mailmansuite.log failed: No such file or > directory > error: stat of /opt/mailman/mm/smtp.log failed: No such file or directory > root@zarathustra: > > What am I doing wrong please? Here's a logrotate script I use: ``` /opt/mailman/mm/var/logs/*.log { missingok sharedscripts su mailman mailman postrotate sudo -u mailman /opt/mailman/mm/bin/mailman reopen &>/dev/null || true if [ -r /opt/mailman/mm/var/gunicorn.pid ]; then PID=`cat /opt/mailman/mm/var/gunicorn.pid` kill -s USR1 $PID fi endscript } ``` A couple of caveats. The first line of the postrotate script may be wrapped. `sudo ... true` is all one line. That line could also be ``` /opt/mailman/mm/bin/mailman --run-as-root reopen &>/dev/null || true ``` I.e., it either has to run as the mailman user or specify the --run-as-root option. Also, if logs aren't in /opt/mailman/mm/var/logs/ or gunicorn.pid isn't in /opt/mailman/mm/var/ those paths need adjusting. Finally, there may be an issue with `mailman reopen` in the postrotate scrupt. See https://gitlab.com/mailman/mailman/-/issues/1078 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 9 months

[MM3-users] Re: mailman web spamming uwsgi error log.

by Mark Sapiro

On 6/28/21 2:02 PM, Sarah H wrote: > I'm having an issue with the mailman web logs (/opt/mailman/web/logs/uwsgi-error.log) spamming the below: > > 20:53:44 [Q] ERROR Failed [rebuild_mailinglist_cache_for_month] - MailingList matching query does not exist. : Traceback (most recent call last): > File "/opt/mailman/venv/lib64/python3.6/site-packages/django_q/cluster.py", line 436, in worker > res = f(*task["args"], **task["kwargs"]) > File "/opt/mailman/venv/lib64/python3.6/site-packages/hyperkitty/tasks.py", line 79, in _rebuild_mailinglist_cache_for_month > mlist = MailingList.objects.get(name=mlist_name) > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/db/models/manager.py", line 82, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/db/models/query.py", line 417, in get > self.model._meta.object_name > hyperkitty.models.mailinglist.MailingList.DoesNotExist: MailingList matching query does not exist. ... > I do not have a list named "MailingList". hyperkitty.models.mailinglist.MailingList.DoesNotExist is the name of the exception. MailingList refers to the hyperkitty.models.mailinglist.MailingList class. It is not the name of a list. The actual code is ``` def _rebuild_mailinglist_cache_for_month(mlist_name, year, month): try: mlist = MailingList.objects.get(name=mlist_name) except MailingList.DoesNotExist: log.warning('MailingList with name %s does not exist', mlist_name) return mlist.cached_values["participants_count_for_month"].rebuild(year, month) ``` Thus, there should be a warning level log message MailingList with name xxx does not exist Identifying the list name. This will be in Django's log which is probably not /opt/mailman/web/logs/uwsgi-error.log, but may be /opt/mailman/web/logs/mailmansuitelog. It is defined in settings(_local).py as the value of LOGGING['handlers']['file']['filename'] I'm not sure how this issue comes about. I suspect it comes from a task that was created before some list was deleted and the task is being continuously retried because it fails. What does your Django admin `qinfo` command show? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: Message of migrated list showing "unsubscribe@%(host_name)s" in footer

by Mark Sapiro

On 10/8/23 16:03, alex(a)presland.net wrote: > > We migrated a number of mailman lists last weekend and I spotted this evening that an email from the list contained a footer along the lines of the following (all bits in CAPITALS were successfully representing the list. > > ===== > LISTNAME mailing-list -- LISTNAME@DOMAIN > To unsubscribe, email LISTNAME-unsubscribe@%(host_name)s > ===== > > 1) I don't know why %(host_name)s hasn't been automagically substituted > 2) I can't find anywhere to change this footer in the Mailman3 Postorius interface The `mailman import21` process creates templates for existing 2.1 regular and digest headers and footers in Mailman 3's var/templates/lists/LIST_ID/LC/ directory. LIST_ID is the list's id like listname.example.com and LC is the language code for the list's preferred language. These have names like list:member:regular:header.txt, list:member:digest:header.txt, list:member:regular:footer.txt and list:member:digest.footer.txt. These are based on the mailman 2.1 lists regular and digest headers and footers with replacements translated to the appropriate Mailman 3 equivalents. However, there are various reasons why some replacements can't be translated, and these are left as is. in your case you need to edit those files and change %(host_name)s to $(domain}, or, since the default mailman/templates/en/list\:member\:generic\:footer.txt is ``` _______________________________________________ $display_name mailing list -- $listname To unsubscribe send an email to ${short_listname}-leave@${domain} ``` just deleting the var/templates/lists/LIST_ID/en/list:member:regular:footer.txt file will probably do what you want. Note that templates defined in Postorius are handled differently, and if a template is currently undefined in Postorius, starting to define it in Postorius starts with an empty template instead of the current file system template. See https://gitlab.com/mailman/postorius/-/issues/366 -- 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: "Cannot connect to SMTP server localhost on port 25"

by Mark Sapiro

On 9/18/19 11:29 AM, Manos Pitsidianakis wrote: > Hello, > > I've been getting "Cannot connect to SMTP server localhost on port 25" > from runner "out" in mailman.log over some mails stuck in shunt queue, > postfix logs show nothing when this happens, tcpdump on lo interface > port 25 shows nothing. The log shows up when I start mailman, and then > it seems not to show up again. That log message is only written once. It won't be written again unless the out runner is restarted or there is a successful delivery followed by another socket.error. > I can do 'telnet localhost 25' just fine, including as mailman user. I > can send and receive mail on my mail server. I tried making a test list > and sent/received messages fine. Is only one list affected, and is it all messages from this list or only some? > smtp debug logs show "Using agent: <mailman.mta.deliver.Deliver object > at 0x7fdd9793c940>" and "IndividualDelivery to: <email(a)address.tld>" on > repeat, where the email address is one of the addresses of the shunted > mails. Do some deliveries of the problem message succeed? I.e., in the normal case without failure, there will be one "IndividualDelivery to: <email(a)address.tld>" message for each recipient in the recipients list. In the shunted message case, the msgdata object in the shunted pickle contains the recipients. Are there "IndividualDelivery to: <email(a)address.tld>" entries for some but not all recipients. Is the last of these an invalid local address? (Postfix can return a 421 status and drop the connection if there are too many invalid local recipients, although I don't know if this would apply in the VERP case. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 5 months

[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

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

3 years, 1 month

[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

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

4 years

Search results for query "sapiro"