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

[MM3-users] Re: Upgrade

by Darren Smith

And as usual, Mark to the rescue. Works like a charm...thank you! By the way, whose idea was it to use Rush songs for the release names? I whole-heartedly approve. -Darren On Mon, Apr 16, 2018 at 11:52 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 04/16/2018 10:26 AM, Darren Smith wrote: > > Nice...spoke too soon. > > > > Mailman info works, but when attempting to start mailman I'm now getting > > this: > ... > > RuntimeError: Click will abort further execution because Python 3 was > > configured to use ASCII as encoding for the environment. Consult > > http://click.pocoo.org/python3/for mitigation steps. > > > Are you starting Mailman from an init script. If so, add > > export LANG=en_US.UTF-8 > > to the script. See > <http://mailman.readthedocs.io/en/latest/src/mailman/docs/ > install.html#running-mailman-3> > > > -- > 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/ >

8 years, 4 months

[MM3-users] Re: Replies

by Mark Sapiro

On 3/17/22 20:47, Matthew R via Mailman-users wrote: > Hi everyone, we're going to be using a Mailman3 list for the purpose of > providing email support. So: > > * Anyone can post to the list > * Agents will reply to the poster to receive support, and the reply > must go back to the original poster (the client) and the mailing list for > other agents to see > * The poster's replies will be sent to the mailing list (so other > agents can see) as well as to the agent who initially replied to the initial > posting > > > > Is there any way to accomplish this? Right now, if the agent replies to the > client's email correctly but the client doesn't hit "Reply All" the email is > only sent to the agent that initially took the "case" and the other agents > aren't aware that there was a response. This is an intractable problem. Ideally, you would be able to configure the list to ensure all mail is sent with a Reply-To: that includes the original From: and the list address, but there is no list configuration that guarantees that. It wouldn't be difficult to patch mailman to do it for a particular list. You could almost get there if all the posts to the list included a Reply-To: In this case setting Reply goes to list to the list and First strip reply to to No, but you can't even hope that all incoming posts include a reply to. But, even if they don't, this may work. I.e., setting Reply goes to list to the list will set a Reply-To: with the list address in all delivered posts. The agent can do Reply-All: and hopefully, this goes to the From: and to the Reply-To. Then the client gets the reply with a Reply-To: to the list and hopefully, the client's reply goes back to the list. I say `hopefully` twice above because if there's a Reply-To; it is not a guarantee with all MUAs that Reply-All will include the From:, and at the client's end, even with a Reply-To: to the list, there's no guarantee the client's MUA will honor that. I say it's an intractable problem because what ever the list does, it relies on the user's MUA to do the right thing, and unfortunately, not all do. -- 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: Mailman-web showing "An error occurred while processing your request."

by Mark Sapiro

On 2/8/23 08:34, C. Souza wrote: > I'm trying to manage 2 held messages in a specific list and I'm getting > this error below when I click on /held_messages. It never happened before. ... > ==> mailmanweb.log <== > ERROR 2023-02-08 16:01:30,149 1516 django.request Internal Server Error: > /mailman3/lists/mylist.domain.com/held_messages > Traceback (most recent call last): ... > File > "/opt/mailman/venv/lib64/python3.6/site-packages/django/utils/dateparse.py", > line 107, in parse_datetime > match = datetime_re.match(value) > TypeError: expected string or bytes-like object I'm not certain, but it looks like one of the held messages has a bad or possibly missing Date: header. Working around this is tricky. You can do the following in mailman shell. ``` $ mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list >>> requests = IListRequests(m) >>> msgstor = getUtility(IMessageStore) >>> for request in requests.held_requests: ... key, data = requests.get_request(request.id) ... if data['_request_type'] == 'held_message': ... print(f'request ID = {request.id}Message-ID = {key}\n ' ... f'message = {msgstor.get_message_by_id(key)}') ... This will print for each held message output like request ID = nnn Message-ID = <the message id> message = the message content You can then handle these messages with >>> from mailman.app.moderator import handle_message >>> handle_message(m, nnn, action) where nnn is the request ID and action is either Action.discard to discard the message or Action.accept to accept it. And finally >>> commit() ``` If you decide you want to edit the message content before accepting it, you could find the message in the file system. One of the headers in the displayed message is something like Message-ID-Hash: IWL2EUW3FT7IIUA3QYTZEX4W4JBZ26HL the message is saved as a python pickle in the file system in Mailman's var/messages/ directory. This has subdirectories of the first two characters of the Message-ID-Hash value and those have subdirectories of the second two characters of the Message-ID-Hash value, so if the above were the actual Message-ID-Hash the pickle would be at var/messages/IW/L2/IWL2EUW3FT7IIUA3QYTZEX4W4JBZ26HL. You would need to pickle the new message content and save that over the existing file. -- 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

[MM3-users] Re: Mass change Digest delivery mode

by Jered Floyd

This is, sadly, correct. I miss the open web, but the finance-bros ruined it for everyone. If you want, you can configure it so only the account creation page is protected by Anubis. This might be a happy medium... JavaScript is only required for the vulnerable step (which would also be the case with most captchas today). --Jered ----- On Aug 5, 2026, at 12:52 AM, Mark Sapiro mark(a)msapiro.net wrote: > On 8/4/26 9:34 PM, iMark wrote: >> >> Le 2026-08-05 04:02, Mark Sapiro a écrit : >> >>> In Python, block structure is defined by indentation which is >>> critical. In interactive mode, a `>>> ` prompt indicates you are at >>> the outer level and a `... ` prompt indicates you are in a block. >>> >> >> >>> The complete interaction should look like >>> ``` >>>>>> for member in m.members.members: >>> ... if member.delivery_mode != DeliveryMode.regular: ... >>> member.delivery_mode = DeliveryMode.plaintext_digests >>> ... >>>>>> commit() >>> ``` > > > Note the above has a formatting error. See my followup post correcting that. > > >> I got to the last line ( member.delivery_mode = >> DeliveryMode.plaintext_digests ) and entered it to then get the ellipsis >> (as you've shown). >> >> What happens after that so I can get back to the outer level (>>>>) and >> commit ? >> >> If I hit Enter, I get this error > > Enter is the appropriate thing. It then runs the block. > >> ... >> Traceback (most recent call last): >> File "<console>", line 3, in <module> >> AttributeError: property 'delivery_mode' of 'Member' object has no setter > And upon running the block it encounters the above error. Unfortunately > when I tested this, I tested on a list with only regular members and > didn't encounter the error. > > The last line > ``` > member.delivery_mode = DeliveryMode.plaintext_digests > ``` > needs to be > ``` > member.preferences.delivery_mode = DeliveryMode.plaintext_digests > ``` > > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to jered(a)convivian.com

2 weeks, 1 day

[MM3-users] Re: Bulk delivery status change?

by Stephen Daniel

The -C ...mailman.cfg fixed it. Thanks!!! On Sun, Nov 10, 2024 at 8:31 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 11/10/24 08:58, Stephen Daniel wrote: > > If I run > >>>> for mlist in getUtility(IListManager): > > ... print(mlist) > > ... > > <mailing list "testlist1(a)chapelwoodhoadev.org" at 0x7f83f593fba8> > > I get only one list. Permissions? Where are the other lists? > > > It should get all the lists. I don't know why it doesn't. Are you > running `mailman shell` with the correct configuration. Try running > ``` > mailman -C path/to/mailman.cfg shell > ``` > and see if that helps. > > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to swd(a)pobox.com >

1 year, 9 months

[MM3-users] Change to content filtering collapse alternatives - was: Re: Mailman shutting down Hyperkitty: Request too large

by Mark Sapiro

On 2/1/25 03:08, Stephen J. Turnbull wrote: > Mark Sapiro writes: > > > Not if we're collapsing alternatives. If we're collapsing a > > multipart/alternative part with text/plain and text/html > > alternatives to just the first alternative we don't keep the > > text/html part. > > I understand that's what we currently do. But I think that when the > MUA provides an empty plain text part and a non-null HTML part, that's > a mark of lazy MUA developers, not author intent. I think that it's > very likely that the author would prefer the reader get converted HTML > rather than a blank. I think this is a request to change the collapsing of alternatives to not collapse to the first alternative if it is empty and a subsequent alternative is not. I see your point in general if the poster composes an HTML message and the MUA makes a multipart/alternative message with an empty text/plain part, but are there actually MUAs that do that? All the ones I'm aware of either make an HTML only message or attempt to make a reasonable text/plain alternative. Even Yahoo mail which does a horrible job of making the text/plain part (i.e. links which are copy/pasted in the HTML are dropped from the plain text) does make one. That said, the effect on the OP's case, which may be more common, may be harmful depending on list and Mailman config. The original message from the OP (edited) is ``` Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1" --000000000000da2dcc062cb38aa1 Content-Type: multipart/alternative; boundary="000000000000da2dcb062cb38aa0" --000000000000da2dcb062cb38aa0 Content-Type: text/plain; charset="UTF-8" --000000000000da2dcb062cb38aa0 Content-Type: text/html; charset="UTF-8" <div dir="auto"><img src="cid:ii_194a8d787554eb091f02" style="max-width: 100%; height: auto;"><br><br></div> --000000000000da2dcb062cb38aa0-- --000000000000da2dcc062cb38aa1 Content-Type: image/jpeg; name="1000013462.jpg" Content-Disposition: inline; filename="1000013462.jpg" Content-Transfer-Encoding: base64 Content-ID: <ii_194a8d787554eb091f02> X-Attachment-Id: ii_194a8d787554eb091f02 <base64 content> --000000000000da2dcc062cb38aa1-- ``` The HTML alternative only renders the jpg as an inline image. After current collapse alternatives this becomes ``` Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1" --000000000000da2dcc062cb38aa1 Content-Type: text/plain; charset="UTF-8" --000000000000da2dcc062cb38aa1 Content-Type: image/jpeg; name="1000013462.jpg" Content-Disposition: inline; filename="1000013462.jpg" Content-Transfer-Encoding: base64 Content-ID: <ii_194a8d787554eb091f02> X-Attachment-Id: ii_194a8d787554eb091f02 <base64 content> --000000000000da2dcc062cb38aa1-- ``` which is an empty first part followed by the jpg part which is then further collapsed to just the jpg part ``` Content-Type: image/jpeg; name="1000013462.jpg" Content-Disposition: inline; filename="1000013462.jpg" Content-Transfer-Encoding: base64 <base64 content> ``` I.e. a single part message with content type image/jpeg. If instead we collapsed the alternatives to the HTML part the message becomes ``` Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1" --000000000000da2dcc062cb38aa1 Content-Type: text/html; charset="UTF-8" <div dir="auto"><img src="cid:ii_194a8d787554eb091f02" style="max-width: 100%; height: auto;"><br><br></div> --000000000000da2dcc062cb38aa1 Content-Type: image/jpeg; name="1000013462.jpg" Content-Disposition: inline; filename="1000013462.jpg" Content-Transfer-Encoding: base64 Content-ID: <ii_194a8d787554eb091f02> X-Attachment-Id: ii_194a8d787554eb091f02 <base64 content> --000000000000da2dcc062cb38aa1-- ``` and what that html part looks like after conversion to plain text depends on the configured command. With the default lynx the content is unchanged, put the type is text/plain which will render as the text with the image attached. With links the plain text content is empty which results again in a message with empty first part and image/jpeg second part. In short, for this message at least, I see no real advantage to dropping the empty text/plain alternative vs. dropping the text/html alternative. Possibly there is a difference if we don't convert HTML to plain text in that some MUAs might render the jpeg inline as opposed to an attachment, but if we do convert with lynx the recipient sees a message with a body which is HTML tags rendered as text. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by Mark Sapiro

On 1/28/21 5:33 AM, David Partain via Mailman-users wrote: > I wrote: >> I have the same issue, and have changed the configuration in /etc/mailman3/mailman-web.py to: >> >> DATABASES = { >> 'default': { >> 'ENGINE': 'django.db.backends.mysql', >> 'NAME': 'mailman3web', >> 'USER': 'mailman3web', >> 'PASSWORD': 'xxxxxxxxxxxxxxxxxx', >> 'HOST': 'localhost', >> 'PORT': '', >> 'OPTIONS': { >> 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", >> 'charset': 'utf8mb4', >> }, >> } >> } >> >> and restarted stuff, but I cannot tell that it has changed anything. > > You responded: >> That should do it. I think the original message should have been saved >> as a queue entry in Mailman's var/archives/hyperkitty/spool/ directory. > > That directory has all of the messages sent to that list: > > # ls /var/lib/mailman3/archives/hyperkitty/spool/ > 1611827925.8030825+925c996b9b6020ee18e9a689ce23384855159f77.pck 1611827926.1923075+e728f3c29c1fe6eeeca641314cdba7007cb6e132.pck > 1611827925.8917305+d16b7004bdbbef98ce40fb8ee70e492715d1607d.pck 1611827926.2623458+1aac13b50d8e7f32eb14d13e6559656aa8f3bd10.pck > 1611827925.9594557+7ad2a910b5ee9142c88f0bf26c60c6df960d4262.pck 1611827926.3488555+04a540651c5f829751518433e1c54168ab63a38b.pck > 1611827926.0404096+a5e745f51a9f7d541aeb770a89604be17019f3c5.pck 1611827926.4206145+de861eec6404d0c8f9f8bdb180e29bff2de7c52b.pck > 1611827926.1167526+0aa63639a4ec102bf63522827637e75e6a2b092a.pck This is what's expected since the underlying issue isn't yet fixed. > Yes, I'm still seeing the errors. When I send mail to a list with a cute emoji, I see the following in /var/log/mailman3/web/mailman-web.log: > > ERROR 2021-01-28 10:58:45,708 16923 django.request Internal Server Error: /mailman3/hyperkitty/api/mailman/archive > (bunch of python errors omitted) > DataError: (1366, u"Incorrect string value: '\\xF0\\x9F\\x98\\x8A\\x0A\\x0A...' for column 'content' at row 1") OK. The issue is with your database it doesn't like '\xF0\x9F\x98\x8A' which is a 4-byte utf-8 encoding for a smiley face emoji. The issue is with MySQL and MariaDB which do not accept 4-byte utf-8 encodings by default. The settings you show above should be sufficient to allow 4-byte utf-8 encodings. I'm not that familiar with how the Debian/Ubuntu package sets things up. Are you sure that /etc/mailman3/mailman-web.py is the settings file used by Django, and if so does it have at the end something like ``` try: from settings_local import * except ImportError: pass ``` and if so is there something there that overrides the DATABASES setting? If all that is OK, you may need to do something like ``` ALTER DATABASE mailman3web CHARACTER SET utf8mb4; ALTER TABLE hyperkitty_email CHARACTER SET utf8mb4; ``` on the database itself. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

Regarding this: # To be added to Django's settings.py EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' EMAIL_HOST = 'localhost' EMAIL_PORT = 25 EMAIL_HOST_USER = <username> EMAIL_HOST_PASSWORD = <password> What should I use for username and password? Should I keep the localhost on the host param? Thanks El mar., 25 jul. 2017 a las 15:10, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/25/2017 12:58 PM, Rafael Mora wrote: > > I got this error starting mailman service: > > > > > > [mailman@localhost ~]$ source env2Traceback (most recent call last): > > File "/usr/local/lib/python3.6/asyncio/base_events.py", line 1043, in > > create_server > > sock.bind(sa) > > OSError: [Errno 99] Cannot assign requested address > ... > > What do you think? > > > I think you have configured > > lmtp_host: mail.example.com > > which is wrong. > > -- > 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/ > -- Atentamente / Best Regards Ing. Rafael Mora

9 years

[MM3-users] Re: Mailman3 not delivering list mail

by Mark Sapiro

On 10/1/20 11:18 AM, gordon(a)dickens.com wrote: > Hi Mark, > > I have errors like these in the mailman3 logs but they occurred earlier (that is prior to my attempting to post messages to the new mailman3 mailing list and which are not echoed to list members): > > > Oct 01 11:08:22 2020 (7895) Skipping and preserving unparseable message: 1601564901.8696995+c2b86623e2dcc8e9800b10ca2bcf8b82e8d8d662 > Oct 01 11:08:23 2020 (7895) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman3/queue/virgin/1601564902.28165 > 63+16bd684dfb18c6175f3e7b0b11312cb203dc9c89.pck' > Oct 01 11:08:23 2020 (7895) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 158, in _one_iteration > msg, msgdata = self.switchboard.dequeue(filebase) > File "/usr/lib/python3/dist-packages/mailman/core/switchboard.py", line 150, in dequeue > with open(filename, 'rb') as fp: > PermissionError: [Errno 13] Permission denied: '/var/lib/mailman3/queue/virgin/1601564902.2816563+16bd684dfb18c6175f3e7b0b11312cb203dc9c89.pck' These relate to the messages in the `bad` queue. It seems there is/was andn issue with ownership and/or permissions on some directory or directories is the path `/var/lib/mailman3/queue/virgin`. Is mailman3, queue and virgin user and group `list` and searchable, readable and writable by `list`. Are all the runners running as user `list` ps -fwwA|grep runner > The above errors occurred prior to the time that I attempted to send to the mailman3 list. However, here is what I see in the logs immediately after I sent a message to the list and which was not then echoed to list members: > > > Oct 01 11:51:03 2020 (7888) ACCEPT: <f92eeaad-245c-124b-dd09-b31a6b3c5686(a)dickens.com> > Oct 01 11:51:07 2020 (7885) HyperKitty archived message <f92eeaad-245c-124b-dd09-b31a6b3c5686(a)dickens.com> to https://georgiajets.org > /mailman3/hyperkitty/list/members(a)georgiajets.org/message/NUOU6UQ6DSHSK2WKNVZFIN5AELK5EYBU/ > Oct 01 11:51:07 2020 (7891) Cannot connect to SMTP server localhost on port 25 This is delivery of the outgoing message which looks like it was successfully archived. These messages come from `/var/lib/mailman3/queue/out` and after the failure are put in `/var/lib/mailman3/queue/retry` and periodically are moved back to the `out` queue and tried again. > Please note the message about the SMTP server not being able to connect to local host on port 25. Please let me know what you think is wrong and how to fix it. Normally it means exactly what is says. Is your MTA (Postfix or ??) running? Can you `telnet localhost 25` successfully? Note that if the message actually says `local host` and not `localhost`, the setting for smtp_host in the [mta] section of mailman.cfg needs to be fixed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Upgrade

by Mark Sapiro

On 5/22/19 2:07 PM, David Krantz wrote: > Hi all, > > I am running a relatively old version of mailman 3, namely 3.2.0a1 > from late september 2017. This is installed using the old > mailman-bundler method. I use postfix and postgres. > > I really have two questions: > > First: What is the normal way to upgrade such a setup? I guess that I > just can get the updated versions of all packages through git, set up > new venv's to simplify a rollback, back up the database and then just > restarting with the new version hoping for the best. That's more or less correct. I did this on mailman3.org a little over a year ago. I suggest you see <https://wiki.list.org/DOC/Mailman%203%20installation%20experience> which describes much of what I did. you can also see <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=re…> for what I had with Mailman Bundler. The biggest hurdle is now Postorius and Hyperkitty are Python3 so you need Python3 versions of various dependencies. Here's roughly what I did. git clone everything from GitLab. As a developer, I've always been running off the heads. There are occasional glitches, but I can work around these. You can also install from PYPI if you want more stability. Everything is mailman, mailman-hyperkitty, mailmanclient, django-mailman3, hyperkitty and postorius. But, I'm getting ahead. Create a new python3.5+ virtualenv. Python3.5 is the minimum, but 3.6 or 3.7 would be even better. Activate that virtualenv and if you are using the branches from GitLab, in each branch directory, do python setup.py clean --all python setup.py install or just pip install everything. You also need to do the things indicated in the Preliminaries and Installation sections of <https://wiki.list.org/DOC/Mailman%203%20installation%20experience>. Also see the Migration section for scripts I use to update from GitLab and build 'everything' and the rest of the document too. Then once you have things set up, it's pretty much a matter of just updating the various scripts you use to run things to point to the new command files in, in my case, /opt/mailman/mm/bin/. One caveat to note is if you are using the Whoosh backend. The Python2 version is incompatible with Python3 so you need to remove the fulltext_index directory and run the django management rebuild_index command to recreate it. You should be able to just run rebuild_index or maybe clear_index followed by update_index without removing the old index first, but there are reports that this doesn't work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 2 months

Search results for query "sapiro"