On 6/19/19 1:56 AM, Aaryan Bhagat wrote:
As far as I can tell, all the relevant list attributes are already defined in mailman/model/mailinglist.py. As noted there, they should probably be added to mailman/interfaces/mailinglist.py. Yes, and I have done that (WIP actually) in the latest pr.
I'm not sure about creating the attributes like bounce score in the member model. Granted this has the advantage of there already being separate, per list member records, but my concern is that it's an address that is bouncing, not a member so it may be more appropriate to keep bounce info with the address rather than the member. Ok, so from what I get I will explain by taking an
exampleaddress subscribed to 2 mailing list.
- Create a bounce_score attribute in the address model.
- Bounces generate from both the lists will add up the bounce_score attribute.
- If
bounce_score >= bounce_score_threshold of list1disable membership of list 1.- If
bounce_score>=bounce_score_threshold of list2disable membership of list2.Is the above inference correct? Or, am I missing something inc context here?
The example I gave earlier would give that rule a problem, to describe again:
List1: Gets 1 message a month, Reset time of 45 day without a bounce, Trigger threshold = 2 bounces
List2: Gets many messages a day, Reset time of 1 day without a bounce. Trigger threshold = 4 bounces to handle occational bounces due to spam false alarms.
First question: different attribute of the bounce reset period, which is used to reset the bounce score?
A user subscribes to both lists, because of lists 2 occasional spam false alarms, which required the elevated threshold (or even just wanting to give a few days to clear a mailbox full error) the user gets unsubscribed from list1 to rapidly. If list1 raises its threshold to handle that, a subscribe to just list 1 will stay subscribed to the list too long after bouncing.
-- Richard Damon