È una buona idea autorizzare la posta in arrivo usando un hash sull'indirizzo? (Simile a BATV, ma con DKIM)

Question

È una buona idea autorizzare la posta in arrivo usando un hash sull'indirizzo? (Simile a BATV, ma con DKIM)

#1 da (2 voti)
#2 da (1 voti)

3

Dichiarazione del problema

Sto cercando dei modi per garantire che i business partner o le e-mail di mittenti attendibili non vengano mai messi in quarantena; .... in altre parole impedisce " ham essere visto come spam". Idealmente questo garantirebbe la consegna anche se il mittente è stato contrassegnato come spammer ( ... vedi blackhole list ).

Poiché la maggior parte della posta elettronica passa attraverso provider di posta elettronica multi-tenant / condivisi che condividono lo stesso spazio IP, è probabile che la reputazione di molte aziende diverse si stiano influenzando a vicenda nel bene e nel male. Cioè, gli spammer possono trarre vantaggio dall'essere co-locati in "buoni" inquilini, e al contrario i "buoni" inquilini possono essere inseriti nella lista nera se lo spammer ottiene lo spazio IP elencato.

Le attuali soluzioni di whitelist di posta elettronica richiedono un'azione speciale da parte del destinatario e tale database deve essere gestito su un MTA. Ma ci sono molti casi in cui questo non è fattibile o la soluzione giusta, come quando è offline, in una fiera o ovunque un destinatario vuole garantire la consegna di un messaggio inviato senza accedere a un portale web o aggiornare le impostazioni della posta indesiderata di Outlook .

Design proposto

Se modifichiamo l'indirizzo email TO, ma anteponendo un valore speciale, un tale hash, ( simile a come funziona BATV ), il motore MTA / SPAM potrebbe ignorare il messaggio e accettarlo così com'è. Ecco come appare un messaggio:

// The sig below will only guarantee delivery 
// for a sender of [email protected]
// to the account [email protected]
[email protected] 

// The sig below will only guarantee delivery 
// for a sender of [email protected]
// to the account [email protected]
[email protected]

L'hash (definito come HMAC) trust sarebbe il primo 80 bit dalla funzione:

(SHA256(Key + Lowercase From + Lowercase To))

Quando l'MTA ricevente riceve il messaggio con l'indirizzo speciale, sarà in grado di convalidare rapidamente l'HMAC ed evitare qualsiasi greylisting o altre tecniche anti-spam che potrebbero essere applicate.

Supponendo che a ciascun utente sia assegnato il sale per la propria capacità di distribuire gli hash e una copia di ciascun hash è disponibile per il MTA a scopo di verifica.

Rendendolo sicuro / privo di spoofagi

Dal momento che chiunque potrebbe ipoteticamente interpretare la tupla di "FROM" e "TO" sopra, penso che sia un buon dado combinare questa caratteristica con misure anti-spoofing come DKIM o SPF, che è meglio definire nel DMARC standard

Utilizzo

Per la whitelist offline di persona,

Questa idea è più adatta per i momenti in cui incontri qualcuno a una conferenza commerciale, un bar o desideri assicurarti di ricevere messaggi da quella persona. Non vuoi che nessuna soluzione Anti Spam impedisca loro di ricevere la tua email. Dovresti inserire il loro indirizzo email nel tuo generatore per creare il seguente indirizzo [email protected]

Questoprocessoinduefasiperlagenerazionedell'indirizzopotrebbeessereautomatizzatoinunavarietàdiapplicazionicomeFacebook,LinkedIno Bump per iPhone.

Per la whitelist email online

Oltre all'impostazione dell'intestazione Reply-To: , il MUA (client di posta elettronica) potrebbe inserire un'intestazione X speciale

X-WhitelistReplyAddress = [email protected]

Domanda

L'obiettivo del "quadro generale" di questa idea è ragionevole? (whitelist offline, consegna garantita dagli MTA, spostamento della posizione della whitelist dal server di posta centralizzato ai mittenti effettivi)
Esiste una RFC proposta simile e esistente che le whitelist di cui il mittente e il destinatario attendibili fanno coppia per la posta elettronica?
Quali altre tecniche esistono per inserire nella whitelist coppie mittente-destinatario nell'email?
Quali componenti crittografici sono appropriati per questa soluzione? L'hashing è la strada giusta da percorrere?

email cloud-computing spam whitelist multi-tenancy

posta random65537 21.08.2013 - 19:26

fonte

2 risposte

1

L'hashing non è lo strumento crittografico giusto; quello che vuoi è un MAC .

Il tuo punto è che vuoi che alcune e-mail passino attraverso i filtri antispam, ma dal momento che non vuoi che gli spammer utilizzino lo stesso percorso (ovviamente), sei pronto a far valere l'uso di un campo aggiuntivo nell'email, che sarebbe contenere un valore di autenticazione che, si spera, gli spammer non possano falsificare. Per semplificare, codifica quel campo in più nell'indirizzo email del destinatario, perché quello è un campo che il mittente compila in ogni caso. Questo richiede un MAC e questo è quello che stai cercando di usare nella tua formula:

SHA256(Salt + Lowercase From + Lowercase To)

Chiama "Salt" un tasto e hai un MAC homebrew (uno scarso, in realtà), che potrebbe essere sostituito con HMAC .

Devi occuparti di dove si trova la chiave. La chiave viene utilizzata per generare il token (l'indirizzo "A:", se si preferisce vederlo in questo modo), e anche per verificare tali token. Uno spammer vorrebbe davvero mettere le mani su una chiave del genere, perché gli permetterebbe di inviare spam che sfuggono ai filtri antispam. Ma la chiave deve essere ospitata su alcuni sistemi online (sia nell'app che genera il token, sia nel server MTA che verifica le e-mail in arrivo), che raramente è una buona cosa per la riservatezza a lungo termine. Inoltre, la chiave non può essere facilmente modificata poiché potrebbe interrompere gli indirizzi email pubblicati in precedenza.

Questo sistema non farà altro che fintanto che puoi educare i mittenti a usare uno strumento personalizzato per calcolare il token (da integrare nell'indirizzo "A:"), e convincerli a digitare effettivamente quel brutto aspetto indirizzo (le persone raramente si dilettano nella gloria dell'esadecimale). Allo stesso tempo, non devi rendere il sistema troppo automatico, perché altrimenti gli spammer si adatteranno e lo useranno, vanificando lo scopo. Il giusto equilibrio è spesso difficile da colpire, in particolare perché un potenziale cliente in una fiera mostra spesso meno energia cerebrale rispetto allo spammer medio.

Inoltre, a molti amministratori di sistema non piacerà affatto: un sistema pensato per evitare i filtri antispam è anche un sistema che permetterà agli utenti di inviare file eseguibili l'uno all'altro - si temerà una festa dei virus.

Per riassumere, non vedo il sistema come realmente pratico. Creerà più problemi di usabilità di quanto non risolva.

risposta data 21.08.2013 - 20:29

fonte

Leggi altre domande sui tag email cloud-computing spam whitelist multi-tenancy

Come si propagano i virus del settore di avvio? Perché il nostro firewall di rete rilascia pacchetti netbios-ns?

score 2 · Accepted Answer

Molti sistemi supportano l'uso di alias con un carattere come + . Pertanto, [email protected] equivale a [email protected] per MDA (ad esempio, finirebbero nella stessa casella di posta).

Quindi, mantieni un elenco di token autorizzati (magari abbinati all'intestazione From da utilizzare): [email protected] [email protected] [email protected] [email protected]

Se qualcuno ti invia un'email a un indirizzo nel tuo elenco, diventa nella lista nera. Se non lo è, viene automaticamente considerato come spam (per evitare di indovinare i token). Ovviamente, se un buon token viene compromesso, lo sostituisci;)

La whitelist non ha bisogno di essere archiviata nel MTA, il filtraggio può essere fatto localmente. Per gli usi offline, puoi creare in anticipo un gruppo di token whitelist. O addirittura inventati al volo fintanto che aggiorni la whitelist controllata dal filtro prima che elabori quella nuova posta.

Questo è esistito da un po 'di tempo, non ricordo quando lo feci per primo. La parte migliore è che funziona oggi , senza dover istruire i MUA su una nuova intestazione X-WhitelistReplyAddress .

Una grande differenza con i tuoi destinatari - l'hashing è che nella tua soluzione c'è una singola chiave da cui derivano i token, mentre qui sono generati token generati casualmente che devi elencare (sebbene tu possa sostituire il search the token in the list con %codice%). Ma se un token whitelist basato su hash viene compromesso, non puoi rimuoverlo senza rekeying token di tutti, mentre nell'altro approccio puoi facilmente sostituire un singolo token (inoltre, se tieni un registro delle entità che hai dato alla tua email, tu può trovare chi ha fatto trapelare / vendere il tuo indirizzo email)