<ul><ul><li>Un   approccio  per il  </li></ul></ul><ul><ul><li>mail filtering </li></ul></ul><ul><ul><li>scalabile, ridond...
La problematica: <ul><li>i mail server invecchiano: difficoltà di gestione </li></ul><ul><li>possono non esserci possibili...
Migrare costa... <ul><li>necessità di competenze sull'MTA di origine non sempre disponibili (legacy systems) </li></ul><ul...
... anche mantenere costa... <ul><li>Gestire MTA di tipo diverso vuol dire: </li></ul><ul><li>logiche operative diverse </...
...anche mantenere costa...  (segue) <ul><li>.. ma soprattutto vuol dire: </li></ul><ul><li>mantenere competenze su più so...
Una situazione esemplificativa <ul><li>Gestire MTA di tipo diverso vuol dire: </li></ul><ul><li>sistemi legacy </li></ul><...
Una situazione esemplificativa  (segue) <ul><li>usare Web di gestione (a cui i clienti accedono) diversi </li></ul><ul><li...
Il  carico  di un MTA <ul><li>Il  carico  è causato principalmente da: </li></ul><ul><li>entità delle regole di sanitizzaz...
Ne consegue che... <ul><li>I nostri MTA dedicano la maggior parte delle loro risorse in  attività estranee  alla consegna ...
... e quindi ... <ul><li>Si rischia di essere costretti a migrare un dominio in quanto lo SLA inizia a sembrare un  obiett...
I sintomi? <ul><li>tempi di greeting SMTP che crescono </li></ul><ul><li>code dei mailserver in crescita </li></ul><ul><li...
L'approccio proposto <ul><li>Approntare un SMTP  proxy  integrando </li></ul><ul><li>su di esso tutte le logiche di filter...
L'approccio proposto  (segue) <ul><li>Le features da considerare come minima sopravvivenza sicuramente contemplano: </li><...
L'approccio proposto  (segue) <ul><li>Queste features possono essere descritte a livello logico mappando i servizi su alme...
L'approccio proposto  (segue) <ul><li>Il main host deve: </li></ul><ul><li>ricevere le mail </li></ul><ul><li>ospitare par...
L'approccio proposto  (segue) <ul><li>Il worker host deve: </li></ul><ul><li>avere modulo server per ogni antivirus – anti...
Gli obiettivi <ul><li>alta disponibilità  </li></ul><ul><ul><li>heartbeating </li></ul></ul><ul><ul><li>utilizzo di virtua...
Lo scenario cambia... <ul><li>MTA di destinazione: solo mail delivery </li></ul><ul><li>base comune di protezione </li></u...
... e di molto... <ul><li>è possibile far si che il main host verifichi i valid recipients su una base di dati comune </li...
Una vista d'insieme
Una vista d'insieme in cluster
Alcuni sviluppi <ul><li>introdurre delle logiche di greylisting sul main host </li></ul><ul><li>creare un'applicazione Web...
Alcuni sviluppi  (segue) <ul><li>firma del corpo della mail  (sigtool?) </li></ul><ul><li>supporto per poter riutilizzare ...
Arrivederci e  grazie  per la cortese attenzione! Simone Marzona   ha conseguito la  laurea in informatica e da alcuni ann...
Licenza d'uso di questo documento <ul><ul><li>Quest'opera è stata rilasciata sotto la licenza Creative Commons Attribuzion...
Upcoming SlideShare
Loading in …5
×

Un approccio scalabile e robusto per il mail filtering. - Simone Marzona

1,270 views
1,212 views

Published on

Questo intervento presenta un approccio al problema del filtraggio dei contenuti delle email che consente di poter scalare verso alti volumi di traffico, di avere una soluzione altamente affidabile sulla quale puntare per poter sgravare i mailserver da tutte le funzionalità relative al filtraggio delle email, rendendo disponibili tutte le risorse per la gestione vera e propria delle mail.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,270
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • In questo incontro si presenta un approccio per affrontare il problema del mail filtering per grossi volumi di traffico. Un approccio perché : vi sono molte alternative, come sempre, per affrontare e cercare di risolvere il problema, questa è una delle tante non sono tutte open alcune richiedono hardware “custom” - appliances non tutte sono applicabili a tutti gli scenari non nego che possano esistere scenari in cui nessuna proposta rappresenti una “soluzione” accettabile Quanto proposto non descrive un prodotto Off the Shelf, piuttosto una logica grazie alla quale è possibile ottenere dei risultati di sicuro interesse. Nello sviluppo di questa logica mi sono fermato nel momento in cui ho ottenuto un prototipo funzionante e ho identificato alcune migliorie da apportare e alcuni sviluppi futuri.
  • Un approccio scalabile e robusto per il mail filtering. - Simone Marzona

    1. 1. <ul><ul><li>Un approccio per il </li></ul></ul><ul><ul><li>mail filtering </li></ul></ul><ul><ul><li>scalabile, ridondato, open... </li></ul></ul><ul><ul><li>Simone Marzona </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>
    2. 2. La problematica: <ul><li>i mail server invecchiano: difficoltà di gestione </li></ul><ul><li>possono non esserci possibilità di aggiornamento </li></ul><ul><li>possono essere basati su piattaforme non più supportate </li></ul><ul><li>aggiornamenti disponibili ma estesi </li></ul>
    3. 3. Migrare costa... <ul><li>necessità di competenze sull'MTA di origine non sempre disponibili (legacy systems) </li></ul><ul><li>reinterpretazione di logiche di aliasing, forwarding, gestione di quota, acl ed altro </li></ul><ul><li>la virtualizzazione attrae ma consente di svecchiare solo l'hardware. </li></ul>
    4. 4. ... anche mantenere costa... <ul><li>Gestire MTA di tipo diverso vuol dire: </li></ul><ul><li>logiche operative diverse </li></ul><ul><li>logiche di gestione diverse </li></ul><ul><li>possibilità di integrazione e configurazione diverse </li></ul>
    5. 5. ...anche mantenere costa... (segue) <ul><li>.. ma soprattutto vuol dire: </li></ul><ul><li>mantenere competenze su più software critici </li></ul><ul><li>mantenere interfacce di gestione diverse </li></ul><ul><li>difficoltà nel far si che MTA diversi diano un servizio omogeneo </li></ul><ul><li>un alto rischio di errori </li></ul>
    6. 6. Una situazione esemplificativa <ul><li>Gestire MTA di tipo diverso vuol dire: </li></ul><ul><li>sistemi legacy </li></ul><ul><li>installazioni non pienamente standard </li></ul>
    7. 7. Una situazione esemplificativa (segue) <ul><li>usare Web di gestione (a cui i clienti accedono) diversi </li></ul><ul><li>operazioni multiple di configurazione </li></ul><ul><li>il numero dei server tende ad aumentare in modo non facilmente controllabile. </li></ul>
    8. 8. Il carico di un MTA <ul><li>Il carico è causato principalmente da: </li></ul><ul><li>entità delle regole di sanitizzazione </li></ul><ul><li>dimensione allegati e messaggi – presenza html </li></ul><ul><li>prestazioni e disponibilità dei dns </li></ul><ul><li>tipo di scansione degli allegati compressi </li></ul><ul><li>altri parametri meno importanti </li></ul>
    9. 9. Ne consegue che... <ul><li>I nostri MTA dedicano la maggior parte delle loro risorse in attività estranee alla consegna delle mail. </li></ul><ul><li>Ragionando in questa ottica si ripropone il noto problema della verticalizzazione dei server . </li></ul><ul><li>É necessario scendere in dettaglio e separare le logiche di filter dalle logiche di deliver. </li></ul>
    10. 10. ... e quindi ... <ul><li>Si rischia di essere costretti a migrare un dominio in quanto lo SLA inizia a sembrare un obiettivo piuttosto che una base di partenza da mantenere e superare. </li></ul><ul><li>...con tutte le conseguenze del caso. </li></ul>
    11. 11. I sintomi? <ul><li>tempi di greeting SMTP che crescono </li></ul><ul><li>code dei mailserver in crescita </li></ul><ul><li>ritardi riscontrabili anche dagli utenti nel deliver </li></ul><ul><li>le webmail ospitate sugli MTA iniziano a perdere di smalto </li></ul><ul><li>prestazioni altalenanti condizionate troppo dal flusso di mail, fenomeno non controllabile </li></ul>
    12. 12. L'approccio proposto <ul><li>Approntare un SMTP proxy integrando </li></ul><ul><li>su di esso tutte le logiche di filtering. </li></ul><ul><li>L'SMTP proxy riceve le mail, </li></ul><ul><li>le filtra e </li></ul><ul><li>le inoltra all'SMTP di pertinenza </li></ul><ul><li>tramite routing SMTP. </li></ul>
    13. 13. L'approccio proposto (segue) <ul><li>Le features da considerare come minima sopravvivenza sicuramente contemplano: </li></ul><ul><li>antivirus multiplo </li></ul><ul><li>antispam multiplo </li></ul><ul><li>sanitizing della mail </li></ul><ul><li>configurazione su base di dominio </li></ul><ul><li>ridondanza e scalabilità </li></ul><ul><li>possibilità di configurazione in cluster </li></ul>
    14. 14. L'approccio proposto (segue) <ul><li>Queste features possono essere descritte a livello logico mappando i servizi su almeno due tipi di host: </li></ul><ul><li>main host </li></ul><ul><li>work host </li></ul>
    15. 15. L'approccio proposto (segue) <ul><li>Il main host deve: </li></ul><ul><li>ricevere le mail </li></ul><ul><li>ospitare parte della logica di filtro </li></ul><ul><li>interrogare gli antivirus e gli antispam tramite un balancer </li></ul><ul><li>interrogare un dnscache </li></ul><ul><li>gestire una logica di heartbeating </li></ul><ul><li>inoltrare le mail filtrate verso l'MTA di pertinenza. </li></ul>
    16. 16. L'approccio proposto (segue) <ul><li>Il worker host deve: </li></ul><ul><li>avere modulo server per ogni antivirus – antispam </li></ul><ul><li>ricevere le connessioni da parte del main host </li></ul><ul><li>elaborare lo stream ricevuto </li></ul><ul><li>fornire l'esito della scansione al main host </li></ul>
    17. 17. Gli obiettivi <ul><li>alta disponibilità </li></ul><ul><ul><li>heartbeating </li></ul></ul><ul><ul><li>utilizzo di virtual machines </li></ul></ul><ul><li>scalabilità </li></ul><ul><ul><li>allocazione dinamica dei worker hosts </li></ul></ul><ul><ul><li>aggiunta e rimozione a caldo dei worker hosts </li></ul></ul><ul><ul><li>live migration – vmotion - altro </li></ul></ul>
    18. 18. Lo scenario cambia... <ul><li>MTA di destinazione: solo mail delivery </li></ul><ul><li>base comune di protezione </li></ul><ul><li>operazioni di configurazione contenute e circoscritte </li></ul><ul><li>integrazione: basta agire sui DNS </li></ul>
    19. 19. ... e di molto... <ul><li>è possibile far si che il main host verifichi i valid recipients su una base di dati comune </li></ul><ul><li>è ipotizzabile far si che gli MTA di destinazione accettino connessioni solo dal main host </li></ul><ul><li>è ipotizzabile sfruttare il main host per verificare la mail in uscita </li></ul>
    20. 20. Una vista d'insieme
    21. 21. Una vista d'insieme in cluster
    22. 22. Alcuni sviluppi <ul><li>introdurre delle logiche di greylisting sul main host </li></ul><ul><li>creare un'applicazione Web di gestione completo di tutte le policy disponibili </li></ul><ul><li>creare un pannello di amministrazione multi livello per gruppi di domini </li></ul><ul><li>ampliare il numero di antivirus - antispam supportati </li></ul>
    23. 23. Alcuni sviluppi (segue) <ul><li>firma del corpo della mail (sigtool?) </li></ul><ul><li>supporto per poter riutilizzare i work host anche per filtrare contenuti non limitati alla mail (upload di contenuti..). </li></ul>
    24. 24. Arrivederci e grazie per la cortese attenzione! Simone Marzona ha conseguito la laurea in informatica e da alcuni anni si occupa di problematiche di network management, system management, e system virtualization . [email_address]
    25. 25. Licenza d'uso di questo documento <ul><ul><li>Quest'opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Condividi allo stesso modo 2.5. Per leggere una copia della licenza visita il sito Web http://creativecommons.org/licenses/publicdomain/ o spedisci una lettera a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. </li></ul></ul>

    ×