gosh yeah this stuff sitting right at the user-system boundary is dear to us all as it can severely impact daily ops on either side

managing ourselves on the user side:

========================

* when using multiple emails, set up forwarding back to a main inbox so you don't have to check a growing list of alternates but you still get the benefits

* yes sharing a "household" email seems good & natural... go ahead and forward those to (multiple) individual inboxes as above...

* i couldn't survive w/o a password database at this point... it needs to sync to all household desktops and mobiles and at least auto-pop desktop browser logins... KeePass is free and covers the basics with 3rd party phone apps as well as Mac... syncing through dropbox is indeed feasible on the cheap but i assume commercial alternatives (1Password, etc) are more integrated/dummy proof.

* um yeah, rule of thumb, don't use work email for anything you could possibly imagine wanting after you've relocated... at least a password database nicely mitigates having to remember all the places you've plugged in a particular email... but this is one of those easy to say lessons that doesn't really sink in until 6 months after you and everybody else that could help you has moved on 🙂

systems side:

=========

* we're relational modelers, so we of course know better than to design internal record identifiers directly dependent on any "visible" data... anything published will be readily changeable data hanging off the hidden internal key... are there any good roadblocks that prevent designing for changing even username as well as email, anything to do with name/surname changes, yes even fixing SSN's, etc... e.g. authentication services like Active Directory readily provide a unique user "SID" GUID, tie downstream systems to that vs any visible loginId.

* yes implement with multiple SELF SERVICE recovery options... motivations: accepting that automated recovery security is implementation that should be taken with due care i.e. mildly risky & spendy vs just tossing a few bodies at the problem and calling it a day ... but don't humans tend to overwhelmed / bored weak spots... the economics aren't there, lower wages won't care (sorry but it's true), higher wages should be doing something more productive... systems bit-rot too though.

* besides the classic security question route, gmail for example encourages providing a back up email for recovery... i feel like there's at least one other major approach i'm forgetting

* cloud vendors are providing very convenient multi-factor auth services to implement on at this point - MSFT Azure's MFA is very nice with the immediate popup on the phone

* related to "householding" idea above, companies should always only publish generic inbound addresses (departmental, etc) vs individual emails that come and go... even these corporate addresses could change or tombstone... consider keeping all alive indefinitely and forward to new vs fully abandoning

* further, enterprise ticket workflow solutions commonly present a shared queue of these inbound emails to all assigned team members instead of leaning on email beyond being one vector of initial ticket creation... outbound responses then carry unique ticket# in the subject for back end to marry up threaded correspondence... yes, we're forced to compromise an internal ticket key by making it visible here, but there's less expectation for permanence on a ticket# vs say a userid.