>However, I have been a Mailman developer for 15 years and am commenting >from that perspective. I fully understand and respect that and in no state to question that ever.
>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. Yes I agree, but I wanted to make it more dynamic like if an email is subscribed to 6 mailing lists and it is bounce threshold is crossed of 5 lists and not from the last one cause it is not that active, there is a high chance of that email being problematic here, so at least lower the bounce_threshold of that mailing list for that email specifically ( done by MODIFIED_THRESHOLD ). This will update the roster of members of mailing lists more dynamically and more efficiently. >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. Yes, that is the current situation now. >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. I wanted to make this method more robust so that users should not be subscribed even if their email is working fine, but if you say this, you say it by experience and I acknowledge that. I also mentioned my approach and implementation several times during GSoC selection phase. So, If the old approach as Mailman2 should be adopted I should follow that, if my modification according to the proposal looks fine, then I should continue it, I have no problem and will do whatever the community thinks is the best for the community. _______________________________________________ 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
