hansen@rc.org writes:
I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators.
I'm sorry to hear about this.
This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing??
Well, if bounce processing were occurring as designed, there would be very few bounces in the queue. So it's a difficult thing to anticipate until it happens. And curiously I haven't heard of this before. I mean, if it were going to happen, I would expect that it would have happened at the very busy lists at python.org. So maybe you have an unusually large number of bounces? Not saying it couldn't have been anticipated that *somebody* would have that situation, but we'd have to be extremely lucky, or have a dedicated "red team" looking for ways the feature can break, to find it before installing it. I'm sorry it happened, but AFAICS it's "one of those things".
Technically, it appears that the model for bounce information is initialized based on the time of processing, rather than the (alleged) time of injection or the (presumably trustworthy) time of receipt by the local MTA. I don't have time to check further on if that's modified later, but "not modified" explains what you saw very well. I guess you must have had many hundreds of bounce messages in the queue.
Probably the simplest way to deal with this is to clear the bounce queue while upgrading, or at least offer the option. Losing a few hours' worth of bounce messages (if they're being processed normally) isn't going to hurt anything. It would also be simple to provide a report of who bounced and the most recent bounce, if desired.
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???.
It is for me when I've authenticated, both for lists where I'm owner and for lists where I'm just a subscriber. (However, the lists where I'm subscriber are on python.org where Mark is the site admin, and may be a little ahead of released versions.)
The members can't see if their account is enabled.
I guess they are email-only members, and have not authenticated to Postorius? I don't think we will allow unauthenticated access to user info in Postorius in a distributed version. If you really need it, the fastest route would be to find a contractor to customize Mailman for that -- custom versions are not a priority for us.
Is this another example of the disconnect between Mailman and Postorius?
Hard to say. If it's not the users' failure to authenticate, I would guess this is most likely due to a skew in the upgrade process where the versions of Mailman core and Postorius were mismatched, but as I wrote above, I can see this in the user's setting page for both my "owned" lists and for my "just a subscriber lists".
It would be inconvenient in your situation because list admins have to visit the user's options page to see and modify it, but I *can* see it.
Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that.
This is a known bug being worked on. I'm sorry it was not fixed in time for your upgrade.
As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status).
I'm quite sure that this situation could have been addressed quickly and efficiently with a Python script, or in an interactive session with mailmanclient. That doesn't help you now, but in the future feel free to ask us to help with that. We generally are able to respond within a few hours. It's probably not as fast as doing it by hand, but there's the consideration of your time spent. Or if there are Python programmers hanging around, a little fiddling with the mailmanclient command line will probably allow them to figure out what's what, enough to do this.
Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago:
a. The ability of moderators to see the list membership (a bug).
It's in the queue. I can't say when it will be released.
b. The ability of members to change their addresses for all lists they are subscribed to.
What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems....
c. That when members go to look at their subscription info, they can actually see the settings.
As far as I know, they already can if they have authenticated. If that's not true in your installation(s), we'll need to find out why, because it works for me.
Enabling access without authentication is a potentially dangerous change that I currently believe shouldn't happen at all in a Mailman distribution, and will certainly take time to design. If your requirements include unauthenticated access, I would not hold my breath, let alone expect it in the near future.
Regards, Steve