Mailspace-logs en herstel

Een leeg resultaat is geen bewijs dat er niets aan de hand is

Drie losse mechanismen op deze pagina veranderen een ontbrekende mogelijkheid of een mislukte aanroep naar de mailserver in een lege lijst in plaats van een fout, en geen van de drie wordt aan de client gemeld:

• bezorgtracing is een Enterprise-functie van de mailserver; waar die niet is gelicentieerd zijn de tracelijsten altijd leeg terwijl de uitgaande wachtrij nog wel gegevens bevat — zie Bezorglogboek;
• het archiveren van verwijderde mail zit net zo achter Enterprise, en waar het niet beschikbaar is leest het archief als leeg — zie Archief met verwijderde mail;
• een onbereikbare of falende mailserver zakt bij de arrays van het bezorglogboek én bij de archieflijst terug naar leeg in plaats van een 5xx, omdat die readers de fout opslokken en intern loggen. Alleen de lijst met herstelbare mailboxen antwoordt hier met 503 — zie Leesfouten.

Er is geen enkele manier om die mogelijkheden op te vragen. Deze API kan je niet vertellen op welke tier de mailserver draait, en gokt er niet naar. Toon nooit "geen bezorgproblemen" of "niets te herstellen" op grond van een lege reactie alleen.

De vier arrays zijn niet even goed beschikbaar — lees dit voordat je erop bouwt

Ze komen uit verschillende objecten op de mailserver, en juist daarom worden ze onder aparte keys teruggegeven in plaats van samengevoegd in één lijst:

• incoming / outgoing komen uit de bezorgtracing van de mailserver, en dat is een functie alleen voor Enterprise. Waar die niet is gelicentieerd zijn beide arrays altijd leeg, hoeveel mail er ook is verwerkt.
• queue komt uit de uitgaande wachtrij, die op elke build bestaat. Die bevat gegevens, ongeacht de licentie.
• issues is de vereniging van de twee — permanente fouten komen uit de traces, berichten die nog opnieuw worden geprobeerd komen uit de wachtrij — dus die is gedeeltelijk aangetast waar tracing niet beschikbaar is: berichten die nog opnieuw worden geprobeerd staan er wel in, afgeronde bounces niet.

Doordat ze apart blijven, kan een client de degradatie zien: een gevulde queue terwijl beide trace-arrays leeg zijn, betekent dat tracing op deze installatie niet beschikbaar is, niet dat er geen mail is verwerkt. Samengevoegd zou "Enterprise niet gelicentieerd" niet te onderscheiden zijn geweest van "geen mailproblemen".

Een client mag lege trace-arrays niet lezen als "geen mailproblemen", en er is geen vlag die je in plaats daarvan kunt controleren — de API krijgt niet te horen op welke tier de mailserver zit, dus die kan het je niet vertellen. Moet je integratie de twee onderscheiden, vergelijk dan de trace-arrays met queue en behandel "traces blijvend leeg" als een eigenschap van de installatie.

Een issues-entry is geen wachtrij-entry, ook al heeft die dezelfde vorm

issues wordt weergegeven in de vorm van een bericht in de wachtrij, uit welke bron het ook komt; dat maakt het uniform om te tonen maar makkelijk om te overinterpreteren:

• Een issue dat uit een trace is afgeleid (een afgeronde bounce of weigering) heeft geen wachtrij-id om mee te dragen en krijgt daarom een stabiele kunstmatige trace-<…>-id — op elke poll dezelfde waarde, dus een client mag erop sleutelen of dedupliceren. Zijn recipients-array bevat één kunstmatige entry waarvan de address de hele komma-gescheiden ontvangerstring van de trace is, met status PermanentFailure, retry_due en retry_count op null, en error.type op null. Zijn flags is ["dsnSent"] wanneer er een bouncemelding is verstuurd en [] wanneer het bericht zonder melding mislukte, en het bevat het volledige SMTP-log in events.
• Een issue dat uit de wachtrij komt is een echte wachtrij-entry, vermeld met alleen zijn falende ontvangers — zijn recipients-array is dus een subset van die onder queue — en zijn events is leeg.

source onderscheidt de twee zonder dat je ze hoeft te inspecteren. Elke entry van queue en van issues bevat het veld: "queue" voor een rij die uit de live uitgaande wachtrij komt, "trace" voor een rij die uit een trace is afgeleid. Het zegt of de rij nog kan veranderen — een wachtrij-entry wordt nog opnieuw geprobeerd, terwijl een issue uit een trace definitief is: de bouncemelding is al verstuurd en het bericht is al uit de wachtrij verdwenen — en het is de enige manier om te zien welke entries een events-log bevatten. De trace-arrays (incoming en outgoing) bevatten het niet: alleen de rijen in wachtrijvorm krijgen het stempel.

Permanente fouten komen altijd alleen uit traces en berichten die nog opnieuw worden geprobeerd altijd alleen uit de wachtrij, dus de twee bronnen tellen hetzelfde bericht nooit dubbel. Dat betekent ook dat afgeronde bounces bij de dingen horen die verdwijnen waar tracing niet is gelicentieerd.

Een leeg archief betekent twee dingen, geen drie

Het archief is een object alleen voor Enterprise op de mailserver, en de lijst erachter is strikt: een query die niet kon worden uitgevoerd antwoordt 503 archived_items_unavailable. Gearchiveerde mail opvragen antwoordt 200 met een lege archived_items-array in twee situaties, en niets in de reactie onderscheidt ze:

• er is niets gearchiveerd;
• de mailserver licentieert archiveren niet. Er is geen manier om die mogelijkheden op te vragen, dus "niet gelicentieerd" en "niets gearchiveerd" zijn bewust niet te onderscheiden — en elk endpoint op id antwoordt dan 404 unknown_archived_item.

"De mailserver kon niet gevraagd worden" is niet langer een van die situaties: dat is de 503. Dat de licentiegrens nog wel terugzakt naar een lege lijst komt doordat de mailserver een verzoek om een gelicentieerd object wel beantwoordt, en een antwoord is precies waar de strikte read op controleert; een server die geen antwoord geeft levert de 503. Een onbereikbare mailserver is dus wél te onderscheiden van een leeg archief. Een niet-gelicentieerde niet.

Behandel een leeg archief als "niets te tonen", nooit als "er is nooit iets verwijderd".

Dit meldt een verzoek, geen afgeronde terugzetting

De mailserver kent geen synchrone terugzetting. De trigger is het zetten van de status van het item op een terugzetverzoek, dat de server vervolgens op zijn eigen schema verwerkt, en hij geeft geen signaal wanneer het klaar is — daarom zegt de reactie restore_queued en nooit restored, en heeft deze API niets om te pollen.

Wil je weten of een terugzetting daadwerkelijk is gebeurd, lees het archief dan opnieuw: een item dat is teruggezet staat er niet meer in, en het bericht komt onder een nieuw id terug in de mailbox. Meld een terugzetting niet als afgerond op grond van deze reactie.

Onomkeerbaar — er zit geen tweede archief achter dit archief

Dit wist het gearchiveerde bericht en de opgeslagen kopie ervan vóór de bewaardeadline. Daarna is er niets meer te herstellen, en er is geen bevestigingsparameter: de enige voorwaarde is dat het item bij deze mailomgeving hoort.

Elke geslaagde wissing wordt met de gebruikte credential vastgelegd in het auditlog van het platform, nadat de mailserver het heeft bevestigd — een logregel voor een vernietiging die niet is gebeurd zou erger zijn dan geen regel.

Lees bij delete_unconfirmed eerst het item terug voordat je iets anders doet

Het is de enige plek op dit vlak waar een onbekende uitkomst niet terug te draaien is, dus dit behandelen als "het verwijderen is mislukt" is de slechtste van de drie mogelijke aannames. Vraag het item op: een 404 betekent dat de wissing is doorgekomen.

Bij geen van beide fouten wordt een auditregel geschreven. Die regel wordt pas geschreven nadat de mailserver de wissing bevestigt, dus het ontbreken ervan is geen bewijs dat het item er nog is.

Een genoemde mailbox is echt; een lege lijst is geen bewijs dat de mail weg is

De controle is een strikte lees, dus een mailserver die helemaal niet gevraagd kan worden antwoordt 503 purged_mailboxes_unavailable in plaats van een lege 200 — zie Leesfouten. Dat sluit het ene gat, maar niet het andere.

De wistaken worden 500 rijen per keer over de hele mailserver gelezen en daarna teruggefilterd naar deze mailomgeving, en de reactie bevat geen totaal en geen signaal dat er is afgekapt. Op een drukke server kunnen de taken van deze mailomgeving buiten dat venster vallen, waardoor een mailbox die de mailserver nog zou herstellen stil ontbreekt in een volkomen gezonde 200.

Lees de lijst dus zoals het veilig is: een record dat erin staat is werkelijk herstelbaar, en een lege lijst betekent "niets gevonden", niet "de mail is weg". Gooi op grond daarvan nooit je eigen laatste record van een mailbox weg — houd een kopie van wat je verwijderde tot de eigen recoverable_until van dat record is verstreken.

password is verplicht, omdat een herstelde mailbox zonder inloggegevens terugkomt

De mailserver geeft het account helemaal zonder wachtwoord terug, dus dit endpoint stelt er een in. Daarmee is het een write die inloggegevens uitdeelt: het levert een werkende mailbox op een adres dat mail ontvangt. Een ontbrekend of leeg password wordt geweigerd met 400 password_blank voordat er iets wordt aangeraakt, en elk succes wordt met de gebruikte credential vastgelegd in het auditlog van het platform.

Een mailbox kan onherstelbaar worden terwijl hij nog in de lijst staat

Herstelbaarheid is een beslissing van de mailserver, en die kan tussen je lijstaanroep en je herstel veranderen. Er zijn drie uitkomsten, en alleen de laatste is het opnieuw proberen waard:

• De eigen deadline van het record is verstreken → 409 not_recoverable. Er is niets aangeraakt, en dit is met opnieuw proberen niet tot een succes te maken.
• De mailserver is gevraagd en antwoordde dat hij geen wistaak meer heeft voor het account (de bewaartermijn is verkort, of het account is op verzoek gewist) → 409 not_recoverable, en de momentopname wordt weggegooid, dus dezelfde :guid antwoordt bij een nieuwe poging 404 unknown_purged_mailbox en de mailbox valt uit de lijst. Ook dit is niet tot een succes te maken — de mail is werkelijk weg. Het deelt de code, de status en de formulering met het geval van de verstreken deadline hierboven, omdat het hetzelfde feit is: definitief, niet opnieuw proberen.
• De mailserver kon niet gevraagd worden — de voorafgaande lees mislukte, of kwam afgezwakt terug → 503 restore_unavailable, en de momentopname blijft precies staan waar hij stond. Probeer het opnieuw.

Die lees is bewust strikt, en de momentopname is de enige kopie van de quota, weergavenaam, aliassen en lidmaatschappen van de mailbox: een mislukte lees mag nooit worden aangezien voor "de mailserver heeft hem gewist" en het record vernietigen van een mailbox die de server nog zou teruggeven. De momentopname wordt daarom alleen na een geslaagde lees weggegooid — nooit na een mislukte.

Vertak op de status, en de drie antwoorden op drie verschillende vragen: 409 betekent dat er niets meer aan te doen is, 422 dat de mailserver heeft geweigerd en opnieuw proberen kan helpen, 503 dat de controle niet kon worden gedaan en er niets is geprobeerd — de enige fout hier waarvan gezegd kan worden dat er niets is veranderd. Je hoeft de lijst niet opnieuw te lezen om uit te zoeken welke fout je kreeg.

De lijst is om dezelfde reden geordend op wat het eerst verloopt: herstel in die volgorde.