Un bando di gara può essere autentico ma contenere una modifica non autorizzata dei dati bancari dopo una compromissione dell'account. L'autenticazione aiuta a valutare l'identità del dominio. L’autorità in materia di appalti deriva dal processo approvato e dalle persone responsabili. Progettare i due controlli in modo che si rinforzino a vicenda senza consentire all'uno di sostituire l'altro.
Mappare l'avviso nel registro degli appalti
Per la pubblicazione di gare d'appalto, avvisi di fornitori e appalti delegati, registrare il sistema di registrazione, l'identificatore dell'avviso, il mittente approvato e il ruolo contrattuale responsabile. La notifica dovrebbe aiutare il fornitore a trovare la documentazione autorevole sugli appalti attraverso un canale conosciuto. Evitare di considerare un collegamento in un messaggio inaspettato come una verifica indipendente dello stesso messaggio.
Registra il tenant dell'applicazione, Dal dominio, dominio busta, DKIM dominio e selettore per ogni percorso. Un portale per gli appalti in outsourcing può avere un'infrastruttura di invio separata dalla posta del personale dell'autorità. Un piè di pagina con marchio o un indirizzo di risposta non stabilisce un percorso di autenticazione allineato. Mantieni la gestione delle risposte nella mappa del percorso perché un avviso autentico può indirizzare le risposte a una casella di posta operativa diversa.
Mantenere i cambiamenti consequenziali dietro la propria approvazione
Classificare gli avvisi in base a ciò che chiedono al destinatario di fare. L'avviso di gara aperta, la modifica della scadenza, la comunicazione dell'aggiudicazione e la richiesta dei dettagli del pagamento hanno conseguenze operative diverse. Questa guida raccomanda una verifica separata degli appalti e dei finanziamenti per modifiche sensibili di fornitori o banche utilizzando i record di contatto stabiliti, non un numero di telefono fornito nell'e-mail contestata.
DMARC non controlla i termini di una gara d'appalto né determina chi ha approvato un premio. Nemmeno una firma passeggera stabilisce che un conto bancario appartenga al fornitore previsto. Conservare l'autorità di modifica, la registrazione approvata e il risultato della verifica indipendente nel sistema di appalto. Queste sono raccomandazioni sul flusso di lavoro, non una dichiarazione della legge sugli appalti di alcuna giurisdizione.
Testare il mittente delegato prima di una scadenza
Esegui campioni approvati per avviso iniziale, modifica e annullamento, con dettagli di gara fittizi. Confermare l'identità del mittente prevista, il risultato della firma, applicabile allineamento, destinazione della risposta e accesso riuscito al verbale ufficiale. Un test di firma non può stabilire che la notifica sia arrivata prima di un termine legale. Conservare separatamente le relative prove di consegna e pubblicazione.
Se un appaltatore cambia piattaforma durante una gara attiva, mantenere il vecchio percorso fino a quando non saranno compresi il passaggio approvato e la gestione della coda. Imposta un proprietario per gli avvisi non riusciti e un processo di notifica alternativo documentato. Non inviare nuovamente silenziosamente un avviso tramite una nuova identità perché un'integrazione non è riuscita. Un cambiamento di questo tipo può confondere i fornitori e deve essere gestito nell'ambito del processo di comunicazione approvato dal team di procurement.
Rivalutare il confine rivolto ai fornitori
Esaminare i report in base al servizio di approvvigionamento, non semplicemente in base al volume totale della posta del dipartimento. Un aggregato apparentemente sano può nascondere un mittente di emendamenti a basso volume. Aumenta i domini di firma imprevisti, le nuove destinazioni di risposta e gli account dei fornitori senza proprietario. Prima di ritirare un dominio o un selettore, stabilisci quali record di gare e avvisi ricorrenti dipendono ancora da esso. Le prove di autenticazione vanno affiancate, anziché sostituite, alle registrazioni degli audit sugli appalti.
Elabora tre registrazioni scritte del percorso
Questi domini di esempio riservati, selettori, ruoli e premesse DKIM di passaggio sono fittizi. In questi casi non vengono forniti o eseguiti messaggi firmati, chiavi, verifiche crittografiche, ricerche DNS , transazioni SMTP o test del servizio live. Non è necessario alcun codice di prova o campione esterno per verificare il ragionamento riportato di seguito.
- pubblicazione bando: visibile Dal dominio tenders.civic.example ; DKIM d=tenders.civic.example; selettore demo1; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL DA identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: responsabile dell'approvvigionamento. Azione successiva: ottenere un campione autorizzato e un risultato di un ricevitore attendibile per questo esatto tenant.
- avviso fornitore: visibile dal dominio suppliers.civic.example ; DKIM d=suppliers.civic.example; selettore demo2; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL FROM identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: titolare delle comunicazioni del fornitore. Azione successiva: conferma questo percorso separato e il relativo evento aziendale anziché ereditare il risultato del primo percorso.
- appalti delegati: visibile dal dominio contracts.civic.example ; DKIM d=provider.example.net; selettore demo3; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL FROM identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: Amministrazione aggiudicatrice. Azione successiva: chiedere al fornitore verificato il percorso di firma allineata supportato da questo tenant; non estendere l'autorizzazione a tutta la sua rete.
Per le prime due firme stipulate, d= è esattamente uguale al dominio From, quindi l'identificatore soddisfa un allineamento rigoroso e rilassato. Dato il risultato DKIM positivo previsto, esiste un percorso di autenticazione allineato per questi ipotetici messaggi. Il terzo firmatario è deliberatamente estraneo al dominio dell'autore e non può fornire quel percorso allineato. Non chiamare il terzo messaggio un errore DMARC : SPF allineato o un altro passaggio allineato Firma DKIM potrebbero ancora soddisfare il meccanismo e tali input sono sconosciuti. Non dedurre la distribuzione reale o il posizionamento della posta in arrivo da alcuna riga.
Una firma crittografica autentica la responsabilità del dominio che firma, non la verità o l'autorizzazione di ogni istruzione. Le modifiche ai byte canonizzati coperti possono invalidare una firma; non tutte le modifiche visibili modificano necessariamente l'input firmato. L'autenticazione e l'accettazione a livello di applicazione rimangono separate.
Utilizzare una scheda di accettazione specifica per l'avviso
Per la gara fittizia T-01 emendamento versione 2, richiedere la versione del record approvata, il ruolo contrattuale autorizzato, l'identità dell'origine, la destinazione della risposta, l'ora di pubblicazione e la prova della notifica del destinatario. Se l'autenticazione passa ma il documento ufficiale rimane la versione 1, interrompere e riconciliare la modifica con l'appalto; non etichettarlo come approvato. Se il record è corretto ma la notifica non riesce, invocare il processo di notifica alternativo già approvato e conservare le prove della tempistica. Un beneficiario modificato attiva il processo di verifica finanziaria separata indipendentemente da entrambi i risultati. Si tratta di decisioni proposte, non di requisiti di legge sugli appalti o di test completati.
Applicare gli standard senza pretenderne la conformità
RFC 9989 Sezioni 4.4 e 5.3.5 supportare l’allineamento e la distinzione del meccanismo. La sua Sezione 7.4 mette in guardia sull'interoperabilità della posta indiretta: i domini che utilizzano p=reject deve utilizzare DKIM valido, non solo SPF , e l'uso generico della mailing list richiede particolare attenzione. Un inventario del percorso non è di per sé un'autorizzazione per imporre il rifiuto. RFC 6376 Sezioni 3.4–3.7 e 6.1 descrivere gli input firmati e la verifica. RFC 9990 Sezione 3.1 fornisce il contesto del reporting, non la prova di arrivo per destinatario. RFC 5321 Sezione 4.2.5 distingue la responsabilità dell'accettazione del server dai risultati della consegna successiva. Le scelte del flusso di lavoro settoriale qui sono raccomandazioni editoriali; l'ambito giuridico, l'idoneità dei fattori e l'autorizzazione locale necessitano di una propria revisione responsabile.