Le e-mail di BCCing sono garantite come affidabili?


29

In altre parole, è un presupposto sicuro che nessuno dei destinatari vedrà mai le e-mail in BCC? Cosa succede se il destinatario è un amministratore del suo server di posta (ma non del mittente) e può apportare modifiche al suo server?


15
Generalmente la posta elettronica non è sicura e non affidabile. Se il destinatario è un amministratore del suo server, allora può farci praticamente qualsiasi cosa.
Lord Peter,

Per quello che vale ho un problema con questo bancomat. stackoverflow.com/questions/31527974/...
johnsnails

Risposte:


21

No. SMTP è un protocollo in chiaro , che utilizza metodi store-and-forward .

Cosa significa:

  • Testo normale: ogni server che inoltra questo messaggio lo vede nella sua interezza, comprese tutte le informazioni di intestazione. Sebbene ogni destinatario nel campo BCC riceva in genere la propria e-mail (quindi il server invia un'e-mail personalizzata in cui tutti gli altri destinatari BCC dovrebbero essere rimossi (enfasi su dovrebbe !), Al contrario di CC, dove i dati viene mantenuto), che una singola e-mail è ancora memorizzata nelle intestazioni, in testo normale (nessuna crittografia, nessuna offuscamento, niente).
  • Store-and-forward: l'e-mail non necessariamente va direttamente al server di posta del destinatario direttamente, ma potrebbe (e di solito viene) inoltrata su una serie di server di posta elettronica intermedi; viene memorizzato su ciascuno (per un periodo di tempo indefinito) e quindi inoltrato all'hop successivo (di nuovo, non necessariamente alla destinazione finale).
  • considerare che l'e-mail viene inviata a un indirizzo inesistente, completo, bloccato o altrimenti non funzionale: la copia della posta, insieme ai dati diagnostici, può finire in più posizioni, non tutte necessariamente cassette postali ( ad es. registri errori o casella postale postmaster )
  • (questo prima che la tua e-mail finisca nei server di posta della destinazione, che potrebbe conservarla per sempre e prontamente consegnarla a chiunque si presenti con una citazione, ma questa è una storia leggermente diversa)

In altre parole, il tuo presupposto non è sicuro. Se si desidera la privacy e la sicurezza, utilizzare firme digitali e crittografia, ad esempio GPG; e-mail vaniglia è uno strumento sbagliato per tale lavoro.


1
In che modo la crittografia risolve il problema di nascondere i destinatari?
detly

Non lo fa, ma Piskvor non parlava necessariamente delle caselle di posta del destinatario del messaggio quando faceva riferimento alla privacy, ma solo dei contenuti. AFAIK, in genere non è possibile nascondere i destinatari di un'e-mail a meno che non possa essere inoltrata tramite proxy senza registrazione. Se il tuo messaggio è così segreto che devi mascherare i destinatari e i contenuti, devi trovare un altro meccanismo di comunicazione.
Afrazier,

2
Ero con Piskvor fino all'ultima frase. Se tutto ciò che vuoi fare è nascondere i destinatari l'uno dall'altro, hai solo bisogno di un client di posta che possa inviare tutti i CCN singolarmente.
Steve Bennett,

@afrazier: Se non avessi già aggiunto una risposta concorrente, avrei annullato il voto a questa per non aver risposto alla domanda del PO.
Blrfl,

1
I destinatari di CCN non vengono registrati nell'intestazione dell'email (ad eccezione degli MTA molto vecchi e non funzionanti). Un server di posta standard non guarda nemmeno l'intestazione, usa solo la busta per decidere dove vanno le e-mail.
Adrian Pronk,

13

Qualsiasi agente di trasferimento di posta (MTA) che sia pienamente conforme a RFC 2822 (in particolare, sezione 3.6.3, Campi dell'indirizzo di destinazione ) rimuoverà il Bcc:campo dall'intestazione prima di tentare la consegna, rendendo impossibile per i destinatari non ciechi determinare i destinatari non vedenti 'identità.

Ci sono un paio di catture:

  • A meno che non si abbia il controllo del primo MTA raggiunto dalle e-mail in uscita, non è possibile garantire che il software su tale MTA eseguirà le istruzioni di RFC 2822.

  • Il fatto che un'e-mail inviata da te a un destinatario che potrebbe essere stato copiato in cieco abbia attraversato uno o più MTA potrebbe sopravvivere nei registri di tali MTA.


1
Ottima risposta specificatamente rivolta a "nessuno dei destinatari vedrà mai e-mail [indirizzi] in BCC". Puoi testare cosa fa il tuo primo MTA con le intestazioni BCC inviando e-mail a un bot di risposta e-mail che restituisce le intestazioni della tua e-mail.
sabre23t

L'MTA non dovrebbe nemmeno vedere l' Bcc:intestazione; invece, il MUA (programma client di posta) dovrebbe specificare tutti gli indirizzi nella busta SMTP ( MAIL FROM).
Grawity

Questo trucco non funzionerà in tutti i casi perché gli standard non richiedono che la consegna attraversi qualcosa che può essere assegnato a un indirizzo del destinatario al di fuori delle intestazioni. MTP non esisteva fino a sei anni dopo la definizione del comportamento BCC (RFC 680, nel 1975); SMTP è arrivato un anno dopo.
Blrfl,

5

Non si deve mai presumere che i destinatari non vengano a conoscenza del destinatario del CCN. Ho ricevuto destinatari di BCCed "Rispondi a tutti" nel loro programma di posta elettronica e ho annunciato a tutti la ricezione di una mail in precedenza, in una straordinaria mancanza di comprensione del significato reale di BCCed. Se hai davvero bisogno che sia privato, inoltra il messaggio dalla cartella Inviati dopo averlo inviato ai destinatari originali, quindi l'unico altro indirizzo nelle intestazioni dei messaggi è tuo.

Detto questo, anche se hai usato BCC, fintanto che il server del destinatario BCCed è separato dal destinatario originale, il server del destinatario non avrebbe accesso alle informazioni BCC, in quanto sarebbe stato eliminato (o più probabilmente mai incluso nel corpo del messaggio) dal server di posta del provider.

Una nota a margine : SMTP non è né affidabile, né particolarmente privato. Alcuni manifesti affermano che esistono "catene" di server SMTP, ma in generale, SMTP invia dal tuo computer, al tuo ISP, all'ISP del destinatario. (e per quanto molti server abbiano internamente) In generale, la tua posta NON verrà inoltrata al server di posta di terze parti, e in effetti tali tentativi sono generalmente vietati per motivi anti-spam. (Ci sono eccezioni, poiché i piccoli fornitori e le reti domestiche inoltreranno al loro fornitore, ma questa è l'eccezione non la regola)

Detto questo, non è garantito che la posta elettronica in transito sia crittografata e qualsiasi cosa potenzialmente sensibile non dovrebbe essere considerata affidabile non crittografata su Internet tramite QUALSIASI metodo, inclusa la posta elettronica, poiché è banale per qualsiasi grande fornitore, o telco toccare le fibre che attraversano le loro strutture o pacchetti di log che viaggiano attraverso i loro router.

L'FBI lo fa regolarmente attraverso il Carnivoro e altri programmi, e in passato sono stati documentati elementi canaglia.


1
I've had BCCed recipients hit "Reply All" in their mail program Questo non mi è mai successo, ma l'ho visto accadere numerose volte. Il tuo consiglio (non Ccn, ma inoltra dopo l'invio) è esattamente quello che faccio anch'io. Odio sembrare un coglione arrogante, ma a volte devi proteggere le persone da se stesse.
Dan7119,

@ Dan7119 Fammi indovinare .. sei stato / anche tu sei stato un amministratore di sistema?
SplinterReality,

Bella risposta. Anche se lo stripping delle informazioni BCC è affidabile al 100%, il fattore umano BCCed recipients hit "Reply All"non è garantito affidabile. Concordo con forward the message from your Sent foldersoprattutto per esperti di non-tech BCCed destinatari, come amministratori delegati.
sabre23t

1

Il tuo client di posta elettronica o server (non so quale) dovrebbe eliminare le informazioni BCC prima di inviare un messaggio. Se ti iscrivi a un messaggio e poi visualizzi la fonte, non dovresti trovare il tuo indirizzo e-mail da nessuna parte tranne nella riga Da (verificato questo con la mia posta).


Grazie. Ma la mia domanda è in realtà più profonda e riguarda l'affidabilità e la sicurezza. Non come dovrebbe essere in teoria.
qwerty,

Bene, per quanto ne so, il modo per vedere se la teoria corrisponde alla pratica è quello di fare il BCC su una e-mail, visualizzare la fonte e vedere se l'indirizzo del BCC è presente.
zpletan,

Il tuo client di posta elettronica non elimina le informazioni BCC. Non ha alcun senso.
Steve Bennett,

1

Tutto dipende dal server. La maggior parte dei server prenderà la linea BCC e sostanzialmente invierà il messaggio una volta per indirizzo. fondamentalmente inserendo l'indirizzo ccn in cc line send, il prossimo indirizzo in cc line e send type thing. Ma tutto dipende dalla configurazione del server MAIL. BCC non dovrebbe mai andare oltre il tuo server di posta in uscita.


7
Falso su tre punti. Innanzitutto, sono i MUA, non i server SMTP, a occuparsi delle Bcc:intestazioni. Quando le cose raggiungono un server SMTP, gli indirizzi dei destinatari si trovano nella busta del messaggio , non nelle intestazioni. In secondo luogo, solo i server di invio SMTP mai riscrivono tali intestazioni in primo luogo. In terzo luogo, i messaggi vengono sempre inviati una volta per destinatario della busta. Questo non è speciale o diverso.
JdeBP,

1

Tutto ciò che viaggia in rete senza firma digitale o crittografia può essere facilmente modificato. Se è necessaria l'integrità end-to-end per la posta elettronica, utilizzare la firma PGP / GPG.

Inoltre dovrai trasferire la tua chiave pubblica PGP / GPG ai destinatari in qualche modo (in modo che possano verificare che i tuoi messaggi e-mail siano davvero tuoi). Il suo tipo di problema con galline e uova: serve per stabilire un canale di comunicazione sicuro, ma richiede già un canale di comunicazione sicuro. L'invio tramite e-mail è corretto, ma è necessario verificare l'impronta digitale della chiave PGP / GPG per telefono o con altri mezzi. Anche pubblicarlo su un sito Web abilitato per https è una buona idea, poiché SSL fornisce le necessarie garanzie di integrità del trasporto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.