Määrittele vertailtava palvelu- ja tuotereitti
Tärkeimpiä lähetyspalveluita koskevassa tutkimuksessa tulisi verrata havaittavissa olevaa konfiguraatiota ja dokumentoitua käyttäytymistä, eikä olettaa, että toimittajabrändi vastaa yhtä yhtenäistä sähköpostipolkua. Palveluntarjoaja voi tarjota tapahtumasovellusliittymiä, SMTP -lähetyksiä, markkinointikampanjoita, oletusverkkotunnuksia ja asiakkaan todennettuja verkkotunnuksia, joilla on erilainen toiminta. Tutkimuksessa on tunnistettava tarkka tuote, reitti, tilikonteksti ja havaintolähde ennen palvelun todennustuen luokittelua.
Tämä käsikirjoitus ehdottaa dokumentaarista ja todisteisiin perustuvaa menetelmää. Se ei luokittele palveluntarjoajia, tee kyselyitä asiakkaiden verkkotunnuksista, luo tilejä tai lähetä testiviestejä. Sana suuri tarvitsee selkeän valintasäännön, kuten ilmoitetun tuoteluettelon tai itsenäisesti tuetun käyttökriteerin. Ilman edustavaa markkinatietoa tutkimuksessa tulisi kuvata valittujen palvelujen vertailua sen sijaan, että se tarkoittaisi täydellistä markkinoiden kattavuutta.
Erota dokumentoitu ominaisuus havaitusta kokoonpanosta
Palveluntarjoajan virallinen asennusopas voi määrittää, mitä se kehottaa asiakkaita määrittämään. Se ei todista, että jokainen tili on ottanut ominaisuuden käyttöön tai että tietty viesti on käyttänyt sitä. Toisaalta yhdeltä tililtä otettu näyte ei voi määrittää kaikkia tuettuja tuotereittejä. Käytä erillisiä sarakkeita dokumentoidulle kyvylle, tilin määritystodistuksille ja vastaanotettujen viestien todisteille. Jokaisen lähteen päivämäärä ja laajuus säilytetään.
Säilytetyt Alchemerin asennusopas kuvaa tätä eroa. Se erottaa oman palvelimensa DKIM/ SPF integraatio mukautetusta SMTP ja rajoittaa dokumentoidun integroinnin tiettyihin toimiin ja kampanjoihin. Sen kampanjatestilinkki ei käytä mukautettua DKIM / SPF reittiä. Vertailu, joka jättää nämä reitin tiedot huomiotta, saattaa erehtyä pitämään testipolun tuloksen palveluntarjoajan yleisten kykyjen perusteella.
Säilytä tilikohtaiset DNS arvot
Mukautetun verkkotunnuksen asetukset tarjoavat usein tili- tai toimialuekohtaisia julkisia arvoja. Tutkimuksen ei pitäisi keksiä universaalia valitsin, sisältää kohteen tai CNAME malli yhdestä esimerkistä. Säilytä voimassa oleva virallinen ohje ja määritä, mitkä kentät edellyttävät valtuutettua tilitodistusta. Älä pyydä tai julkaise yksityisiä allekirjoitusavaimia, API-salaisuuksia tai valtuustietoja; tutkimuskysymys koskee yleensä julkista konfiguraatiota ja havaittavissa olevia identiteettejä.
RFC 6376 määrittelee DKIM -allekirjoitustoimialueen ja valitsin käsitteet. RFC 7208 määrittelee SPF SMTP identiteetin arviointi. Nämä standardit tukevat toimitettujen arvojen tulkintaa, mutta ne eivät kerro tutkijalle, mitkä arvot tietty toimittaja antaa asiakkaalle. Tilikohtaisten todisteiden puuttumisen on oltava aukko.
Erottele suora palvelutuki delegoidusta infrastruktuurista
Tuote voi käyttää toisen toimittajan toimitusinfrastruktuuria paljastaen samalla oman määritystyönkulkunsa. Tätä suhdetta on tuettava nykyisellä ensimmäisen osapuolen todisteella ennen kuin se väitetään. Vaikka infrastruktuurin toimittajan yleinen dokumentaatio tuettaisiin, se ei automaattisesti kuvaa sovelluksen tarkkaa lähettäjän identiteettiä, aluetta, tiliasetuksia tai vahvistusprosessia.
Säilytetyt Blackbaud-kehitysagentin opas havainnollistaa tuotekohtaisen yhdistelmän vaaditusta edelleenlähetyksestä ja DKIM , ehdollisesta SPF ohjeesta ja erillisestä testisarjasta. Tutkimuksen tulisi säilyttää tämä laajuus sen sijaan, että se tiivistää koko Blackbaud-portfolion tältä yhdeltä reitiltä. Esimerkki on dokumentaarinen; Blackbaud-tiliä tai viestiä ei ole tarkastettu.
Tallenna oletus- ja mukautettu identiteetin käyttäytyminen erikseen
Tunnista jokaiselle reitille dokumentoitu lähettäjän oletuskäyttäytyminen, tuetut mukautetun toimialueen vaihtoehdot ja kaikki todisteet kirjekuoren ja allekirjoituksen identiteetistä. Pidä näyttönimi näkyvissä verkkotunnuksesta, POSTIA LÄHETTÄJÄ verkkotunnus ja DKIM d -arvo eroavat toisistaan. Brändätty näyttönimi ei vahvista verkkotunnuksen kohdistus. Jaettu palveluntarjoajan identiteetti voi todentaa oikein ilman, että se on kohdistettu asiakkaan aiottuun näkyvään verkkotunnukseen.
RFC 9989 määrittää kohdistussuhteen. Vertailussa tulee kysyä, mikä polku voi tarjota kohdistetun todennuksen tuetuissa määrityksissä, ei pelkästään sitä, mainitseeko toimittaja SPF vai DKIM . Jos luotettua vastaanotettua näytettä ei ole, ilmoita, että kyky on dokumentoitu, mutta toiminnallista kohdistusta ei ole vahvistettu. Älä täytä taulukkoa arvatuilla läpäisytuloksilla.
Vältä vertaamasta toisin kuin vahvistussignaaleja
Palveluntarjoajat voivat käyttää erilaisia asetustarkistuksia: DNS läsnäolo, luodut testiviestit, verkkotunnuksen omistajuustarkistukset tai reittikohtaiset yhteystestit. Näillä signaaleilla on eri kattavuus. Vihreä varmennettu tarra tulee kuvata palveluntarjoajan dokumentaation mukaisesti, ei normalisoida yleiseksi todisteeksi siitä, että jokainen viesti todennetaan ja saapuu postilaatikkoon. Säilytä kaikki testin sivuvaikutukset ja lupavaatimukset.
Twilio SendGrid tapahtumaviittaus määrittelee käsitellyt ja toimitetut tapahtumat tietyissä käsittelyvaiheissa; toimitettu koskee vastaanottavaa palvelinta, ei ihmisen lukemaa. Jos toimitustelemetria sisältyy vertailuun, säilytä se semantiikka ja vältä käsittelemästä yhden palveluntarjoajan tapahtumatunnistetta toisen palveluntarjoajan tapahtumatunnisteen vastaavina ilman todisteita. Tällä tutkimuksella ei ole todellisia tapahtumia tai toimitustuloksia.
Versioi lähdekokoelma ja käsittele estettyjä todisteita
Säilytä tarkat viralliset URL-osoitteet, sieppauspäivämäärät, tilannevedostiivisteet, tuoteversiot, jos saatavilla, ja tukiosat. Dokumentaatio voi muuttua tutkimusta kirjoitettaessa. Kirjaa ylös, onko vaatimus peräisin nykyiseltä haetulta sivulta, selvästi päivätystä säilytetystä kaappauksesta vai vahvistamattomasta liidistä. Hakukatkelma on hyödyllinen löydön kannalta, mutta se ei saa korvata luettavaa ensisijaista lähdettä käyttöönottovaatimuksissa.
Jos lähde evätään tai palauttaa ei-käytettävissä olevan komentotulkin, kirjaa vika ja pidä tukialuetta, jota ei tueta. Älä ohita rajoitusta toisella reitillä tai korvaa kolmannen osapuolen opetusohjelmalla, kun merkitset tulosta ensimmäisen osapuolen varmennettuna. Palveluntarjoajat, joilla ei ole riittävää ensimmäisen osapuolen tukea, jää ratkaisematta. Älä muunna puuttuvaa näyttöä havaituiksi ominaisuuksiksi tai laske näitä palveluntarjoajia valmiiksi vertailuiksi.
Palveluvertailutaulukko
Luo sarakkeita valinnan perusteluille, toimittajalle, tuotteelle, reitille, tarvittaessa alueelle, tilin kontekstille, viralliselle lähteelle, lähdepäivälle ja tuetuille asetuksille. Lisää julkisen arvon alkuperä, varmennusmenetelmä, dokumentoidut rajoitukset, havaitut lähettäjän/kirjekuoren/allekirjoitustunnukset ja luotettavan vastaanottajan tulos, jos se on todella saatavilla. Erottele ei tuettu ja ei todistettu; luettavan asiakirjan puuttuminen ei ole todiste siitä, että ominaisuutta ei ole olemassa.
Tietojoukon tulee sisältää virhe- ja poissulkemisloki sekä vakaa sääntö tuotteiden laskentaa varten. Yhtä toimittajaa, jolla on useita erillisiä reittejä, ei pitäisi laskea epäjohdonmukaisesti sarakkeiden tai jaksojen välillä. Arvioijan tulee pystyä rekonstruoimaan jokainen luokitus säilytetyistä todisteista ilman salaisuuksia. Tälle luonnokselle ei tuotettu tällaista täytettyä vertailutietojoukkoa tai tilitaulukkoa.
Kuvitteellinen diagnoosi: oletustestiviestistä tulee palveluntarjoajan päätös
Kuvitteellinen tutkija lähettää tuotteen esikatselun tai testipolun ja näkee toimittajan omistaman identiteetin. Päätelmäluonnoksen mukaan palvelu ei voi tukea asiakkaan verkkotunnuksen todennusta. Tarkastuksessa havaitaan puuttuva laajuus: testipolku voi poiketa dokumentoidusta mukautetun verkkotunnuksen reitistä, eikä tilin määritystä ole määritetty. Tulos tukee vain testattua polkua, ei yleistä kykyvaatimusta.
Ehdotettu korjaus on säilyttää kapea havainto, tarkastella nykyistä reittidokumentaatiota ja jättää tukemattomat vertailut auki. Myöhempi valtuutettu testi voi arvioida aiotun kokoonpanon luotettavan vastaanotetun viestitaulukon avulla. Tämä skenaario on kuvitteellinen; viestiä ei lähetetty eikä palveluntarjoajalle annettu pisteitä. Se osoittaa, miksi havaittavissa olevan konfiguraation on pysyttävä sidottuna tarkaan tuotteen reittiin.
Julkaisun tila
Luettelo vaatii versioidut tietojoukot, kyselymenetelmän ja virhe-/poissulkemislokin, jotka toinen analyytikko voi toistaa. Ne alkuperäiset esineet pysyvät avoimina. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos sisältää vertailevan tutkimussuunnitelman, ei markkinasijoituksia, suoritettuja tilejä tai takuuta palvelukäyttäytymisestä.