Tarjousilmoitus voi olla aito, mutta sisältää luvattoman pankkitietojen muutoksen tilimurron jälkeen. Todennus auttaa arvioimaan verkkotunnuksen identiteetin. Hankintavalta tulee hyväksytyltä prosessilta ja vastuullisilta ihmisiltä. Suunnittele kaksi tarkistusta vahvistamaan toisiaan antamatta toista korvata toisella.
Yhdistä ilmoitus hankintatietueeseen
Tarjousjulkaisua, toimittajailmoituksia ja delegoituja hankintoja varten tallenna tietuejärjestelmä, ilmoituksen tunniste, hyväksytty lähettäjä ja vastuullinen sopimuspuolen rooli. Ilmoituksen tulee auttaa toimittajaa löytämään luotettavan hankintatietueen tunnetun kanavan kautta. Vältä käsittelemästä odottamattomassa viestissä olevaa linkkiä saman viestin itsenäisenä vahvistuksena.
Tallenna sovelluksen vuokraaja, From domain, envelope domain, DKIM verkkotunnus ja valitsin jokaiselle reitille. Ulkoistetulla hankintaportaalilla voi olla erillinen lähetysinfrastruktuuri viranomaisen henkilöstön postista. Brändätty alatunniste tai vastausosoite ei luo tasattua todennuspolkua. Jatka vastausten käsittelyä reittikartassa, koska aito ilmoitus voi ohjata vastaukset toiseen toimivaan postilaatikkoon.
Pidä seurauksista johtuvat muutokset oman hyväksyntänsä takana
Luokittele ilmoitukset sen mukaan, mitä ne pyytävät vastaanottajaa tekemään. Tarjouskilpailuilmoituksella, määräajan muuttamisella, ratkaisuviestillä ja maksutietopyynnöllä on erilaisia toiminnallisia seurauksia. Tämä opas suosittelee erillistä hankinta- ja rahoitustarkastusta arkaluonteisille toimittaja- tai pankkimuutoksille käyttämällä vakiintuneita yhteystietoja, ei kiistanalaisen sähköpostin puhelinnumeroa.
DMARC ei tarkasta tarjouksen ehtoja tai määritä, kuka hyväksyi tarjouksen. Myöskään ohimenevä allekirjoitus ei osoita, että pankkitili kuuluu aiotulle toimittajalle. Säilytä hankintajärjestelmässä muutosvaltuus, hyväksytty tietue ja riippumaton tarkastustulos. Nämä ovat työnkulkusuosituksia, eivät minkään lainkäyttöalueen hankintalakeja.
Testaa valtuutettu lähettäjä ennen määräajan päättymistä
Suorita hyväksyttyjä näytteitä alustavaa ilmoitusta, muutosta ja peruuttamista varten kuvitteellisten tarjoustietojen kanssa. Vahvista tarkoitettu From-identiteetti, allekirjoitustulos, soveltuva linjaus, vastauksen kohde ja onnistunut pääsy viralliseen tietueeseen. Allekirjoitustesti ei voi osoittaa, että ilmoitus saapui ennen lakisääteistä määräaikaa. Säilytä asiaankuuluvat toimitus- ja julkaisutodisteet erikseen.
Jos urakoitsija vaihtaa alustaa aktiivisen tarjouskilpailun aikana, säilytä vanha reitti, kunnes hyväksytty katkaisu ja jonokäsittely on ymmärretty. Aseta omistaja epäonnistuneille ilmoituksille ja dokumentoitu vaihtoehtoinen ilmoitusprosessi. Älä lähetä ilmoitusta hiljaa uudelleen uuden identiteetin kautta, koska integrointi epäonnistui. Tällainen muutos voi hämmentää tavarantoimittajia, ja se on käsiteltävä hankintatiimin hyväksymän viestintäprosessin mukaisesti.
Arvioi uudelleen toimittajan raja
Tarkista raportit hankintapalveluittain, ei pelkästään osaston postin kokonaismäärästä. Näennäisesti terve aggregaatti voi piilottaa pienen volyymin tarkistuksen lähettäjän. Eskaloi odottamattomia allekirjoitustoimialueita, uusia vastauskohteita ja omistamattomia toimittajatilejä. Ennen kuin poistat verkkotunnuksen tai valitsimen käytöstä, selvitä, mitkä tarjoustiedot ja toistuvat ilmoitukset ovat edelleen riippuvaisia siitä. Todennustodistus kuuluu hankintojen auditointitietueiden rinnalle, ei niiden sijalle.
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ä.
- tarjousjulkaisu: näkyy verkkotunnuksesta tenders.civic.example ; DKIM d=tenders.civic.example; valitsin demo1; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF POSTIA LÄHETTÄJÄ henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Hankintapäällikkö. Seuraava toimenpide: Hanki valtuutettu näyte ja luotettava vastaanotin tulos juuri tälle vuokralaiselle.
- toimittajailmoitus: näkyvä verkkotunnuksesta suppliers.civic.example ; DKIM d=suppliers.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: Toimittajaviestinnän omistaja. Seuraava toimenpide: Vahvista tämä erillinen reitti ja sen liiketapahtuma sen sijaan, että periisit ensimmäisen reitin tulosta.
- delegoitu hankinta: näkyvissä alkaen domain contracts.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: Hankintaviranomainen. 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ä kutsu kolmatta viestiä DMARC virheeksi: aligned 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.
Käytä ilmoituskohtaista vastaanottokorttia
Kuvitteellisessa tarjouskilpailussa T-01 muutosversiossa 2 vaaditaan hyväksytty tietueversio, valtuutettu sopimusrooli, From henkilöllisyys, vastauksen kohde, julkaisuaika ja vastaanottajan ilmoituksen todiste. Jos todennus onnistuu, mutta virallinen tietue säilyy versiona 1, lopeta ja sovita muutos hankinnan kanssa; älä merkitse sitä hyväksytyksi. Jos tietue on oikea, mutta ilmoitus epäonnistuu, käynnistä jo hyväksytty vaihtoehtoinen ilmoitusprosessi ja säilytä ajoitustodisteet. Vaihtunut edunsaaja käynnistää erillisen rahoituksen varmistusprosessin tuloksesta riippumatta. Nämä ovat päätösehdotuksia, eivät hankintalainsäädännön vaatimuksia tai valmiita testejä.
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.