Poznaj nas
Pomoc
Obsługa klienta
Formularz kontaktowy
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin w spadku. Korzystając z tej strony, zgadzasz się z naszą polityką cookies.
Formularz kontaktu
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin. Korzystanie z serwisu oznacza akceptację polityki cookies.
Należy pamiętać, że korzystając z witryny bez zmiany ustawień przeglądarki, użytkownik wyraża zgodę na politykę prywatności i przechowywanie plików cookie, które umożliwiają sprawne działanie naszej witryny.
Problema DKIM
Oggi si è verificata una situazione interessante quando uno dei nostri dipendenti non riusciva a contattare una società esterna. Mi ha informato che la posta non gli arrivava da un dominio, supponiamo che fosse dominio.com, anche se i suoi messaggi arrivavano, l’altra parte non riceveva nessun messaggio di ritorno con il motivo del rifiuto della posta. Mi ha chiesto di controllare il problema, vi spiegherò brevemente come ho fatto e cosa l’ha causato.
Diagnostica delle notizie – Exim
Poiché stiamo usando exim come nostro MTA, i comandi qui saranno specifici per quel sistema, ma il processo può essere facilmente utilizzato anche in postfix.
La prima informazione è che se i messaggi non vengono restituiti al mittente significa che sono bloccati da qualche parte, hanno incontrato un errore temporaneo e uno dei server cercherà di consegnarli di nuovo. Questa è un’azione standard e non c’è niente di strano qui, chi ha letto il nostro articolo su come funziona la posta lo saprà. E l’informazione importante è che i messaggi sono stati inviati da domain.com.
Poiché i messaggi sono bloccati da qualche parte, controlleremo la nostra coda di messaggi da consegnare per vedere se sono bloccati da noi o non ci hanno nemmeno raggiunto:
Cioè, il messaggio è stato nella nostra coda per 66 minuti e non può essere consegnato, il che può essere un po’ sorprendente che il messaggio sia sul nostro server e non abbia ancora raggiunto il destinatario, ma ne parleremo a tempo debito. Il prossimo test è quello di controllare i log usando l’utile comando exigrep, che cerca i messaggi basati su dati dati, ad esempio un dominio, e visualizza tutte le informazioni su ciò che è successo. Usare un semplice grep in questa situazione ci porterebbe a non avere tutte le informazioni.
Cioè, abbiamo la ragione, il messaggio non viene consegnato perché non riesce a trovare la voce DKIM nella zona DNS, e il messaggio stesso è firmato e dovrebbe essere controllato se proviene da una fonte reale, quindi solo per essere sicuri, controlliamo se tale voce esiste perché potrebbe essere un problema con il nostro server DNS locale. Useremo il server DNS pubblico di Google per controllare:
Così abbiamo la ragione, la voce txt per il dominio zendesk1._domainkey.domain.com non esiste e lì il nostro server cercherà la chiave DKIM con cui può controllare la firma. Innanzitutto, perché zendesk1._domainkey.domain.com? Bene, prima nel registro avevamo dato i dati DKIM: „d=domain.com s=zendesk1 c=relaxed/relaxed a=rsa-sha256 t=1431354869″ come potete vedere la voce s= è effettivamente zendesk1 e s sta per selettore. Ci dice sotto quale dominio dobbiamo cercare la voce DKIM, in questo caso zendesk1._domainkey.domain.com, secondo lo schema: value s._domainkey.value d, dove d è il dominio. Se non c’è nessuna voce txt lì, significa che c’è un problema temporaneo con il server DNS o qualcuno non l’ha inserito lì, come nel caso di questo dominio.
La stessa query dig ha restituito un’altra informazione, cioè che i server DNS sono mantenuti da Cloudflare. Questa è un’azienda con cui abbiamo lavorato e di cui scriveremo sicuramente di più. Cloudflare funge da proxy per il server web, ma questo richiede di rinunciare anche al proprio server DNS, cosa significa? Bene, quel qualcuno semplicemente non ha inserito la chiave DKIM nella zona DNS, quindi il nostro server non ha potuto controllare se il messaggio è correttamente firmato, e ha aspettato con la consegna fino a quando qualcuno aggiunge una voce DNS o il server DNS inizia a rispondere, ma questo non è successo fino a 6 ore dal momento in cui il messaggio è arrivato sul nostro server ed è stato automaticamente restituito al mittente come non consegnabile a causa di un errore DKIM. Naturalmente ho informato l’altra parte del problema e stiamo aspettando che lo risolvano.
Un buon strumento per verificare la corretta configurazione delle e-mail è il sito web , basta inviare un’e-mail all’indirizzo fornito e fare clic sul pulsante e si otterrà un rapporto completo. Le e-mail inviate dai nostri domini ottengono 10/10 punti.
Bonus – Cos’è il selettore DKIM?
Un selettore non è altro che un’informazione su quale chiave DKIM il messaggio è stato firmato e dove cercarla. È stato introdotto per dare agli amministratori la possibilità di inserire più chiavi per un singolo dominio in modo che le chiavi vecchie o compromesse possano essere facilmente revocate, o non si debba tenere d’occhio la chiave perché va persa, si può rapidamente cambiare il selettore e iniziare a firmare con la nuova chiave, o anche non cambiarlo affatto ma iniziare a firmare con la nuova chiave immediatamente, tuttavia questo significa che i messaggi che vengono inviati durante il cambiamento possono essere restituiti a causa della chiave sbagliata.