On 6/16/19 7:25 PM, Aaryan Bhagat wrote: >> 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.
I think it is a very tough problem, and needs a lot of thought. While it is a great goal to say that if we can detect that an email address has stopped working via one list, then another list, that might be less active, could possibly benefit by inheriting the information. The big problem is that because bounce detection is really an inexact measurement, the detection of really problem email addresses is tough. Take a couple of lists I run as an example: List 1 is a monthly newsletter. An email is sent early in the month, every month, and no other traffic. If we want to allow subscribers to bounce once and only on the second bounce (because it was just a transitory issue) you need a second bounce, then at least for email from this list, you need 2 bounces (and likely don't want more) and need something like 45 days between bounces to reset the count. List 2 is much more active, many messages a day, and some ISP will occasionally bounce a message with a spam false alarm. If we used the same settings as above, many people would get disabled for the false alarm spam. You can change the reset parameter to reset if you get just one day without a bounce, as that meant messages did get through, and you likely want the threshold higher, something like 4-7 bounces to give people a chance to clear issues, or just not get hit when you get a couple of false alarms in a row. Unless Mailman could somehow keep track of successfully sent messages, and be able to use that in the rules, it is hard to see how to deal with both lists with a common counter. And keeping track of success can be hard, as some systems will accept the message, and later return the rejection message (this does have back-scatter issues, but it is done), and the delay can be significant (I've seen rejects days later for some system issues). -- Richard Damon _______________________________________________ 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
