Stephen writes: >If we receive a bounce that indicates that the address does not exist, >we should stop sending warnings there. Somebody has screwed up pretty >badly, and it wasn't us.
That is the main hurdle, bounce extraction cannot determine the exact cause so we cannot ever say with surety the reason. Stephen writes: >In most cases, this deletion will be valid and intended by the user >(or well-deserved for abusing the account). In those cases, the >address should be unsubscribed. Yes, this is the expected `good` behaviour which is most suitable in cases like these. Stephen writes: >Do we unsubscribe on the theory that it's almost always correct to >do so, or do we keep it around and just disable without further >warnings in case of resurrection and to associate mail "From" that >address with the user? (This has issues in case the address is >resurrected but assigned to a different person.) As mentioned above, since cannot know the reason so we should not rush with the actions like unsubscribing from the mlist or deleting the address. I think we should let the normal implementation run its course then make some actions. I mean: - First, `bounce_score_threshold` will be crossed. - Then a probe will be sent if this probe bounces then `DeliveryStatus` is disabled of that `member`. - Then warning emails will be sent, till the count reaches `bounce_you_are_disabled_warnings`. - When both of them are exhausted then we can unsubscribe the user. - I can make a separate template telling the reason for this type of unsubscription. - I think `Address` instances or the `Member` instances should not be deleted as when the person will subscribe with the same email, data will be restored, but as you pointed out if the email is different then nothing of that sort will happen and space will be wasted. This I am not sure of and `Mark`, `Abhilash` and `Stephen` please point your opinion on this. If not much is clear on this then the default is I will not delete the data. Stephen writes: >If the user has other addresses, should Mailman warn them about this situation? This seems to overcomplicate things, keeping the `address` instances separate will be simple and no problems will arise. It can be implemented but I am not sure about its priority as of now. Default I will not implement this. Stephen writes: >Should the user be allowed to post "From" that address? Probably not. For a case when only `DeliveryStatus` is disabled then I think the user can post. But when the case happens such that the condition which I explained above in the points are met then we will unsubscribe that user and then there won't be any problem. Stephen writes: >Should the address be deleted? It's possible that the user will >use this address in From. Technically this is probably invalid >(the user doesn't have the right to use that address at all if >they can't receive mail there). But I don't see a good reason not >to associate such mail with their Mailman user. As explained above, I am not sure whether the address should/shouldn't be deleted, but if the user is unsubscribed then there won't be any problem if the user uses the address in From as the mailing list will not recognize it. If something is not explained well-enough please point out. Am I missing something here? _______________________________________________ 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
