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

[MM3-users] Re: Weird hourly indexing error

by Mark Sapiro

On 5/5/20 8:55 AM, Mark Dadgar wrote: > I moved my mail server to a Digital Ocean droplet. I basically installed all the appropriate packages and then rsync’d everything that matters from my metal server up to the cloud instance. Everything more or less works fine. > > However, I am now getting this hourly error - see below. ... > [ERROR/MainProcess] Failed indexing 1 - 1000 (retry 5/5): Term too long (> 245): XSUBJECT95251413 (pid 36301): Term too long (> 245): XSUBJECT95251413 > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py", line 97, in do_update > backend.update(index, current_qs, commit=commit) > File "/usr/local/lib/python3.8/dist-packages/xapian_backend.py", line 488, in update > database.replace_document(document_id, document) > xapian.InvalidArgumentError: Term too long (> 245): XSUBJECT95251413 This error comes from Xapian. It is due to a (new) message in your archive that contains a 'word' longer than 245 characters. There is a PR at <https://github.com/notanumber/xapian-haystack/pull/181> that addresses this plus another suggested fix in that PR's comment thread. Note: I got there by googling "xapian term too long" which gave <https://github.com/notanumber/xapian-haystack/issues/153> as the first hit and that led me to the above. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

[MM3-users] Re: File "/usr/lib/python2.7/httplib.py", line 1148, in getresponse raise ResponseNotReady()

by Mark Sapiro

On 9/28/20 12:58 AM, r.woithe(a)callassoftware.com wrote: > Hello, > i set the necessary config params like descriped at https://wiki.list.org/x/17892072 with timeout = 9000. > But we still get the nigthly email. If you are still using Mailman core 3.2.2, those settings have no effect because the REST server doesn't use gunicorn prior to 3.3.0. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > I guess the best way would to upgrade to mailman-core 3.3.3 to avoid this error. > Unfortunatly i can not use the ubuntu package-manager... > Or is there a second way to avoid this error? I don't know if upgrading Mailman core would avoid the error or not. As I indicated, it's almost certainly not a REST timeout after all. We need to understand what causes the error. As I've said, the sync_mailman goes through the message senders and tries to set the senders mailman_id. If you apply the attached patch to hyperkitty/models/sender.py, it will log the error and ignore it. Then, we'll get a bit more info from the log message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

[MM3-users] Re: Extracting mailing list users

by Mark Sapiro

On 1/2/23 07:06, Jan Eden via Mailman-users wrote: > On 2023-01-02 14:36, Eggert Ehmke via Mailman-users wrote: > >> Thank you, that worked! Now all my addresses are clean. >> >> Still, don't you think this should be possible via Postorius, or by some mailman cli command, like >> mailman rename_member <old> <new> Yes, it should be possible to change the display name for an address via Postorius. See https://gitlab.com/mailman/postorius/-/issues/451. >> It happened I had still the patched cli_members.py where I had both the old and new line active: >> print(formataddr((address.display_name, address.original_email)), file=outfp) >> print(f'{address.display_name} <{address.original_email}>', file=outfp) >> The first (old) line still produces the output with utf-8 codes. Is this to be expected? > > I would assume the original line outputs the QP-escaped names, to be > used in an email header. Yes. The original `formataddr((address.display_name, address.original_email))` creates the format `display name <email>` suitable for use in an email header. Thus, if the display name contains non-ascii, it is RFC 2047 encoded. The encoding may be quoted-printable or base64 depending on which is shorter. -- 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: Social signup?

by Mark Sapiro

On 3/12/23 14:32, Duane Raymond wrote: > > Thanks for clarifying. Once I implemented social login, the buttons for > social login did appear fine on the login page, but not on the signup > page. I noticed for this list as well, there are no social signup > buttons. The buttons do not appear on the sign-up page. They probably should, but they don't. > So if it works, how does this happen? > > 1. Is there something I am missing adding to my settings.py and > settings_local.py files to make it appear on the Posterius/Hyperkitty > signup (vs login) page? (I searched but couldn't find anything) You aren't missing anything. > 2. Do I manually add this code to the Posterius/Hyperkitty signup > template? No > 3. If a user tries to login via the login page and isn't registered will > it be counted as a signup? Yes, that's how it works. > I'm trying to get my head around where this is working from / what I need > to do to get social signup obvious on the signup page (or other route) I just created https://gitlab.com/mailman/django-mailman3/-/issues/67 for 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, 1 month

[MM3-users] Re: Emergency moderation and clearing out a lot of held messages

by Mark Sapiro

On 11/11/22 16:36, Caballero, Danny (Dan) wrote: > Thanks for some clarification. > > I cleared out 2800 held messages via Python shell "mailman -l" option and it took about 28 hours. Anything done via Mailman shell is a connection from Mailman core to the database, correct? That's correct. > Although I can't replicate that many messages via Postorius/DJango, I do see similar slowness there as well at a message per minute or more of processing. > > I recreated the above Mailman shell clean up via Docker container running MariaDB and noticed similar processing time for discarding held messages. That leads me to conclude that the issue isn't network related or specific to AWS RDS. I'm assuming the docker container installation also had all the lists/users? It seems this must be related to a large number of lists/users and we must be doing a number of queries that doesn't scale well. This seems excessive. We'll have to look at the processing to see what we're doing. There have been some recent improvements in scaling. What Mailman core version is 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, 5 months

[MM3-users] Re: Mailing list resends same email multiple times

by Mark Sapiro

On 3/9/23 04:18, 朱超 wrote: > Hello, I need your help. There have question about Scenes: > > Add mailbox a and mailbox b to mailing lists c and mailing lists d, and send mail to mailing list c and mailing list d through mailbox b , among which a has received many mails sent by b, check the log and find: The file about path:/opt/mailman /var/queue/bounces has the content of retrying mail, but I turned off process bounces. > > Mailing list sends mail via exim, logs found in exim： 023-03-09 00:54:47 1pa4YR-001xk5-0y <= <> R=1pa4YM-001xje-1F U=exim P=local S=7672 T="Mail delivery failed: returning message to sender" from <> I need more information. Even though the list isn't brocessing bounces, bounces will still be returned to the -bounces address and queued in /opt/mailman/var/queue/bounces. If they remain there, the bounce runner is not processing them. If the list's bounce processing is turned off, the bounce runner should just dequeue the message and discard it. If multiple messages go to the list, something is returning them to the list posting address instead of the list-bounces address. -- 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: Mailman3 on FreeBSD

by Mark Sapiro

On 08/12/2017 04:51 PM, Barry Warsaw wrote: > On Aug 10, 2017, at 16:32, John Poltorak <karotlopj(a)gmail.com> wrote: >> >> On FreeBSD they ought to be in /usr/local/etc/mailman.cfg however I don't >> see any indication as to what I should put in this file and if it was in >> /usr/local/etc/mailman.cfg then how would mailman find it? > > It wouldn’t by default. Right now Mailman does not search for /usr/local/etc/mailman.cfg, but that wouldn’t be a difficult change to add. I’m not sure whether that would makes sense as a general default or not. I’m not up on the FreeBSD conventions and standards here; can you explain why /usr/local/etc is preferred over /etc on that distro? I was hoping Abhilash would chime in here, because I think John is using the docker image and there's probably a specific path for mailman.cfg. As far as what goes in it, it could even be empty if you want to accept all the defaults, but you probably want at least [mailman] site_owner: real_person(a)example.com I expect if you do find -name mailman.cfg in your installation, you'll find at least examples. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 8 months

[MM3-users] Re: mailman3 admin from mailman2 & File location questions

by Mark Sapiro

On 11/3/21 1:38 PM, bob B wrote: > Question1 > We use help users with list settings, so we would log into mailman2 with the master password. So what is the best way to duplicate this for mailman3. I assume I can just use the admin account and share that password with my other admins. But I see the domain owners, but is that working? I added someone as a domain owner, and they do not see private email lists and it looks like that can not edit any list settings? There was a post that this had not yet been implemented? Any other options? Domain owners should be able to manage lists in their domains, but currently they can't. You can go to the Django admin interface and give any user superuser status, and then they will be 'admins'. You don't have to share passwords. > Question2 > Where are all the emails/archives stored? are they in /opt/mailman/...., or are they in the database? It depends on the archiver. For the prototype archiver they are in the archives/prototype/ directory in Mailman's var directory. For HyperKitty they are in the database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Deleting messages from HyperKitty archive

by Mark Sapiro

On 3/25/24 12:42, Mark wrote: > Hi, > > I'm running Mailman 3.3.9 with HyperKitty version 1.3.8 (venv installed > as per the docs). > > As superuser (listmaster) I can "Delete message/thread" and "Delete > archive". > > These options aren't there for the list owners. > > The docs (link below) say that in the newer HyperKitty version 1.3.9, > list owners can delete messages/threads > > Is there a patch I can implement on HyperKitty version 1.3.8 (so list > owners can delete messages), or is it possible to update HyperKitty to > version 1.3.9 without bringing everything crashing down? > > *** > https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html > 1.3.9 (2024-02-27) > List owners can now delete messages and threads and reattach threads. > (Fixes #261) > *** The patch is at <https://gitlab.com/mailman/hyperkitty/-/merge_requests/584/diffs>. Upgrading HyperKitty can be done in your venv by something like ``` pip install hyperkitty==1.3.9 ``` however, there may be things that also depend on later versions of django-mailman3, mailmanclient, mailman-web or even mailman core, thus it is best to upgrade everything. For the recommended virtualenv install, see <https://docs.mailman3.org/en/latest/upgrade-guide.html#virtualenv-install> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 1 month

[MM3-users] Re: Data too long for column 'data' in workflowstate

by Mark Sapiro

On 12/14/20 9:46 AM, Morris Jones wrote: > I ran into this error attempting to add a user to a mailing list: > > (pymysql.err.DataError) (1406, "Data too long for column 'data' at row 1") > [SQL: INSERT INTO workflowstate (token, step, data) VALUES (%(token)s, > %(step)s, %(data)s)] > [parameters: {'token': '7394fbf654b3faffc6a65eb95e0616eea6651b9e', > 'step': 'do_confirm_verify', 'data': '{"pre_approved": false, > "pre_confirmed": false, "pre_verified": false, "invitation": false, > "address_key": "dorothyxxxxxxxx(a)gmail.com", "subscriber_key": 1, > "user_key": "00201c01dcc443c3a0d8f6d1ea42e230", "token_owner_key": 1, > "send_welcome_message": null}'}] > > In MySQL I see that column 'data' in workflowstate is VARCHAR(255), and > the data in the query is 259 characters. > > If I have a moment I'll write a bug or patch ... but I'm not really > current on schema migrations. This is <https://gitlab.com/mailman/mailman/-/issues/793> fixed by <https://gitlab.com/mailman/mailman/-/merge_requests/730> You may be able to apply the fix from the merge request, but that depends on your install's latest Alembic Revision ID being 9735f5e5dbdb. Alternatively, I think it may be sufficient to just ALTER TABLE workflowstate MODIFY `data` VARCHAR(510); -- 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

Search results for query "sapiro"