
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 thatmember
. - 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 theMember
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 andMark
,Abhilash
andStephen
please point your opinion on this. If not much is clear on this then the default is I will not delete the data.
If the user has other addresses, should Mailman warn them about
Stephen writes: 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?