Search results for "Postorius" - Mailman-users

Re: Member Issue Discovered

by Mark Sapiro

On 10/19/20 6:11 PM, Brian Carpenter wrote: > > No one set their preferred address here at all. The first incident was > an imported list member who was not a registered user. And the import21 created the user and address records for this user. > They wanted their > real name changed to something else. The list owner tried to figured out > how to do that, found no way to do it, figured out it was just easier to > unsubscribe them, and resubscribed them to the list using a different > name. The old name showed up again. This is a bug and please fix it > soon. If you feel this is a bug that needs to be fixed, file an issue or issues reporting it. > This has nothing to do with being subscribed to other lists. In your particular instance that's true. > I can > probably come up with a workaround using Affinity (one of the benefits > of moving away from Postorius) but I can't imagine this not being a > serious issue as Mailman 3/Postorius is more widely adopted. File an issue at https://gitlab.com/mailman/postorius/-/issues asking for the ability to change the display name associated with an address and/or an issue at <https://gitlab.com/mailman/mailman/-/issues> requesting that adding an address with a display_name as a member, non-member, moderator or owner of a list override an existing display_name for that address. I don't think you can do this in affinity because I don't think there is currently a REST endpoint to do it. You can do it easily in mailman shell, but that doesn't help the user or list admin. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Re: Unwanted E-mail to Maillists Submitted via Postorius Interface

by Stephen J. Turnbull

Brett Delmage writes: > On Thu, 26 Aug 2021, Stephen J. Turnbull wrote: > > > However, it turns out that bots are almost as good at solving captchas > > as humans, and they can retry a lot faster. Captchas are also really > > horrible from an accessibility perspective. > > I have to disagree. > > I previously put a captcha on a Joomla website which stopped 100% of all > bogus account signup attempts. > > What was it ? "How many letters are in the word 'jazz'"? > This captcha is fully accessible, too. Of course, point taken. I've done similar things, and know quite a few such anecdotes. It's a good method, as long as *only a few of us use it*. But if enough people use it, patterns will show up, and we'll get into a "proof of waste" race with the spammers as we try to come up with logic puzzles people can solve but spammers' ML can't. I don't think it really addresses the issue that attackers can solve it easily if they want to, and will eventually automate that solution, although it does address the issue of accessibility (mostly -- I am not an expert but I wouldn't be surprised if long-time screen reader users are relatively poor spellers!) And it's not a satisfactory solution for a lot of our users. We can't safely add enabling functions to Mailman, because I'm sure there are a dozen Spamming as a Service (SpAAS) groups out there with Mailman 3 clone repos. So you need a skilled admin to implement custom CAPTCHAs. > If there's a captcha problem out there, it's because too many people just > use the same old, same old - Of course they do. After all, that's what software is for -- very cheaply using others' solutions for common problems. In this case, though, the "problem" is smart -- it's human attackers and their tools. > which is worth the bots cracking because it is used everywhere. That evaluation is close, but not exact in the age of SpAAS. If they want you, they'll get you, it's trivial for an open-subscription site. And if they need a human to crack your trivial CAPTCHA, a smart spammer (or even somebody who hates you for banning them from your comments) will add it to their box of tricks. I bet you'll get tired sooner than they do. Eventually it will make it into kiddie-scripts. The other thing is that if such simple captchas become popular, you know that the pros will start scanning sites for them just to make a database of patterns, and add hacks for any popular ones (or if they're smart, for every pattern they find -- I bet on a regular basis they'll get as lucky as I did when I stopped Klez, and then Fretham too, with just "iframe.*height=1"). Steve

4 years, 3 months

Re: Question: What happens if I delete a user from all lists and that user is sole owner of some list?

by Odhiambo Washington

On Wed, Apr 3, 2024 at 2:07 PM David Partain via Mailman-users < mailman-users(a)mailman3.org> wrote: > Hi, > > One of the great things about our new installation compared with our > old is the ability to manage users via > > https://our.wee.domain/postorius/users > > I might have been able to manage them using the command line on the old > installation, but there is no 'mailman delmembers' on that box. > > Since I now have this Mighty Power, I want to use it to clean up. There > are many users who should no longer be on the system, so I want to run > something along the lines of: > > mailman delmembers --member some(a)email.address --fromall \ > --no-goodbye-msg --no-admin-notify > > or, if I'm feeling brave, something like this. > > mailman delmembers --file somefile --fromall \ > --no-goodbye-msg --no-admin-notify > > My question is: If one of these users is the sole owner of a list, what > will happen? Will the user be deleted and that list now owner-less? > Will mailman refuse to delete that user until I add a new owner? > > Thanks in advance for your feedback. > 1. Create a testlist 2. Assign an owner to it 3. Delete the owner via the CLI or Postorius Give us your feedback :) -- 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]

1 year, 8 months

Re: Auto discard after max_days_to_hold not working.

by Hitashi mancho

Hi Mark, As you have mentioned about implementation of "Auto discard after max_days_to_hold" in a next release. How do I install that release? I have installed mailman3 using pip in virtual environment and whenever I try to upgrade the release using pip install -U, it gives package already compiled and up to date. My Mailman version is as follows. Mailman version: GNU Mailman 3.3.10 (Tom Sawyer) Python 3.11.9 Rocky Linux 9.5 Regards, Hitachi. On Thu, May 1, 2025 at 12:51 PM Hitashi mancho <huhamails(a)gmail.com> wrote: > Thank you so much, Mark and Stephen, for the quick action and response. > Waiting for the next release. > > On Tue, Apr 29, 2025 at 10:52 AM Mark Sapiro <mark(a)msapiro.net> wrote: > >> On 4/28/25 10:55, Mark Sapiro wrote: >> > >> > `mailman import21` will import the setting, but per the above comment, >> > it doesn't yet work. The setting exists and is exposed in REST, but it >> > appears it is not actually implemented. >> >> >> This is now implemented for the next release. See >> https://gitlab.com/mailman/mailman/-/issues/1215 and >> https://gitlab.com/mailman/mailman/-/merge_requests/1346 for Mailman >> core and https://gitlab.com/mailman/postorius/-/issues/628 and >> https://gitlab.com/mailman/postorius/-/merge_requests/1001 for Postorius. >> >> -- >> 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 huhamails(a)gmail.com >> >

2 months, 1 week

New Mailman 3 installation issues

by sarah.hartt＠ionica.ca

I have been trying to get a mailman 3 installation working for longer than I'd like to admit. Core appears to be installed and working as desired but Postorius (and hyperkitty, but I haven't even started troubleshooting it while trying to get the web interface working) is only loading the main page with no lists shown and all remaining links return a server error (specific text is: "Server error An error occurred while processing your request." with the error text highlighted). I think I followed all of the installation instructions, including the updated pythonpath line in the systemd module, but it's entirely possible that there is an error somewhere along the way. I have had to make two minor tweaks, the /static/ location was moved from /opt/mailman/web/static to /var/www/mailman/ (owner mailman:nginx) as nginx was giving permissions errors (even if it owned the files or with the mod set to 777) with the default location and wouldn't load the css, and installed postgres directly from their repo as the method in the guide doesn't create the user. Aside from that everything should be exactly as laid out in the installation guide. The logs are showing everything running and the DB logs show all the queries going through successfully, there are no errors in the web logs corresponding with the errors being served on the site aside an entry for a 500 in the access logs [18/May/2021:12:13:01] "GET /archives/ HTTP/1.1" 500 1102 "http://mailman3/mailman3/lists/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.91 Safari/537.36" "-" when I took a look in the DB tables many of them appear to be empty, I have a few lists in core that were imported from 2.1 but no new lists created. Mailman: 3.3.4 Postorius: 1.3.4 OS: Oracle Linux 8.3 Python: 3.6 postgres: 13.2

4 years, 6 months

Re: Mailman 3 Web Application Startup Time or Availability - 502 Bad Gateway and Postorius

by Mark Sapiro

On 5/3/21 1:45 PM, summersan(a)nclack.k12.or.us wrote: > Hello, > > I've been setting up a new Mailman 3 installation earlier this year, and I think things have been going okay so far. > > I've noticed, however, that after a long amount of time passes (for example, a weekend), when I try to visit the local Mailman 3 web application (e.g., example.mailman.site/mailman3/lists/, where it says "Postorius" at the top left corner of the page and shows a list of mailing lists in the body of the page), I sometimes get a 502 Bad Gateway type of error (referenced from my notes). As far as I can tell, this looks like a normal web server (nginx?) error. If I try visiting the Mailman 3 server location again in a web browser shortly thereafter, I still might get a 502 Bad Gateway error. If I wait a while longer (maybe a minute or more?), the Mailman 3 web application appears to load as expected. What is your configuration for accessing Mailman. I gather you are proxying from nginx to something. Is that something gunicorn or uwsgi? You mention gunicorn but this can be confusing as mailman core's REST API uses gunicorn, but that is separate from the web server's wsgi interface to Django. In any case, this issue is probably with whatever nginx is proxying to (gunicorn or uwsgi) and not with Django or Mailman core. > I've tried looking at the gunicorn documentation (https://docs.gunicorn.org/en/stable/index.html) and searching online (including in this Mailman3 mailing list) to see if there's something that can be done to fix this issue. The closest thing I can find for now is advice for something that, while possibly being technologically unrelated, includes the idea of "warmup requests", which makes me think of simply setting up some sort of script to periodically load a page on the Mailman 3 web application in order to keep it more available for visitors (https://stackoverflow.com/a/57056170) That's certainly a possibility and may be a solution. It would be simple enough to set up an hourly cron to do a curl or wget to retrieve example.mailman.site/mailman3/lists/ and see if that helps. > Is there a setting or something in any of the Mailman 3 related programs that could help with keeping the Mailman 3 web application up and running more often without having to resort to making an ongoing, automated request to the Mailman 3 web application? Nothing that I'm aware of, but if so, it would most likely be a gunicorn or uwsgi setting rather than something in Mailman or Django, although it could be that gunicorn or uwsgi is timing out in trying to connect to Django in which case it could be a Django issue, but not one I've heard of. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

Execute assorted Mailman functions via Mailman shell terminal

by Andy Matthews

When my company migrated from MM2 to MM3, they discovered there were things that didn't work as expected (don't get me started). So they developed a set of Python functions which allowed then to fill in the missing functionality. However, they've discovered that some of those functions either never worked properly, or no longer work. For example, ``` def list_nonmembers(mlist): for accepted in mlist.accept_these_nonmembers: print("Accepted: ",accepted) for held in mlist.hold_these_nonmembers: print("Held: ",held) ``` They're run by shelling into the machine which hosts mailman and executed like so (where scripts is `scripts.py`) ``` sudo -iu mailman mailman shell -l MAILING_LIST_ID --run scripts.list_nonmembers ``` I'm recommending that we install Postorius, as I suspect many of the functions they've written are already present in that UI, but it's not as simple as that. Instead they're wanting a handful of these functions (including the one listed above) replaced sooner than we could get Postorius up and running. I've gotten this far: ``` from mailman.interfaces.listmanager import IListManager from zope.component import getUtility mylist_id = 'bravo-open1(a)tena-sda.org' list_manager = getUtility(IListManager) mylist = list_manager.get(mylist_id) ``` The mylist variable is of type `mailman.model.mailinglist.MailingList`, and includes an Attributes for nonmembers: ``` mylist.nonmembers <mailman.model.roster.NonmemberRoster object at 0x7ffffa3e65b0> ``` But this nonmembers property doesn't output any users/addresses when printed, and throws a TypeError when I try to iterate over it: ``` Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: 'NonmemberRoster' object is not iterable ``` So, given a mailing list instance, retrieved via `list_manager.get(mylist_id)`, how would I go about printing all nonmembers and their current roles in a list (held, accepted, etc.)? Alternately, is there a different question I should be asking in order to retrieve that information?

7 months

Cannot setup HTTPS support for mailman3-web

by jean-christophe manciot

Ubuntu 20.04 mailman3 3.2.2-1 mailman3-web 0+20180916-10 python3-django 2:2.2.9-2ubuntu1 In ```/etc/mailman3/uwsgi.ini``` (example.org is defined in the local /etc/hosts as 10.0.0.1): ``` [uwsgi] # Port on which uwsgi will be listening. ### suwsgi: uwsgi protocol over TLS uwsgi-socket = example.org:8430 # https://uwsgi-docs.readthedocs.io/en/latest/HTTPS.html?highlight=ssl https = /etc/ssl/example.org.crt,/etc/ssl/example.org_rsakey.pem.decrypted,HIGH ... # Drop privileges and don't run as root. uid = www-data gid = www-data ... ``` I suppose that uwsgi reads the certificate & its private key before dropping root privileges. Right now, uwsgi cannot access them as ```www-data```. In ```/etc/mailman3/mailman-web.py``` (symlinked to django settings.py) : ``` ... SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_SCHEME', 'https') # Other security settings # SECURE_SSL_REDIRECT = True # If you set SECURE_SSL_REDIRECT to True, make sure the SECURE_REDIRECT_EXEMPT # contains at least this line: # SECURE_REDIRECT_EXEMPT = [ # "archives/api/mailman/.*", # Request from Mailman. # ] # SESSION_COOKIE_SECURE = True # SECURE_CONTENT_TYPE_NOSNIFF = True # SECURE_BROWSER_XSS_FILTER = True # CSRF_COOKIE_SECURE = True # CSRF_COOKIE_HTTPONLY = True # X_FRAME_OPTIONS = 'DENY' ... POSTORIUS_TEMPLATE_BASE_URL = 'https://example.org:8430' ``` In ```/etc/nginx/sites-enabled/example.org.conf``` ``` ... location / { include /etc/nginx/uwsgi_params; # upstream app server uwsgi_pass suwsgi://example.org:8430; } ``` uwsgi is listening on the right address/port: ``` # networks-list-connections.sh | grep :8430 tcp 0 0 10.0.0.1:8430 0.0.0.0:* LISTEN 33 54336045 1768187/uwsgi ``` Despite those settings and all the relevant systemd services restarted, I get ```502 Bad Gateway``` while browsing to ```https://example.org/postorius/lists/?all-lists``` (or any other page) with the following error nginx message: ``` *1 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 10.0.0.1, server: example.org, request: "GET /postorius/lists/?all-lists HTTP/2.0", upstream: "suwsgi://10.0.0.1:8430", host: "example.org", referrer: "https://example.org/postorius/lists/" ``` Of course, without those specific https/suwsgi settings, everything works fine. What am I missing/doing incorrectly? Does uwsgi need access to the certificate/private key while running as non-root for instance?

5 years, 11 months

Re: Performance of member listing [was: How to remove a nonmember...]

by skenny＠scss.tcd.ie

OK, I've done a clean rebuild of my server with Puppet. (I'll post a copy of my docker-compose file and related config files at the end of this message.) Via the postorius web interface, I've created a new list called scss-sysadmins(a)scss.tcd.ie, and I've added 1,800 nonmembers to it using this fairly basic piece of code: ---- add_nonmembers.py start --------------------------------------- #!/usr/bin/python3 from mailmanclient import Client import sys listarg = str(sys.argv[1]) client = Client('http://172.19.199.2:8001/3.0', 'restadmin', 'restpass') this_list = client.get_list(listarg) this_list_short = this_list.list_name work_dir = "/usr/local/mailman-scss/list_membership/" + this_list_short + "/" nonmembers_add_file = work_dir + "nonmembers.add" infile = open(nonmembers_add_file, "r") for addr in infile: if addr.isspace(): continue addr = addr.strip() print("Adding " + addr + "as a nonmember ") this_list.add_role('nonmember', addr, display_name='') infile.close() ---- add_nonmembers.py end --------------------------------------- After doing this, a Postgres "select * from member" SQL command executed in the database container prints a total of 1,801 rows (one more than the number of nonmembers added). In the web interface, I bring up the list of nonmembers, and then click on "delete" to remove an individual nonmember (in all that follows I've replaced the actual username with XXXXXXXX for privacy reasons). This fails after 30 seconds and the following message appears: Something went wrong Mailman REST API not available. Please start Mailman core. Next, in the mailmain-core container, I increase Gunicorn's timeout parameter to 300 seconds (I edited /usr/lib/python3.6/site-packages/mailman/config/gunicorn.cfg and restarted the container), and try the same operation again. Here's what happens: (1) After 2 minutes and 3 seconds approx, the "Confirm remove role" page appears; (2) I click on "Remove XXXXXXXX(a)tcd.ie", and after a *further* 2 minutes and 3 or so seconds later, the operation completes - the nonmember no longer appears on the page. The URL that appears in the address bar of my browser after clicking on "delete" is http://mailman-web.scss.tcd.ie/postorius/lists/scss-sysadmins.lists.scss.tc… Here are the entries in the *.log files from the -web and -core containers generated by the latter (timeout = 300) attempt to remove a nonmember: ==> ./core/var/logs/mailman.log <== [22/Apr/2020:17:17:25 +0000] "GET /3.1/lists/scss-sysadmins.lists.scss.tcd.ie HTTP/1.1" 200 395 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:19:20 +0000] "POST /3.1/members/find HTTP/1.1" 200 896038 "-" "GNU Mailman REST client v3.3.0" ==> ./web/logs/uwsgi.log <== [pid: 21|app: 0|req: 65/198] 109.255.134.153 () {36 vars in 1160 bytes} [Wed Apr 22 17:17:25 2020] GET /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/XXXXXXXX(a)tcd.ie => generated 6217 bytes in 115377 msecs (HTTP/1.1 200) 6 headers in 331 bytes (1 switches on core 0) ==> ./core/var/logs/mailman.log <== [22/Apr/2020:17:19:45 +0000] "GET /3.1/lists/scss-sysadmins.lists.scss.tcd.ie HTTP/1.1" 200 395 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:48 +0000] "POST /3.1/members/find HTTP/1.1" 200 896038 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:48 +0000] "DELETE /3.1/lists/scss-sysadmins(a)lists.scss.tcd.ie/nonmember/XXXXXXXX%40tcd.ie HTTP/1.1" 204 0 "-" "GNU Mailman REST client v3.3.0" ==> ./web/logs/uwsgi.log <== [pid: 21|app: 0|req: 66/199] 109.255.134.153 () {44 vars in 1320 bytes} [Wed Apr 22 17:19:45 2020] POST /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/XXXXXXXX(a)tcd.ie => generated 0 bytes in 122966 msecs (HTTP/1.1 302) 7 headers in 450 bytes (1 switches on core 0) ==> ./core/var/logs/mailman.log <== [22/Apr/2020:17:21:48 +0000] "GET /3.1/lists/scss-sysadmins.lists.scss.tcd.ie HTTP/1.1" 200 395 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:48 +0000] "GET /3.1/lists/scss-sysadmins.lists.scss.tcd.ie/roster/owner HTTP/1.1" 200 626 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:48 +0000] "GET /3.1/lists/scss-sysadmins.lists.scss.tcd.ie/roster/moderator HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:48 +0000] "GET /3.1/members/find?list_id=scss-sysadmins.lists.scss.tcd.ie&role=nonmember&count=0&page=1 HTTP/1.1" 200 93 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:50 +0000] "GET /3.1/members/find?list_id=scss-sysadmins.lists.scss.tcd.ie&role=nonmember&count=25&page=1 HTTP/1.1" 200 12506 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:50 +0000] "GET /3.1/lists/scss-sysadmins(a)lists.scss.tcd.ie/requests HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.0" [22/Apr/2020:17:21:50 +0000] "GET /3.1/lists/scss-sysadmins(a)lists.scss.tcd.ie/held?count=50&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.0" ==> ./web/logs/uwsgi.log <== [pid: 21|app: 0|req: 67/200] 109.255.134.153 () {38 vars in 1339 bytes} [Wed Apr 22 17:21:48 2020] GET /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/members/nonmember/ => generated 41068 bytes in 2266 msecs (HTTP/1.1 200) 7 headers in 416 bytes (1 switches on core 0) [pid: 21|app: -1|req: -1/201] 109.255.134.153 () {36 vars in 1031 bytes} [Wed Apr 22 17:21:51 2020] GET /static/postorius/img/mailman_logo_small_trans.png => generated 0 bytes in 0 msecs (HTTP/1.1 304) 0 headers in 29 bytes (0 switches on core 0) My configuration uses two Docker compose files, one for a Postfix mail server container, and the other for all the mailman stuff. (As you'll see, my browser connection to the mailman-web container is facilitated by exposing port 8000 to port 80 on the Docker host. I'll front everything with an nginx reverse proxy later.) Here is the latter, followed by my mailman-extra.cfg and settings_local.py: ---- mailman-docker-compose.yml start ------------------------------------------------------ version: '2' services: mailman-core: image: maxking/mailman-core:0.3 container_name: mailman-core hostname: mailman-core volumes: - /opt/mailman/core:/opt/mailman/ - /etc/scss-mailman-config/mailman-extra.cfg:/opt/mailman/mailman-extra.cfg - /usr/local/mailman-scss:/opt/mailman/scss stop_grace_period: 30s links: - database:database depends_on: - database environment: - DATABASE_URL=postgres://mailman:mailmanpass@database/mailmandb - DATABASE_TYPE=postgres - DATABASE_CLASS=mailman.database.postgresql.PostgreSQLDatabase - HYPERKITTY_API_KEY=someapikey networks: mailman: ipv4_address: 172.19.199.2 restart: always mailman-web: image: maxking/mailman-web:0.3 container_name: mailman-web hostname: mailman-web ports: - 80:8000 depends_on: - database links: - mailman-core:mailman-core - database:database volumes: - /opt/mailman/web:/opt/mailman-web-data - /etc/scss-mailman-config/settings_local.py:/opt/mailman-web/settings_local.py environment: - DATABASE_TYPE=postgres - DATABASE_URL=postgres://mailman:mailmanpass@database/mailmandb - HYPERKITTY_API_KEY=someapikey - SECRET_KEY=shhitsasecret - SMTP_HOST=172.19.199.10 - MAILMAN_ADMIN_USER=skenny - MAILMAN_ADMIN_EMAIL=skenny(a)scss.tcd.ie - UWSGI_STATIC_MAP=/static=/opt/mailman-web-data/static - SERVE_FROM_DOMAIN=mailman-web.scss.tcd.ie - DEFAULT_FROM_DOMAIN=mailman-web.scss.tcd.ie networks: mailman: ipv4_address: 172.19.199.3 restart: always database: environment: POSTGRES_DB: mailmandb POSTGRES_USER: mailman POSTGRES_PASSWORD: mailmanpass restart: always image: postgres:9.6-alpine volumes: - /opt/mailman/database:/var/lib/postgresql/data networks: mailman: ipv4_address: 172.19.199.4 networks: mailman: driver: bridge ipam: driver: default config: - subnet: 172.19.199.0/24 ---- mailman-docker-compose.yml end ------------------------------------------------------ ---- mailman-extra.cfg start ------------------------------------------------------ # mailman-extra.cfg [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: 172.19.199.2 lmtp_port: 8024 smtp_host: 172.19.199.10 smtp_port: 25 configuration: /etc/postfix-mailman.cfg [mailman] # This address is the "site owner" address. Certain messages which must be # delivered to a human, but which can't be delivered to a list owner (e.g. a # bounce from a list owner), will be sent to this address. It should point to # a human. site_owner: mrrobot(a)lists2.scss.tcd.ie [logging.smtp] level: debug path: smtp.log ---- mailman-extra.cfg end ------------------------------------------------------ ---- settings_local.py start ------------------------------------------------------ # Hosts/domain names that are valid for this site; required if DEBUG is False # See https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts ALLOWED_HOSTS = [ "localhost", # Archiving API from Mailman, keep it. # "lists.your-domain.org", # Add here all production URLs you may have. "mailman-web", "mailman-web.scss.tcd.ie", "172.19.199.3", ####sk os.environ.get('SERVE_FROM_DOMAIN'), ####sk os.environ.get('DJANGO_ALLOWED_HOSTS'), ] INSTALLED_APPS = [ 'hyperkitty', 'postorius', 'django_mailman3', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount', # -------------------------------------------------------------------------- # We're killing the following ... (tip from brian(a)emwd.com on this page: # https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… # But it doesn't stop people signing up. We need to deal with that via # Nginx .... # -------------------------------------------------------------------------- #'django_mailman3.lib.auth.fedora', #'allauth.socialaccount.providers.openid', #'allauth.socialaccount.providers.github', #'allauth.socialaccount.providers.gitlab', #'allauth.socialaccount.providers.google', ---- settings_local.py end ------------------------------------------------------ Thanks again for helping Stephen

5 years, 7 months

Any possible way to reduce robot spam accounts?

by Stephen J. Turnbull

Franklin Weng writes: > I really have no idea how the robots find my system since I haven't > told anyone the ip or URL of my mailman instance.� And, they're > registering on the system, not the mailing list since I have only > one list for testing now and it wasn't assaulted by spam yet. The bots just check every domain on the internet for the /mailman3 and /postorius paths. > * just let users join from email (lists-join(a)lists.url) instead of > registering on the mailman instance?� or What I do is open up the firewall only to ips I have legit users at. You probably can't do that, but if you can, it's quite effective. You could restrict it to email-only subscription in one of the following ways, but the bots have known how to do that since the 90s, and the only control you have is to require moderator approval. Requiring address verification doesn't help much, the bots have been doing that almost as long. You can disable the administrative UI entirely, by removing the entries for mailman3 and postorius from the top-level urls.py. You can edit the template for the list information to remove the subscription form. > * use a scheme like CAPTCHA to reduce the successful opportunity of > robot registering? I think somebody has implemented CAPTCHA for Mailman 3. Search the archives of this list. But the bots also know how to solve CAPTCHAs, and for some CAPTCHAs they were faster and more accurate than humans. Unless your users expect instant membership, or you expect an awful lot of subscriptions, I would just let subscriptions accumulate for a day or two and then discard them all. You can also write a script to figure out the IPs and ban those hosts at the firewall. Steve

2 years, 4 months

Mailman-users search results for query "Postorius"