hi,
after mark has helped me at the end of january to find users that were not attached to any mailing list (indicating people who pressed the wrong button when trying tosign up), we sent out a 2nd mass mail to our target audience to ask them to subscribe again.
we are now getting feedback from people, who say that they are unable to sign up, with mailman3 telling them:
Subscription request already pending
this is somewhat bad as:
- at least some of the users (who reported the problem) tried to subscribe 2 months ago (2022-01-04) - if they did not confirm their email back then, i'm pretty sure that this email has been lost by now
- my /etc/mailman3/mailman.cfg has "pending_request_life: 3d"
- i (as administrator) do not see any "pending subscriptions" (the list is setup with a simple "Confirm" subscription policy
- i (as administrator) do not find any mention of the user's email address anywhere either in postorious webinterface of the list, nor in the django
- in the sql-dump (it's been a while since i worked with postgres on a higher level) i do see the user's email in the workflowstate, address and pendedkeyvalue tables.
the installation is (still) mailman_3.2.1-1 on a Debian/buster system (using the Debian/buster packages for mailman3)
i wonder:
- why are the pending subscriptions not expired? (i guess they should have expired after 3 days)
- why can't people re-subscribe while there's a subscription pending (e.g. if the confirmation mail got lost)?
- how can i list all pending subscriptions (for a given mailinglist)?
- how can i resolve the situtation (e.g. send out another reminder; manually expire the pendings; manually confirm the pendings,...)
gfmdsd IOhannes
On 3/14/22 06:00, IEM Network Operation Center (IOhannes m zmölnig) wrote:
we are now getting feedback from people, who say that they are unable to sign up, with mailman3 telling them:
Subscription request already pending
this is somewhat bad as:
- at least some of the users (who reported the problem) tried to subscribe 2 months ago (2022-01-04) - if they did not confirm their email back then, i'm pretty sure that this email has been lost by now
- my /etc/mailman3/mailman.cfg has "pending_request_life: 3d"
This is https://gitlab.com/mailman/mailman/-/issues/729 fixed in Mailman 3.3.5.
- i (as administrator) do not see any "pending subscriptions" (the list is setup with a simple "Confirm" subscription policy
The count badge only counts subscriptions waiting moderator approval. If you pull down the Subscription requests tab and click Pending Confirmation you should see them and be able to discard them.
i wonder:
- why are the pending subscriptions not expired? (i guess they should have expired after 3 days)
It's a bug fixed in Mailman core 3.3.5
- why can't people re-subscribe while there's a subscription pending (e.g. if the confirmation mail got lost)?
Because that's the way it was implemented.
- how can i list all pending subscriptions (for a given mailinglist)?
Pull down the Subscription requests tab and click Pending Confirmation.
- how can i resolve the situtation (e.g. send out another reminder; manually expire the pendings; manually confirm the pendings,...)
If the above doesn't answer that. provide more detail.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3/14/22 17:03, Mark Sapiro wrote:
On 3/14/22 06:00, IEM Network Operation Center (IOhannes m zmölnig) wrote:
This is https://gitlab.com/mailman/mailman/-/issues/729 fixed in Mailman 3.3.5.
thanks for comfirming.
- i (as administrator) do not see any "pending subscriptions" (the list is setup with a simple "Confirm" subscription policy
The count badge only counts subscriptions waiting moderator approval. If you pull down the Subscription requests tab and click Pending Confirmation you should see them and be able to discard them.
hmm. i'm not sure i can follow. my "Subscription requests" tab seems to not have any "Pending Confirmation" section (see attached screenshot).
this is with "Postorius Version 1.2.4" (as installed by the mailman3 Debian package).
fdsm< IOhannes
Mailman's content filtering has removed the following MIME parts from this message.
Content-Type: image/png Name: Subscription requests.png
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.
Something like the following in mailman shell can do it.
>>> # Cutoff date delete pended subscriptions older than this
>>> cutoff = '2022-03-01'
>>> pendings = getUtility(IPendings)
>>> # Prior to Mailman core 3.3.5 need to explicitly delete workflow
>>> wfm = getUtility(IWorkflowStateManager)
>>>for token, data in pendings.find(pend_type='subscription'):
... if data['token_owner'] != 'subscriber':
... continue
... if data['when'] >= cutoff:
... continue
... pendings.confirm(token, expunge=True)
... # for MM < 3.3.5
... wfm.discard(token)
...
>>> commit()
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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 shellcan 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@example.com" but send the confirmation-reply from "foo@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
On 3/15/22 03:04, IEM Network Operation Center (IOhannes m zmölnig) wrote:
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.
That is correct.
is it still possible to just use these tokens to confirm the pending subscription (even though it is long overdue)?
Yes.
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?
See https://gitlab.com/mailman/mailman/-/issues/901
You can add something like
Alternatively, you can confirm by going to the URL
https://$domain/mailman3/lists/$list_id/confirm/?token=$token
to the list:user:action:subscribe template. Note that $domain may not
be appropriate here because it is the email domain which may not be the
web domain.
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.
The current template https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/templates/en/li... doesn't say that.
would it be enough if people just sent an email to this special email-address (that contains the token), regardless of the subject?
Yes.
i'm thinking of sending a rather personalized email that has a more attractive subject than "confirm flkdsajfsalkjflsajfsoisjdl".
The current mail has Subject: Your confirmation is needed to join the
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@example.com" but send the confirmation-reply from "foo@example.com", will that still work?
Yes. Only the token is required.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
thanks again, Mark, for your detailed answer.
On 3/15/22 17:21, Mark Sapiro wrote:
See https://gitlab.com/mailman/mailman/-/issues/901
You can add something like
Alternatively, you can confirm by going to the URL https://$domain/mailman3/lists/$list_id/confirm/?token=$token
hmm. the list-url (e.g. where you can subscribe to the list) for my instance looks like https://$domain/postorius/lists/$list_id/ (that is: it spells "postorius" rather than "mailman3"). so i guess the URL should be https://$domain/postorius/lists/$list_id/confirm/?token=$token, which unfortunately returns 404.
also, my postorius/urls.py does not contain an url-pattern for "confirm", unlike the current one as found on https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/urls.py#L83
so i guess this was not possible yet with postorius 1.2.4
to the list:user:action:subscribe template. Note that
$domainmay not be appropriate here because it is the email domain which may not be the web domain.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.
The current template https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/templates/en/li... doesn't say that.
yes. the *current* template. but not the template that came with mailman3 3.2.1
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@example.com" but send the confirmation-reply from "foo@example.com", will that still work?
Yes. Only the token is required.
cool thanks. together with the not-yet-expired tokens, i think i can create some ad-hoc web-service that translates URLs to confirmation replies.
mfd IOhannes
On 3/15/22 12:22, IEM Network Operation Center (IOhannes m zmölnig) wrote:
hmm. the list-url (e.g. where you can subscribe to the list) for my instance looks like https://$domain/postorius/lists/$list_id/ (that is: it spells "postorius" rather than "mailman3"). so i guess the URL should be https://$domain/postorius/lists/$list_id/confirm/?token=$token, which unfortunately returns 404.
also, my postorius/urls.py does not contain an url-pattern for "confirm", unlike the current one as found on https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/urls.py#L83
so i guess this was not possible yet with postorius 1.2.4
Yes, This was added in Postorius 1.3.4 (over a year ago)
yes. the *current* template. but not the template that came with mailman3 3.2.1
Which is over 3 years old.
You should really be taking up these issues with Debian. Maybe if they got enough pressure from users, they would update their package.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Mark Sapiro (mark@msapiro.net) [220315 22:18]:
On 3/15/22 12:22, IEM Network Operation Center (IOhannes m zmölnig) wrote:
yes. the *current* template. but not the template that came with mailman3 3.2.1
Which is over 3 years old.
You should really be taking up these issues with Debian. Maybe if they got enough pressure from users, they would update their package.
Debian (as all distributions) freezes their packages when releasing, that's why it's called stable. If someone wants newer packages, it's possible to use stable-backports (see below).
Debian oldstable has mailman3 version 3.2.1. Debian stable has mailman3 version 3.3.1.
So, in this case, the version in Debian oldstable is used. Which is, well, a bit behind stable, because oldstable is one release behind from the current stable.
From (any) software point of view, distributions are always too old. However, having a frozen version of packages has great benefits for admins and reduces efforts. That's why distributions exists.
As I said multiple times (also here), my recommendation is: if the software in the distribution works for you, use it. If not, use your own. However, don't assume that pressure works here at all - distributions are freezing packages for very good reason.
As Debian is an volunteer effort, however it is always possible to help the distribution and get what you want by that.
A good way is stable-backports, because this allows the admin to select to have single packages from the more current testing branch of Debian. However, this only happens if someone does the necessary handholding. So far nobody volunteered for mailman, therefor mailman isn't in stable-backports. If I'd like to have a current mailman on Debian, that would be my path forward (together with running Debian stable, not oldstable); but that's not an easy one if you are not involved with debian yet.
Andi
On 3/15/22 15:20, Andreas Barth wrote:
Debian (as all distributions) freezes their packages when releasing, that's why it's called stable. If someone wants newer packages, it's possible to use stable-backports (see below).
Debian oldstable has mailman3 version 3.2.1. Debian stable has mailman3 version 3.3.1.
So, in this case, the version in Debian oldstable is used. Which is, well, a bit behind stable, because oldstable is one release behind from the current stable.
I understand that, but even Debian sid has mailman3 3.3.3-1 and mailman3-web 0+20200530-2 which are quite old for a package like Mailman 3 which is still in active development.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Mark Sapiro (mark@msapiro.net) [220315 23:31]:
I understand that, but even Debian sid has mailman3 3.3.3-1 and mailman3-web 0+20200530-2 which are quite old for a package like Mailman 3 which is still in active development.
If we speak about unstable, that's something else.
However, Debians next stable release won't release with mailman 3.3.3, as this package is removed from testing at the moment. I'd be happy if someone would update this package, however, I don't think I should get myself also involved there. ('Removed from testing' means: the current unstable package is considered not to be in shape to be released with the next stable release).
So, if someone wants to get involved into Debian package maintainership with mailman3 (and related packages), that would be great, and I'm happy to support.
As said, the most easiest way to get things fixed in Debian is by doing it.
Andi
participants (3)
-
Andreas Barth -
IEM Network Operation Center (IOhannes m zmölnig) -
Mark Sapiro