En udbudsbekendtgørelse kan være autentisk og alligevel indeholde en uautoriseret bankdetaljeændring efter et kompromitteret konto. Godkendelse hjælper med at evaluere domænets identitet. Indkøbsmyndigheden kommer fra den godkendte proces og ansvarlige personer. Design de to checks til at forstærke hinanden uden at lade den ene erstatte den anden.
Tilknyt bekendtgørelsen til indkøbsprotokollen
Ved udbudsoffentliggørelse, leverandørbekendtgørelser og delegerede indkøb registreres registreringssystemet, bekendtgørelsesidentifikation, godkendt afsender og ansvarlig kontraherende rolle. Meddelelsen skal hjælpe en leverandør med at finde den autoritative indkøbspost gennem en kendt kanal. Undgå at behandle et link i en uventet besked som uafhængig bekræftelse af den samme besked.
Optag applikationslejeren, Fra domæne, konvolutdomæne, DKIM domæne og vælger for hver rute. En udliciteret indkøbsportal kan have adskilt afsendelsesinfrastruktur fra myndighedens personalepost. En brandet sidefod eller svar-til-adresse etablerer ikke en tilpasset godkendelsessti. Fortsæt med at håndtere svar på rutekortet, fordi en ægte meddelelse kan sende svar til en anden operationel postkasse.
Hold konsekvensændringer bag deres egen godkendelse
Klassificer meddelelser efter, hvad de beder modtageren om at gøre. En udbudsbekendtgørelse, fristændring, tildelingskommunikation og anmodning om betalingsoplysninger har forskellige driftsmæssige konsekvenser. Denne vejledning anbefaler separat indkøb og finansverifikation for følsomme leverandør- eller bankændringer ved hjælp af etablerede kontaktoplysninger, ikke et telefonnummer, der er angivet i den omstridte e-mail.
DMARC undersøger ikke et tilbuds vilkår eller afgør, hvem der har godkendt en tildeling. En forbigående underskrift fastslår heller ikke, at en bankkonto tilhører den påtænkte leverandør. Behold ændringsbemyndigelsen, godkendt registrering og uafhængig verifikationsresultat i indkøbssystemet. Disse er workflow-anbefalinger, ikke en erklæring om nogen jurisdiktions lov om indkøb.
Test den delegerede afsender inden en deadline
Kør godkendte prøver til første varsel, ændring og annullering med fiktive udbudsdetaljer. Bekræft den tilsigtede From-identitet, signaturresultat, gældende justering, svardestination og vellykket adgang til den officielle post. En underskriftstest kan ikke fastslå, at meddelelsen er ankommet inden en lovlig frist. Opbevar det relevante leverings- og udgivelsesbevis separat.
Hvis en entreprenør skifter platform under et aktivt udbud, behold den gamle rute, indtil den godkendte afskæring og køhåndtering er forstået. Indstil en ejer for mislykkede meddelelser og en dokumenteret alternativ meddelelsesproces. Indsend ikke en meddelelse stille og roligt via en ny identitet, fordi en integration mislykkedes. En sådan ændring kan forvirre leverandører og skal håndteres under indkøbsteamets godkendte kommunikationsproces.
Revurder den leverandørvendte grænse
Gennemgå rapporter fra indkøbsservice, ikke kun på tværs af afdelingens samlede postvolumen. Et tilsyneladende sundt aggregat kan skjule en afsender af lavvolumen ændring. Eskaler uventede signeringsdomæner, nye svar-til-destinationer og uejede leverandørkonti. Inden du trækker et domæne eller vælger tilbage, skal du fastslå, hvilke udbudsregistre og tilbagevendende meddelelser, der stadig afhænger af det. Autentificeringsbeviser hører sammen med, snarere end i stedet for, indkøbsrevisionsposter.
Gennemfør tre skriftlige ruteoptegnelser
Disse reserverede eksempeldomæner, vælgere, roller og forbipasserende DKIM lokaler er fiktive. Ingen signeret besked, nøgle, kryptografisk verifikation, DNS opslag, SMTP transaktion eller live-servicetest leveres eller udføres for disse tilfælde. Ingen testkode eller ekstern prøve er nødvendig for at inspicere begrundelsen nedenfor.
- udbudspublikation: synlig fra domænet tenders.civic.example ; DKIM d=tenders.civic.example; vælgerdemo1; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Anskaffelsesleder. Næste handling: Få en autoriseret prøve og et betroet modtagerresultat for netop denne lejer.
- leverandørmeddelelse: synlig Fra suppliers.civic.example ; DKIM d=suppliers.civic.example; vælgerdemo2; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Leverandørkommunikationsejer. Næste handling: Bekræft denne separate rute og dens forretningsbegivenhed i stedet for at arve den første rutes resultat.
- delegeret indkøb: synlig fra contracts.civic.example ; DKIM d=provider.example.net; vælgerdemo3; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Ordregiver. Næste handling: Spørg den bekræftede leverandør om denne lejers understøttede tilpassede signeringssti; ikke udvide autorisation til hele dets netværk.
For de første to angivne signaturer er d= nøjagtigt lig med From-domænet, så identifikatoren opfylder både streng og afslappet justering. I betragtning af det angivne succesfulde DKIM resultat findes der en tilpasset godkendelsessti for disse hypotetiske meddelelser. Den tredje underskriver er bevidst ikke relateret til forfatterdomænet og kan ikke levere den tilpassede sti. Kald ikke den tredje besked for en DMARC fejl: aligned SPF eller en anden aligned passing DKIM signatur kunne stadig opfylde mekanismen, og disse input er ukendte. Udled ikke reel implementering eller indbakkeplacering fra nogen række.
En kryptografisk signatur autentificerer et signeringsdomænes ansvar, ikke sandheden eller godkendelsen af enhver instruktion. Ændringer af dækkede kanoniserede bytes kan ugyldiggøre en signatur; ikke enhver synlig redigering ændrer nødvendigvis det signerede input. Godkendelse og accept på applikationsniveau forbliver adskilt.
Brug et meddelelsesspecifikt acceptkort
For fiktivt udbud T-01 ændringsversion 2, kræve den godkendte postversion, autoriseret kontraherende rolle, Fra identitet, svardestination, udgivelsestidspunkt og modtager-meddelelsesbevis. Hvis autentificeringen godkendes, men den officielle registrering forbliver version 1, skal du stoppe og afstemme ændringen med indkøb; mærk det ikke godkendt. Hvis registreringen er korrekt, men meddelelsen mislykkes, skal du påberåbe den allerede godkendte alternative meddelelsesproces og beholde tidsbevis. En ændret modtager udløser den separate finansverifikationsproces uanset resultatet. Det er forslag til beslutninger, ikke udbudsretlige krav eller gennemførte test.
Anvend standarderne uden at kræve overholdelse
RFC 9989 afsnit 4.4 og 5.3.5 understøtte justeringen og mekanismens skelnen. Dens afsnit 7.4 advarer om interoperabilitet mellem indirekte mails: domæner, der bruger p=reject skal bruge gyldig DKIM , ikke SPF alene, og brug af mailinglister til generelle formål kræver særlig omhu. En ruteopgørelse er ikke i sig selv tilladelse til at håndhæve afvisning. RFC 6376 afsnit 3.4–3.7 og 6.1 beskrive signerede input og verifikation. RFC 9990 Afsnit 3.1 giver rapporteringskontekst, ikke bevis for ankomst pr. modtager. RFC 5321 Afsnit 4.2.5 adskiller serveracceptansvar fra senere leveringsresultater. Valg af sektorarbejdsgange her er redaktionelle anbefalinger; juridisk omfang, faktor egnethed og lokal autorisation har brug for deres egen ansvarlige gennemgang.