Re: Changing subscription address
by Stephen J. Turnbull
Thank you for your comments, Allan!
Allan Hansen writes:
> On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>>In the 'Mailman Settings' screen, List-based Preferences' tab,
>You may mean the 'Subscriptions' tab.
I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab
is non-functional. It's in some sense aesthetically more pleasing
than 'List-Based Preferences', but you have to do extra, unnecessary
work to get anything done from the 'Subscriptions' tab. It may make
sense to just get rid of the current 'Subscriptions' tab and rename
'List-based Preferences' to 'Subscriptions'.
The only functionality of 'Subscriptions' over 'List-based
Preferences' is that it lists you once for each role and address
(member, non-member, moderator, owner) that you have for that list.
This is possibly more confusing than helpful for non-owners.
Moderators get informed of their role every time they need to do
something. And it's possible to be both a member and a non-member of
a list, which is pretty confusing.
> Under 'User profile for <name>', under the 'E-mail Addresses', add
> button to ensure that 'Primary E-mail' is used for all lists.
If you define "ensure" strictly, this would be a fair amount of work
because it would require overriding the normal "cascade" of
preferences, and incidentally a way to turn off that override. I'd
rather not make the implementation so complicated.
There does need to be a way to revert each option to inherit, and
there currently doesn't seem to be one. The 'Preferences' interface I
described in the previous post doesn't provide it either. I will
think about that.
It should be normally unnecessary to use the 'Preferences' interface,
because the default subscription should be "use primary address". For
people using the current versions of Mailman 3, who are already have a
bunch of subscriptions with the same *explicit* address, I think it is
good enough. But if there's demand for a "revert all to use primary
address" button, that would be easy enough to add.
Here's why I think such a button would be unnecessary in future
versions of Mailman. What should happen if you subscribe by an
address not already known to Mailman without creating an account in
Postorius is
1. Mailman registers the address.
2. Mailman creates a User object to "own" that address, and makes
that address the primary address for the User.
3. Mailman creates a subscription which links the User (not the
address) to the mailing list so that the primary address is used.
For addresses already known to Mailman, Mailman should look up the
User registered to that address, and if the subscription address is
the primary address, set "use primary address" for the subscription.
In this scheme, as far as I can see, your user doesn't need to do
anything with the account until she wants to change the address. At
that point she needs to activate the account:
- visit her personal options page in Postorius
- request a password reset (she doesn't have one yet, so she can't log
in)
- click the special link
- set a password or link a social media account, and
- finally change the address.
Note that this is the bare minimum of work for her. She has to prove
she can read mail at that address. Anything less, and *anybody* can
change her subscriptions. We could omit requiring a new password,
but it's not a lot of work once you've got to this point, while the
"request, wait for email, click link, do work" dance is pretty
annoying. Why make someone do it again next time?
This is problematic if she's already lost access to the old address,
of course, but in that case you're probably going to have to intervene
anyway.
I don't think Postorius requires her to do anything else, but if she
wants to she can update her profile at that point.
I have to check the code, and probably also ask Barry and the other
folks who designed the current subscription mechanism in case there's
some fatal flaw in the scheme above. But I think that should do what
almost all "one address" users want, and it's probably what the
majority of people who have multiple addresses and use different ones
for different purposes want most of the time, too.
Note to self of possible problems: (1) The primary address is where
you would send administrative mail to the account holder and that
might not be an appropriate address for the default subscription.
(2) This is a pretty radical change from the current situation, so it
might need to be an option for the list or domain owner.
> And, indeed, new subscriptions should default to 'Use Primary.'
I agree. I'm astonished that there are situations where they don't,
to be quite honest. That's the whole point of having accounts in the
first place -- having *one* source of information about the user
rather than spreading it out over a bunch of lists.
> Is that possible now?
It is already the default for someone who subscribes by logging in to
Postorius. I assume that it is *not* the default for someone who
subscribes by email or mass subscription, otherwise you wouldn't have
the problem.
> Does a member have to have an account for me to set it up thus for
> them?
Yes. The primary address is an attribute of the account.
Subscriptions can't know anything about a primary address unless there
is an account. However, it should be possible to make this default
for an account that hasn't been activated yet, such as in a mass
subscription.
Regards,
Steve
5 years, 3 months
Re: Changing subscription address
by Abhilash Raj
> On Mar 22, 2021, at 7:53 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Abhilash Raj writes:
>
>> Well a couple of stars have to align for it to work unfortunately.
>
> I'm not going to wait for the stars; I have backward-incompatible
> surgery in mind.
>
>> Add to that you can’t set an address as primary using just email
>> commands, you end up with what you are seeing.
>
> Right. The idea is that the first time an address is used, a User
> will be created and that address will be primary for that User. When
> the person wants to claim that address, they go to Postorius, create a
> Postorius account, do the address verification dance and set
> credentials, which links the Postorius account to the User via the
> Address.
>
> This is why the ability to merge Users becomes an urgent need: people
> who subscribe via email are going to end up with multiple Users.
Well, it doesn’t change the situation much from status quo. You also
have multiple users today, even if you subscribe via individual address
since an address always has a User. And like we were discussing over
on the other thread, when the owner decides to join in P and control both the
addresses from single P account, we’ll merge both users.
>
>> We don’t necessarily need the flag on user to set an unverified primary
>> address, we might be able to get away without that. We could set the
>> address as primary *after* we verify it. We always verify addresses
>> regardless of the choice of the subscription mode (user or address).
>
> I'm not clear what you're saying. In general admins can't read your
> mail, so they can't verify you on a mass subscribe or an import.
What I meant was, we can set the address as primary after the verification
dance with the user and then subscribe the primary address.
The existing subscription workflow is a multi-step process that can be
paused and resumed. We pause when we send out a confirmation
email and then resume when that confirmation token is somehow
processed via email or API. So, post receiving the confirmation and
before actually subscribing, we can se the address as primary if the
user doesn’t have one and subscribe user as inhert. We don’t do any
of that if user already has chosen a primary address and it doesn’t
match the current address.
Also, mass-subscribe and import does allow you to verify an address by
clicking this “Pre-verified” checkbox, which can be useful if you are
migrating from a different service or you exported a list of users from
somewhere you know to be valid.
>
>> Right now, P is explicit about it. You can choose if you want Primary
>> Address or one of the explicit addresses added to your account. The
>> primary address is the pre-selected choice, so if you go and just click
>> on subscribe button, you get the primary address being subscribed. If
>> you choose the explicit address then we subscribe the explicit address.
>>
>> Is that something you think needs modifying?
>
> No. The option to set a subscription to the literal primary address
> should still be available. I don't see a good reason to complicate
> the UI logic by comparing primary to literal addresses just to remove
> that one. I just want the primary address to be populated
> automatically, and inherit-from-primary be the default subscription
> address when the subscription address matches primary, *unless* the
> subscriber explicitly chooses that literal address in Postorius.
>
> This is backward-incompatible, but I think it will be overwhelmingly
> popular with new users and old.
There would be no behavioral change for users using email commands.
For those using P, I think will be able to manage and switch rather easily.
>
>> The email join command does the first part you suggested, (if the lookup
>> succeed and matches primary address, use inherit) but doesn’t do the
>> second part (it will create a user, add the address to it and then use the
>> address to subscribe). We can and should fix that.
>
> I think that's all we need to do going forward.
>
> We do need a better UI for setting options (including address) for a
> selection of subscriptions, but that's an independent task.
>
> Thanks for looking at this, Abhilash!
Of course :)
>
> Steve
--
thanks,
Abhilash Raj (maxking)
5 years, 3 months
Re: REST API Question: possible to change user preferred email?
by Abhilash Raj
On Fri, Mar 15, 2019, at 10:59 AM, Nathan Dixon wrote:
> Hi,
> We are in need of being able to change a user's email address via the REST
> API. After looking through the documentation and code, I can't see a way to
> do this in a simple way.
>
> Although the documentation seems to show that if a user changes their
> preferred address, it will track throughout all their subscriptions.
It depends on how are you actually using Mailman. Postorius today subscribes
people using their addresses, so the method you mentioned below is the correct
way to change addresses.
If you think you are going to do this more frequently, you could subscribe users
with their user_ids and then when you need to change their memberships, you
just update their preferred_address.
See [1] here for how to join a mailing list using user_ids. Note that this isn't
available today using Postorius (our Web UI), but I'd be happy to work with you
if you want to contribute it.
[1]: https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/membership.h…
>
> See:
> https://gitlab.com/mailman/mailman/blob/master/src/mailman/rest/docs/member…
> "When Gwen changes her preferred address, her subscription automatically
> tracks the new address."
>
> The only way I can see to do this via the REST API would be to do the
> following long winded way:
>
> *1. Create a new address:*
> POST to http://<api_url>/3.1/users/<$OldEmail>/addresses
> $postData: {email = "$NewEmail"}
>
> *2. Verify the new address:*
> POST to http://<api_url>/3.1/addresses/<$NewEmail>/verify
> $postData: { }
>
> *3. Get all the memberships for the old email address*
> $memberships = GET to http://<api_url>/3.1/addresses/<$OldEmail>/memberships
>
> *4. Change users email for each membership individually*
> foreach ($membership in $memberships) {
> PATCH to http://<api_url>/3.1/members/<$membership.member_id>
> $pathData: { address = $NewEmail }
> }
>
> *5. Delete Old Address*
> DELETE to http://<api_url>/3.1/addresses/<$OldEmail>
>
> Am I missing something (as in there is a way to do a single PATCH request
> somewhere)? Or is this the only way to update someone's email address with
> these 5 steps?
>
> Thanks,
> Nathan Dixon
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>
--
thanks,
Abhilash Raj (maxking)
7 years, 3 months
Re: Reject with notification not working
by Mark Sapiro
On 3/26/26 10:30 AM, MegaBrutal via Mailman-users wrote:
>
> To be honest, I didn't quote logs because I didn't find anything upon first
> check. But now I looked again and found interesting entries.
>
> I get different errors depending on whether I define
> the list:user:notice:rejected template.
>
> When the template is not defined:
>
> Mar 26 01:48:02 2026 (28606) Uncaught runner exception: 'ascii' codec can't
> encode character '\xed' in position 21: ordinal not in range(128)
I suspect you have a list:user:notice:rejected.txt template other than
the default defined in the file system somewhere, probably in the
/opt/mailman/mm/var/templates/ hierarchy. I say this because the default
template at
/opt/mailman/venv/lib/python3.11/site-packages/mailman/templates/en/list:user:notice:rejected.txt
doesn't contain a hex ED (lower case i with acute accent) character.
The issue is the list's preferred language is English and the preferred
character set for English is ascii and the resultant message built from
the template contains that non-ascii character.
> And this is what happens when I define the template:
> ...
> requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost',
> port=8000): Max retries exceeded with url: /mailman3/api/templates/list/
> hirlevel.lista.autistaktol.hu/list:user:notice:rejected (Caused by
> NewConnectionError('<urllib3.connection.HTTPConnection object at
> 0xf46e5910>: Failed to establish a new connection: [Errno 111] Connection
> refused'))
Here you have defined the template in Postorius and Mailman core is
attempting to get the template from the Postorius API and the connection
is refused.
What is your setting for POSTORIUS_TEMPLATE_BASE_URL and if you prepend
that to
/mailman3/api/templates/list/hirlevel.lista.autistaktol.hu/list:user:notice:rejected,
can you get the resultant URL?
In both cases, the messages are shunted and you can see them,
particularly the first one with
mailman qfile
/opt/mailman/mm/var/queue/shunt/1774486082.6627975+afc236d96580c03921fa8a6f172f4a81eb2d20f6.pck
> I have so many questions...
>
> 1. What is it about the ASCII encoding? "ordinal not in range(128)"?
> What do we even do with ASCII in 2026? I tried to send a message that only
> contains ASCII characters, but the result was the same, so it's probably
> not in the e-mail contents.
It's in the template. There are reasons, mostly historical but also
practical why the default character set for English is ascii. Also see
<https://gitlab.com/mailman/mailman/-/work_items/1268>.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
2 months, 4 weeks
MM3 error on moderation request
by Odhiambo Washington
MM3 - 3.3.10, Postorius 1.3.13.
After receiving the notification to attend to a moderation request:
```
At your convenience, visit
https://mm3-lists.kictanet.or.ke/mm/lists/kictanet.lists.kictanet.or.ke/hel…
to approve or deny the request(s).
```
Upon visiting the link I ended up with a server error.
mailmanweb.log has the below to say:
```
[ERROR] [2024-10-10 12:29:15,905] [log] 809040 139858772735552 Internal
Server Error: /mm/lists/kictanet.lists.kictanet.or.ke/held_messages
Traceback (most recent call last):
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py",
line 1026, in find_library
return parser.libraries[name]
~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'humanize'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/exception.py",
line 55, in inner
response = get_response(request)
^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/base.py",
line 197, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/contrib/auth/decorators.py",
line 23, in _wrapper_view
return view_func(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/auth/decorators.py",
line 63, in wrapper
return fn(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/views/list.py",
line 889, in list_moderation
return render(request, 'postorius/lists/held_messages.html', context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/shortcuts.py",
line 24, in render
content = loader.render_to_string(template_name, context, request,
using=using)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py",
line 61, in render_to_string
template = get_template(template_name, using=using)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py",
line 15, in get_template
return engine.get_template(template_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/backends/django.py",
line 33, in get_template
return Template(self.engine.get_template(template_name), self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py",
line 175, in get_template
template, origin = self.find_template(template_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py",
line 157, in find_template
template = loader.get_template(name, skip=skip)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/cached.py",
line 57, in get_template
template = super().get_template(template_name, skip)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/base.py",
line 28, in get_template
return Template(
^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 154, in __init__
self.nodelist = self.compile_nodelist()
^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 200, in compile_nodelist
return parser.parse()
^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 513, in parse
raise self.error(token, e)
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 511, in parse
compiled_result = compile_func(self, token)
^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader_tags.py",
line 293, in do_extends
nodelist = parser.parse()
^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 513, in parse
raise self.error(token, e)
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py",
line 511, in parse
compiled_result = compile_func(self, token)
^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py",
line 1088, in load
lib = find_library(parser, name)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py",
line 1028, in find_library
raise TemplateSyntaxError(
django.template.exceptions.TemplateSyntaxError: 'humanize' is not a
registered tag library. Must be one of:
account
admin_list
admin_modify
admin_urls
allauth
bootstrap_tags
cache
compress
d_gravatar
date_helpers
debugger_tags
decorate
gravatar
highlight
highlighting
hk_generic
hk_haystack
i18n
indent_text
l10n
log
markdown
membership_helpers
more_like_this
nav_helpers
p_gravatar
pagination
postorius_helpers
rest_framework
socialaccount
static
syntax_color
tz
widont
[WARNING] [2024-10-10 12:29:16,384] [log] 809040 139858704070336 Not Found:
/mc/compose
```
How to fix?
--
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: Emergency moderation and clearing out a lot of held messages
by Stephen J. Turnbull
Caballero, Danny (Dan) writes:
> I don't understand. We have a single database configured for
> everything. I don't recall reading anything in the set-up
> documentation about using more than 1 database for Mailman3.
I was trying to help localize the database request to one of the three
major components: core, Postorius, HyperKitty. If you use the two-
database scheme documented here:
https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…
knowing that database would at least identify whether the slowness is
associated with core or with the web apps.
The excruciating details:
Conceptually, there are three separate databases: the one used by
Mailman core to manage everything but authentication and archives, the
one used by Django to manage authentication for HyperKitty and
Postorius, and the one used by HyperKitty to manage archives. They
don't share tables, and there are no name collisions for the tables so
it doesn't really matter how the backend handles them.
The two database configuration is not really a recommendation. I
suppose the practice derives from an abundance of caution, as there
are concepts like "User" that must be implemented in somewhat
different ways across components (core doesn't authenticate users,
while Postorius's primary function is authentication of users). I
myself would worry that there might be name collisions among tables,
which would cause mayhem, but that's probably excessive.
3 years, 7 months
Rolling releases for Container Images and Funding Campaign for Mailman
by Abhilash Raj
Hi Everyone,
As you all know I have been working on container images for Mailman 3.
We now have a new "rolling" tag for both mailman-core and
mailman-web images. These images have latest source installed
for every Mailman component. You can find more information about them
on the website [3].
New images are available on quay.io and, moving forward, the rest of
the image builds will also be moved to Quay[4][5].
These images are built using git-heads *only* if they are passing our
test suite and are re-generated weekly. You should be aware that while
all these components are tested with their individual test suites, their
combination might sometimes not be stable. This will get you
updates/bug-fixes much faster :)
As most of you already know, Mailman 3 is the new and improved version
with extra features, better security and much better architecture. We
released Mailman Suite 3.0 in April 2015 and have come a long ways since
then. Mailman Suite 3.1, release May 2016, was aimed to provide
feature-parity with Mailman 2.x series and we think we _almost_ hit that
goal.
Apart from no monthly password reminders, Mailman 3 has a much better
Administrator/User interface, REST API for scripting, a really awesome
archiver, support for multiple domains, support for external plugins,
support for SSO/social login and so much more!
I love working on Mailman and would enjoy being able to do so full time
for next 6-8 weeks. Mailman 3 is not very far from becoming the default
version everyone would use, but it still needs some work to get there. I
need help from you, the users of Mailman, to get us there. If you or
your organization would like to move to (or, already moved to) Mailman
3, I urge you to donate[1] to us.
There are options to donate using Credit Card, Paypal, Bitcoin, Wire
Transfer
(of any currency), Check and money order.
If this campaign succeeds, here is a road map of what I intend to get
done:
- Move Django apps(UI/Archiver) to Python 3 (or bilingual)
- Fork `mailman import` command to provide an upgrade path to Mailman
3.x from Mailman 2.x
- Fix MySQL compatibility in Core
- Changes in Postorius:
- Add support for missing options that are already exposed in Core’s
API
- e.g. Support for setting templates
- Find the commonly used options that are not exposed in Core, add
them to Core's API and add to Postorius
- Add Admin Dashboard project from GSoC 2014 (maybe?)
- Add better testing of container images and provide deployment
instructions for Kubernetes & Docker Swarm
- Improve the container images to work with new micro-services
architecture,
to achieve scaling and redundancy in services.
- Administrator/User documentation for Postorius & Mailman
- (optional) Fork [mmcli](https://github.com/rajeevs1992/mailmancli)
project from Rajeev, fix if there is anything missing and add it as
an
additional command line tool to work with Mailman Core. Maybe pull it
under Mailman umbrella.
Except for these, if there is something more important that is
preventing the adoption of Mailman 3 from your end, we can discuss them.
I'd like to mention that I have been working on Mailman 3 for quite some
time now and I intend to implement every single item on the list. You
donations would help it get done much sooner, hopefully in time for 3.2
release schedule (at PyCon US 2018).
You can follow the progress of this campaign here[2].
[1]: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=22
[2]: https://wiki.list.org/x/17892025
[3]: https://asynchronous.in/docker-mailman/#rolling-releases
[4]: https://quay.io/repository/maxking/mailman-web
[5]: https://quay.io/repository/maxking/mailman-core
--
Abhilash Raj
maxking(a)asynchronous.in
8 years, 7 months
Migrating to Mailman3
by Stephen J. Turnbull
dap1--- via Mailman-users writes:
> I am about to migrate from mailma2 on CentOS to mailman3 on
> Ubuntu. Are there any special gotchas of which I need to be aware?
> TIA.
* The Ubuntu packages are old, and not well-supported by Ubuntu or the
Mailman project. Mailman 3 is not a hyperactive project, but we are
making steady progress and many new Mailman 3 users have issues or
requests for enhancement for 2-, 3-year-old packages that have been
fixed or implemented in the most recent releases. For these reasons,
we strongly recommend installing from source or from PyPI in a virtual
environment:
https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…
(Installing from source is not hard, but it's more work than using
pre-built packages. Source is required for beta testers and
developers, but not recommended for most production environments.)
* If your preferred RDBMS is in the MySQL family:
1. Make sure the Mailman database(s) have the utf8mb4 charset option
set. Otherwise all emoji and some Asian characters will cause
your database to throw errors (I think this is mostly an issue for
HyperKitty and maybe a few users who put them in their display
names in Postorius and Mailman core). This is not needed for
PostgreSQL or SQLite3.
2. You may want to increase the timeout for startup (I think this is
in the systemd units for mailman and mailmanweb). The issue is
that the mysqld doesn't exit until the journal has been flushed to
the main database (or something like that), and this may take many
seconds. This is not an issue for SQLite3 (it's a library) or
PostgreSQL (it uses dbus to notify systemd that it's ready).
* The migration scripts for list database and web databases are quite
good, but not 100%.
* The user model is completely different. Ordinary subscribers will
probably be happy or won't notice, but there are some traps for
administration roles. The most important is that some list owners
will give the owner password to moderators so they can do work like
use mass subscribe, but put them on the moderator list attribute so
they get the moderation notices. These moderators will lose the
"owner" capabilities like mass subscribe.
* If you're looking at a multinode installation with Mailman core,
Postorius and HyperKitty distributed across several hosts or
containers, configuration can be finicky. I don't recommend it unless
you're familiar with such distributed operations.
Steve
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
8 months
Re: Issues with @gmail.com addresses
by Mark Sapiro
On 9/5/23 12:59, Mohsen Masoudfar wrote:
> Hi,
>
> since 8/1/2023 I get complains from users with @gmail.com addresses, that they are not getting any emails.
> I checked the logs and I see that the emails are going out:
>
> to=<xxxx(a)gmail.com>, relay=email-smtp.us-east-1.amazonaws.com[35.169.171.20]:587, delay=0.46, delays=0.03/0.06/0.13/0.24, dsn=2.0.0, status=sent (250 Ok xxx )
>
> But it seems the users are getting email delivered to them.
> I’ve advised them to check their spam, promotions, and social folders and to add the list address to their email safe-senders lists, but still no success.
> Is there any way to help this list members?
Even though gmail publishes a DMARC policy of none, it has recently
started enforcing a stricter policy for mail From: the gmail.com domain.
You need to apply DMARC mitigations to mail From: the gmail.com domain.
There are two ways to do this.
One way is to set DMARC Mitigations -> DMARC Mitigate unconditionally to
Yes (and set DMARC mitigation action appropriately)
The other way requires upgrading Postorius and Mailman core to the heads
of the GitLab branches (core=3.3.9b1, postorius=1.3.9b1). Doing this
enables a DMARC Addresses setting which can be set to `^.*(a)gmail\.com$`
to apply DMARC mitigatations to mail From: the gmail.com domain
regardless of it's published policy.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
2 years, 9 months
Re: Fwd: Re: Removing a mail addresses and users
by Abhilash Raj
On Sun, Jun 14, 2020, at 12:45 PM, Allan Hansen wrote:
> All,
>
> Thank you for your thoughtful responses to my call for a removal of the
> core vs. Django disconnect. From your responses it appears that my
> suggestion my issues were caused by the Mailman Core was not based in
> reality. Instead, the issue is how Postorius interacts with the Core.
> My apologies for overreaching, as the cause of my issues is not an
> issue to me. Keeping Core a simple list manager is fine, if Postorius
> is easy to use and does the expected.
>
> As a Subscriber, you are able to do switch emails in subscriptions from
> your options page. The URL to which is displayed in the List's Summary
> page when you are logged in. Yes, it requires an approval if the list's
> settings are set to moderate but that is going to be fixed, see this
> issue[1]. It is quite simple IMO to fix this one, if someone wants to
> take this up.
>
> Well, it’s more than that. Based on the current setup, I have asked my
> subscribers who want to change their subscription addresses to:
> a. Create an account if you do not already have one.
> b. Go to the user profile page.
> c. Select ‘E-mail Addresses’.
> d. Add the new e-mail to the user profile.
> e. Wait for the verification notice and verify the new address.
> e1. If it does not show send email to hansen(a)rc.org
> <mailto:hansen@rc.org> to get the email verified manually.
> f. Sign in to the account again and to the user profile (or refresh
> the page if not signed out).
> g. Select the new address as the primary address.
> h. Click on ‘Manage Lists’
> i. For each list you are subscribed to:
> i1. Select the list
> i2. Click ‘List Options Page.’
> i3. Pull down the ’Select Email’ menu.
> i4 Select your new email.
> i5. Press ‘Change email used for subscription.
> i6. When the moderator contacts you, explain that you are just
> changing your email.
> i6.1. If the moderator is late, send a reminder or send email to
> hansen(a)rc.org <mailto:hansen@rc.org> to bypass the moderator.
So, a-f is something we still always want to keep since we aren't going to deal with un-verified email addresses.
Now, Primary Address is something interesting in Mailman 3, which wasn't utilized until now in Postorius. I recently added a new feature to Postorius which allows users to subscribe via their Primary Address and it switches the delivery address when you switch your primary address. You can play with how it looks at https://lists.mailman3.org (Mailman instance serving this list) where you will see "Primary Address (myprimaryemail(a)example.com)" as an option when subscribing/switching address.
This is still somewhat new feature and there are gaps to it, but it will grow over time. For example, as as admin, you can only subscribe a User's address and not their Primary Address (from Mass Subscription page, or through the CLI commands).
As a User, you are able to switch to using your primary address and then every time you switch your primary address, all your subscription shifts to that new address without any extra steps.
Also, I just created a fix for i6[1], so switching email addresses won't require approvals anymore. I am still debating if this should be configurable by list owners.
[1]: https://gitlab.com/mailman/postorius/-/merge_requests/532
>
> Most people choke on these instructions, so I have unfortunately
> resorted to just asking them to subscribe the new address and forget
> about the old. This is not good for our reputation when the old
> addresses start bouncing. So, in more detail:
>
> I would like to ask my subscribers who want to change their address to:
> a. Create an account if you did not already have one.
> b. Go to the user profile page.
> c. Select ‘E-mail Addresses’.
> d. Select an existing address e-mail listed the user profile.
> e. Press new button ‘Change address’.
> f. When page refreshes, enter the new e-mail address.
> g. Press ‘Apply.'
> d. Wait for the verification notice.
> d1. If it does not show send email to hansen(a)rc.org
> <mailto:hansen@rc.org> to get the email verified manually.
>
> In other words, in addition to ‘Make Primary’ and ‘Re-send
> Verification’ and ‘Remove’, another button says: ‘Change Address’ or’
> ‘Replace Address’ or some such.
>
> This button brings up another page that looks the same, but instead of
> ‘Add E-mail Adress’ is says : Enter New E-mail Address’
> and instead of ‘Add E-mail’ is says: ‘Apply’. Then the page refreshes
> back to the original page, but the new address is now
> replacing the old address. Optionally, it can show the old address
> still with a ‘pending change’ until verification.
I am still thinking about a few implementation details of this one, I've created an issue[2]
[2]: https://gitlab.com/mailman/postorius/-/issues/435
I am thinking we could minimize changes by retaining the same workflow for adding and verifying new address, but add a new workflow of some sort to switch subscriptions to a new address with a single button click. This should simplify the Loop of going to each option page and switching addresses. Finally, the old address can be removed.
Another train of thought is that when you Delete your email address, you get an option to switch all the subscriptions on that address to some other address. I could do this by adding a page after you click on "Remove" button. Although, this would restrict the ability to switch subscriptions by only deleting the original one, which I don't want.
Maybe I'll end up implementing both of these.
What do others think about this?
>
> Further, when the new address is verified, all lists get updated with
> the new address replacing the old
> address and all settings associated with the old address are now
> associated with the new address. No moderator or admin
> involvement needed (other than d1).
The fix[1] I mentioned above should already resolve this issue.
>
> You are able to sign in via web and manage your email and
> subscriptions. The preferences also work exactly how you described
> above where the lower level override the default and/or upper level
> settings.
>
> To some extent that is true, Abhilash, and I appreciate that. The above
> (address change) is a missing piece in that picture and I look forward
> to seeing it added, if you have time.
>
> Yours,
>
> Allan Hansen
> hansen(a)rc.org
>
>
>
>
> > On Jun 14, 2020, at 0:19 , Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
> >
> > Mark Sapiro writes:
> >
> >> Then the people who developed the web based management UI (Postorius)
> >> and archive UI (HyperKitty) chose to develop those within a Django
> >> framework and Django has its own concept of User separate from Mailman
> >> Core and that is where the disconnect occurs.
> >>
> >> It's not that Mailman Core lacks what you want. It's that Django doesn't
> >> use it.
> >
> > I think that's mostly right, in terms of the features that users miss.
> > However, as far as I know, Mailman core does lack facilities for
> > identification, authentication, and authorization of connections to
> > the REST API. And that means that the front ends have to handle
> > this. I would guess that's why the web interfaces are built around
> > Django user authentication.
> >
> > I think it would be possible to have somewhat tighter integration
> > between the Django "web users" and the Mailman core User objects, but
> > it's not necessarily going to be trivial.
> >
> > I see that Abhilash is pretty optimistic, but I fear this this is
> > going to be a long-tail situation where we're going to be seeing core
> > user vs. web-gui user integration issues in 2030 (maybe by then only 1
> > every 450 days ;-). I have some ideas, maybe in a couple weeks I can
> > sketch them out.
> >
> > Steve
> > _______________________________________________
> > 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/
>
--
thanks,
Abhilash Raj (maxking)
6 years