Search results for query "sapiro"
- 6225 messages
[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 '^$|^.*#' ¯\_(ツ)_/¯ :-)
3 years, 5 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
4 years, 2 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.
10 years
[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
4 years, 3 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
2 years, 2 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
11 months, 2 weeks
[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
4 years, 5 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, 10 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
5 years, 7 months
[MM3-users] Re: Turn off social logins?
by Torge Riedel
Am 16.02.19 um 13:50 schrieb Stephen J. Turnbull:
> Mark Sapiro writes:
> > On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:
> > > Torge Riedel writes:
> > >
> > > > - there is a way to do this now via settings_local.py, but feels
> > > > a little bit risky if default configuration changes on update of
> > > > mailman
> > >
> > > This should not be true. If it is, we need to fix that. Will check.
> >
> >
> > It is more or less true [...] the only way settings_local.py can
> > change something like INSTALLED_APPS is to redefine INSTALLED_APPS
> > in it's entirety which leads to the possibility of INSTALLED_APPS
> > changing in settings.py and those changes not being picked up in
> > settings_local.py.
>
> That's a different issue from the one I believe Torge is worried
> about, which is an update overwriting settings_local.py. But it's not
> good.
Well, Mark got it what I was meaning. Maybe my explanation was not precise enough.
Hopefully an update is not overwriting settings_local.py in any case. Is it part of delivery and then changed afterwards? Haven't checked that yet.
I personally like the way other services are importing custom settings by including all config files from a given directory. Maybe it is not worth for mailman cause custom settings will not grow very big - so no need to split it in tiny files.
>
> > The way around this is to remove the import of settings_local from
> > settings.py and then put
> >
> > from settings import *
> >
> > at the beginning of settings_local.py and then point Django at
> > settings_local rather than settings.
>
> I don't understand the ramifications of making this change (presumably
> Barry or somebody had a reason for the change from Mailman 2's
> method), but at first glance it looks like a big step in the right
> direction.
>
> > Then you can do things like
> >
> > try:
> > INSTALLED_APPS.remove('allauth.socialaccount.providers.google')
> > except ValueError:
> > pass
> >
> > in settings_local.py except there are still issues because, e.g.,
> > INSTALLED_APPS is defined as a tuple (immutable) and not a list in
> > settings.py.
>
> Given the concerns of privacy advocates, I would say that it would be
> better to have a separate
>
> AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...]
>
> in settings_local.py, and merge that in to INSTALLED_APPS. Of course
> removing specific providers would be OK too, but I think that this is
> a place where "deny all / accept what you want" is appropriate.
>
> Steve
>
7 years, 3 months