Stephen writes: >What "threshold"? The disabled_warning_interval?
Yes, exactly. I apologise for being informal. Stephen writes: >Incrementing the warning counter should always happen if the mail is >successfully sent. Yes, I meant that only, I apologise for not explaining correctly. Stephen writes: >I don't know offhand how any of the above operations could fail, and >most likely to fail is sending mail, which is handled by the virgin, >outgoing, and retry queues, not by the logic you're working on here. >Still, perhaps some of the operations should be conditional on >success. I also realize that sending mail is the `critical connection` of this whole flow and most of the operations will work on certain conditionals, of course, I just showed a rough outline of the process. As for when each and individual operation will be executed depending/not-depending upon the success/failure of the previous one I am currently working on that. >Also, you need to think about what happens if the warning >fails for some address. Probably you just treat that as equivalent to >a bounce in most cases, but what happens if it's a "no such address"? >Is that already handled? Yes, that is correct, as of now, if bounces are received for `warning_messages` then they will be treated normally as it would have been done for other emails. For the problem, you mentioned regarding `no such address`, it was something which occurred to me earlier but I had not pondered upon it so much. Let me clearly explain the problem. - Imagine if some email address goes `wrong/nullified` for some reasons. - Bounces will originate and after sometime, it will be disabled and warnings will be sent. - Warning emails will also be recorded as bounces and after all the number of warnings increase `bounce_you_are_disabled_warnings` no more warnings will be sent by Mailman. - But in the end, no action was taken and it will still be there in the roster and will again be called by the process responsible for sending warnings. - For this type of behaviour, a specific action is required? - I mean when the above (1-4) are satisfied I can remove or somehow disable it totally from the roster so even the process responsible for sending warnings will not recognize it. What other implementation for this type of behaviour can be implemented? Some pointers are required on this. _______________________________________________ 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
