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

[MM3-users] Re: Wrong info in moderation mail when held due to match of a header rule

by Mark Sapiro

On 10/17/20 10:39 AM, Torge Riedel wrote: > > The message is being held because: > > Header "Yes" matched a header rule > > At your convenience, visit your dashboard to approve or deny the > request. > > I think this is wrong, it should read 'Header "x-spam" matched a header > rule'. Cause the header rule is configured for header "x-spam" and > pattern "Yes". The message is defined as 'Header "{}" matched a header rule' where {} is replaced with the value of the matching header. I agree it would be better if it were something like 'Header value "{}" matched a header rule for {}:' with {}s replaced with the header value and name. That would make it in your case 'Header value "Yes" matched a header rule for x-spam:' > I haven't found a bug report for this yet on gitlab. If someone of the > developers confirm this is wrong, I will file a bug on gitlab for it. Please do file a bug. It won't be fixed until after the upcoming 3.3.2 final release because we not making i18n changes between the candidate and final releases. Also, if you don't like my suggestion, feel free to suggest something else. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

[MM3-users] Re: Upgrade to 3.3.2 fails

by Mark Sapiro

On 12/26/20 11:28 AM, Joel Lord wrote: > innodb_page_size of 16384 is the default, so that is what I'm working > with as well. The row size limit is half the page size minus some > overhead, so it comes out to 8126 and I bet that is yours as well. > > Yes, I am utf8mb4 at the database and table levels, and I bet you are > right. Just to confirm, between 3.2.1 and 3.2.2 the column archive_rendering_mode was added to the mailinglist table. This column is type - integer (4 bytes), but could be enough to push the row over the limit. As far as utf8mb4 vs. utf8 is concerned. There will be issues with the hyperkitty_email table subject and content columns in particular and maybe others if email messages contain 4-byte utf-8 unicodes. However, as I read the MySQL docs, for columns like VARCHAR(255) and VARCHAR(510), the difference affects only the number of characters that can be stored in the column and not the actual column width. I.e., a VARCHAR(255) column is actually up to 256 bytes wide (1 byte for length and up to 255 butes of data) and can thus hold up to 85 3-byte utf-8 encodings or up to 63 4-byte utf-8 encodings, but since any string normally contains only a few if any (probably none in the case of the mailinglist table) the actual limit is much closer to 85. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

[MM3-users] Re: Archive search failing on one list

by Mark Sapiro

On 10/9/23 22:50, Mark wrote: > > I'm still on this problem of one list's archive-search not returning > any results. I created a new list today and it also has the same > problem. > > In short, the older lists all seem fine -- their search results are up- > to-date so that tells me the cron is okay. It's just these 2 newer > lists that have the problem. > > It's taken me while to get my head around the Django admin command you > have suggested, as I kept getting an error when starting: Steve has addressed your issues with multiple Django admin commands, some of which apparently don't reference the correct settings. > The format of my final line is different to yours ... > > Mine: <MailingList: <MailingList thepost(a)example.com>> > > Yours: <MailingList listname(a)domain.com (listname.domain.com)> > > Does this (missing list_id) give any clue as to why the archive-search > isn't working, or is just that starting with "# python3 manage.py > shell" is the wrong thing to do? It is not a clue as to the problem. The format of that `representation` changed in HyperKitty 1.3.5. What is your version? What happens if you do, with the appropriate Django admin and list name, ``` python3 manage.py update_index_one_list thepost(a)example.com ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 8 months

[MM3-users] Re: Pre-approved howto

by Mark Sapiro

On 7/5/18 6:14 AM, thor.rustad(a)gmail.com wrote: > I have tried to understand the concept of pre-approved messages, but I'm spending way too much trying to figure it out. Help! There is a list attribute, moderator_password, which is not currently exposed in Postorius and therefore must be set via 'mailman shell'. Here's a sample session. > $ mailman shell -l junk(a)msapiro.net > Welcome to the GNU Mailman shell > The variable 'm' is the junk(a)msapiro.net mailing list >>>> m.moderator_password >>>> from mailman.config import config >>>> m.moderator_password = config.password_context.encrypt('xxx123').encode('us-ascii') >>>> m.moderator_password > b'$6$rounds=656000$SKMqTlPybIZSBjYB$wCga5qALCv8oobp4cDql2iKEg8T6qIgk8XEKYbkk9QXENeFQDHZ1M4AtmqfureYQDB5g.Az.nZPrWAr9N9g1N0' >>>> commit() That will set the list's moderator_password to the encrypted value of 'xxx123'. Then, if a post to the list contains Approved: xxx123 either as a header in the message (recommended if possible) or as the first non-blank line in the first text/plain part of the message, the post will be 'pre-approved'. The header can actually be any of Approve:, Approved:, X-Approve: or X-Approved: and if it is not a header, but is found in the first text/plain part of the message, it will be removed from that part and a best effort will be made to remove it from other text/* body parts in case it is also in an alternative part. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

[MM3-users] Re: Removing the footer from mails

by Mark Sapiro

On 10/21/2017 01:46 PM, Peter Mueller wrote: > Hi, > > mailman2 had the configuration variable "msg_footer" to edit/remove the > footer. How can I get rid of the footer in mailman3? The doc is at <http://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/decorate.…>, but it's a bit complex. First, the message footer template name is 'list:member:regular:footer' and the digest footer template name is 'list:member:digest:footer' and if you want the same template for both, the name 'list:member:generic:footer' will do. The easiest way to set these is to create a template for the desired language (probably 'en') or an empty file if you want no footer. Then, there is a 'var' directory in the Mailman installation which contains sub directories named 'archives', 'cache' 'data', 'etc', 'ext', 'lists', 'locks', 'logs', 'messages', 'queue' and 'templates'. You can put list specific templates in var/templates/lists/LIST.ID/en/, domain specific templates in var/templates/domains/DOMAIN/en/ and sitewide templates in var/templates/site/en/. For example if you put an empty file at var/templates/site/en/list:member:generic:footer and a non-empty file at var/templates/lists/list.example.com/en/list:member:regular:footer, all messages and digests will have no footer except for regular deliveries from the list.example.com list which will use it's template. list overrides domain overrides site overrides default. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 8 months

[MM3-users] Re: Mailman3 on Debian 10

by Mark Sapiro

On 1/30/20 9:22 AM, Bala Mutyam wrote: > Sorry one more issue, > > Mailman settings page giving me below error. > > Server error > An error occurred while processing your request. > > Error logs: > > ERROR 2020-01-30 17:20:11,331 16285 django.request Internal Server Error: /postorius/accounts/subscriptions/ > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 41, in inner > response = get_response(request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 187, in _get_response > response = self.process_exception_by_middleware(e, request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 185, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view > return view_func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/postorius/views/user.py", line 306, in user_subscriptions > mm_user = MailmanUser.objects.get_or_create_from_django(request.user) > File "/usr/lib/python3/dist-packages/postorius/models.py", line 164, in get_or_create_from_django > return self.get(address=user.email) > File "/usr/lib/python3/dist-packages/postorius/models.py", line 86, in get > return method(*args, **kwargs) > File "/usr/lib/python3/dist-packages/mailmanclient/client.py", line 322, in get_user > return User(self._connection, content['self_link'], content) > KeyError: 'self_link' Just prior to this is a call to the REST API to GET /users/user(a)example.com (or whatever the user's address is). It appears that that user doesn't exist in core. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: # comment allowed in a template file?

by Mark Sapiro

On 7/27/20 5:15 AM, skenny(a)scss.tcd.ie wrote: > > The effect of the template files not being readable by user "mailman" was interesting. Hundreds of lines like the following got written to mailman-core's var/log/smtp.log file at the rate of 4 per second: > > Jul 23 17:09:54 2020 (25) Using agent: <mailman.mta.bulk.BulkDelivery object at 0x7fdf9e7b5f28> > > (the hex number was different each time). That's a `debug` level log message written for every delivery. It has nothing to do with the unreadable templates except that the unreadable template causes looping in an attempt to send the message. Did you perhaps set [logging.smtp] level: debug in an effort to diagnose the template issue? > Having excessively restrictive permissions on the template files is a silly - but easy enough - mistake to make. If it were possible to add it to Mailman 3, a more descriptive logging message could point others who make it in the right direction, perhaps. I spent a long time trying to figure out why messages weren't getting sent out from Mailman core, and in the end it was luck in form of a colleague's suggestion about file permissions that got me out of the rut. There is clearly a bug in that an unreadable template should just be skipped and the fact logged. I have reported <https://gitlab.com/mailman/mailman/-/issues/745>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: Mailman - delete or backup old archived messages

by Mark Sapiro

On 6/30/21 6:23 AM, Lucia Moreno wrote: > Hi Mark, > > We are facing the same issue. My postgres database is growing too fast and > I would need to do some creaning of old archives dated from 2001 and keep > only the last, lets say... 5 years. > > Could you please help us with the development of such a script? I have no > experience in python. The attached script is a rough idea. It assumes your Mailman is installed in a virtualenv at /opt/mailman/mm/venv and the django settings module is /opt/mailman/mm/settings.py. The pruned messages will be in a mbox at /opt/mailman/pruned.mbox. The age of messages to prune is defined by the days=365*5 argument in CUTOFF = datetime.datetime.today() - datetime.timedelta(days=365*5) All these things may need adjustment for your purpose. There is also a commented bit showing how you could do just one list. It's probably good to do just one list at a time since it's not clear how useful the pruned.mbox will be if it contains messages from multiple lists. I.e., run it for one list and move the pruned.mbox aside before doing the next list. Note that I've tested that this works, but it's possible that it will leave HyperKitty in a bad state. Backup your database before running this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

[MM3-users] Re: Archive download - unexpected end of file

by Mark Sapiro

On 3/1/25 13:58, Mark wrote: > > I have a MM3 list to whose archive I recently added an mbox file of > older emails. > > Viewing/searching the archive (Hyperkitty) is working fine. > > Downloading archives "for the month" or "last 30 days" delivers the > expected ".mbox.gz" file and those are fine. > > However, when I download the "Entire archive" and attempt to gunzip that > ".mbox.gz" file I get the error: " ... unexpected end of file". The process creating the zip for download times out. You can increase the timeout. If your wsgi server is Gunicorn, see https://docs.gunicorn.org/en/stable/settings.html#timeout - for uwsgi see https://uwsgi-docs-additions.readthedocs.io/en/latest/Options.html#harakiri However, it's probably easier to get it in pieces. You can prpbably get chunks bigger than a month. Look at the URL for a month, e.g. for Jun, 2005 it will be something like https://www.example.com/archives/list/<fqdn-listname>/export/<fqdn-listname>-2025-02.mbox.gz?start=2025-01-01&end=2025-02-01 The <fqdn-listname>-2025-02.mbox.gz can be any arbitrary file name. The start and end parameters determine what's included. E.g. for all of 2024 https://www.example.com/archives/list/<fqdn-listname>/export/<fqdn-listname>-2024.mbox.gz?start=2024-01-01&end=2025-01-01 Note that the end date is the first date not included, i.e. the day after the last date included. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 3 weeks

[MM3-users] Re: Questions regarding message acceptance

by Mark Sapiro

On 7/28/20 6:35 AM, Pawel Grzywaczewski wrote: > Hello, > > I have few questions regarding usage of Mailman3: > > 1) We have list1 and list2 with members. Can we specify that all members of list1 can post messages to list2? This is a Mailman 2.1 feature that does not currently exist in Mailman 3. > 2) In explanation of “Accept these non-members” it’s written: “While non-regexp addresses can be entered here, it is preferred to add the address as a nonmember and set the nonmember's Moderation to Default Processing”. > > I noticed that if someone posts to a list then he is added automatically to non-members. Which means that next time he will be able to post. > My understanding is that it’s better to use the feature “Accept these non-members”. Am I correct? You are mistaken. When a non-member attempts to post to a list she is automatically added to non-members with a moderation action of list default, which means that this and subsequent posts will be handled according to the list's "Default action to take when a non-member posts to the list" If you want to accept a non-member's posts you need to set that non-member's moderation action to "Default Processing" to still apply other tests that might hold the message or to "Accept" if you want to accept anything from that non-member. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

Search results for query "sapiro"