Ecco una drammatizzazione di come va la comunicazione, quando una mail viene ricevuta ovunque.

Contesto: un server di posta elettronica, da solo in una baia, da qualche parte a Mosca . Il server se ne sta lì oziosamente, con un'espressione di aspettativa.

Server:
Ah, lunghi sono i giorni della mia servitù,
Che sarà trascorso in sempre solitudine,
'Ere arriva salutando dagli anelli esterni
Il veloce portatore di notizie esterne.

Si apre una connessione.

Server:
un client in arrivo! Forse una posta
Alla mia tutela sarà affidata
Che io possa trasmettere come il più bel destriero
E al destinatario portare il racconto completo.

  220 mailserver .kremlin.ru ESMTP Postfix (Ubuntu)  

Benvenuto nel mio regno, vagabondo della rete,
Scopri che sono un potente server di posta.
Come farai in questo il giorno va affrontato
Dovrà sorgere il bisogno di indovinare il tuo nome?

Cliente:

  HELO whitehouse.gov  

Ti saluto, custode del networking,
sappi che vengo generato dal pallido edificio.

Server:

  250 mailserver.kremlin.ru  

L'indirizzo IP in entrata si risolve attraverso il DNS in "nastyhackerz.cn".

Nobile inviato, sono tuo al comando,
Anche se la tua voce proviene dalle calde pianure
Della terra oltre le montagne asiatiche ,
Soddisferò la tua richiesta più debole.

Cliente:

  MAIL FR OM: barack.obama@whitehouse.gov RCPT TO: vladimir.putin@kremlin.ru Oggetto: la bomba più grande Ti sfido a una gara del più grande missile nucleare, patetico maniaco! Prima Oussama, poi i comunisti!.  

Ecco il mio messaggio, da inviare,
E trasmettere fedelmente sull'etere;
Attento agli indirizzi e al nome del mittente
Verrà visualizzato all'altra estremità.

Server:

  250 Ok  

Così è stato scritto, quindi deve essere fatto.
Il messaggio viene inviato e in Russia non c'è più.

Il server invia l'email così com'è, aggiungendo solo un " Ricevuto: "intestazione per contrassegnare il nome che il client ha dato nel suo primo comando. Poi inizia la Terza Guerra Mondiale. The End.

Commento: non c'è alcuna sicurezza nelle email. Tutti i nomi di mittenti e destinatari sono indicativi e non esiste un modo affidabile per rilevare lo spoofing (altrimenti ci sarebbero molti meno spam).

Qualsiasi indirizzo email di "mittente" può essere falsificato, poiché puoi modificare i dati in uscita che ti piacciono. Non devi ingannare Gmail. Detto questo, Gmail può individuare problemi evidenti quando un'e-mail contrassegnata come inviata da un'organizzazione arriva da un altro dominio.

Non puoi nemmeno essere sicuro che l'email originale provenga da Paypal nel tuo esempio: che Anche il bit del mittente può essere falsificato!

Se vuoi una sorta di autenticazione per evitare che ciò accada, hai bisogno di un modo per firmare o crittografare le email, o un controllo fuori banda per confermare che l'email proviene dal tuo amico (come hai menzionato nel tuo commento)

Seriamente, non fidarti di nessuna email. Non fare clic su alcun link in un'email . Soprattutto da obiettivi di alto valore come Paypal. Dovresti invece accedere come faresti normalmente e controllare se ti hanno inviato qualcosa.

Come altri hanno già detto, chiunque può falsificare qualsiasi indirizzo email, incluso il campo "Mittente": non esiste alcun motivo tecnico per cui paypal debba includere la propria email in campo del mittente, lo fanno solo perché sono un'azienda onesta. Non aspettarti che gli spammer siano così gentili.

Per inciso, tuttavia, vorrei ricordare che gmail supporta DKIM, che ti consente di verificare un Paypal l'email proveniva davvero da Paypal.

Per abilitarlo: fai clic sull'icona a forma di ingranaggio in alto a destra -> impostazioni di posta -> labs -> Abilita "Icona di autenticazione per mittenti verificati"

Le e-mail Paypal ora firmate verranno visualizzate con una piccola icona a forma di chiave accanto:

È molto simile alla posta. Chiunque può inviarti una lettera con carta intestata che assomiglia alla filiale locale della tua banca. Ci sono alcune cose che puoi fare per catturare imitatori come questi: potresti assicurarti che il timbro postale provenga dalla città giusta. Se la tua banca utilizza sempre la posta all'ingrosso invece dei singoli francobolli, potresti notarlo, ecc. Ma probabilmente non ti preoccupi mai di controllare queste cose, e anche se lo facessi, ciò non sarebbe sufficiente per verificare che la lettera provenga dalla tua banca.

La differenza principale tra posta e posta elettronica è che con la posta elettronica un falso è più pratico: può essere progettato una volta e quindi ripetuto a un costo quasi zero.

Ciò significa che tutte le contraffazioni e le contromisure sono su scala più massiccia e (a meno che tu non sia come me ¹ ) nella tua casella di posta arriverà della posta falsa e spetta a te filtrarla manualmente.

In conclusione, proprio come non chiameresti un numero di telefono su una lettera per "verificare le informazioni del tuo account" (come il tuo SSN e la carta di credito), non dovresti nemmeno fare clic sui link nelle email e aspettarti il ​​login schermo o qualsiasi altro modulo per inviare in modo sicuro le informazioni private alla tua banca. Se lo fai, potresti ritrovarti a inviare le tue credenziali a un impostore e non te ne accorgi mai.

^1. Ho eliminato tutto il mio spam. Ho il mio nome di dominio. Assegno a ogni contatto il proprio indirizzo e-mail e tutto finisce nella mia casella di posta. In questo modo, se Bob riceve un virus sul suo computer e comincio a ricevere parte di quello spam di basso livello, posso dire a Bob di cambiare la sua password e-mail e di iniziare a utilizzare un nuovo indirizzo e-mail per la sua e-mail. Il nuovo indirizzo email non riceverà spam e posso eliminare quello vecchio, perché solo Bob lo stava usando.

Non devo andare a dire alla mia banca e agli altri miei amici, ai miei fornitori, ai miei colleghi che il mio indirizzo e-mail è cambiato, perché ognuno ha il proprio indirizzo. (Non devo nemmeno aggiornare StackExchange e Gravater.) Questo va bene per me (niente spam), va bene per Bob (sa di avere un "virus o qualcosa del genere" - a volte posso essere diretto, ma bisogna stare attenti a non sbagliare dopo), buono per gli altri miei amici (non mi lamento mai di quante email ho ricevuto nelle ultime 24 ore e spiego perché non sono tornato da loro)

Penso che tutti voi abbiate trascurato un piccolo dettaglio menzionato nella drammatizzazione sopra, che in realtà è molto facile da controllare:

Le e-mail contraffatte non provengono da un indirizzo e-mail che appartiene legittimamente al dominio da cui affermano di avere origine. Parte del protocollo SMTP include una serie di intestazioni complete dei messaggi che sempre include il percorso di ritorno del messaggio, che è l'indirizzo email che effettivamente ha inviato il messaggio. Non solo, ma gli indirizzi IP hanno anche una regione geografica definitiva a cui sono assegnati. Quindi puoi cogliere queste discrepanze con un po 'di ricerca.

Prendi, ad esempio, la suddetta drammatizzazione.

Menziona che l'email proviene da whitehouse.gov. Ecco il suo indirizzo IP:

  calyodelphi @ dragonpad: ~ $ dig + short whitehouse.gov173.223.0.110  

Ora, diciamo che nastyhackerz.cn si risolve in un indirizzo IP da qualche parte nel blocco 1.0.32.0-1.0.63.255 (per riferimento: http://www.nirsoft.net/countryip/cn.html primo blocco nell'elenco). Quell'indirizzo IP sarà nelle intestazioni complete del messaggio. Tutto quello che devi fare è portare quell'IP online per rintracciare la sua geolocalizzazione (puoi usare http://www.geoiptool.com/ per esempio)

L'IP per whitehouse. gov (173.223.0.110) al momento della stesura di questo post si geolocalizza a Boston, Massachusetts (per qualche motivo un sistema di prevenzione dello spam non mi consente di pubblicare la mia ricerca su geoiptool a causa dei punti di reputazione, quindi puoi andare a fare la ricerca da solo) che è abbastanza vicino a casa (Distretto di Columbia)! Supponiamo solo che whitehouse.gov sia ospitato in un data center che si trova a Boston solo per renderlo più facile da spiegare.

Purché l'IP e l'indirizzo email che l'email fosse effettivamente inviato da non corrisponde all'IP e all'indirizzo di posta elettronica da cui afferma di essere inviato, può essere determinato come spoofing. Devi solo guardare nelle intestazioni complete dei messaggi.

Diamo un'occhiata alle intestazioni di un'e-mail che ho inviato da uno dei miei domini (dragon-architect.com) al mio indirizzo e-mail personale:

  Delivered-To: dragon.architect @ gmail.com Ricevuto: da 10.180.89.68 con ID SMTP bm4csp105911wib; Tue, 29 Jan 2013 08:54:47 -0800 (PST) X-Received: entro 10.60.30.38 con ID SMTP p6mr1296792oeh.2.1359478487251; Tue, 29 Jan 2013 08:54:47 -0800 (PST) Return-Path: <calyodelphi@dragon-architect.com>Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) by mx.google .com con ID ESMTP m7si14056914oee.29.2013.01.29.08.54.45; Mar, 29 gennaio 2013 08:54:46 -0800 (PST) Ricevuto-SPF: neutro (google.com: 69.93.154.35 non è consentito né negato dal dominio calyodelphi@dragon-architect.com) client-ip = 69.93. 154.35; Risultati di autenticazione: mx.google.com; spf = neutral (google.com: 69.93.154.35 non è né consentito né negato dal dominio di calyodelphi@dragon-architect.com) smtp.mail=calyodelphi@dragon-architect.com Ricevuto: da gateway14.websitewelcome.com (Postfix, da userid 5007) id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST) Ricevuto: da bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) da gateway14.websitewelcome.com (Postfix) con ID ESMTP EA7191DFDB314 per <dragon .architect @ gmail.com>; Tue, 29 Jan 2013 10:54:42 -0600 (CST) Ricevuto: da [127.0.0.1] (port = 43458 helo = dragon-architect.com) da bentley.websitewelcome.com con esmtpa (Exim 4.80) (envelope- da <calyodelphi@dragon-architect.com>) id 1U0ESK-0001KE-DP per dragon.architect@gmail.com; Tue, 29 Jan 2013 10:54:44 -0600MIME-Version: 1.0Content-Type: text / plain; charset = UTF-8; format = flowedContent-Transfer-Encoding: 7bitDate: Tue, 29 Jan 2013 10:54:44 -0600 Da: calyodelphi@dragon-architect.com A: <dragon.architect@gmail.com> Oggetto: test delle intestazioni
ID messaggio: <11c694cd1e07c66a404000008321d0c4@dragon-architect.com >X-Sender: calyodelphi@dragon-architect.comUser-Agent: Roundcube Webmail / 0.8.4X-AntiAbuse: questa intestazione è stata aggiunta per tracciare qualsiasi abuso, includilo : Nome host principale - bentley.websitewelcome.com X-AntiAbuse: dominio originale - gmail.comX-AntiAbuse: originatore / chiamante UID / GID - [47 12] / [47 12] X-AntiAbuse: dominio indirizzo mittente - dragon-architect.comX -BWhitelist: noX-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dragon-architect.com) [127.0.0.1]: 43458X-Source-Auth: calyodelphi @ dragon-architect. comX-Email-Count: 1X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20 = Testing testing!  

Ci sono molti dati casuali da esaminare, ma qui ci sono due righe: percorso di ritorno e da. Dal momento che ho legittimamente inviato questa email a me stesso, entrambi corrispondono. Il percorso di ritorno non può essere falsificato. Oppure, se possibile, è incredibilmente difficile da falsificare in modo efficace e richiede una configurazione deliberata del demone SMTP utilizzato per inviare la posta. Confrontare il percorso di ritorno e i campi dati da nelle intestazioni complete è un modo in cui io e i miei colleghi in cui lavoro possiamo identificare lo spoofing e determinare se è necessario inviare un ticket di supporto.

Allora, cosa succede se entrambi corrispondono, ma l'email dovrebbe essere ancora falsa? Ci arriveremo nella prossima sezione ...

Ora, come accennato prima, ci sono altri mezzi per determinare la falsità di un'e-mail. I record SPF sono uno di quei modi, ma non sono sempre perfetti. Prendi, ad esempio, l'SPF di whitehouse.gov e confrontalo con l'SPF del mio dominio:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all " 

Di solito, un buon record SPF include anche l'indirizzo IP del server che ha inviato la posta, quindi chiunque abbia creato il record SPF per whitehouse.gov probabilmente non lo sa. Considero il record SPF di whitehouse.gov troppo generico per essere efficace nel determinare le origini effettive di qualsiasi messaggio che afferma di provenire da whitehouse.gov. L'SPF per il mio dominio, invece, che è stato generato automaticamente dal server che ospita il mio dominio (per gentile concessione del mio webhost), è molto specifico e include l'indirizzo IP del server stesso.

Ammetto di non avere familiarità con il modo in cui i record SPF sono formattati e come funzionano, ma ho imparato abbastanza sul mio lavoro da poter almeno identificare i record SPF generici e specifici. Immagino sia qualcosa che dovrei probabilmente approfondire un fine settimana quando sono annoiato e voglio del materiale tecnico da leggere!

Comunque, di nuovo in pista qui. Guarda le linee ricevute. Uno di loro afferma così: Ricevuto: da bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Indovina cosa? Corrisponde all'indirizzo IP nel record SPF del mio dominio.

Se l'IP nell'SPF non corrisponde all'IP del server che ha effettivamente inviato l'email, questa è un'altra indicazione che hai uno spoofing sul tuo mani. Pertanto, un record SPF generico come "v = spf1 + mx ~ all" semplicemente non taglierà la senape di sicurezza. Non mi fiderei nemmeno delle email provenienti da un dominio legittimo con un SPF generico come questo.

Forse dovremmo presentare una petizione su petitions.whitehouse.gov per chiedere che il loro gli amministratori della sicurezza rivisitano il record SPF che hanno creato per il dominio! (Io scherzo, io scherzo.)

MODIFICA

In realtà devo correggere MASSIVAMENTE me stesso sui record SPF! Ho fatto alcune supposizioni sbagliate e ho imparato alcune cose oggi dopo aver chiesto a un collega che era più informato di me sui record SPF. Quindi, userò i due SPF per whitehouse.gov e dragon-architect.com nella mia autocorrezione:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all " 

L'SPF per il mio dominio è in realtà più indulgente dell'SPF per whitehouse.gov (qualcosa che ho intenzione di correggere stasera dopo aver terminato questa modifica). Spiegherò perché:

"v = spf1 + mx ~ all" dice sostanzialmente che le email da whitehouse.gov dovrebbero provenire dai nomi host definiti nei record MX per whitehouse.gov e tutte le email che non provengono da quei nomi host dovrebbero essere spoof, ma se sono contrassegnate come spoof o meno dipende dal destinatario dell'email.

  calyodelphi @ dragonpad: ~ $ dig + short mx whitehouse.gov110 mail6.eop.gov.105 mail2.eop.gov.110 mail5.eop.gov.105 mail1.eop.gov.105 mail4.eop.gov.105 mail3.eop. gov.  

"v = spf1 + a + mx + ip4: 70.84.243.130? all" dice che le email da dragon-architect.com dovrebbero arrivare dall'indirizzo IP di dragon-architect.com (67.18.28.78), i nomi host definiti nei record MX per dragon-architect.com o dall'indirizzo IP del server che ospita dragon-architect.com (70.84 .243.130). Eventuali e-mail che non provengono da quelle, beh, che? Tutto alla fine significa semplicemente che non ci sono consigli sull'opportunità di passare o rifiutare le e-mail.

Allora qual è la carne e le patate di un record SPF? Il "tutto" alla fine. Per citare questo collega in merito a "tutti":

  + fondamentalmente tutto significa che TUTTI passano - il record è inutile, al dominio del mittente non interessa? Tutto indica neutro e consiglia di non passare o rifiuta la posta
~ tutto indica un errore e il server è considerato non valido, ma non suggerisce specificamente un'azione. -tutto è un errore irreversibile, qualsiasi altra cosa non è valida, rifiutala o contrassegnala.  

Quindi "all" è dove si definisce quanto sia rigoroso il record SPF. Ma se il record SPF viene effettivamente utilizzato per determinare lo spoofiness di un messaggio di posta elettronica dipende completamente dal servizio di posta elettronica ricevente.

averlo. SPF in poche parole.

Quindi sì. TL; DR: controlla le intestazioni complete per vedere se i campi return-path e from corrispondono. Quindi ricontrolla i tuoi record SPF se ce ne sono per vedere se ottieni indirizzi IP corrispondenti.

SMTP ( Simple Mail Transfer Protocol) è chiamato così per un'ottima ragione.

L'SMTP è nato nel 1982 sul vecchio ARPANET, che era di proprietà e controllato dal Dipartimento della Difesa degli Stati Uniti, e inteso per la comunicazione tra persone con autorizzazioni di sicurezza che lavorano su progetti governativi che generalmente potevano essere attendibili per non usarlo in modo improprio. La "sicurezza" di questa rete è stata ottenuta semplicemente posizionando le macchine che potevano connettersi ad essa all'interno di aree fisicamente protette delle varie strutture, accanto al lavoro riservato che queste strutture stavano eseguendo. Di conseguenza, la protezione effettiva dei dati inviati lungo la rete non è stata generalmente considerata fino a dopo la disattivazione di ARPANET, con il primo salto di qualità avvenuto intorno al 1993 con l'API Secure Network Programming (che ha gettato le basi per Secure Sockets Layer, ora generalmente noto come Transport Layer Security). Sebbene la maggior parte dei protocolli (inclusi SMTP / POP / IMAP) ora possa aggiungere TLS per un canale di comunicazione sicuro, tutto ciò che fornisce è riservatezza e autenticità del server; non fornisce l'autenticità del mittente o l'integrità del messaggio e inoltre non fornisce il non ripudio.

C'è un'opzione disponibile per la sicurezza della posta elettronica, chiamata PGP (Pretty Good Privacy; è l'umorismo ironico di Phil Zimmerman per un sistema che nessun computer al mondo potrebbe rompere se implementato correttamente). Può, con varie opzioni, fornire tutti e quattro i principi fondamentali della sicurezza delle informazioni; riservatezza, integrità, autenticità e non ripudio (il mittente, che ha firmato l'e-mail utilizzando il proprio certificato, non può affermare di non averlo effettivamente inviato; nessun altro potrebbe averlo, a meno che il certificato non sia stato compromesso). Utilizza un sistema simile di certificati a chiave pubblica e scambio di chiavi sicuro come si vede in un handshake TLS a due vie, ma alcuni dettagli vengono modificati per riflettere la natura asincrona del trasporto e-mail e per riflettere il desiderio di un decentralizzato " web of trust "che preclude la necessità di autorità di certificazione affidabili a livello globale.

Tuttavia, questo sistema deve ancora decollare nonostante abbia più di 25 anni, e come tale è richiesto solo dalle agenzie governative e da alcune grandi società. Praticamente tutti i provider di posta elettronica recapiteranno ancora volentieri e-mail fraudolente tramite connessioni protette alla tua casella di posta. Puoi, in molti casi, incoraggiare i tuoi amici e altre persone da cui desideri ricevere e-mail ad adottare lo schema PGP, e tutto ciò che non è validamente firmato va in "quarantena", ma questo è davvero solo un altro livello di "filtro antispam ", e non conosco un solo provider di posta elettronica pubblico a cui puoi chiedere di rifiutare le e-mail senza una firma digitale a titolo definitivo; il server di posta elettronica dovrebbe essere sotto il tuo controllo, come un server Exchange aziendale.

• Paypal sta sfruttando un problema di sicurezza qui? ... Come può PayPal falsificare le email così facilmente?

Tecnicamente, no, non è un problema di sicurezza, la posta elettronica non è sicura all'inizio. Stanno utilizzando una delle seguenti intestazioni SMTP nell'intestazione del messaggio (non nell'intestazione della busta)

1. Resent-From
2. Resent -Sender
3. Sender

C'è una differenza concettuale tra "remailing" e "spoofing". Il client di posta dovrebbe visualizzare questa differenza. Il client Gmail non esegue questa operazione.

• Paypal non sta effettuando lo spoofing, sta utilizzando una di queste intestazioni SMTP: Resent-From , Resent-Sender o Sender”

• È molto facile falsificare un dominio ... anche con i controlli SPF abilitati

• Il MUA (client di posta elettronica) dovrebbe visualizzare Visualizza da , il suo stato di verifica SPF, DKIM e DMARC.

• L'intestazione Resent- * dovrebbe essere utilizzata in un modo che chiarisca che questo messaggio è "re-mail".

• In generale, la soluzione migliore è utilizzare DKIM + DMARC o SPF + DMARC e un MUA che visualizzi i risultati della verifica.

Qualche sottofondo

In generale, ci sono due indirizzi "da" e due indirizzi "a" in ogni messaggio SMTP. Uno è noto come busta RFC2821, l'altro è il messaggio RFC2822. Hanno scopi diversi

The Envelope: (RFC2821)

• La busta è composta da metadati che non vengono visualizzati nell'intestazione SMTP . Scompare quando il messaggio passa al successivo MTA.

• RCPT From: è dove andranno i rapporti di mancato recapito. Se un messaggio proviene da Postmaster o da un servizio di remailer, di solito è <> o someSystem@place.com . È interessante vedere che salesforce utilizza questo metodo simile a constantContact come chiave in un database come toUserContactID@salesforce.com per vedere se il messaggio è stato respinto.

• RCPT TO: è a chi viene effettivamente inviato il messaggio. Viene utilizzato allo stesso modo per gli utenti "a" e "bcc". Questo di solito non influisce sulla "visualizzazione degli indirizzi" nel client di posta, ma ci sono occasioni in cui gli MTA visualizzano questo campo (se le intestazioni RFC2822 sono danneggiate).

The Message (RFC2822)

• La parte del messaggio inizia quando viene emesso il comando data .

• Queste informazioni includono le intestazioni SMTP che conosci, il messaggio e i suoi allegati. Immagina che tutti questi dati vengano copiati e incollati da ogni MTA al successivo, in successione fino a quando il messaggio raggiunge la posta in arrivo.

• È consuetudine che ogni MTA anteponga la copia sopra menzionata e incolla con le informazioni sull'MTA (IP di origine, IP di destinazione, ecc.). Incolla anche i dettagli del controllo SPF.

• Questo è il Visualizza da posizionato. Questo è importante. Gli spoofer sono in grado di modificare questa impostazione.

• Il Mail From: nella busta viene scartato e solitamente posizionato qui come return-path: indirizzo per i rapporti di mancato recapito

Quindi, come impediamo alle persone di modificare Display From? Ebbene DMARC ridefinisce un secondo significato per il record SPF. Riconosce che esiste una differenza tra Busta da e Visualizza da e che esistono motivi legittimi per cui non corrispondono. Poiché SPF è stato originariamente definito in modo da preoccuparsi solo di Envelope From, se Display From è diverso, DMARC richiederà un secondo controllo DNS per vedere se il messaggio è consentito da quell'indirizzo IP.

Per consentire scenari di inoltro , DMARC consente inoltre a Visualizza da di essere firmato crittograficamente da DKIM e se uno spammer o un phisher non autorizzato tentasse di assumere tale identità, la crittografia fallirebbe.

Che cos'è DKIM? DKIM è una tecnologia di crittografia leggera che firma i dati che risiedono nel messaggio. se hai mai ricevuto un messaggio da Gmail, Yahoo o AOL, i tuoi messaggi erano firmati DKIM. Il punto è che nessuno saprà mai che stai utilizzando la crittografia e la firma DKIM a meno che tu non guardi nelle intestazioni. È trasparente.

DKIM di solito può sopravvivere all'inoltro e al trasferimento a diversi MTA. Qualcosa che SPF non può fare. Gli amministratori di posta elettronica possono usarlo a nostro vantaggio per prevenire lo spoofing.

Il problema risiede nel fatto che l'SPF controlla solo la busta RFC2821 e non Visualizza da . Poiché la maggior parte delle persone si preoccupa di Visualizza da mostrato in un messaggio di posta elettronica e non del percorso di ritorno NDR, abbiamo bisogno di una soluzione per proteggere e proteggere questo pezzo.

Qui è dove DMARC entra. DMARC ti consente di utilizzare una combinazione di un controllo SPF modificato o DKIM per verificare Visualizza da . DKIM ti consente di firmare crittograficamente il display RFC2822 ogni volta che l'SPF non corrisponde a Display From (cosa che accade frequentemente).

Sta falsificando Display From un problema di sicurezza?

Sì, il phishing tramite la posta elettronica è un importante problema di sicurezza che molti fornitori stanno esaminando. Vale a dire Paypal, AOL, Google, Yahoo e altre società stanno implementando DMARC per risolvere questo problema di phishing.

Perché è ancora possibile falsificare l'intestazione "Da:" nelle e-mail?

Alcuni amministratori di server non hanno implementato le ultime tecnologie per prevenire questo genere di cose. Una delle cose principali che impedisce l'adozione di queste tecnologie sono i "servizi di inoltro di posta elettronica" come un software di mailing list, inoltri automatici o remailer alumni scolastici (.forwarder). Vale a dire:

1. SPF o DKIM non è configurato.

2. Non è impostato un criterio DMARC.

3. Il client di posta elettronica non mostra i risultati della verifica del campo Visualizza da e del campo Invia di nuovo- * o Mittente.

Che cosa fa PayPal?

Paypal utilizza l'intestazione Sender per indicare che è stato re-mail. Questo è l'uso corretto e previsto di questa intestazione.

Che cosa sta facendo di sbagliato GMail?

Gmail non chiarisce che è in uso l'intestazione Sender, non convalida il Display From indirizzo in modo intuitivo e non fa distinzione tra display from e mittente.

Non ha nulla a che fare con "spoofing" o subdole di alcun tipo.

Per anni e anni molti di noi hanno ricevuto una copia di vari moduli, in particolare moduli di tipo "tell-a-friend" ecc. dove a livello di codice l'indirizzo "mittente" che identifica il "mittente dell'utente" non è quello del server di invio della posta sebbene sia posta legittima non attraverso un server di posta aperto utilizzato per l'inoltro.

Forse un forum o un programma guestbook restituisce un'e-mail "Da:" interna di "contatto utente" che identifica un altro utente e non il sito principale.

Quando configuriamo i nostri client di posta elettronica, possiamo impostare l'indirizzo "Da:" predefinito, spesso totalmente estraneo al server di posta vero e proprio.

In altre parole, l'indirizzo "da" definito non ha assolutamente nulla a che fare con la macchina che esegue l'invio effettivo.

Anche se oggigiorno nel caso di " punteggio a livello di spam "è rischioso utilizzare (LATO SERVER)" in modo programmatico "da indirizzi non del dominio / macchina di origine dovremmo prendere l'indirizzo" Da: "semplicemente non hing più di un identificatore per il consumo umano.