Portaali voi hyväksyä sovelluksen, kun sen vastaanotto epäonnistuu, tai lähettää muistutuksia onnistuneesti, kun tilapäivitykset käyttävät unohdettua välitystä. Kummassakin tapauksessa kansalainen kokee palvelun rikki. Käsittele kuitteja, muistutuksia ja tilailmoituksia kolmena itsenäisesti omistamana reittinä ennen kuin luotat yhdistettyyn todennusmittariin.
Sido jokainen ilmoitus tilasiirtymään
Jos haluat kuitin, tunnista hakemustapahtuma, joka luo sen, ja tunniste, joka yhdistää sen lähetykseen. Tallenna tapaamismuistutusta varten aikataulujärjestelmä, aikavyöhyke ja uudelleenjärjestelykäyttäytyminen. Tilapäivitystä varten tunnista tapauksenhallinnan siirtymä ja arvovaltainen paikka, jossa kansalainen voi tarkistaa sen. Pidä ilmoitusaika erillään taustalla olevan tapahtuman ajasta.
Yhdistä jokainen tapahtuma lähettävään sovellukseen, toimittajan vuokraajaan, toimialueelta, kirjekuoren lähettäjä, DKIM verkkotunnus ja valitsin. Verkkoportaalin verkkotunnus ja TLS -varmenne eivät näytä, mikä järjestelmä lähettää sähköpostia. Sovellusintegraatio voi valita eri palveluntarjoajan jokaiselle ilmoitusperheelle, vaikka kaikilla viesteillä olisi sama visuaalinen ulkoasu.
Suunnittelu testaa muutoksia, ei vain onnellista polkua
Käytä kuvitteellisia sovelluksia ja valtuutettuja testipostilaatikoita. Käynnistä lähetys, muutettu tapaaminen, peruutettu tapaaminen ja tilan muutos hyväksytyssä testiympäristössä, jos mahdollista. Tarkista viestien lopulliset tavut ja vastaanottajan luotettava todennustulos. Varmista, että linkit ja näytettävät viittaukset johtavat odotettuun viralliseen palveluun sisällyttämättä todellisia kansalaistapausten tietoja yleisiin testilokiin.
Ennen uudelleenjärjestelyä jonossa oleva muistutus voidaan allekirjoittaa oikein ja silti kuvata vanhentunutta tapaamista. Verkkotunnuksen todennus ei ratkaise tätä sovellusvirhettä. Seuraa ilmoituksen alkavaa tapahtumaa ja versiota, jotta toiminnot voivat erottaa vanhentuneen sisällön identiteettivirheestä. Vastaavasti kuitin kaksoiskappale tulisi tutkia tapahtuma- tai uudelleenyritysongelmana sen sijaan, että se luokiteltaisiin automaattisesti huijausta.
Päätä, kuka pysäyttää katkenneen matkan
Sovelluksen omistajan tulee arvioida, voiko kansalainen jatkaa turvallisesti, kun sähköposti ei ole käytettävissä. Ajoituksen omistajan tulee käsitellä muistutusten poikkeavuuksia ja tapaustoimintojen tulee käsitellä tilailmoituksia. Määritä hyväksytty vaihtoehtoinen tilantarkistuspolku ja eskalaatiokontakti ennen kiristyskäytäntöä. Älä lupaa vaihtoehtoista kanavaa, ellei sitä aidosti tueta ja henkilöstöä.
Jos lähettäjä ei ole kohdistettu, tarkista palvelun todellinen mukautetun toimialueen ominaisuus ja vuokralaisen luomat tietueet. Muuta vain hyväksyttyä identiteettipolkua, testaa sitä ja säilytä päivätty palautussuunnitelma. Vältä laajaa SPF lisäykset tehty vain siksi, että lähde-IP näyttää tutulta. Palveluntarjoaja voi todentaa oman verkkotunnuksensa, vaikka se ei pysty perustamaan linjaus julkisen palvelun From-verkkotunnuksen kanssa.
Tarkkaile täydellisyyttä pelkkien prosenttiosuuksien sijaan
Kirjaa ylös, mitkä ilmoitusperheet havaittiin, mitkä testattiin ja mitkä jäävät vahvistamattomiksi. Sisällytä harvoin esiintyvät elinkaaritapahtumat ja paikalliskieliset muunnelmat, kun ne käyttävät erilaisia malleja tai järjestelmiä. Käyttää koontiraportit tunnistaakseen mallit todellisen raportoinnin kattavuudessa ja tutkia sitten puuttuvia tai epäonnistuneita reittejä palvelun todisteiden avulla. Päivitä kartta portaalipäivitysten, aikataulumuutosten, toimittajan vaihdon ja Lähettäjä-toimialueen muutosten jälkeen. Tässä ei ole asetettu erityistä lakisääteistä ilmoitusten määräaikaa.
Käy läpi kolme kirjallista reittitietuetta
Nämä varatut esimerkkialueet, valitsijat, roolit ja ohittavat DKIM tilat ovat kuvitteellisia. Näissä tapauksissa ei toimiteta tai suoriteta allekirjoitettua viestiä, avainta, kryptografista vahvistusta, DNS hakua, SMTP tapahtumaa tai live-palvelutestiä. Alla olevan perustelun tarkistamiseen ei tarvita testikoodia tai ulkoista näytettä.
- kuitti: näkyy verkkotunnuksesta receipts.civic.example ; DKIM d=receipts.civic.example; valitsin demo1; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF MAIL FROM henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Sovelluspalvelun omistaja. Seuraava toimenpide: Hanki valtuutettu näyte ja luotettava vastaanotin tulos juuri tälle vuokralaiselle.
- tapaamismuistutus: näkyvissä Verkkotunnuksesta appointments.civic.example ; DKIM d=appointments.civic.example; valitsin demo2; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF MAIL FROM henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Omistaja ajoitetaan. Seuraava toimenpide: Vahvista tämä erillinen reitti ja sen liiketapahtuma sen sijaan, että periisit ensimmäisen reitin tulosta.
- tilailmoitus: näkyvä Verkkotunnuksesta status.civic.example ; DKIM d=provider.example.net; valitsin demo3; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF MAIL FROM henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Asianhallinnan omistaja. Seuraava toimenpide: Pyydä vahvistetulta toimittajalta tämän vuokralaisen tuettu tasattu allekirjoituspolku. älä laajenna valtuutusta koko verkostoonsa.
Kahdella ensimmäisellä määrätyllä allekirjoituksella d= on täsmälleen sama kuin From-toimialue, joten tunniste täyttää tiukan ja kevyen kohdistuksen. Kun otetaan huomioon edellytetty onnistunut DKIM tulos, näille hypoteettisille viesteille on olemassa kohdistettu todennuspolku. Kolmas allekirjoittaja ei tahallaan liity tekijän verkkotunnukseen eikä voi tarjota tätä tasattua polkua. Älä soita kolmatta viestiä a DMARC vika: kohdistettu SPF tai muu kohdistettu ohitus DKIM -allekirjoitus voisi silti täyttää mekanismin, ja näitä syötteitä ei tunneta. Älä päättele todellista käyttöönottoa tai postilaatikon sijoittelua mistään rivistä.
Salausallekirjoitus todentaa allekirjoitustoimialueen vastuun, ei jokaisen ohjeen totuuden tai valtuutuksen. Muutokset peitettyihin kanonisoituihin tavuihin voivat mitätöidä allekirjoituksen; jokainen näkyvä muokkaus ei välttämättä muuta allekirjoitettua syötettä. Todennus ja sovellustason hyväksyntä pysyvät erillään.
Ratkaise vanhentunut muistutusesimerkki
Oletetaan, että kuvitteellinen tapaus C-01 tapaamisen versio 1 oli klo 10.00 GST ja versio 2 siirtää sen klo 11.00 GST samana päivänä. Jo jonossa oleva version 1 muistutus vaaditaan tasatun DKIM välittämiseksi. Sen identiteettitulos ei ole 10:00 ajankohtainen. Aikataulun omistajan tulee soveltaa hyväksyttyä peruutus- tai korvaussääntöä, tarkistaa nykyinen tapaaminen virallisessa portaalissa ja tarkistaa, onko korjaus todella toimitettu. Jos viesti sisältää sen sijaan version 2, mutta ei luotettavaa todennustodistusta, tutki postin reitti erikseen. Tässä ei käytetty todellista tapausta, viestiä, uudelleenjärjestelytyötä tai korjauslähetystä.
Käytä standardeja vaatimatta noudattamista
RFC 9989 kohdat 4.4 ja 5.3.5 tukevat kohdistuksen ja mekanismin eroa. Sen Osio 7.4 varoittaa epäsuoran postin yhteentoimivuudesta: verkkotunnukset käyttävät p=reject on käytettävä kelvollista DKIM , ei pelkästään SPF , ja yleiskäyttöinen postituslista vaatii erityistä huolellisuutta. Reittivarasto ei itsessään ole lupa pakottaa hylkäämään. RFC 6376 kohdat 3.4–3.7 ja 6.1 kuvaile allekirjoitettuja syötteitä ja todentamista. RFC 9990 kohta 3.1 tarjoaa raportointikontekstin, ei vastaanottajakohtaista saapumistodistusta. RFC 5321 kohta 4.2.5 erottaa palvelimen hyväksymisvastuun myöhemmistä toimitustuloksista. Tässä toimialakohtaiset työnkulkuvalinnat ovat toimituksellisia suosituksia; oikeudellinen ulottuvuus, tekijöiden soveltuvuus ja paikallinen lupa tarvitsevat oman vastuullisen tarkastelun.