Onnistunut API-vastaus ei ole sama asia kuin todennettu toimitus. Ennen kuin vertaat hintoja tai SDK:n mukavuutta, määritä, mitä palvelun on todistettava viestin lähettäjän henkilöllisyydestä ja elinkaaresta. Tämä opas tarjoaa toimittajaneutraalin hyväksymismenetelmän, ei paremmuusjärjestystä tarjoajaluetteloa tai väitettä, että jokin tietty suunnitelma tukee kaikkia ominaisuuksia.
Määritä tärkeät viestit
Listaa salasanan nollaukset, kuitit, suojausilmoitukset ja muut tapahtumavirrat erikseen. Tallenna jokaiselle haluttu Lähettäjä-toimialue, sovelluksen omistaja, suurin hyödyllinen viive, odotettu äänenvoimakkuuden malli ja kaksoisviestin seuraus. Sisällytä ajoitetut viestit ja vaihtoehtoiset ympäristöt. Päätä, mitkä virrat selviävät palveluntarjoajan tapauksesta ja mitkä voivat odottaa turvallisesti.
Pyydä jokaiselta listalle valitulta palveluntarjoajalta nykyinen ensimmäisen osapuolen dokumentaatio, joka kattaa mukautetut allekirjoitusalueet, kirjekuoriverkkotunnuksen asetukset, valtuustietojen laajuuden, tapahtuman toimituksen ja säilyttämisen. Tallenna suunnitelma ja aluerajoitukset. Myyjän esittely ei ole todiste siitä, että ehdottamasi tili sisältää saman ominaisuuden. Pidä vastaamattomat kysymykset näkyvissä sen sijaan, että annat optimistisia pisteitä.
Todista, että hallitset identiteetit
Määritä oma testialiverkkotunnus dokumentoidun toimialueen vahvistusprosessin avulla. Käytä kyseiseltä tililtä luotuja DNS arvoja. Säilytä muut valtuutetut lähettäjät olemassa olevissa SPF ja välttää päällekkäisyyksiä SPF tietueita yhdellä omistajalla. Lähetä todellisen tuotantoon tarkoitetun API-päätepisteen ja sanomatyypin kautta.
Kaappaa valvotussa postilaatikossa näkyvä Lähettäjä, kirjekuoren verkkotunnus, DKIM d ja s sekä luotetut todennustulokset. Palveluntarjoajan riippumattoman verkkotunnuksen läpäisevä allekirjoitus ei osoita DMARC linjaus sinun kanssasi. Yksi tasattu kulkupolku voi täyttää DMARC , mutta mukautetulla kirjekuoren hallinnalla voi silti olla merkitystä palautuksen omistajuuden tai muun liiketoiminnan vaatimuksen kannalta. Arvioi nämä vaatimukset erikseen.
Määrittele, mitä kukin tapahtuma tarkoittaa
Rakenna tapahtumasanakirja palveluntarjoajan dokumentaatiosta: hyväksytty, jonossa, toimitettu, lykätty, palautunut ja valitettu eivät ole keskenään vaihdettavissa olevia tuloksia. Kysy, tarkoittaako toimitettu tapahtuma SMTP -etäpalvelimen hyväksyntää postilaatikon sijoittamisen sijaan. Testaa webhook-pyyntöjen todennusta, päällekkäisten tapahtumien käsittelyä, tilaus- ja uudelleenyrityskäyttäytymistä tuetun käyttöliittymän mukaisesti.
Käytä vakaata sisäistä viestin tunnistetta yhdistääksesi sovelluksen tarkoituksen, API-lähetyksen, toimittajan tunnisteen ja vastaanottajan tuloksen. Jos lähetyksen aikakatkaisu, älä lähetä automaattisesti uudelleen harkitsematta, onko palveluntarjoaja jo hyväksynyt sen. Vaadi dokumentoitua idempotenssisemantiikkaa tai kyseiselle API:lle sopivaa palautusmenettelyä. Älä oleta, että jokainen palveluntarjoaja paljastaa saman duplikointiominaisuuden.
Suorita käännettävä valintaharjoitus
Havainnollinen hyväksymistaulukko: kuitissa on käytettävä tasattua example.org identiteettiä; aikakatkaistusta toimituksesta ei saa luoda kahta kuittia; lykätyn tapahtuman on oltava toiminnan omistajan nähtävissä; käytöstä poistettujen valtuustietojen on lopetettava lisälähetykset. Merkitse jokainen tulos esitellyksi, vain dokumentoiduksi, ei-tuetuksi tai testaamattomaksi. Tämä esimerkki ei sisällä palveluntarjoajan tai live-testin tulosta.
Testaa edustavaa sisältöä ja liitteitä palveluntarjoajan sääntöjen mukaisesti. Käytä kontrolloituja vastaanottajia ja synteettisiä hyötykuormia asiakastietojen sijaan. Mittaa määritetyn työnkulun ja havaintoikkunan latenssia ja säilytä raaka-aikaleimat. Älä ekstrapoloi pientä pilottia käytettävyyden tai postilaatikon sijoitustakuuksi.
Päätä poistumissuunnitelmalla
Käsittele täyttämättömiä identiteetti- tai palautusvaatimuksia portteina ennen kustannusten laskemista. Sisällytä poistumissuunnitelmaan DNS puhdistus, valtuustietojen peruutus, säilytettyjen tapahtumien vienti ja eston käsittely. Vahvista varareitti ennen kuin kutsut sitä vikasietostrategiaksi. Toista valinnan jälkeen identiteetti- ja tapahtumatarkistukset, kun suunnitelmat, verkkotunnukset, SDK:t tai reititys muuttuvat. Hyödyllinen tulos on allekirjoitettu vaatimusmatriisi ja toistettava testitietue, ei ominaisuusmäärän voittaja.
Ratkaise epäselvä lähetys ennen kuin yrität uudelleen
Oletetaan, että sovellustietueet pyytävät DEMO-42:ta, API-yhteys aikakatkaisee eikä palveluntarjoajan viestitunnusta palauteta. Lopputulos on tuntematon, ei epäonnistunut. Käytä palvelun dokumentoitua sovinto- tai idempotenssiprosessia, tallenna todisteet ja eskaloi, jos se ei pysty selvittämään, tapahtuiko hyväksyminen. Uuden pyynnön sokea luominen vaarantaa kuittien kaksoiskappaleet. Tämä on hypoteettinen takaisinperintäpäätös; palveluntarjoajalta ei kysytty eikä viestiä lähetetty. RFC 9989 kohta 5.3.5 kuvaa DMARC -arviointia, ei API-idempotenssia tai liiketoimintatapahtuman loppuun saattamista.
Noudata lähettäjän velvollisuuksia ennen hylkäämistä
RFC 9989 kohta 7.4 vaatii verkkotunnusten julkaisemisen p=reject käyttää kelvollisia DKIM -allekirjoituksia eikä luottaa pelkästään SPF ään DMARC kautta. Kohdassa 8 mainitaan erikseen täyden osallistumisen vaatimukset, mukaan lukien yhdenmukaistetut SPF ja DKIM . Yhden viestin välityskohdistusmekanismi ei siksi ole täydellinen käyttöönottovalmiusstandardi. Kohta 7.4 varoittaa myös epäsuorista virroista ja suosittelee olemaan hylkäämättä verkkotunnuksia, jotka isännöivät käyttäjiä, jotka saattavat lähettää viestejä postituslistoille. sen vaiheittainen havainto-opastus ei korvaa todellisten suhdannesyklien ja vaikutuspolkujen tarkistamista.