Waarom één e-mailwijziging organisatiemeldingen stilletjes kan breken
Een eigenaar die een inbox opheft, wijzigt meestal één ding: waar de mail terechtkomt. Maar GitHub kan een adres in ten minste drie verschillende rollen gebruiken, en die falen op verschillende manieren.
| Rol | Wat het doet | Wat er breekt als je de inbox opheft |
|---|---|---|
| Inloggen en herstel | Hiermee authenticeer je en herstel je het account | Je kunt buiten het account zelf worden gesloten |
| Goedgekeurd notificatieadres | Ontvangt organisatiemail wanneer levering tot een domein is beperkt | Organisatiemeldingen bereiken je niet meer |
| Openbare commit-identiteit | Toont een adres in commit-metadata | Hooguit cosmetisch; het bezorgt geen mail |
Behandel deze als afzonderlijke controles. Het wijzigen van het ene bevestigt de andere niet.
De domeinbeperking is het deel dat mensen missen
Als je organisatie de levering van meldingen beperkt tot een goedgekeurd domein, moet het adres dat je wilt behouden bij dat domein horen en geverifieerd zijn.
GitHub vereist verificatie van een e-mailadres op een goedgekeurd domein wanneer een organisatie de levering van meldingen tot dat domein beperkt. Bron
Een persoonlijk adres dat je beheert, is dus niet automatisch acceptabel. Vraag de organisatie-eigenaar welk domein is goedgekeurd voordat je de oude inbox opheft, en bevestig dat je vervangende adres op dat domein staat en in je GitHub-e-mailinstellingen als geverifieerd wordt weergegeven.
Een tweede beperking sluit de snelste oplossing uit:
GitHub staat verificatie via wegwerp-e-maildiensten niet toe. Bron
Als de vervangende inbox een wegwerp- of tijdelijke dienst is, zoek dan een ander adres. Een doorstuurregel naar een wegwerpinbox is hetzelfde probleem met een extra stap.
Verwar het commit-adres niet met het notificatieadres
Een commit kan een no-reply-adres tonen, en dat is opzettelijk.
Een no-reply commit-auteursadres is een privacymechanisme, geen vervanging voor een bereikbaar, geverifieerd notificatieadres. Bron
Dit is belangrijk wanneer je je instellingen controleert: een no-reply-adres in de commit-geschiedenis zien zegt niets over of organisatiemail je zal bereiken. Controleer de notificatie- en inlogadressen afzonderlijk.
Een checklist voor het opheffen
Werk deze in volgorde af en sluit de oude inbox pas als elke stap is gedaan.
- Inventariseer de rollen van het oude adres. Inloggen, herstel, notificatielevering en openbare commit-identiteit. Noteer welke van deze de oude inbox momenteel vervult.
- Voeg eerst het vervangende adres toe. Voeg het toe aan het account en voltooi de verificatie voordat je iets verwijdert.
- Bevestig het goedgekeurde domein. Vraag de organisatie-eigenaar welk domein is goedgekeurd voor notificatielevering en controleer of je vervangende adres daarmee overeenkomt.
- Sluit wegwerpdiensten uit. Als de vervanging afhankelijk is van een tijdelijke e-mailprovider, kies dan een ander adres.
- Houd herstel in eigen hand. Zorg dat je tijdens de hele wijziging inlog- en herstelmail kunt ontvangen op een adres dat je beheert.
- Stuur een test. Activeer een organisatiemelding met laag risico en bevestig dat deze in de nieuwe inbox aankomt.
- Hevel pas dan de oude inbox op. Houd een terugweg tot je echte mail hebt zien aankomen op het vervangende adres.
Beslissingstabel: is de vervanging klaar?
| Vraag | Zo ja | Zo nee |
|---|---|---|
| Is het nieuwe adres geverifieerd op het account? | Ga verder | Verifieer het eerst |
| Staat het op het goedgekeurde domein van de organisatie? | Ga verder | Vraag de eigenaar; hef nog niet op |
| Is het een wegwerpdienst? | Kies een ander adres | Ga verder |
| Heb je daar een echte organisatiemelding ontvangen? | Hef de oude inbox op | Houd beide aan tot je dat hebt |
Veelvoorkomende foutpaden
- Het verkeerde adres verifiëren. Je bevestigt een persoonlijk adres, maar de organisatie levert alleen aan haar goedgekeurde domein. Mail stopt stilletjes.
- Het oude adres te vroeg verwijderen. Verificatiemail kan nog nodig zijn voor het account zelf. Houd de oude inbox open tot de nieuwe is bewezen.
- Vertrouwen op de commit-identiteit. Een net no-reply commit-adres ziet eruit alsof alles is ingesteld, maar het zegt niets over notificatielevering.
- Een wegwerpinbox gebruiken. Die kan niet worden geverifieerd voor beperkte levering en is een slechte plek voor herstelmail.
Als je het goedgekeurde domein niet kunt bevestigen, beschouw de migratie dan als onvolledig. Vraag het de organisatie-eigenaar in plaats van te gissen.
Wat deze gids niet vaststelt
Dit artikel beschrijft geen actuele GitHub-menulabels, exacte tekenregels of de stappen voor elk plantype. Die details veranderen en moeten worden gecontroleerd in je eigen instellingen en de documentatie van je organisatie. De bovenstaande controles gaan over rollen en verificatie, niet over een specifieke schermindeling.
Een gerelateerde volgende taak
Zodra organisatiemail stabiel is, wil je misschien weten welke andere accounts aan een adres zijn gekoppeld dat je opheft. Dat is een andere vraag dan notificatielevering, en die wordt behandeld in de gids over accounts vinden op basis van een e-mailadres.
Als je een snelle eerste controle over openbare profielen wilt, controleert TraceSeek gebruikersnamen op 3.000+ platforms, met een gratis eerste scan en zonder registratie. Een openbare match is een aanwijzing, geen bewijs dat een account bij dezelfde persoon hoort, dus verifieer alles wat belangrijk is rechtstreeks.