What benefit would DKIM provide if SPF is already used?
Se un dominio ha configurato SPF, il server di posta ricevente può controllare se il mittente richiesto della posta in base alla finestra di dialogo SMTP (cioè MAIL FROM) è autorizzato a inviare posta da questo indirizzo IP. Questo aiuta lo spoofing del mittente solo un po 'poiché viene controllato solo il mittente basato sulla finestra di dialogo SMTP, ma non l'intestazione From della posta. Ma i clienti di posta solitamente si preoccupano solo di quest'ultimo.
Con DKIM il server di posta in uscita firma una posta e questa firma può anche essere controllata dal mittente, cioè non solo dal server SMTP ricevente. Questa firma potrebbe includere l'intero corpo, ma potrebbe anche includere solo parte del corpo. E anche se l'intestazione From fa parte di questa firma, ciò non significa che l'intestazione From deve provenire dal dominio dei firmatari, il che significa che lo spoofing è ancora possibile.
Lo spoofing di Da viene indirizzato solo configurando un criterio DMARC che richiede che il dominio nell'intestazione From sia protetto da SPF o DKIM e che specifica un criterio quando il requisito non è soddisfatto.
Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?
Le e-mail non dichiarano di provenire da un server specifico ma da un dominio specifico. E come ho detto, SPF e DKIM da soli non proteggono dallo spoofing dell'intestazione From. E DKIM protegge solo parte della posta contro le modifiche: solitamente protegge tutto il corpo ma potrebbe essere configurato per consentire l'estensione del corpo. E protegge solo alcune intestazioni ma non tutte.
If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?
La posta viene consegnata hop per hop e anche se è crittografata con TLS, questa è rilevante solo tra gli hop. Quindi ci sono molte parti coinvolte che hanno accesso alla posta non protetta e potrebbero modificarla.
Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?
Se l'attaccante può spoofare record MX DNS che specificano come viene consegnata una posta o se l'attaccante può intercettare la posta su un trasporto non protetto o in uno degli hop l'hacker può modificarla. Ma l'attaccante non può semplicemente mettere un server su internet e dichiararlo come il server responsabile per il dominio, deve convincere altre parti a inviare la posta attraverso questo server (cioè a spoofing del record MX DNS).
If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?
I messaggi viaggiano crittografati dal tuo client di posta al server di posta del tuo provider, vengono decodificati lì, modificati (intestazione ricevuta, magari intestazione DKIM) e nuovamente crittografati per trasportarli all'hop successivo che potrebbe essere google già o potrebbe essere un altro server di posta upstream.
Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?
Mentre l'utente malintenzionato può aggiungere un'intestazione Received-SPF alla mail e quindi richiedere il controllo di SPF, un server di posta (MTA) sul bordo tra Internet e Intranet che riceve questa posta potrebbe controllare nuovamente da quale indirizzo IP la posta arriva davvero, cioè non si fida dell'intestazione Received-SPF. Questa intestazione viene utilizzata principalmente dai controllori dello spam che desiderano incorporare il risultato del test SPF nel controllo della reputazione ma non eseguono il server di posta e pertanto non hanno accesso all'IP originale del mittente.