No answer required, I think I understand the situation pretty well now. But if I'm missing something, I would very much appreciate criticism.
Andreas Barth writes:
Well, currently these are exclusive-states, I'd rather see them as or-able-states.
Right, I understand that. I don't understand *why*.
There are real costs to making them or-able. There are constraints: 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo' state. Such invariants are finicky to code and tricky to maintain, compared to a simple "mutually exclusive".
I guess you want to allow the or of any subset of disabled states, but presumably then they need to individually resettable in order for the admin to clear their disable without overriding a subscriber's preference or a bounce record. That set of controls is more complex, and requires additional mental effort on the part of anyone using them. If there are restrictions on which states can be or-ed, that's more coding and maintenance cost.
Then there's the question whether the subscriber can override the admin's setting. If they can, why does the admin have this power in the first place?
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
Exactly.
But if the admin should respect the DBS (disabled by subscriber) setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. Are there use cases where the admin does not want to repect the subscriber's choice, and enables it anyway? What are they?
Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
Why wouldn't they get the exact state from the original server? Or do you mean from a non-Mailman server?
I expect that state to be the most-often used when setting a state manually.
For "who set that", I would consider having some kind of history as useful (and displaying "last set by user / $person" to the admin but not the user).
Why not to the subscriber? As I explain below, the subscriber at least needs to be able to distinguish between DBA and DBB (disabled by bounce).
Keeping history of who is additional complexity, consumes a minor amount of resources, and is insufficient to the purpose. Assuming that there are reasons for admins to disable/enable other than as a courtesy to a subscriber, that reason is presumably important. Not only will the subscriber not know, but one admin may forget, and there may be multiple admins.[1]
I still don't see any reason for an admin to disable delivery other than as a courtesy to the subscriber or to the bounce processor.
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
I'm suggesting exactly that, yes. Why? Well, worked with user for too long. ;)
E.g. consider that seeing archives works only for subscribers. And the subscriber in question complains about too many mails but still re-enables getting mails. This is basically "an admin has blocked you from more mails but not unsubscribed you". Might be an corner case, but still. Might also be too unimportant.
This is possible. If it occurs less than once in a million years, it's "too unimportant" to even think about.[2] Have you actually done this, or know anybody who has?
Is it really different from "at request of subscriber"? Practically, the only difference I can see is if such a subscriber should be prevented from overriding DBA. Are you suggesting that?
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Except if someone sets the state to "disabled" and then undo this, the state is automatically cleared.
This is possible, but it's not clear what harm would be done. In most cases, bounces are intermittent and clear themselves up, in which case this is the right thing. But if the subscriber bounces again, they'll get disabled again, only cost is a slight waste of resources.
Here's how I would assess the issues. In the descriptions below, I am assuming that each state is the only "active" state.
- DBS is probably a "vacation" or "post-only" setting. For that reason it should be re-enabled only by the subscriber (or by an admin at the request of the subscriber).
- DBB is a "warning" and a minor convenience to the email system (slightly reducing traffic to mailboxes that are expected to fail, and perhaps avoiding some reputational damage to the list). Re-enabling much of the time causes no damage, as bounce disables are typically due to things like out of disk space, and are likely fixed by the time the subscription is reenabled. Most of the rest will be zombie mailboxes, which will rarely be reenabled, will quickly be redisabled by bounce, and at worst cause mild inconvenience. Finally, events like a Mailman upgrade and the April 2014 DMARC fiasco will be pretty evident, and the damage there has already been done, reenabling actually fixes it (although it may not be effective if the systemic problem hasn't been resolved).
- DBA is interesting mostly to *subscribers*, who need to distinguish DBA (which the subscriber can reenable freely) from DBB (which warns the subscriber to get in touch with their postmaster). It's comforting to subscribers who may be sure they never disabled their subscription; otherwise, it's semantically identical to DBS as far as I can see.
Am I missing something?
It seems to me that given 1-3, assuming a 4-state design:
- It's never unreasonable to re-enable, except DBS.
- In the DBA state, changing to either DBS or DBB causes no problems. (Changing to DBB is unlikely, since no mail is being sent. However, it's possible, due to the race between Postorius and mail in transit, and due to spam and other spoofing of the list domain.)
- In either of the other two states, we should never change to DBA.
- In either of the other two states, if the other event occurs, you would want the state to be DBS|DBB. I contend that if we substitute DBS, little harm is done. If the subscriber reenables, it's on them to fix the bounce problem if it reoccurs in any case. Since the subscriber has deliberately set DBS, the admin should not reenable without permission of the subscriber (I think we're mostly in agreement on that).
I think this 4-state design is much easier to design, validate, and maintain than the 16-state design you propose. If you're really worried about DBS|DBB, then we could have a 5-state design where enabling from DBS|DBB generates a warning that there may still be a bounce problem on the subscription. Instead, it could leave the subscription in state DBB, but that seems to me to be obnoxious, since there's little likelihood of harm from reenabling, and in many cases the bounce problem will have resolved itself in the meantime.
Regards, Steve
Footnotes: [1] There's also the question of GDPR obligations if personal reasons (such as "violated code of conduct") are in the history.
[2] I'm not sure where we'd actually draw the line, probably on the order of "once a year per thousand subscribers", that being every week for say a campus-wide list at Ohio State University with 55,000 students.