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

[MM3-users] Re: Mailman3 without Hyperkitty in docker

by Abhilash Raj

On Thu, Feb 28, 2019, at 10:18 PM, Danil Smirnov wrote: > Hi Abhilash, > > Thank you very much - the previous error is fixed now. > > But I have another one now, which causes the same 500 Server Error: > > bash-4.3# cat /opt/mailman-web-data/logs/uwsgi-error.log > *** Starting uWSGI 2.0.18 (64bit) on [Fri Mar 1 05:42:09 2019] *** > compiled with version: 6.3.0 on 01 March 2019 01:52:42 > os: Linux-3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017 > nodename: mailman-web > machine: x86_64 > clock source: unix > detected number of CPU cores: 2 > current working directory: /opt/mailman-web > detected binary path: /usr/local/bin/uwsgi > !!! no internal routing support, rebuild with pcre support !!! > setgid() to 101 > setuid() to 100 > chdir() to /opt/mailman-web > your memory page size is 4096 bytes > detected max file descriptor number: 1048576 > building mime-types dictionary from file /etc/mime.types...1168 entry found > lock engine: pthread robust mutexes > thunder lock: disabled (you can enable it with --thunder-lock) > uwsgi socket 0 bound to TCP address 0.0.0.0:8080 fd 8 > uwsgi socket 1 bound to TCP address 0.0.0.0:8000 fd 9 > Python version: 3.6.8 (default, Jan 30 2019, 23:58:16) [GCC 6.3.0] > Python main interpreter initialized at 0x55a2df7f57e0 > python threads support enabled > your server socket listen backlog is limited to 100 connections > your mercy for graceful operations on workers is 60 seconds > mapped 166752 bytes (162 KB) for 2 cores > *** Operational MODE: threaded *** > Traceback (most recent call last): > File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 20, in import_string > return getattr(module, class_name) > AttributeError: module 'django.contrib.auth.middleware' has no attribute 'SessionAuthenticationMiddleware' > > The above exception was the direct cause of the following exception: > > Traceback (most recent call last): > File "wsgi.py", line 38, in <module> > application = get_wsgi_application() > File "/usr/local/lib/python3.6/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application > return WSGIHandler() > File "/usr/local/lib/python3.6/site-packages/django/core/handlers/wsgi.py", line 136, in __init__ > self.load_middleware() > File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 34, in load_middleware > middleware = import_string(middleware_path) > File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 24, in import_string > ) from err > ImportError: Module "django.contrib.auth.middleware" does not define a "SessionAuthenticationMiddleware" attribute/class > unable to load app 0 (mountpoint='') (callable not found or import error) > *** no app loaded. going in full dynamic mode *** > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 1) > spawned uWSGI worker 1 (pid: 37, cores: 2) > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > --- no python application found, check your startup logs for errors --- > > As per my investigation, this error possibly caused by Django upgrade: > > *The SessionAuthenticationMiddleware class is removed. It provided no functionality since session authentication is unconditionally enabled in Django 1.10.* > > See https://docs.djangoproject.com/en/2.0/releases/2.0/ > > After I've removed the line > https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web… > from settings.py, the container is finally working. > > I've placed PR in github: > https://github.com/maxking/docker-mailman/pull/314 Thank you for your contributions! I have merged your pull request and it should now be out (hopefully!). > > Thank you for your help. > > Danil > > > пт, 1 мар. 2019 г. в 04:33, Abhilash Raj <maxking(a)asynchronous.in>: >> >> >> On Thu, Feb 28, 2019, at 5:19 PM, Abhilash Raj wrote: >> > On February 27, 2019 11:53:34 PM PST, Danil Smirnov <danil(a)smirnov.la> wrote: >> > >Hi Mark, >> > > >> > >Actually all this stuff happens inside the container after it's started >> > >and >> > >initialized without errors. I didn't amend the image anyhow. >> > > >> > >Also I have the configuration based on docker-compose.yaml provided in >> > >the >> > >repository which works just fine for mailman-web image. >> > > >> > >The very same config with postorius image (+ UWSGI_STATIC_MAP param) >> > >fails >> > >with 500 error... >> > > >> > >Now answering your questions: >> > > >> > >ср, 27 февр. 2019 г., 22:56 Mark Sapiro <mark(a)msapiro.net>: >> > > >> > >> do you have django-q in INSTALLED_APPS in your Django settings and >> > >what >> > >> is set for Q_CLUSTER? >> > >> >> > > >> > >I've checked settings.py inside the container and I haven't found any >> > >of >> > >the mentioned configurations there. >> > > >> > >Does the manage.py that's being run here point to the right >> > >settings.py? >> > >> >> > > >> > >No clue. >> > > >> > >Also I wonder why we have some Hyperkitty-related cronjobs in non-HK >> > >configured image? >> > > >> > >https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web… >> > >> > Because I am a dum dum ;-) >> > >> > Will work on removing those crons and stuff. Would be nice if you >> > opened an issue on Github so that I don't forget. >> >> Should now be fixed in the latest image. >> >> > >> > >Danil >> > > >> > > >> > > >> > >> -- >> > >> 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/ >> > >> >> > >_______________________________________________ >> > >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/ >> > >> > >> > -- >> > Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> -- >> thanks, >> Abhilash Raj (maxking) -- thanks, Abhilash Raj (maxking)

6 years, 7 months

[MM3-users] Re: Errors while importing mm2 list archives - SOLVED

by Odhiambo Washington

On Thu, Dec 22, 2022 at 9:36 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/20/22 22:25, Odhiambo Washington wrote: > > > > In my case, running `mailman` without any arguments just makes it grok :) > > > > (venv) [mailman@gw ~/mm]$ mailman info > ... > > *config file: /opt/mailman/mm/mailman.cfg* > > > That's because it first looks in the current directory for `mailman.cfg` > and only if it doesn't find it there does it look in /etc/mailman3. > And that happens because I have all my config files in /opt/mailman/mm/. So if I moved all of them to /etc/mailman3/ it would settle for that? I will test it. >> Ultimately, when I did the import, there was only one email from the > >>> archives that failed to be imported - which I honestly don't mind, but > >>> maybe there is a solution for this > >>> "'utf-8' codec can't encode character '\udcae' in position 331: > >> surrogates not allowed" ?? > >> > >> > >> If you provide a copy of that message from the mbox, either on the list > >> or to me directly, I'll investigate. > >> > > > > A mbox file containing that email and the associated thread can be > > downloaded from here: > > https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz > > The offending message is multipart with an attached message/rfc822 part > and that part has a preamble which in bytes is > > b'This document is a Single File Web Page, also known as a Web Archive > file. If you are seeing this message, your browser or editor doesn't > support Web Archive files. Please download a browser that supports Web > Archive, such as Windows\xae Internet Explorer\xae.' > > The '\xae' is an iso-8859-1 encoding for '®', but no charset is > specified for this preamble so email message parsing ends up decoding > those as surrogates '\udcae' which throws the exception when > hyperkitty.lib.incoming.add_to_list() in trying to save the attachment > does `att.set_content(content)`. > > Normally, when messages to be archived arrive from core via > mailman_hyperkitty, the surrogates are replaced by > email.utils._sanitize(), but this doesn't happen with messages from > hyperkitty_import. > I am glad it's an email that is probably overtaken by events. However, the good thing is that I will have the archives from MM2 still accessible once I move to MM3. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 9 months

[MM3-users] re-sending confirmation mails (was Re: Re: pending subscriptions lost?)

by IEM Network Operation Center (IOhannes m zmölnig)

On 3/14/22 18:36, Mark Sapiro wrote: > On 3/14/22 09:18, IEM Network Operation Center (IOhannes m zmölnig) wrote: >> >> this is with "Postorius Version 1.2.4" (as installed by the mailman3 >> Debian package). > > The Debian packages are OK for people who want to install things via a > package manager, but they are quite out of date. i know. the problem is, that right now i have a running (Debian-based, thus outdated) mailman3 installation, and I still haven't found a proper strategy to upgrade and keep staying up-to-date. so for the time being i'm stuck with what i have. > > Something like the following in `mailman shell` can do it. thanks a lot. afaiu, this snippet allows me to purge outdated pending subscriptions. modifying it slightly, also allows me to just list the pending subscriptions along with their tokens and print them out. is it still possible to just use these tokens to confirm the pending subscription (even though it is long overdue)? if so, i could just send out a reminder to those 50 or so people who have not confirmed yet. while investigating this a bit, i also noticed that it seems that with mailman3 the only option to confirm a pending subscription is via email ("leaving the subject intact") - at least that is the only option that is listed in the confirmation mail. now i would like to massage this into what i think is a bit more user-friendly. first of all: most email confirmation systems allow me to either "reply by email" or "click this link". is there a way to do this for mailman3? that is: is there a (hidden) URL that would accept the token in order to confirm a subscription? also: the confirmation mail says that the subject must be kept intact. however, i noticed that the actual "From" address of the confirmation mail already contains the token. would it be enough if people just sent an email to this special email-address (that contains the token), regardless of the subject? i'm thinking of sending a rather personalized email that has a more attractive subject than "confirm flkdsajfsalkjflsajfsoisjdl". finally: what else is required to approve the confirmation? will the sender's email-address be taken into account? (e.g. if they subscribed "foo+mylist(a)example.com" but send the confirmation-reply from "foo(a)example.com", will that still work? sorry for so many questions. i *did* search the documentation, but simply haven't found anything that would help me. i've probably looked in the wrong places, but mailman3 is rather huge so it's easy to miss the imprtant parts. gmdsa IOhannes

3 years, 7 months

[MM3-users]Re: mailman 2 vs. mailman 3: what happened to multipart/digest?

by John Hein

Mark Sapiro wrote at 12:18 -0700 on May 12, 2016: > On 5/12/16 9:16 AM, deu8yz2mpq(a)snkmail.com wrote: > > Digest delivery in mailman 2 encapsulated the individual message/rfc822 messages in a multipart/digest container. This allowed email clients to show the messages in the particular digest in a threaded view. > > > This format vs. plain text digests was a user option in Mailman 2. > > > > It seems like the various digest options that I have tried [1] in mailman 3.1.0 (as implemented for the fedora-users mailing list) no longer encapsulate messages in multipart/digest. > > > The core still supports the same plain text and MIME format digests and > the same individual subscriber and per-list default formats as did > Mailman 2. The issue is none of these things are exposed in Postorius. > > If you subscribe to digests on this list, you will receive the > 'encapsulated' MIME format because the lists mime_is_default_digest > setting is True, but currently that has to be set through the > bin/mailman shell tool. > > > > Is this intentional? Is it a bug - feature that was lost in translation from 2 to 3? Is there a delivery option I'm missing that will turn that back on? Thanks for the info - and Barry's reply as well. I understand that MIME digests are supported in Mailman 3 - that's what I'm using (and thanks, Barry, for the info that Summary Digests is the same right now). My quibble is that the multipart/digest encapsulation level is gone. Barry Warsaw wrote at 15:16 -0400 on May 12, 2016: > The MIME format of MIME digests should roughly be: > > multipart/mixed > text/plain (the digest heading) > text/plain (the TOC) > message/rfc822 > message-1 > message/rfc822 > message-2 > ... > text/plain (footer) But mm 2 had: multipart/mixed text/plain (the digest heading) text/plain (the TOC) multipart/digest <--- this is the part that's gone in mm3 message/rfc822 message-1 message/rfc822 message-2 ... text/plain (footer) So was that removal intentional, a bug or ?? Maybe you're saying there is definitely an unexposed (in Postorius) knob for that in mm3. > > It is the intent that Postorius will eventually expose all these > settings. We're not there yet. At present you could possibly do this by > interacting with mailmanclient, although I'm not certain the settings > are exposed there. You can do it via bin/mailman shell if you have > access and know what you're doing (see > <http://mailman.readthedocs.io/en/release-3.0/src/mailman/runners/docs/diges…>) > > If you file an issue at > <https://gitlab.com/mailman/postorius/issues/new>, it might help > expedite this. Okay.

9 years, 5 months

[MM3-users] Re: Customise Postorius templates?

by Duane Raymond

On Mon, 7 Feb 2022 at 00:56, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > On Feb 1, 2022, at 11:01 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > > > > On 2/1/22 09:47, Duane Raymond wrote: > >> Hi, > >> I'm looking to do some radical customisation of the Postorius (and > Hyperkitty) templates over the next 6 ish months and was wondering if there > is a 'best practice' way to do this that will survive updates to MM3. I've > searched around and not found much and also tested copying > >> > venv/lib/python3.7/site-packages/postorius/templates/postorius/lists/summary.html > >> to > >> var/templates/lists/summary.html > >> As suggested in some posts - but it didn't seem to pick up the > customisation - only customisations in the venv path worked - and they get > overwritten on update. > The best way to do this would be utilize Django’s template loader. See > here[1] for the documentation on how you can do this. You want to put the > path where you are putting the templates under `DIRS` option of the > `TEMPLATES` section. > > Do make sure that you are keeping the directory structure correct so that > Django can discover them. Like, Hyperkitty’s base.html should be in > `/custom/path/hyperkitty/base.html`, where `/custom/path` is what you’ve > setup in DIRS setting above. > This looks promising! I've not got it working yet, but this is what I've tried: 1. Created folder 'custom' in the mm root (in my case: /opt/mailman/mm/) 2. Copied the files and folders from postorius/templates/postorius/* and hyperkitty/templates/hyperkitty/* to the custom/ folder (not the full postorius/templates/postorius/ match, just evening in the second postorius/ dirrectory) 3. Recursive update of permissions of the custom/ folder and files to be mailman 4. Updated /opt/mailman/mm/settings.py by changing "'DIRS': []" to "'DIRS': [BASE_DIR, '/custom/']" in the "TEMPLATES =" section 5. Edited the original AND copied postorius/lists/summary.html to have a small change in the footer of each so I know what version it is serving 6. Restarted: gunicorn qcluster mailman nginx and cleared browser cache 7. Reloaded the 'info' page of a few lists to see which version ti was serving Variants: I've also changed the DIRS value to the hard-coded path: /opt/mailman/mm/custom Result: it is still serving the default/original Postorius template vs the custom one. Any suggestions for things I should do to make it use the /custom/ folder instead? Any recompiling or other actions beyond just restarting? (I probably don't need to restart qcluster and maybe not even mailman core for this to take effect but I do it just in case!) Cheers, Duane

3 years, 8 months

[MM3-users] Re: Hyperkitty on Debian 12

by Markus Grandpre

Dear Michael, thank you very much for your clarification. Best regards, Markus Am 3/26/24 um 17:38 schrieb Michael Oberrauch: > On Tue, 2024-03-26 at 08:06 +0100, Markus Grandpré wrote: >> Dear Mr Sapiro, >> >> thank you very much for your help. The required command is: >> >> # mailman-web hyperkitty_import \ >> -l mailman21-migration-test-04(a)mailman.uni-konstanz.de \ >> /var/mailman21/testlist.mbox >> >> Due to the following warnings, I still have to customize Hyperkitty: >> >> django_mailman3.MailDomain: (models.W042) Auto-created primary key >> used >> when not defining a primary key type, by default >> 'django.db.models.AutoField'. >> HINT: Configure the DEFAULT_AUTO_FIELD setting or the >> DjangoMailman3Config.default_auto_field attribute to point to a >> subclass >> of AutoField, e.g. 'django.db.models.BigAutoField'. >> ... >> >> Can you give me another hint? As Linux admin I installed the packages >> mailman and mailman-web that were offered to me under Debian 12. >> Although during the installation of the packages user "list" was >> created, I cannot use it: >> >> # su - list >> This account is currently not available >> >> As with Mailman 2.1, I will probably have to continue working with >> Mailman3 as root. Too bad that there is no documentation for Debian >> admins like me, who don't want to dive too deep into the python >> framework. Or have I overlooked something? >> >> Best regards, >> Markus >> >> > > Hi Markus, > > we are also running MM3 on Debian 12 from Package Repositories. > > First of all, you should not try to directly switch user (su) to the > lists user, it's generally intended to executes commands as that user, > if necessary; either using `runuser`, `sudo`, or `su -c`. > > However, the prepackaged scripts `mailman-wrapper` and `mailman-web` > already do this and therefore you ca run those as root without > permission problems. > > On Debian there are two relevant users for MM3: the list user runs > mailman core, whereas the www-data user runs Postorius and Hyperkitty. > So you have to make shure, that the www-data user can access the .mbox > files while importing. > > Hope that helps. > > Cheers, > Michael > > > > _______________________________________________ > 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 markus.grandpre(a)uni-konstanz.de -- Markus Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre und Infrastruktur, Tel: ++49 7531 88 4342

1 year, 6 months

[MM3-users] Re: mail loops back to myself

by Florian Sukup

On 6/12/25 05:08, Mark Sapiro wrote: > On 6/11/25 13:51, Florian Sukup wrote: >> I have now elimiated reverse.rrr.com. But there isn't much change: >> >> vvvvvvvvvvvvvvvvvvvvvvvvv >> Jun 11 22:19:57 arvak postfix/relay/smtp[1015580]: initializing the >> client-side TLS engine >> Jun 11 22:19:57 arvak postfix/smtpd[1015581]: initializing the >> server-side TLS engine >> Jun 11 22:19:57 arvak postfix/smtpd[1015581]: connect from >> host.xxx.com[m.y.i.p] >> Jun 11 22:19:57 arvak postfix/relay/smtp[1015580]: warning: host >> host.xxx.com[m.y.i.p]:25 greeted me with my own hostname host.xxx.com >> Jun 11 22:19:57 arvak postfix/relay/smtp[1015580]: warning: host >> host.xxx.com[m.y.i.p]:25 replied to HELO/EHLO with my own hostname >> host.xxx.com >> Jun 11 22:19:57 arvak postfix/relay/smtp[1015580]: 29FCF5F867: >> to=<mylists(a)lists.yyy.com>, relay=host.xxx.com[m.y.i.p]:25, delay=0.2, >> delays=0.06/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for >> lists.yyy.com loops back to myself) >> Jun 11 22:19:57 arvak postfix/smtpd[1015581]: disconnect from >> host.xxx.com[m.y.i.p] ehlo=1 quit=1 commands=2 > > > I think you need to add host.xxx.com to mydestinations. > I did that now but no change. When I look into the log, first the smtpd receives the message from my mail client. Then the email is queued. And then the smtp initiates a TLS layer to send it to the smtpd on the same machine. For my understanding this cannot be correct. The smtpd at first should hand it to mailman and not relay it to itself. Is that correct? Here is the complete log up to the point when the error email is created: vvvvvvvvvvvvvvvvvvvvvvvvvvvv Jun 12 12:22:24 arvak postfix/smtpd[1197617]: connect from host.xxx.com[192.168.77.100] Jun 12 12:22:24 arvak postfix/smtpd[1197617]: 53E665F8D2: client=host.xxx.com[192.168.77.100] Jun 12 12:22:24 arvak postfix/cleanup[1197827]: 53E665F8D2: message-id=<35c8a748-b410-46a6-91fc-5cee9f31fc39(a)email.addr> Jun 12 12:22:24 arvak postfix/qmgr[1147234]: 53E665F8D2: from=<my(a)email.addr>, size=598, nrcpt=1 (queue active) Jun 12 12:22:24 arvak postfix/relay/smtp[1197829]: initializing the client-side TLS engine Jun 12 12:22:24 arvak postfix/smtpd[1197830]: initializing the server-side TLS engine Jun 12 12:22:24 arvak postfix/smtpd[1197830]: connect from host.xxx.com[m.y.i.p] Jun 12 12:22:24 arvak postfix/relay/smtp[1197829]: warning: host host.xxx.com[m.y.i.p]:25 greeted me with my own hostname host.xxx.com Jun 12 12:22:24 arvak postfix/relay/smtp[1197829]: warning: host host.xxx.com[m.y.i.p]:25 replied to HELO/EHLO with my own hostname host.xxx.com Jun 12 12:22:24 arvak postfix/relay/smtp[1197829]: 53E665F8D2: to=<mylists(a)lists.yyy.com>, relay=host.xxx.com[m.y.i.p]:25, delay=0.31, delays=0.12/0.01/0.18/0, dsn=5.4.6, status=bounced (mail for lists.yyy.com loops back to myself) Jun 12 12:22:24 arvak postfix/smtpd[1197830]: disconnect from host.xxx.com[m.y.i.p] ehlo=1 quit=1 commands=2

4 months

[MM3-users] Re: Newbie question 2: Rewriting issue for bounced emails

by William Oliver

On Sun, 2021-12-26 at 18:23 -0800, Mark Sapiro wrote: > On 12/26/21 6:19 PM, Mark Sapiro wrote: > > > > Otherwise, you can do this in mailman shell, e.g. > > ``` > > $ mailman shell > > > > 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. > > > > >>> dm = getUtility(IDomainManager) > > >>> d = dm.get('example.com') > > >>> d.alias_domain = x.example.com > > >>> commit() > > ``` > > > Ooops. That should be > > d.alias_domain = 'x.example.com' > > I.e., quoted > > Thanks. I am *almost* there. Adding the vmap in mailman fixed *almost* everything. Now I can add users, get receive mails to the list, archive messages correctly, and send emails. Except... The list sends emails to local recipients fine. I have three users on my test list: fp145(a)libertyfp.org (local) billo(a)billoblog.com (not local) oliver(a)billoblog.com (not local) When I send a message to the list from *any* of these three, the mailman3 accepts it and attempts to broadcast it out. It is delivered sucessfully to the local email address, but it looks like there's a relaying problem with external addresses. In the syslog snippet below, note that the fp145(a)libertyfp.org mail is delivered, but the mail to the recipients at billoblog.com get an "Access denied" Dec 27 15:33:25 libertyfp postfix/smtpd[419593]: connect from mail.libertyfp.org[2.56.57.28] Dec 27 15:33:25 libertyfp postfix/smtpd[419593]: DC203421BE: client=mail.libertyfp.org[2.56.57.28] Dec 27 15:33:25 libertyfp postfix/cleanup[420001]: DC203421BE: message- id=<9785b5a56581104fe079221bb947eb3a03813d97.camel(a)billoblog.com> Here it is getting delivered locally: Dec 27 15:33:25 libertyfp postfix/cleanup[420001]: DC203421BE: warning: header Subject: [Testlist] bbbbb from mail.libertyfp.org[2.56.57.28]; from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org> to=<fp145(a)libertyfp.org> proto=ESMTP helo=<mail.libertyfp.org> Dec 27 15:33:25 libertyfp postfix/qmgr[418758]: DC203421BE: from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>, size=2651, nrcpt=1 (queue active) Dec 27 15:33:25 libertyfp postfix/virtual[420016]: DC203421BE: to=<fp145(a)libertyfp.org>, relay=virtual, delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir) Dec 27 15:33:25 libertyfp postfix/qmgr[418758]: DC203421BE: removed Here it is getting bounced for billo(a)billoblog.com and oliver(a)billoblog.com: Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: NOQUEUE: reject: RCPT from mail.libertyfp.org[2.56.57.28]: 554 5.7.1 <billo(a)billoblog.com>: Recipient address rejected: Access denied; from=<testlist-bounces+billo=billoblog.com(a)libertyfp.org> to=<billo(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org> Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: disconnect from mail.libertyfp.org[2.56.57.28] ehlo=1 mail=2 rcpt=1/2 data=1 rset=1 quit=1 commands=7/8 Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: connect from mail.libertyfp.org[2.56.57.28] Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: NOQUEUE: reject: RCPT from mail.libertyfp.org[2.56.57.28]: 554 5.7.1 <oliver(a)billoblog.com>: Recipient address rejected: Access denied; from=<testlist-bounces+oliver=billoblog.com(a)libertyfp.org> to=<oliver(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org> This error occurs whether the account posting to the list is in the libertyfp.org domain or billoblog.com domain. Note that "regular" mail from libertyfp.org does get delivered to outside addresses just fine, originating from inside the domain or through an email client outside the domain. I tried changing the smtp port in mailman.cfg to 587, but that didn't change anything. In my reading, there seems to be differing discussions about what should be in the mydestinations value, but I don't know what it should be. Here's the current last bit of my main.cf, along with the mydestinations setting: mydestination = localhost.org, localhost # add to the end (add virtual users) # if specify multiple domains, specify comma or space separated virtual_mailbox_domains = libertyfp.org virtual_mailbox_base = /home/vmail virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox virtual_uid_maps = static:20000 virtual_gid_maps = static:20000 # mailman3 changes owner_request_special = no always_add_missing_headers = yes transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp local_recipient_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains default_destination_recipient_limit = 30 default_destination_concurrency_limit = 15 virtual_alias_maps = hash:/opt/mailman/mm/var/data/postfix_vmap header_checks = regexp:/etc/postfix/header_checks Here's the current values in /opt/mailman/mm/var/data/postfix_domains: # AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own. x.libertyfp.org libertyfp.org here's postfix_lmtp: # AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own. # Aliases which are visible only in the @x.libertyfp.org domain. testlist(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-bounces(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-confirm(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-join(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-leave(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-owner(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-request(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-subscribe(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 testlist-unsubscribe(a)x.libertyfp.org lmtp:[mail.libertyfp.org]:8024 Heres the postfix_vmap that was (finally) successfully created: # AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own. # Virtual mappings for the @libertyfp.org domain. testlist(a)libertyfp.org testlist(a)x.libertyfp.org testlist-bounces(a)libertyfp.org testlist-bounces(a)x.libertyfp.org testlist-confirm(a)libertyfp.org testlist-confirm(a)x.libertyfp.org testlist-join(a)libertyfp.org testlist-join(a)x.libertyfp.org testlist-leave(a)libertyfp.org testlist-leave(a)x.libertyfp.org testlist-owner(a)libertyfp.org testlist-owner(a)x.libertyfp.org testlist-request(a)libertyfp.org testlist-request(a)x.libertyfp.org testlist-subscribe(a)libertyfp.org testlist-subscribe(a)x.libertyfp.org testlist-unsubscribe(a)libertyfp.org testlist-unsubscribe(a)x.libertyfp.org For what it's worth, here's the extended header info for the mail that *was* delivered: Return-Path: <testlist-bounces+fp145=libertyfp.org(a)libertyfp.org> X-Original-To: fp145(a)libertyfp.org Delivered-To: fp145(a)libertyfp.org Received: from mail.libertyfp.org (mail.libertyfp.org [2.56.57.28]) by mail.libertyfp.org (Postfix) with ESMTP id 226F6421BA for <fp145(a)libertyfp.org>; Mon, 27 Dec 2021 16:27:17 -0500 (EST) Received: from [10.112.157.251] (unknown [92.60.40.252]) by mail.libertyfp.org (Postfix) with ESMTPSA id F3608421BA for <testlist(a)libertyfp.org>; Mon, 27 Dec 2021 16:27:11 -0500 (EST) Message-Id: <562c2f8aaeb3c9e2ccf198aff197dbd299fc002a.camel(a)libertyfp.org> From: fp145(a)libertyfp.org <fp145(a)libertyfp.org> To: testlist(a)libertyfp.org Date: Mon, 27 Dec 2021 16:27:07 -0500 In-Reply-To: <eb3380eecc734e240f65ddf974d81ee7dac6ca20.camel(a)libertyfp.org> References: <eb3380eecc734e240f65ddf974d81ee7dac6ca20.camel(a)libertyfp.org> User-Agent: Evolution 3.40.0-1 Mime-Version: 1.0 Message-Id-Hash: FKEDFEFMXBD6YUDWKL235PQRIMUYYPEQ X-Message-Id-Hash: FKEDFEFMXBD6YUDWKL235PQRIMUYYPEQ X-Mailfrom: fp145(a)libertyfp.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember- moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.5 Precedence: list Subject: [Testlist] Re: test from fp145 List-Id: Test list <testlist.libertyfp.org> Archived-At: <https://libertyfp.org/archives/list/testlist@libertyfp.org/message/FKEDFEFM… > List-Archive: <https://libertyfp.org/archives/list/testlist@libertyfp.org/> List-Help: <mailto:testlist-request@libertyfp.org?subject=help> List-Owner: <mailto:testlist-owner@libertyfp.org> List-Post: <mailto:testlist@libertyfp.org> List-Subscribe: <mailto:testlist-join@libertyfp.org> List-Unsubscribe: <mailto:testlist-leave@libertyfp.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Evolution-Source: 14004b3d9af2d67c898fd6d6c16b487f796088f5 I'm beginning to hate postfix. billo

3 years, 9 months

[MM3-users] Re: Confusing mailman user model

by Gilles Filippini

Gilles Filippini a écrit le 19/07/2020 à 18:00 : > Mark Sapiro a écrit le 19/07/2020 à 17:30 : >> On 7/19/20 8:10 AM, Gilles Filippini wrote: >>> Hi, >>> >>> I'm trying to understand the Mailman user model, and I'm confused about >>> the respective roles of tables 'auth_user' and 'user'. >> >> >> auth_user is a Django auth table. These are the users listed in the >> Django admin web UI. >> >> user is Mailman core's users. >> >> >>> Both have an 'id' column referred to as 'user_id' when used as a foreign >>> key. But there seems to be no relation at all between them as they use >>> different ids for the same user. >> >> >> Right, they are unrelated. >> >> >>> Our mailman server was migrated from mailman2 to mailman3 about 1.5 year >>> ago, and there is an inconsistency I'd like to fix: >>> 2 of our users have a registered Mailman account with their respective >>> email addresses in table 'auth_user', but these very same addresses in >>> the 'address' table are linked to another old admin account in the >>> 'user' table. >> >> Their Mailman account is the 'old' one. the auth_user account is a >> Django account >>> >>> Then if add one of these addresses as a domain owner, it it the old >>> admin address which is selected instead. How could I fix that? >> >> >> That's because domain owner in a Mailman thing and involvs the Mailman >> user. You could delete the Django users via the Django admin UI and then >> re-register them via Postorius. That *might* work. > > When login into postorius, it is the Django account that is used, right? > Then how is the mailman account retrieved from there? It seems UUIDs are > used in the process, but I fail understanding how, so far. Wouldn't it > be safe to retrieve the new Mailman account associated to these Django > users, and link there emails from 'address' table' to them? Reading the mailman-web source code I understand now that the mailman account is retrieved from the Django account email address. Then both users are tied to the same old mailman admin account, and deleting then registering them again won't change anything on this aspect. Would this work? 1- For both addresses, update their record in table 'address' to set 'user_id' to null 2- On their next login to Mailman-web, a new mailman account would be created and associated with their own email address. Is my understanding correct? _g.

5 years, 2 months

[MM3-users] Re: Member Issue Discovered

by Brian Carpenter

On 10/19/20 11:32 PM, Mark Sapiro wrote: > On 10/19/20 7:42 PM, Brian Carpenter wrote: >> On 10/19/20 10:23 PM, Mark Sapiro wrote: >>> And the import21 created the user and address records for this user. >> Does the same thing for a new subscriber as well. So there is no pathway >> to change a real name that is associated with an email address. None. >> Zilch. Mailman 2 made this so easy and Mailman 3 made it impossible. I >> will let someone else file the bug report. You don't really think that >> this is an issue which means it will be years before it is addressed. So >> I will save me some time. I will learn to live with it. > > I didn't say I didn't think it was a real issue. I mostly questioned > whether a new subscription should change an existing display_name. I > agree that there should be a way for a user to change the display_name > associated with her address. I'm not so sure about a list admin. Respectively, I think you are asking the wrong question here. The real question is why isn't a display_name being removed when a list subscriber is unsubscribed. Also list members being forced into a powerless role by Mailman 3's architecture have no way of changing a name except through a list owner unless they register an account but then again, *even that doesn't allow them to change their display name*. There are also other use cases in which a list owner will want to identify portions of their membership roster through the use of the display_name. Most list members interact with a Mailing list program via email. I know you understand that. However it is List owners that are the "real" power users of Mailman and so the admin interface should be designed in such a way that empowers List owners. Taking the ability away from List owners (and List members to make), what should be a simple name change, weakens them. > And in any case, I'm only one person. I'm not the only one deciding > what's important and what's not. I only decide what I want to work on, > not what anyone else thinks is important or wants to work on, so even if > I think something is not worth doing, that doesn't mean it won't get > done, and once again for emphasis, I do thing a user should be able to > change the display name associated with her address(es). Again I think we are missing something here from this conversation: data is not being removed. A list subscriber being removed (unsubscribed) should have their information totally removed. It is not. I now have one list owner who realizes this and it is not good. How does this not violate GDPR? This is why I think all the mailman developers ought to make this issue a high priority. It is creepy to see a name returned out of nowhere when someone resubscribes to a list without associating a name with a second resubscribing. I think this puts List owners at a disadvantage. > > Mailman 3 is totally different from Mailman 2.1 in this respect. Mailman > 2.1 had no concept of user. All it knew was addresses subscribed to > lists and an address subscribed to one list had no connection to the > same address subscribed to another list or being an owner or moderator > of a list. I think this should still be the case for non-registered list members. List owners/moderators are different. They HAVE to be registered users of Postorius/Affinity in order to manage/moderate a list. I wonder what the majority of list members' scenarios are. Is the majority scenario in play today the one where most list members are only subscribed to a single list on a single mailman instance? Or is it the scenario that is in majority use the one where a single list member is subscribed to multiple lists? I think that it is important to find out because it should govern the development process to a certain degree. This single approach of having registered user account with multiple associated email accounts elevates one scenario at the expense of the other. It also assumes/requires that list members have a registered user account and I can tell you from my experience that is not going to happen. The majority of mailman 2 users will not registered with a Mailman 3 admin interface. Some will of course, the majority will not. Maybe the behavior should and will change but it will take years for that to happen. So what I am challenging and questioning here is the approach where such assumptions are being made already that results in the weakening of list owners. > > Mailman 3 does have a concept of user and addresses belonging to a user. > This complicates things in some ways. In Mailman 2.1 we could have "The > Boss <user(a)example.com" as a member of one list and "Just a Peon > <user(a)example.com>" as a member of another list. In Mailman 3 that is > not possible unless the addresses are tweaked in some way to make them > different. Perhaps there is a better approach here to handle single member w/multiple subscriptions that doesn't hurt the ability of List owners to serve the needs of list members who do not have a registered user account and prevents the removal of data when a SINGLE user unsubscribes from a list. > > You don't seem to be concerned about the case where I subscribe to a > second list with a different display name and am surprised to find my > display name changed on the first list, but it's something that I have > to consider. I am not concerned because I think such cases are in the extreme minority. Are you saying that people are now going to be using different real names associated with their other subscriptions as well and that is going to be so needed it warrants this complex system that you have come up with? If someone whats to have a different name associated with a different subscription/email address then I am going to tell them create a new user account and use a good password management program to keep track of their logins. Right now I think this minority use case scenario is negatively impacting other administrative tasks of Mailman, particularly in the removal of user data when someone unsubscribes from a list. Its the use of a square peg being forced into a round hole. Except in this case most of the holes are round but by golly, we are going to use that square peg regardless! > > As far as filing or not filing an issue, issues in the GitLab trackers > are how we track these things. Threads on mailing lists are appropriate > for discussion of issues, but if something is going to get changed or > fixed, an issue in the tracker is the way to ensure it doesn't get put > aside and forgotten. If this is as important to you as it seems to be, > please file the issue. I will but what is disturbing is that you don't think that the non-removal of user data in cases of unsubscribing is not important or even an issue. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 11 months

Search results for query "sapiro"