[sf-lug] Mailman subscriber/member bounce processing (was: Re: unsub [REDACTED] from sf-lug)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: unsub [REDACTED] from sf-lug
> Date: Fri, 7 May 2021 21:21:05 -0700

> Quoting Al Whaley:
>
>> [REDACTED] (not spelled quite like that) had [REDACTED] bounce
>> messages go from 'mailbox full' to 'mailbox does not exist' so I
>> unsubscribed [REDACTED].
>> I got tired of looking at the bounce messages.
>
> Beat me to it.  ;->  I was actually on the edge of doing that, myself.

[--> on-list]

Speaking of which ... had earlier drafted up, but not quite completed ...
anyway, finished that up now ...:

So ... Mailman 2.x (mailman2) bounce processing.
I'm thinking, for some/many lists, these parameters need be adjusted to
work usefully.  I believe these are mostly Debian 10 buster defaults,
which are probably mailman2 defaults.

In (very) short, we have:
Bounce detection sensitivity

Should Mailman perform automatic bounce processing?                  Yes

The maximum member bounce score before the member's subscription is
disabled. This value can be a floating point number.                 5.0

The number of days after which a member's bounce information is
discarded, if no new bounces have been received in the interim. This
value must be an integer.                                              7

How many Your Membership Is Disabled warnings a disabled member should
get before their address is removed from the mailing list. Set to 0 to
immediately remove an address from the list once their bounce score
exceeds the threshold. This value must be an integer.                  3

The number of days between sending the Your Membership Is Disabled
warnings. This value must be an integer.                               7

Some details:

bounce_score_threshold (bounce): The maximum member bounce score before
the member's subscription is disabled. This value can be a floating
point number.
Each subscriber is assigned a bounce score, as a floating point number.
Whenever Mailman receives a bounce from a list member, that member's
score is incremented. Hard bounces (fatal errors) increase the score by
1, while soft bounces (temporary errors) increase the score by 0.5.
Only one bounce per day counts against a member's score, so even if 10
bounces are received for a member on the same day, their score will
increase by just 1. This variable describes the upper limit for a
member's bounce score, above which they are automatically disabled, but
not removed from the mailing list.

So, here's the potential/probable problem/issue - most notably some/many
lists may be relatively low volume (e.g. infrequent mailings).  E.g.
BALUG-Announce is 1 to 3 emails per month, possibly even fewer (global
pandemic 'n all that, or whatever).  Users may also get monthly password
reminder, but they can also disable that.

So let's say we've got the above parameters and addresses that are
let's say hard bouncing/failing on every attempt.

With a threshold of 5.0 that goes up at most by 1 per day, but after 7
days if there are no new bounces, that's "forgotten".
So, e.g., low volume such as BALUG-Announce, max. 3 - 4 with password
reminder - emails per month if those happen within 7 days but each a
day or more apart, that's max bounce score up to 4 ... but if more than
7 days 'till the next mail, e.g. in the next month, then that's
forgotten, and we start all over again.

So ... maybe the bounces ought be remembered considerably longer?
But looks like there's nothing to reset bounce score on account of
mail being successfully delivered / not bouncing - it only counts
bounce information.  So, similar parameters could fairly quickly
disable sending if only a small percentage bounced ... let's say
one hard bounce per day out of dozens or more messages per day - count
still goes up by 1 per day.  Well, maybe Mailman 3.x (mailman3) is
better?

Anyway, mailman2 ... mostly those first two parameters: 5.0 & 7
I'm thinking the 2nd parameter need be fair bit higher, to "remember"
longer - at least for lower traffic/volume lists.
And I did, on BALUG-Test list, set up a subscriber that hard bounces ...
have a posting going through daily from another subscriber and ...
the hard bouncing one hasn't been disabled ... well, it did finally make
it to that after I'd earlier first stated drafting this.  So now up to
the 5 (currently configured threshold) on that subscriber for that
list.  Better visibility into current score would be good ... maybe
mailman3 fixes that?  Though is possible to "see" that in mailman2,
though it's relatively buried ... use
/usr/lib/mailman/bin/dumpdb
on the relevant Python2 Pickle db file that contains the data,
e.g.:
/usr/lib/mailman/bin/dumpdb /var/lib/mailman/lists/balug-test/config.pck
and then view / parse out the relevant information.
$ /usr/lib/mailman/bin/dumpdb  
/var/lib/mailman/lists/balug-announce/config.pck | wc -l
3830
$ /usr/lib/mailman/bin/dumpdb  
/var/lib/mailman/lists/balug-test/config.pck | sed -ne '/^     
'\''bounce_info'\'': {   '\''/,/^        >},$/{s/^\(         
confirmation cookie: \).*$/\1[REDACTED]/;p}'
     'bounce_info': {   'test-0qkqqxic0j5bhezz7w7a at balug.org': <bounce  
info for member test-0qkqqxic0j5bhezz7w7a at balug.org
         current score: 5.0
         last bounce date: (2021, 4, 30)
         email notices left: 1
         last notice date: (2021, 5, 7)
         confirmation cookie: [REDACTED]
         >},
$
So ... the information is there ... but not super accessible,
e.g. listadmin certainly can't see it from web GUI, though listadmin
can see in the web GUI
nomail -- Is delivery to the member disabled? If so, an abbreviation  
will be given describing the reason for the disabled delivery:
B -- Delivery was disabled by the system due to excessive bouncing  
from the member's address.
And that will show with a B ... but nothing shows there until it hits
the configured threshold.
In order to see status details along the way ... need to have access to
the file:
$ ls -ld /var/lib/mailman/lists/balug-test/config.pck
-rw-rw---- 1 www-data list 7488 May  8 06:19  
/var/lib/mailman/lists/balug-test/config.pck
$
So ... local login and member of group list ... "of course" that group
has access to do most anything with mailman2, and can also read all
users' config data, including stored clear text of passwords too.
Anyway, not great for listadmins having access to what details
they should - but not access they shouldn't have.
Though I suppose reasonably crafted commands to run under sudo could
cover the needed ... but that would still need CLI login access ...
unless one crafted up some listadmin authenticated web GUI to be
able to look at the appropriate details.

Anyway ...

And the user notifications of being disabled are a good thing - gives
user fighting chance to fix situation (or at least be aware of it),
e.g. if there are some intermittent bounces or bounces of some
content (e.g. drain bamaged anti-spam rejecting non-spam) that have
delivery disabled but the notifications about that make it through.
Also, the periodic reminders/attempts at notification of this state,
also help ensure if mail is consistently hard bouncing, that's not
"forgotten", but advances through to member being removed.

Maybe I increase how long this is "remembered" on BALUG-Test for now,
and consider other lists after further testing/review.
And, yes, after so considering for most all the (BALUG) lists ...
increased:
The number of days after which a member's bounce information is
discarded, if no new bounces have been received in the interim. This
value must be an integer.                                              7
 From 7 to 185.
That will probably work "well enough" for lower volume/traffic lists.
In more recent years, might be okay for all of BALUG's mailman2
"advertised" (publicly listed) lists.
Some lists some circumstances that 185 might be too high ... as mailman
doesn't reset it when a sent email is successfully received.
So, 5 hard and/or 10 "soft" bounces, each not more than 1 day apart,
and counting no more than 1 per day ... might be "too easy" to hit 5
on that "score" if the bounce failures are "remembered" up to 185 days,
and only reset if more than 185 days go by with 0 bounces for that long.
Still, likely okay for BALUG's lists and their current (and as it's been
for many years now) traffic volumes.  For higher volume lists,
that "remembered" of only 7 days may be quite good enough.

And also, with it set at 185 days ... I could peek at ... 30, 90, ... 180
days into it, see if it appears on track for doing reasonable things ... or
not - and if not, adjust accordingly (e.g. change that number).