On 14/01/14 13:34, Marco Ermini wrote: >> "Junk Mail is war. RFCs do not apply." (cit) >> >> Wietse Venema :-)
Hai vinto una birra, ma non so quando mai saremo nello stesso posto e pagarla. Poteva essere un piccolo stimolo a restare dov'eri, ma tanto immagino che da quelle parti le occasioni da birra non manchino comunque... :-) > Ho letto prima un'opiione (Tullio Andreatta) circa l'inutilit? di SPF. > Tendo in generale a essere d'accordo con quanto ? stato scritto in quel > messaggio. Tuttavia non sono molto d'accordo circa l'inutilit? di SPF - se > ovviamente accompagnato a DMARC, DKIM e tutto il resto. > > Vorrei sapere cosa ne pensate in generale sull'efficacia di queste > tecniche. So che i grossi "player" ci puntano, ma in generale mi sembrano > di una complessit? notevole - tant'? che dove lavoravo prima erano > praticamente impossibile da implementare (organizzazione troppo grande e > troppe persone da convincere, e quando la questione diventa cos? > complessa...). Sono tecnologie che hanno un loro ruolo ben preciso e di ampio utilizzo liddove si tratti di piattaforme di mail marketing o di messaggistica transazionale. Ma da sole non forniscono alcuna metrica relativa alla reputazione del mittente: tutto quello che ti possono dire è che il mittente non è forgiato. Che poi sia spam o meno, nulla dicono. Nè è il loro ruolo. Sono pertanto complementari a meccanismi di reputation: se i miei meccanismi di reputazione mi dicono che paypal.com è 100% good, e la mail soddisfa DKIM/DMARC posso permettermi di bypassare in toto gran parte degli altri filtri - dato che so di potermi fidare del mittente - riducendo il rischio di falsi positivi. Ma solo perché "so" chi è paypal e che va trattata di conseguenza, non per DKIM in sè... Per una azienda X anche grossa, dove la tipologia di mail in uscita è varia (mail generate da automatismi vari, mail "normali" inviate dai dipendenti, mail marketing fatto in maniera più o meno approssimativa dal commerciale di turno), l'utilità è opinabile, a meno di non essere disposti a segmentare le componenti del flusso postale che potrebbero trarne un vantaggio[1]. C'è poi il problema che DKIM e DMARC hanno un ampio utilizzo lato ricevente da parte di operatori con una competenza ben radicata nel settore email (i grossi fornitori di sistemi/servizi di filtraggio e i gorilla del settore freemail come Google, Hotmail, Yahoo, etc.) ma la loro diffusione in ambito più ristretto (mailserver aziendali e dintorni) è sempre rimasta piuttosto limitata. In parte per complessità intrinseca, in parte perchè se non sai che farci (leggasi: non hai o non capisci i meccanismi di reputation cui agganciarli) te ne fai poco. In soldoni, se * sei grosso e conosciuto * invii comunicazioni di carattere informativo/commerciale/transazionale * i riceventi hanno interesse a trattare in modo privilegiato tali comunicazioni (il che significa anche che sono "100% clean") * hai uno o più domini che dedichi a questa sola finalità [1] allora DKIM (e/o DMARC, soprattutto nel caso di invii transazionali) sono circa un must, attualmente. Per domini "generici", aggiungono poco o nulla. > Altra domanda: in generale osservo che molte organizzazioni cercano la > "magic box" (o adesso la "magic cloud") a cui delegare i problemi. Non ho > visto fin'ora alcuna "killer app" contro lo spam e gli utenti di pi? o meno > tutte queste "magic box" o "magic cloud" si lamentano per lo spam. La mia > impressione ? che sia una battaglia pi? complessa di quello che il CTO > medio possa comprendere, e che ciascuna azienda/situazione ha bisogno di > una certa customizzazione - come diceva Emanuele Balla giustamente, > *qualcuno* deve decidere cosa ti puoi permettere di "perdere" quando filtri > le email, ed ? piuttosto difficile tradurre quello che il CTO *pensa* (e > chiss? poi cosa ha capito) con un filtro Postfix/qmail... Soprattutto c'è un problema di differenti visioni e visibilità: il fatto che quello che è spam per A non è necessariamente spam per B; sicchè se sia a che B si servono dello stesso oggetto/servizio, uno dei due inevitabilmente ottiene il contrario di quello che desidera. Per una infinità di ragioni che richiederebbero un thread a sè (e per il quale non sono certo questa sia la lista adatta), ma è tuttavia un dato di fatto. Aggiungici che lo spam è una lotta tra parti, per cui se da un lato ci sono gestori/creatori di filtri dall'altro c'è chi fa di tutto per evadere gli stessi, il che rende l'approccio "fire and forget" del tutto inapplicabile: qualcuno le cose le deve gestire e chi riceve deve mettersi in testa che il filtro applicato (quale che sia la soluzione scelta) non funziona per magia (FUSSP!) ma per la competenza di qualcuno, che necessita anche di feedback, sia positivo che negativo. Il succo, comunque, è che la "magic box", non esiste e probabilmente non può esistere. E' un pippone, ma te la sei cercata :-P E non è nemmeno finito... [1] Il fatto è che in particolare per DKIM (e di conseguenza DMARC) la reputazione che ha senso considerare sarebbe quella del signer e non tanto del mittente. Ma non ci sono attualmente in circolazione meccanismi di reputation "pubblici" basati su questa. Qualcuno ci ha provato, ma il mercato non ha manifestato alcun interesse e l'implementazione è andata sostanzialmente morendo. Sicchè a meno che il ricevente non sia sufficientemente grosso da permettersi di implementare meccanismi di reputation interni (Google, etc), di fatto le uniche sorgenti di reputazione da poter agganciare a DKIM sono quelle che si basa sul dominio in quanto tale, e derivano pertanto dalla somma di tutti gli utilizzi cui il dominio stesso è soggetto. Per tale ragione, se si usa DKIM/DMARC su -diciamo- delle mail transazionali, è preferibile farlo su un dominio dedicato allo scopo, in modo da eliminare le "sorgenti di rumore" (mail "normali", etc) che possano ostacolare l'acquisizione di una reputazione coerente per lo stesso. La qual cosa, però, può potenzialmente avere ricadute sul piano del brand e della riconoscibilità aziendale (o il management può pensare che lo abbia), il che porta la complessità delle valutazioni ad esplodere ^_^ ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
