On 3/8/26 19:17, iMark wrote:

I can see on a MM3 list's administration panel that a member has a bounce count of 4.

When I query the "bounceevent" table in the mailman database ...

SELECT * FROM mailman.public.bounceevent WHERE list_id = '<MY_LIST_ID>' AND email = '<MEMBERS_EMAIL_ADDRESS>'

... the result is only 2 records from the last 24 hours. It appears that the table only stores 24 hours worth.

The Task runner runs periodically and among other things deletes all processed bounce events older than the configured dsn_lifetime which defaults to 1 day.

So I figure I'm looking in the wrong place. Where should I be looking?

What are you looking for?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 3/8/26 20:57, iMark wrote:

===========

My thinking was that to reset that member's bounce_count from 4 to 0,  I could just delete the records (resulting from the query) in the "bounceevent".

But as the query result only shows 2 bounces, I'm looking for where the Admin web UI is getting "4" from (ie. the processed bounce events older than 24 hours).

The list member's bounce score is the bounce_score column in the member table, but finding the correct row is dificult because you need the list_id which you'd look up in the mailinglist table and either the address_id from the address table or the user_id from the user table.

It's much easier to use mailman shell as in

$ mailman shell -l list@example.com
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.
The variable 'm' is the list@example.com mailing list
 >>> mbr = m.members.get_member('user@example.com')
 >>> mbr.bounce_score = 0
 >>> commit()

But what is the point of doing this? If the member is bouncing, the score will continue to increment, and if not the bounces will become stale and a future bounce will set the score to 1.

You mentioned reset_bounce.py, but that doesn't reset scores. It sets delivery enabled for users whose delivery is disabled by bounce, but you can do that, albiet one by one, in Postorius just by clicking the user in the membership list and setting Delivery Status to Enabled. In Postorius <=1.3.13, Delivery Status doesn't show in the membership list, but it will in the next release.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan