Conform RFC 6376:
6.3. Interpretați rezultatele/Aplicați politica locală
Este dincolo de scopul acestei specificații să descriem ce acțiuni
un Evaluator de Identitate poate face, dar e-mail care poartă un SDID validat
prezintă o oportunitate unui evaluator de identitate care nu a fost autentificat
e-mailul nu. Mai exact, un e-mail autentificat creează un
identificator previzibil prin care alte decizii pot fi sigure
gestionate, cum ar fi încrederea și reputația. Dimpotrivă, neautentificat
e-mailului nu are un identificator de încredere care poate fi folosit pentru a atribui încredere
si reputatie. Este rezonabil să tratăm e-mailurile neautentificate ca
lipsit de orice încredere și fără reputație pozitivă.
În general, modulele care consumă ieșirea de verificare DKIM NU TREBUIE
determina acceptabilitatea mesajului doar pe baza lipsei acestuia
semnătură sau pe o semnătură neverificabilă; o astfel de respingere ar cauza
probleme severe de interoperabilitate. Dacă un MTA dorește să respingă astfel de
mesaje în timpul unei sesiuni SMTP (de exemplu, atunci când comunicați cu
un egal care, prin acord prealabil, este de acord să trimită doar mesaje semnate),
iar o semnătură lipsește sau nu verifică, MTA de manipulare
TREBUIE să utilizeze un cod de răspuns 550/5.7.x.
În cazul în care Verificatorul este integrat în MTA și nu este
este posibil să se preia cheia publică, probabil pentru că serverul de chei este
nu este disponibil, un mesaj de eșec temporar POATE fi generat folosind a
cod de răspuns 451/4.7.5, cum ar fi:
451 4.7.5 Nu se poate verifica semnătura - serverul de chei indisponibil
Eșecuri temporare, cum ar fi incapacitatea de a accesa serverul de chei sau
alte servicii externe sunt singurele condiții care TREBUIE să folosească un 4xx
Cod de răspuns SMTP. În special, verificarea semnăturii criptografice
eșecurile NU TREBUIE să provoace răspunsuri SMTP 4xx.
Odată ce semnătura a fost verificată, acea informație TREBUIE să fie
transmise evaluatorului de identitate (cum ar fi un permis explicit/
lista albă și sistemul de reputație) și/sau utilizatorului final. Dacă SDID-ul
nu este aceeași cu adresa din câmpul De la: antet, e-mail
sistemul TREBUIE să facă eforturi pentru a se asigura că SDID-ul real este clar
cititorul.
În timp ce simptomele unei verificări eșuate sunt evidente --
semnătura nu se verifică - stabilirea cauzei exacte poate fi mai mult
dificil. Dacă un selector nu poate fi găsit, este pentru că
selectorul a fost eliminat sau valoarea a fost modificată cumva în
tranzit? Dacă linia de semnătură lipsește, este pentru că a fost
niciodată acolo, sau a fost îndepărtat de un filtru exagerat de zel? Pentru
în scopuri de diagnosticare, motivul exact pentru care verificarea eșuează
TREBUIE să fie disponibile și, eventual, înregistrate în jurnalele de sistem.
Deci, poate varia în funcție de configurația serverului de primire, dar probabil majoritatea nu vor marca ca spam, mai ales dacă există înregistrări SPF și DMARC valide și alți indicatori ai unui expeditor valid (reputația adresei IP, reputația domeniului etc.).
