Autentificeret mail er ikke en leveringsbekræftelse

En applikation kan afslutte en forretningsopgave korrekt og derefter fejle ved afsendelsen af den tilhørende mail. Hvis din grænseflade samler begge dele i ét grønt flueben, mangler teamet viden om, hvor det skal gribe ind.

En besked har flere observerbare tilstande

I det tænkte produktdesign opretter en supportportal beskeden N-68. Afsendelsestjenesten accepterer opgaven. Senere kommer en tilbagemelding fra det modtagende mailsystem. Grænsefladen bør udlede præcis det udsagn, dokumentationen understøtter.

Tabellen er en foreslået kobling til dette design. Den indeholder ingen afsendelsestest udført her. Det skal afklares, hvilke tilbagemeldinger der findes for den anvendte tjeneste og dens hændelser.

Domænekontrol besvarer et andet spørgsmål

Et vellykket DMARC-resultat bekræfter autoriseret brug af afsenderdomænet, ikke indholdets kvalitet eller uskadelighed. Det er heller ingen generel garanti for accept. Modtageren kan anvende flere kontroller og beslutte anderledes.

Produktbeskeden bør derfor ikke automatisk gøre et positivt autentificeringsresultat til »leveret«. Omvendt forklarer fravær i indbakken ikke alene, hvilken autentificeringsmekanisme der kunne være fejl i. Undersøg afsendelsesvejen og den konkrete tilbagemelding sammen.

Behandl tilbagemeldinger som en del af applikationen

AWS beskriver særskilte hændelser for returmeddelelser og klager og peger på muligheden for flere notifikationer. I dette design kræver applikationen derfor en kobling til beskeden og en fastlagt behandling af gentagne tilbagemeldinger. En anden hændelse bør ikke uden grund udløse en anden besked.

Mangler en hændelse, er den del af tilstanden fortsat ukendt. Overvåg disse tilfælde, og giv en ansvarlig rolle opgaven med at håndtere dem. Så kan teamet følge beskeden, mens forretningsopgavens tilstand forbliver sporbar. Udsagnet i grænsefladen følger dermed den tilgængelige observation.

Kilder

• IETF: DMARC

• AWS: Setting up event notifications