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

iMark writes:

From time to time Microsoft will spit the dummy and start blocking mail from the lists.

We're all familiar with this....

This will last a day or two, but in the meantime bounce counts get cranked up which can send some lists over the edge and start disabling/removing subscribers.

Only the first permanent failed delivery in a calendar day is counted. Both temporary (status 4xx) failures and additional permanent (5xx) failures are logged and update the "most recent bounce" timestamp, but do not increment the bounce count. If the threshold is set to "3" (days) it will be at least 72 hours before a "clean" subscription is disabled.

The process is implemented in model/bounce.py:BounceProcessor.process_event. (The header comment for that section of code is sloppy, read the code.)

The disable delivery threshold and the interval after which bounce info is considered stale is configured per-list in Postorius.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan