On 6/14/19 11:09 AM, Aaryan Bhagat wrote:
>> Mark would know more about this, but I wonder if there is a need to keep
>> the bounce score separate for each MailingList and keep the association
>> with a Member Object, as compared to an Address object
>
> Keeping it as separate has definitely its own perks, this is the basis for my
> proposal and I have gone through with this extensively in with Stephen in an
> earlier thread during GSoC selection phase, I have mentioned the details in
> my proposal regarding this.
>
>> Does the formula to count bounce score take into account a MailingList's
>> property that could have resulted in a bounce on one list but not on
>> other list?
>
> Well, I have taken them indirectly into account using the MODIFIED_THRESHOLD
> attribute (reasons explained with examples in the proposal), it would
> certainly help in more efficient ruling out the members to disable the
> subscription.
Disclaimer:
I am NOT a GSOC mentor, nor do I wish to be.
I have not read the proposal
<https://docs.google.com/document/d/1Pv-EuIwrhKM-_inf2HMHVgVzRKjEUwRl-_flMamsJsc/>
in full detail.
However, I have been a Mailman developer for 15 years and am commenting
from that perspective.
It seems to me that some things in your proposal are too complex.
Mailman 2.1 bounce processing was simple. There is no concept of a user.
There are only email addresses subscribed to lists and there is no
connection between an email address subscribed to one list and the same
address subscribed to another list.
MM 2.1 lists each have their own bounce processing parameter settings
and these exist in Mailman 3 as well. This is appropriate as things like
bounce_info_stale_after and bounce_score_threshold depend on the
frequency of list posts.
Even though Mailman 3 has a concept of a user and understands things
like an address may be receiving mail from more than one list but this
address belongs to the user who is subscribed to these lists, I think
this connection is irrelevant for bounce processing. I think the only
relevant thing is that an email address on a list is bouncing, and that
should affect delivery and the ultimate disabling thereof from only that
list.
As you note, bounces can occur for various reasons. E.g., this address
doesn't exist, this address has a full mailbox, this email appears to be
spam and so on. The issue here is you don't know which of those reasons
is the reason for a specific bounce. Bounces are received and processed
by flufl.bounce and the only information you get is whether flufl.bounce
considers it to be a temporary or permanent failure (generally 4xx or
5xx SMTP status). It doesn't distinguish between a 5xx for non-existent
address and a 5xx for unacceptable message content.
The problem of what you refer to as “Bad mailing-list” or addresses
bouncing because of the content of some posts is addressed in MM 2.1 by
bounce probes. See
<https://mail.python.org/archives/list/mailman-developers@python.org/message/AY4FPVYNHK2D25F67R5VL3E46XHQKSFK/>
for some description of that.
In any case, I think simply keeping track of bounces by list and address
and taking action on that based on the lists settings is the appropriate
thing to do.
If there are things I'm missing, perhaps you can give me specific
pointers to places where they have been described or discussed that I
may have missed.
--
Mark Sapiro <m...@msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
