Potilaat voivat nähdä saman logon vastaanottomuistutuksissa, rekisteröintiviestissä ja portaalisähköpostissa, vaikka kolme eri sovellusta lähettäisi heidät. Tunnista palvelu jokaisen viestin takana. Testaa sitten sekä sen sähköpostin identiteettiä että sovelluksen toimintaa, joka tekee ilmoituksesta hyödyllisen ja turvallisen.
Tunnista laukaisin ja kohde
Tallenna tapaamisten osalta, mikä ajoitustapahtuma laukaisee viestin ja kuinka uudelleenaikataulu tai peruutus vaikuttaa jonossa oleviin muistutuksiin. Tallenna rekisteröintiä varten sovellus, joka vastaa viestin sovittamisesta aiotun henkilön kanssa. Portaaliin pääsyä varten tunnista tilipalvelu ja hyväksytty linkin tai koodin elinkaari. Pidä todellinen sähköpostin tarjoaja ja vuokralainen jokaisen sovelluksen vieressä, ei vain portaalin verkkosivuston osoitetta.
Tallenna Lähettäjä-toimialue, kirjekuoren identiteetti, DKIM verkkotunnus ja valitsin jokaiselle reitille. Tarkista vastauksen kohde ja hyväksytty portaaliisäntä erillisinä kenttinä. Kelvollinen allekirjoitus palvelualueen alla ei varmista, että linkki on turvallinen, ajankohtainen tai tarkoitettu vastaanottajalle. Toisaalta tuttu portaalin URL-osoite ei todista, että sähköposti oli valtuutettu.
Testaa elinkaarimuutoksia kuvitteellisilla tietueilla
Luo hyväksyttyjä synteettisiä tapaamis- ja rekisteröintitapauksia. Harjoittele uusi tapaamisaika, siirrä aika, peruutus, kaksoisrekisteröintiyritys ja portaalin käyttöpyyntö, jos testiympäristö sen sallii. Tarkista, mitkä viestit todella näkyvät, estääkö sovellus vanhentuneet muistutukset ja johtavatko linkit odotettuun testiportaaliin.
Käytä tilin käyttöoikeusviesteissä toimimattomia esittelyarvoja tai erillistä hyväksyttyä testitiliä. Älä säilytä käyttökelpoisia potilaiden pääsylinkkejä tai koodeja yleisessä todennustodistuksessa. Viivästetty käyttösähköposti voi läpäistä DKIM , kun sen tunnus on vanhentunut. Tämä on sovelluksen elinkaaren tulos, ei todiste todennusvirheestä.
Erottele kolme erilaista epäonnistumista
Jos DKIM epäonnistuu tai kohdistettua polkua ei ole, sähköposti- ja palvelutiimien tulee tutkia allekirjoituksen, identiteetin ja viestien muutokset. Jos muistutuksella on väärä aika, ajoituksen omistajan tulee tutkia tapahtumaversiot ja aikavyöhykkeen käsittely. Jos viesti saapuu vanhentuneeseen osoitteeseen, rekisteröinti- ja identiteettitiimien tulee noudattaa hyväksyttyä vastaanottajan korjausprosessia. Älä ratkaise kahta viimeistä ongelmaa rentoutumalla DMARC politiikkaa.
Säilytä lyhyt testitietue, joka sisältää synteettisen tapauksen tunnuksen, tapahtuman ajan, lähettäjän identiteetin, havaitun todennuksen, sovelluksen tuloksen ja omistajan. Käytä mahdollisimman vähän muokattuja todisteita. Sähköpostin otsikot voi silti sisältää henkilökohtaisia osoitteita ja reititystietoja, joten käsittele niitä organisaation pääsy- ja säilytyssääntöjen mukaisesti sen sijaan, että olettaisit otsikot julkisiksi.
Määrittele hyväksymispäätös
Vaadi oikea lähetystunnus sekä odotettu sovelluskäyttäytyminen jokaiselle viestiperheelle. Allekirjoituspassi ei yksinään voi hyväksyä portaalimatkaa. Vahvista hyväksytty palautuspolku palvelun omistajalta, kun muistutukset tai käyttöoikeusilmoitukset epäonnistuvat, luomatta hyväksymätöntä vaihtoehtoista viestintäkanavaa.
Alla oleva kuvitteellinen kartta jättää tarkoituksella portaalin käyttöoikeusnäytteeseen tarjoajan verkkotunnuksen allekirjoituksen, joka ei ole täsmälleen kohdakkain. Sen määrätty salauskelpoisuus osoittaa, miksi pelkän DKIM =passin etsiminen ei riitä. Tuotantovalmius vaatii todellista palvelua ja soveltuvaa näyttöä SPF tai DKIM linjaus, ei kirjallinen lähtökohta.
Tarkista uudelleen ajoittajan vaihdon, rekisteröintimuutosten, identiteetin tarjoajan siirron, uusien portaalipalvelinten ja lähettäjän verkkotunnuksen muutosten jälkeen. Sisällytä vähäisiä poikkeuksia, kuten peruutetut tapaamiset ja palautetut tilit. Tämä on toiminnallinen vahvistusmenetelmä, ei väite, että jokin terveydenhuollon alusta tai EmailAuth -tuote ottaa jo käyttöön nämä hallintalaitteet.
Tarkista kirjallinen reittikirja
Kaikilla riveillä käytetään varattuja kuvitteellisia verkkotunnuksia, ehdotettuja omistajia ja määrättyjä DKIM tuloksia. Valitsin demo1 on havainnollistava tarra, ei asennettu avain. SPF -tulokset, muut allekirjoitukset, DNS käytännön löytäminen, todellinen vastaanotto ja sovelluksen onnistuminen ovat tuntemattomia. Avaimia, allekirjoitettuja viestejä, testin suorittamista tai toimitustodisteita ei toimiteta.
- tapaaminen: From appointments.care.example ; POSTIA LÄHETTÄJÄ tuntematon; DKIM d=appointments.care.example, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Omistajaa ajoitetaan. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
- rekisteröinti: osoitteesta registration.care.example ; POSTIT tuntematon; DKIM d=registration.care.example, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Rekisteröinnin omistaja. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
- portaalin käyttöoikeus: osoitteesta access.care.example ; POSTIT tuntematon; DKIM d=provider.example.net, valitsin demo1, oletettu läpäisy; ehdotettu omistaja Henkilöllisyyspalvelun omistaja. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
Oletettu läpäisevä allekirjoitus, jonka d= vastaa täsmälleen From, tarjoaa tiukasti kohdistetun polun tälle hypoteettiselle viestille. Liittymätön d= ei anna tasattua polkua kyseisestä allekirjoituksesta. Tuntematon SPF tai muut allekirjoitukset estävät yleisen epäonnistumispäätöksen jälkimmäisessä tapauksessa. Nämä kirjalliset tilat eivät muodosta live-kokoonpanoa tai postilaatikon sijoittelua.
Vertaa kolmea elinkaaripäätöstä
Käytä kuvitteellista portaalikoteloa P-02 ehdotetussa testivuokralaisessa. Ajanvarausversio 1 klo 09:00 GST peruutetaan ennen kuin sen jonossa oleva muistutus lähetetään: jopa määrätty DKIM passi jättää aikatauluvirheen. Väärälle synteettiselle tilille osoitettu rekisteröintiviesti on vastaanottajan kartoitusvirhe. Käyttölinkki, jonka oletettu 09:10 GST vanhenee klo 09:12 GST, on arvioitava sovelluksen vanhenemissääntöjen mukaisesti; todennus ei pidennä voimassaoloa. Aikataulu-, rekisteröinti- ja identiteetin omistajat kirjaavat kukin odotetun tuloksensa ja erillisen havainnon. Tässä näitä havaintoja ei toimiteta, joten mikään niistä ei ole läpäissyt testi. Älä kopioi reaaliaikaisia tunnuksia, potilaslinkkejä tai käyttökelpoisia koodeja todistepakettiin.
Pidä todisteiden rajat selvänä
RFC 9989 Kohdissa 4.4 ja 5.3.5 erotetaan todennus ja kohdistus; Kohta 5.4 jättää viestien käsittelyn vastaanottajakäytännön tehtäväksi. Kohta 7.4 edellyttää kelvollista DKIM ää pelkän SPF n sijaan verkkotunnusten julkaisussa p=reject ja varoittaa hylkäämästä verkkotunnuksia, joiden käyttäjät lähettävät viestejä Internetin postituslistoille. Katetut kanonisoidut tavut määrittävät DKIM eheyden RFC 6376 osioiden 3.4–3.7 ja 6.1 mukaisesti. Kumpikaan mekanismi ei vahvista kliinistä, koulutusta tai laillista auktoriteettia. Kerää valtuutetut nykyiset todisteet todellista käyttöönottoa varten; Tässä olevat toiminnalliset tarkistuslistat ovat suosituksia, eivät lainkäyttöaluekohtaisia vaatimustenmukaisuuden arviointia.