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

[MM3-users] Re: MM3 Postfix FROM header issue

by Mark Sapiro

On 12/18/23 12:18 PM, eboltz(a)lhtservices.com wrote: > Mark, > > I don't think the setup will work, as the client uses O365 for the emails and doesn't appear to like the virtual lists domain on the MM3 server. I've tried both using the O365 email connector as well Smtp2Go, both have the same issue with headers. > > real email domain = example.org > MM3 virtual domain = lists.example.org Actually, lists.example.org is a real email domain. > The FROM: header is always what's causing the issue, plus it doesn't like any external emails as it can't send held messages or posts to users outside of the example.org domain. If you want to use these 3rd party smtp relays, you have to configure them to accept mail from the lists.example.org domain. It should not be difficult, but it is not a Mailman issue. It is strictly an issue with configuring the 3rd party relay to accept the mail. -- 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: Clearing webserver cache - Nginx

by Mark Sapiro

On 8/5/24 10:30, Odhiambo Washington via Mailman-users wrote: > > Actually, what I mean is that CF is proxying requests to the host named > m3-lists.kictanet.or.ke. > I do not have any configuration other than DNS proxying at CF. ``` dig a mm3-lists.kictanet.or.ke ... mm3-lists.kictanet.or.ke. 300 IN A 172.67.167.73 mm3-lists.kictanet.or.ke. 300 IN A 104.21.11.217 ``` Both of those are cloudflare IPs, and why 2? > So when you talk to m3-lists.kictanet.or.ke via a browser, it's CF IP who > you talk to and it in turn talks to the host directly. And how is that configured? > So the IP address you see in the logs is CF's IP address, not yours, not > mine and CF are doing some caching. That's why > they are requesting for expired files. Why is cloudfare trying to access /opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css locally if all it is doing is proxying the request to the actual mailman server? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 3 weeks

[MM3-users] Re: Login confusion

by Mark Sapiro

On 2/11/25 01:26, Stephen J. Turnbull wrote: > > That will work in the short run, but I'm not sure that's a long-term > solution. It's not clear to me that allauth won't do the same thing > again. Allauth since 0.62.0 and better since 0.63.0 no longer does this. See https://codeberg.org/allauth/django-allauth/src/branch/main/ChangeLog.rst#s… > > Could I have achieved the same deletion using the REST interface? > > I don't know. I would think not. That's correct. The issue is in the account_emailaddress database table which is an allauth table that Mailman core and hence the REST api know nothing about. Our latest recommendation is django-allauth>=65.4, but that requires changes, see https://gitlab.com/mailman/django-mailman3/-/merge_requests/316 and https://gitlab.com/mailman/mailman-web/-/merge_requests/58 although the changes only affect testing and a deprecation warning. Also, installing that django-allauth version may result in upgrading Django to a version which doesn't support django-haystack<3.3.0 and may also require manually upgrading django-haystack. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months, 2 weeks

[MM3-users] Re: How to separate bans for sending emails to lists and subscribing to them

by Mark Sapiro

On 5/29/19 9:29 AM, Nathan Dixon wrote: > Hi, > Our requirements for using Mailman are that we can have non-members send an > email to a list from any domain name, but only people who's email addresses > match a list of specific domains should be able to actually subscribe to > those lists. > > I can't seem to find any way of doing this. Any ideas? > > I have tried using the bans (global and on each list) but these appear to > stop all subscriptions and emails being sent to or from a list if the > address matches a ban. Right. The default posting rules chain includes 'banned-address' which discards posts from banned addresses. You can work around this by creating a new chain based on mailman/chains/builtin.py but without the 'banned-address' rule and setting the list's posting_chain to use it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

[MM3-users] Re: If you delete a list but not the HyperKitty archive

by Mark Sapiro

On 1/4/22 6:45 AM, Philip Colmer wrote: > > So ... should the archive be deleted when the list is deleted and it is a > bug that it isn't? Or is it expected that access to the archive is "frozen" > once a list is deleted? It is often desired to have a public archive available after the corresponding list has been deleted. Even for a private archive, it may be desirable for site admins to have access. Furthermore, a list might not even have a HyperKitty archive in the first place. Thus, what to do about a HyperKitty archive (or prototype archive or ...) when a list is deleted is an administrative decision and is best left up to the site admins to do it or not. As you note with a private archive, former members no longer have access when the list is gone, but unless an attempt throws some uncaught exception, that is not a bug. -- 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: Apache+mod_wsgi issue

by Mark Sapiro

On 12/26/22 07:08, Odhiambo Washington wrote: > > So it seems your WSGIDaemonProcess is defined somewhere outside the VHOST, > right? Or it wasn't necessary? > And what does your urls.py look like? Eggert's configuration is for uWSGI. This is completely different from Apache mod_wsgi. Background: Python PEP 333 defines the Python Web Server Gateway Interface (WSGI) which is a protocol for communication between web servers and applications. Django is one such WSGI application. Basic web servers typically do not support WSGI directly but need some kind of intermediary. Apache mod_wsgi is an Apache module that extends Apache to communicate with WSGI applications. Both uWSGI and gunicorn are separate applications that can receive http requests via proxy from a web server and communicate them to a WSGI application and receive responses from the application and return them to the web server. Thus Apache mod_wsgi, uWSGI ang gunicorn are three separate ways of providing the connection between the web server and Django (or other WSGI applications), each with their own separate configuration requirements. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

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

by Mark Sapiro

On 9/23/23 19:19, Mark wrote: > > Yes, the query returns a result and the case in "name" matches that in > the query ... > > select * from hyperkitty_mailinglist where name like 'listname(a)domain.com' > > id | 91 > name | listname(a)domain.com > display_name | Listname > description | ... > subject_prefix | [Listname] > archive_policy | 1 > created_at | 2023-09-21 08:55:36.385239+2 > list_id | listname(a)domain.com Is that really what you get for list_id? It should have a dot, not at as listname.domain.com. What if you do something like the following where django-admin is whatever command you use for the Django admin command. ``` $ django-admin shell Python 3.9.16 (main, Dec 11 2022, 12:49:23) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from hyperkitty.models.mailinglist import MailingList >>> mlist_name = 'listname(a)domain.com' >>> mlist = MailingList.objects.get(name=mlist_name) >>> mlist <MailingList listname(a)domain.com (listname.domain.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, 9 months

[MM3-users] Re: out queue backlog and delivery rate

by Mark Sapiro

On 4/8/22 09:47, dancab(a)caltech.edu wrote: > For anyone coming across this thread. It seems increasing the runners did the job for us. The smtp.log is now showing smaller lists being completely processed while larger lists are still in progress of sending out to members. > > We edited the mailman.cfg to include the following and the mailman stop; mailman start > > [runner.in] > class: mailman.runners.incoming.IncomingRunner > instances: 2 There's probably no issue that would be helped by increasing in runner instances. > [runner.out] > class: mailman.runners.outgoing.OutgoingRunner > instances: 2 I would suggest larger, 4 or even 8. This is not a single queue/multiple server setup. It is multiple queue/multiple server. I.e. The queue entries are named based on a hash of the message and each instance processes its own slice of the hash space. So, with 2 slices and a large recipient message being processed, there's a 50% chance that the next message will wind up waiting. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 2 months

[MM3-users] Re: FYI: Django security releases issued: 4.0.6 and 3.2.14

by Mark Sapiro

On 7/8/22 6:34 AM, Stephen J. Turnbull wrote: > David Newman writes: > > > Interesting -- that does produce two directories with names starting > > with a tilde: > > > > /opt/mailman/venv/lib/python3.9/site-packages/~jango: > > /opt/mailman/venv/lib/python3.9/site-packages/~jango-3.0.14.dist-info: > > I would guess that those are the previous versions before the upgrade, > moved out of the way in case a revert-to-previous was needed. Again, > guessing, they should have been removed by the upgrade process once > the new package was fully installed. Was there an interrupted or > partially successful upgrade in the past? When pip is doing an upgrade of the xyz package, it renames the existing package as ~yz and then ultimately deletes the old ~yz package after successfully installing the new xyz. In this case, the upgrade was aborted because of the Django<3.1 constraint in mailman-web and apparently pip then installed Django<3.1 and left the ~jango* directories behind. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

[MM3-users] Re: Where to configure 'hostname' used in 'From:'-header?

by Mark Sapiro

On 3/10/23 01:55, Dmitri Heerdegen wrote: > > I've recently installed MM3 with Exim4 on, say, subdomain.myhost.tld > and configured MM3 to use lists.someotherdomain.tld as web host and mail > host. > Thus, the mailman.cfg contains: > > [mta] > smtp_host: lists.someotherdomain.tld > > When I send a message to test(a)lists.someotherdomain.tld it gets > delivered, however the 'From:'-header becomes "test(a)subdomain.myhost.tld". The From: should be unchanged from the incoming post unless the list is anonymous or DMARC mitigations are applied. In the case of anonymous lists, the From should be the list's address and in the case of DMARC mitigations it should be something like User Name via listname <list-address>. In either case, the list address should be list-name@list-domain where list-domain is the list's email domain. If the address is being rewritten as test(a)subdomain.myhost.tld it is probably Exim doing it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 3 months

Search results for query "sapiro"