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

[MM3-users] Re: Problems with New MM3 Installation

by Mark Sapiro

On 5/11/21 7:46 PM, Jeff wrote: > > I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation: > > 1) some emails that arrived before I got the archive working are still sitting in: > > /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new > > Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared? /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a collection of messages in maildir format. This is how the prototype archiver stores messages. This has nothing to do with HyperKitty. It is a separate archiver. If you don't want messages to be stored there, you can disable the prototype archiver for the list by unchecking prototype in Postorius -> Settings -> Archiving -> Active archivers or disable it entirely for the installation by setting ``` [archiver.prototype] enable: no ``` in mailman.cfg > 2) Some messages that arrived while I was having other problems with the setup have been stored in: > > /usr/local/mailman3/mm/var/queue/shunt > > What should I do to get these messages processed? Assuming the issues that caused them to be shunted have been fixed, just run the command ``` mailman unshunt ``` > 3) Similar to above, some messages are in: > > /usr/local/mailman3/mm/var/queue/bad > > How can I get these messages processed? First examine the messages with ``` mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file> ``` To be sure you want them. Also examine mailman.log for the times they were stored in the `bad` queue. You are looking for 'Skipping and preserving unparseable message: <file>' and/or 'SHUNTING FAILED, preserving original entry: <file> messages and you want to determine which runner preserved the message. There may be a 'whichq' entry in the message's metadata in which case, that's the answer. Once you have determined the queue, you can just move the .psv file from the bad queue to the appropriate queue, renaming it from .psv to .pck in the process. > 4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else? I know little about uwsgi. setting it to `uwsgi://localhost:8000` might work. You could also set it to the base URL that a user would use to access the web UI, e.g. `https://example.com` and that would presumably be proxied to uwsgi. For example, on the server for this list we have ``` POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org' ``` which gets proxied to gunicorn, but the idea is the same. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: old usernames appearing in mailman.log

by Mark Sapiro

On 6/25/23 10:57 PM, Ken Alker wrote: > > I have studied the output, looked at the code lines referenced in the > Traceback, and I can't figure out the problem (I feel like the sad guy > on the side of the street with his hood up staring into the engine bay > with stream pouring out and not knowing what to do next). I did some > analyses on the log file and determined that there are 71 messages it is > having problems processing and there are 71 messages "stuck" in > /opt/mailman/mm/var/archives/hyperkitty/spool/ (and that it has tried to > process each message about 20 times). Each time there is a new post, it retries all the messages in the spool/ directory. > Since upgrading to V3.3.8 I've > not seen new messages get stuck like this (although it's only been > running smoothly for 24 hours now and there hasn't been much activity). > But I'm suspecting there was something awry between the conversion from > V2 to V3 in February and me installing V3.3.8 that caused this (based on > message time stamps). It is HIGHLY likely these messages are in the > archiving spool as a result of me unshunting the shunt queue and that > they are copies of the messages that got delivered to the subscribers > when I did that... but are now hung up in the archiving process. Are new messages being archived OK. If so, that is a real mystery. It says mailman-hyperkitty can talk to hyperkitty and archive new messages, but it can't talk to hyperkitty when attempting to process a queued message. > Following is an excerpt from mailman.log. Note that the "first section" > (from DOCTYPE at top to 404 at bottom) is repeated four times (maybe not > identical; but similar) (so I did not include it to save room) before > the Traceback appears. > > Jun 25 00:13:04 2023 (386086) No cached copy of the public suffix list > found > Jun 25 00:13:04 2023 (386086) ACCEPT: > <7500f0e2-1ae1-309d-60d7-6e592c7abf7a(a)west.net> > Jun 25 00:13:04 2023 (386090) HyperKitty failure on > https://lists.netlojix.com/hyperkitty/api/mailman/urls: I just went to that URL and got a 404. This is a serious problem. https://lists.netlojix.com/hyperkitty/api/ also returns a 404. It should return some documentation of the API. https://lists.netlojix.com/archives/api/ does work and returns the expected information. Your urls.py file probably contains in its urlpatterns list ``` re_path(r'^mailman3/', include('postorius.urls')), re_path(r'^archives/', include('hyperkitty.urls')), ``` The simplest fix is to add ``` re_path(r'^postorius/', include('postorius.urls')), re_path(r'^hyperkitty/', include('hyperkitty.urls')), ``` to that list. Another way to fix this is in your mailman-hyperkitty.cfg, you have ``` base_url: https://lists.netlojix.com/hyperkitty ``` Change that to ``` base_url: https://lists.netlojix.com/archives ``` but it wouldn't hurt to add the `^postorius/` and `^hyperkitty/` patterns to urls.py anyway. -- 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: Changing default message limit (max_message_size)

by Abhilash Raj

On Mon, May 27, 2019, at 8:23 AM, Mark Sapiro wrote: > On 5/27/19 12:05 AM, roger(a)reasonal.com wrote: > > I found the field in settings that would appear to do this, but it just throws an error for whatever I give it ("An error occured**: Unknown attribute: max_message_size"). > > This should be fixed at > <https://gitlab.com/mailman/mailman/merge_requests/329>. > > Perhaps you need to update your Docker images > <https://asynchronous.in/docker-mailman/> That's right. You are probably using a new version of Postorius but not of Mailman Core. Please make sure the container images you have are updated. > > Also, see > <https://gitlab.com/mailman/postorius/issues/246#note_69323948> for a > not about changing this via `mailman shell` (withlist), but see the > subsequent comment about `quit()` > > > > PS As a suggestion, may be a good idea to indicate what units it's expecting... bytes? kB? Nybbles? > > Reported at <https://gitlab.com/mailman/postorius/issues/362>, thanks. > > > PPS ** Psst: occurred with two r's... > > Reported at <https://gitlab.com/mailman/postorius/issues/361>, thanks. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

7 years, 4 months

[MM3-users] Re: Apache Conf

by Thomas G

Hi tried both. Same result. xxxx - - [19/Oct/2018:21:14:22 +0200] "GET /static/postorius/js/script.js HTTP/1.1" 404 4051 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" Le ven. 19 oct. 2018 à 18:59, Mark Sapiro <mark(a)msapiro.net> a écrit : > On 10/19/18 10:29 AM, Guiseppin Thomas wrote: > > Hi, > > Currently, I use a nginx configuration for mailman. It's work perfectly. > > > > I tried to do the same with Apache, but the statics files are not > > delivered (404). > ... > > <VirtualHost *:80> > > ServerName mailing.ddd.fr > > > > ErrorLog ${APACHE_LOG_DIR}/mailing.error.log > > CustomLog ${APACHE_LOG_DIR}/mailing.access.log combined > > > > <Location /static/> > > Alias "/opt/mailman/static/" > > </Location> > > > > <Location /> > > ProxyPass http://localhost:8000/ > > ProxyPassReverse http://localhost:8000/ > > ProxyPreserveHost On > > </Location> > > </VirtualHost>/ > > > In Apache, location > <http://httpd.apache.org/docs/2.4/mod/core.html#location> is not > appropriate for resources in the file system. > > Try > > Alias /static/ /opt/mailman/static/ > > not within a location block. > > -- > 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/ >

8 years

[MM3-users] Re: Link in the top-left corner of Hyperkitty

by Gelpi Andrea

Il 08/05/20 17:13, Mark Sapiro ha scritto: > On 5/8/20 8:06 AM, Seth Seeger wrote: >> On May 8, 2020, at 10:58 AM, Mark Sapiro <mark(a)msapiro.net> wrote: >> >>> You have to edit the display name for the domain in the Django web admin >>> Sites section. >> >> Huh. I had it properly set for the domain that is active, but it wasn’t taking affect. I changed it for the (old) test site, and it changed it. So the name that is showing doesn’t match the domain name that I was changing it for. > > > It should show the display name corresponding to the domain name that > matches the domain in the URL that you go to. If this doesn't seem > correct, perhaps there is some issue with the way you are proxying in > your web server. > Also in debian there is the some problem. The domain name is that of the installation site (example.com) and does not change if you change the webserver and the domian. It seems to be static. You can change it changing the site name in django admin console, but it doesn't change if you change the webserver name. Which file does provide it? Thanks -- Gelpi ing. Andrea -------------------------------------------------------------- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. --------------------------------------------------------------

6 years, 5 months

[MM3-users] Re: Apache+mod_wsgi issue

by Odhiambo Washington

On Tue, Dec 27, 2022 at 1:58 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/26/22 11:08, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > > El 26/12/22 a las 19:19, Mark Sapiro escribió: > >> On 12/26/22 07:42, Odhiambo Washington wrote: > >> > >>> Hi @Guillermo Hernandez (Oldno7) <guillermo(a)querysoft.es> > >>> > >>> Does your https://site.name/user-profile/ work? > >> > >> Again, Guillermo is using uWSGI, not Apache mod_wsgi > > > > Well... now I am not sure, you know I've been confused before about that. > > > I was looking at what you posted at > https://forums.freebsd.org/threads/mailman-3.61050/#post-488128. I > focused on the part beginning with > > - initiated the uwsgi with a > /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini & > [snip] Based on the above you ARE using Apache mod_wsgi and if you are still > also running uwsgi as > > /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini & > > that is unnecessary. > Aha. This is interesting. I have been running the same, although via supervisord, thinking that it is necessary. So, this was a confusion! And it looks pretty easy to confuse mod_wsgi with uwsgi when dealing with the ever-evolving monster that most of us have been facing in MM3 over the years :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 9 months

[MM3-users] Re: using SSH/TLS with external MTA

by Odhiambo Washington

On Sat, Jul 27, 2024 at 11:02 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/27/24 01:32, Roland Giesler via Mailman-users wrote: > > On 2024/07/25 20:50, Mark Sapiro wrote: > >> > >> It is the mail server at box2.gtahardware.co.za that is refusing to > >> relay this message. I think this issue needs to be resolved in that > >> MTA's configuration. > > > > Indeed that is so, but that box is in daily use by a few different users > > and they authenticate and send email without any problems. I'm checking > > out the link you shared in my other thread now. > > Since I think you said the MTA at box2.gtahardware.co.za is Postfix, you > probably need to add the IP of the Mailman server to mynetworks in > Postfix main.cf on box2.gtahardware.co.za. > ASMTP works on the premise of "we can relay mail for you if we can authenticate you with certain credentials" Adding the IP to "hosts we can relay mail for" negates the need to authenticate, IMHO. So I am still waiting for how MM3 does ASMTP. Does it? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 2 months

[MM3-users] Re: Block members from sending cc's and bcc's

by Mark Sapiro

On 11/14/25 15:36, Cathryn McGuire wrote: > Hi Mark, > > "It appears in your case that Gateway to news is Yes and Newsgroup > moderation is Moderated" > > I don't see any Gateway to mail or Gateway to news, but Newsgroup moderation was set to Moderated (as you said). I changed it to Not Moderated. That's good. As I've said, I don't know what the affinity UI looks like. If you send me (off list) a screen shot of the page where you see Newsgroup moderation, I can advise you further, but basically, anything to do with Newsgroups should be set to Off or No. > In the following case, they are cc'ing to the mailist, and To: is to a member. Sometimes they are not members. Sometimes they To: to the mailist and cc: to the member or non-member. > > Subject:Re: [Neighbours] Furnace problems > To:Bill McCreery <billmccreery1(a)gmail.com> > Cc:neighbours@mailist.dunbar-vancouver.org > Content-Type:multipart/alternative; boundary="000000000000f9e5900643322d20" > X-MailFrom:dunontime@gmail.com > X-Mailman-Rule-Hits:header-match-neighbours.mailist.dunbar-vancouver.org-0 > X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation My understanding is you want to hold for moderation any message with a Cc: unless it it To: the list with a Cc: to a member, and I said that with what's available to you in the list's settings, you can't distinguish between Cc: to a member and Cc: to a nonmember, so you have to hold any message with a Cc: > "If the reason was actually what is posted above with 'neighbors' > rather than 'cc:', that's a problem with EMWD's Mailman core." > > Does that mean that any cc: to neighbours or to a member or non-member should be blocked (held)? > Or, does that mean if the cc: is to neighbours, it should be allowed through? That quote was in response to your post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… wherein you said > The message is being held because: > > Header "neighbours > > <neighbours(a)mailist.dunbar-vancouver.org>" matched a > header rule I thought that was a typo and the real reason was Header "Cc: <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. If that was the case, it was expected and was due to your header filter on Cc: headers. My confusion was I couldn't see how the reason could have been Header "neighbours <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. And if it was, that was an EMWD issue. I think the header rule you have will hold any post with a Cc: to anywhere. If you want to not hold posts with a Cc: <neighbours(a)mailist.dunbar-vancouver.org> regardless of To:, you can do that by adjusting your header rules, but I don't think you want that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months

[MM3-users] Re: How to Unshunt Specific Message ?

by Shashikanth Komandoor

Hahahaha. Looks like a work around. I understood "moving out of the shunt queue" means "Moving the files from /var/lib/mailman/mailman/var/shunt directory to any other directory say /opt/...." in my environment. Because I installed mailman software inside /var/lib/mailman only. Please correct me if I am wrong. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Tue, Aug 11, 2020 at 8:49 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 8/11/20 1:46 AM, Shashikanth Komandoor wrote: > > > > I learnt how to unshunt the messages that got unshunted in > > mailman 3. But the command *mailman unshunt* would unshunt all the > messages > > in the shunt queue. > > > > I want only a specific message to be unshunted and resent. I > > don't find my requirement reached with the help of *mailman unshunt*. > > > You need to move all the unwanted messages out of the shunt queue before > running unshunt. > > > -- > 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/ > -- Thanks & Regards, Shashi Kanth.K 9052671936

6 years, 2 months

[MM3-users] Re: Digests not working correctly

by Mark Sapiro

On 6/4/23 11:45, Joel Lord wrote: > So I seem to have problems with both periodic AND size-triggered > digests. Size first, this is simpler. Just got one sent out, clearly > triggered by a new email getting added to the queued up messages, but > the setting for the list is the default 30KB and the digest came out at > 23.2 KB. Is it measuring the accumulated queue as size on disk > including metadata and filesystem block sizes or something, rather than > the size of what the emailed digest will be? The threshold is determined by the size in bytes of the MMDF format mailbox file in which the the messages for the digest are saved. This does not include metadata and is not affected by block sizes. It contains the raw messages with all headers and 8 bytes of message separators per message and a 'From ' line per message. Once the digest is triggered, the messages are configured into a digest message with boilerplate, a TOC and possibly a header and/or footer added. The messages themselves may be added as separate MIME message/rfc822 parts to a mime format digest or added as text to a plain format digest. Many headers are removed as the messages are added. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.…> for what is kept. In addition any non text/plain parts in the message are not included in the plain format digest, but are replaced by notes that they have been removed. All this says that a MIME format may be larger or smaller than the threshold depending on the size of the removed headers vs. the added parts, and a plain text digest will probably be smaller if the messages have non text/plain parts, e.g. if content filtering doesn't collapse alternatives and leaves the text/html alternative part, this part will not be in a plain format digest. > Periodic is much more complicated, even to explain. I have the cron job > running nightly at 11:00 PM and it certainly seems to be working, except > for one really odd thing. The list also definitely has periodic digests > enabled in the web UI. This is a very bursty list, so it will go mad > with traffic for a few weeks and then will go mostly idle for a month or > so. The first digest of a burst is definitely size-triggered, but > pretty reliably it has the last few messages from the previous burst in > there. So the one I got today had three messages from today and one > message from May 4th. But that May 4th message should have gone out at > 11:00 PM on May 4th with the daily digest and then gotten flushed from > the pending digest queue, right? That's correct. Do you ever get periodic digests sent at 11:00 PM? If not, there is some issue either with configuration or something. If you get them sometimes, I don't know what could be wrong. -- 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

Search results for query "sapiro"