Sender Policy Framework: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Inserimento Note |
m Refusi |
||
(4 versioni intermedie di 4 utenti non mostrate) | |||
Riga 1:
Il '''Sender Policy Framework''' ('''SPF''') è uno standard di [[autenticazione]] email progettato per prevenire la falsificazione degli indirizzi [[Posta elettronica|email]] durante l'invio di messaggi.
▲Il '''Sender Policy Framework''' ('''SPF''') è uno standard di [[autenticazione]] email progettato per prevenire la falsificazione degli indirizzi [[Posta elettronica|email]] durante l'invio di messaggi.
Lo scopo principale dello SPF è fornire un meccanismo per verificare l'autenticità dell'origine di un'email, contribuendo così a combattere lo [[spam]] e il [[phishing]], inoltre lo SPF consente ai proprietari di domini di specificare, attraverso un record pubblicato nel DNS del loro dominio, quali [[server]] sono autorizzati a inviare email a nome del loro dominio.
Questo riduce significativamente il rischio di email contraffatte. Quando un server di posta
L'SPF supporta inoltre istruzioni di controllo come "SOFTFAIL" (ammesso con avvertimento) o "FAIL" (rifiutato), che determinano come gestire le email in base alla corrispondenza tra l'indirizzo IP del mittente e il record SPF. Sebbene SPF sia uno strumento utile per ridurre la falsificazione degli indirizzi email, è spesso utilizzato in combinazione con altri metodi di autenticazione, come [[DomainKeys Identified Mail]] (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Funzionamento: Verifica: Controlla se l'email supera i test SPF e DKIM. Allineamento: Verifica la corrispondenza dei domini. Politica: Se non supera i controlli, si riferisce alla politica DMARC per decidere come gestire l'email (quarantena o rifiuto). Vantaggi: Protegge contro lo spoofing. Consente ai proprietari di domini di controllare la gestione delle email non autenticate. Fornisce report utili per monitorare tentativi di spoofing.In sintesi, DMARC migliora la sicurezza delle email e la reputazione dei domini.
== Storia ==
Il concetto alla base di SPF fu menzionato per la prima volta nel 2000,<ref>{{Cita web |url=http://www.openspf.org/History/Pre-SPF |titolo=SPF: First Public Mention 2000 |accesso=28 agosto 2014 |urlarchivio=https://web.archive.org/web/20150130122506/http://www.openspf.org/History/Pre-SPF |dataarchivio=30 gennaio 2015 |urlmorto=sì }}</ref> ma divenne realtà solo nel 2002, quando Dana Valerie Lank
Nel giugno del 2003, Meng Weng Wong unì le specifiche RMX e DMP
In origine, l'[[acronimo]] SPF doveva significare Sender Permitted From e a volte veniva anche chiamato SMTP+SPF; tuttavia, nel febbraio 2004 il suo nome venne cambiato nell'attuale Sender Policy Framework.
All'inizio del 2004, l'IETF creò il gruppo di lavoro MARID
== Principi di funzionamento ==
Il [[Simple Mail Transfer Protocol]] consente a ogni computer di inviare e-mail senza alcuna verifica del mittente: il messaggio può dichiarare di provenire da un qualsiasi indirizzo di origine. Questo aspetto facilita l'operato degli [[
Il Sender Policy Framework (SPF) consente al proprietario di un dominio di definire le regole per identificare i server autorizzati a inviare e-mail con un indirizzo del mittente appartenente a quel dominio, utilizzando opportuni [[record TXT]] del [[Domain Name System]] (DNS). I destinatari possono confrontare la provenienza del messaggio con le regole SPF e, in caso di incongruenze, decidere di rifiutare i messaggi in arrivo da origini non autorizzate prima ancora di ricevere il contenuto del messaggio. I principi di funzionamento sono quindi simili a quelli delle "DNS-based blackhole lists" ([[DNSBL]]), con l'eccezione che SPF utilizza il sistema di delegazione dell'autorità del Domain Name System. La prassi attuale richiede l'uso di record in formato TXT,<ref name="rfc7208-txt">{{cita web|titolo=Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |url=https://tools.ietf.org/html/rfc7208|autore=Scott Kitterman |anno=2014 |mese=aprile |editore=[[Internet Engineering Task Force|IETF]] |accesso=26 aprile 2014 }}</ref> proprio come nelle prime implementazioni. Nelle fasi iniziali della definizione, è stato registrato e reso disponibile un nuovo tipo di record (SPF, tipo 99), e l'uso dei record in formato [[.txt|TXT]] per SPF è stato proposto come meccanismo alternativo di compatibilità per i software DNS che non lo supportavano. L'RFC sperimentale <nowiki>RFC 4408</nowiki>
L'indirizzo del mittente viene inviato all'inizio della comunicazione [[Simple Mail Transfer Protocol|SMTP]], all'interno delle informazioni di consegna del messaggio, detto tecnicamente ''envelope.'' Se il [[mail server]] verifica che tale dominio non può provenire da quel client, può comunicare un messaggio di rifiuto, facendogli generare un ''bounce message'' detto “messaggio di rimbalzo” verso l'indirizzo del mittente originale. L'SPF non previene però la falsificazione dell'indirizzo del mittente indicato nel corpo del messaggio. Gli [[spammer]] possono quindi inviare e-mail che possono superare il controllo SPF, se hanno un account in un dominio con una sender policy valida oppure approfittare di un sistema compromesso. Tuttavia, fare ciò rende lo spam più difficile da identificare.
Riga 28 ⟶ 27:
Il principale vantaggio di SPF è che i possessori di indirizzi email utilizzati come mittenti falsificati non ricevono un numero elevato di messaggi di errore indesiderati e risposte automatiche. Quando i destinatari implementano SPF per specificare le fonti legittime dei loro messaggi, i ricevitori possono rifiutare immediatamente le email non autorizzate, riducendo così il fenomeno del [[Backscatter (posta elettronica)|backscatter.]]
L'SPF offre anche ulteriori benefici oltre all'identificazione delle email indesiderate. In particolare, se un mittente fornisce informazioni SPF valide, i ricevitori possono utilizzare risultati SPF positivi insieme a una whitelist per riconoscere i mittenti affidabili. Tuttavia, situazioni come sistemi compromessi o utenti che inviano email condivise possono limitare l'efficacia di questo approccio.
== Le ragioni dell'
Se un dominio pubblica un record SPF, è meno probabile che spammer e phisher riescano a inviare email fingendo che provengano da quel dominio, poiché le email falsificate vengono catturate con maggiore efficacia dai filtri antispam. Di conseguenza, un dominio protetto da SPF diventa meno attraente per [[spammer]] e [[Phishing|phisher]] come indirizzo ''spoofed'' (falsificato). Questo riduce la probabilità che l'indirizzo venga inserito in una blacklist dai filtri antispam e, di conseguenza, aumenta le possibilità che le email legittime vengano consegnate correttamente, evitando così falsi positivi nei filtri.
== FAIL e l'inoltro ==
Riga 37 ⟶ 36:
# Chi inoltra il messaggio non modifica il return-path (cammino di ritorno).
# L'hop
# L'hop esegue un controllo SPF.
Questa è una caratteristica necessaria e fondamentale di SPF: i controlli effettuati oltre il "confine" del Mail Transfer Agent ([[MX record|MX]]) del destinatario possono funzionare solo in modo diretto.Chi pubblica una policy SPF deve essere consapevole del rischio che le email legittime possano essere respinte se non conformi alla policy definita. Pertanto, è consigliabile effettuare dei test fino a ottenere risultati soddisfacenti.
== Test HELO ==
L{{'}}''
'''Esempio di Return-Path vuoto'''
Riga 52 ⟶ 51:
# '''Messaggio di errore:''' Poiché il Return-Path è vuoto, il server non sa dove inviare il messaggio di errore e quindi non ti informa della mancata consegna.
Questo controllo è importante per garantire che l'identità del server che invia il messaggio sia autentica.Se viene utilizzata un'identità HELO falsificata, il risultato del controllo SPF sarà "NONE", il che non fornisce alcuna protezione.
Tuttavia, se l'identità HELO è associata a nomi di host validi nel record SPF, allora il controllo può effettivamente proteggere l'identità HELO. Questa funzionalità è stata sempre supportata come opzione per i destinatari e le specifiche più recenti di SPF raccomandano di verificare sempre l'HELO.
Questa verifica consente ai destinatari di inserire determinati mittenti in una whitelist se il risultato del controllo HELO è "PASS", oppure di respingere tutte le email se il risultato è "FAIL". Inoltre, questo meccanismo può essere integrato in sistemi di reputazione, poiché sia le whitelist che le blacklist sono esempi di sistemi di reputazione. Questa versione mantiene i concetti originali ma li presenta in modo più diretto e comprensibile.
== Implementazione ==
Riga 62 ⟶ 61:
* '''Pubblicare una politica (policy)''': I domini e gli host specificano quali server possono inviare email a loro nome, assicurando che le comunicazioni siano riconosciute come legittime e provenienti da fonti autorizzate. Fanno ciò aggiungendo record addizionali alle loro informazioni DNS già esistenti: Ogni [[nome di dominio]] o host che possiede un record di tipo A (A record) o un record di tipo MX (MX record) è in grado di gestire la posta elettronica e dovrebbe avere anche un record SPF. Il record A serve a mappare un nome di dominio a un indirizzo IP, permettendo ai browser di localizzare il server web associato al dominio. D'altra parte, il record MX è fondamentale per l'instradamento delle email, poiché indica ai server di posta come e dove inviare i messaggi per quel dominio, garantendo così la corretta consegna delle email.
* '''Questo è particolarmente importante''' se il dominio viene utilizzato per inviare email o come parte dell'argomento HELO/EHLO durante la comunicazione con i server di posta. Il record SPF definisce quali server sono autorizzati a inviare email per quel dominio, contribuendo a prevenire la falsificazione dell'indirizzo del mittente.
* '''Record SPF per host non utilizzati per l'invio di email:''' Gli host che non inviano email dovrebbero pubblicare un record SPF che indichi qualcosa come "v=spf1 -all". Questa configurazione è altamente raccomandata per validare il record SPF tramite strumenti di testing disponibili sul sito del progetto SPF.
* '''Utilizzo delle informazioni SPF da parte dei destinatari:''' I destinatari delle email eseguono query DNS semplici e ordinarie, che sono spesso memorizzate nella cache per migliorare le prestazioni. Interpretano le informazioni SPF come specificato nel record e agiscono in base al risultato ottenuto.
Riga 71 ⟶ 69:
** '''Sender Rewriting Scheme (SRS)''': Utilizzare un meccanismo che modifica l'indirizzo del mittente per risolvere problemi legati ai reindirizzamenti<ref>{{Cita web|lingua=en|url=http://www.open-spf.org/SRS/|citazione=SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in draft-mengwong-sender-rewrite and further expanded on in a paper by Shevek.|accesso=27 ottobre 2022}}</ref>
Pertanto, la questione centrale nell'ambito dei record SPF riguarda le specifiche relative alle informazioni DNS che i set di domini e destinatari utilizzano. I record riportati di seguito sono formulati secondo la sintassi standard dei
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
Riga 80 ⟶ 78:
Sono definiti otto ''meccanismi'':
{|
| valign="top" | ALL || Lo standard di autenticazione email SPF verifica sempre gli indirizzi IP dei server di posta in uscita. Quando un indirizzo non corrisponde a nessuno dei criteri precedentemente definiti, osia alle regole e alle autorizzazioni specificate nel record SPF di un dominio, viene applicato il risultato di default, come ad esempio <kbd>-all</kbd>
|-
| valign="top" | A - AAAA || Se il nome di dominio ha un record di indirizzo (A per IPV4 o AAAA per IV6) che corrisponde all'indirizzo IP del mittente, l'email è considerata valida. In altre parole, il sistema verifica se il server che ha inviato l'email è autorizzato a farlo controllando le informazioni DNS del dominio.
Riga 106 ⟶ 104:
== Modificatori ==
I modificatori SPF sono progettati per consentire future estensioni al [[framework]]. Attualmente, solo due modificatori definiti nell'<nowiki>RFC 4408</nowiki>
* <code>exp=some.example.com</code>: Questo modificatore restituisce il nome di un dominio che contiene un record TXT nel DNS. Questo record viene interpretato utilizzando la macro parametrizzazione SPF fornendo una messaggio esplicativo per i risultati di tipo FAIL. Tipicamente, il record contiene un URL aggiunto al codice di errore SMTP per fornire ulteriori dettagli sul motivo del fallimento. Tuttavia, questa funzionalità è utilizzata raramente.
Riga 120 ⟶ 118:
Una tipica politica SPF potrebbe essere scritta come v=spf1 a -all. Questa configurazione può eseguire fino a tre richieste DNS: (1) una richiesta per il record TXT, (2) una richiesta per il record SPF (che è stato reso obsoleto dall'<nowiki>RFC 7208</nowiki>), e (3) una richiesta per i record A o AAAA. Quest'ultima richiesta conta come primo valore verso il limite di dieci. In questo esempio, è anche l'ultima richiesta, poiché ALL non richiede ulteriori ricerche DNS.
Come abbiamo già illustrato in precedenza la
== Controversie ==
Nel 2004, quando il ricercatore nel campo della sicurezza informatica Steven Michael Bellovin
* La SPF (Sender Policy Framework) originariamente utilizzava record TXT nel DNS, progettati per contenere testo in formato libero, senza una specifica semantica. I sostenitori dell' SPF riconobbero che sarebbe stato preferibile avere record appositamente dedicati, ma questa scelta fu fatta per consentire una rapida implementazione del protocollo. Nel luglio del 2005, La [[Internet Assigned Numbers Authority|IANA]] (Internet Assigned Numbers Authority) assegnò il Return Record di tipo 99 a SPF. Tuttavia, l'uso di record SPF dedicati è stato successivamente abbandonato. A partire dal 2016, è ancora necessario utilizzare i record TXT per configurare le politiche SPF..<ref name="rfc7208-txt" />
* Quando Steve Michael Bellovin sollevò dubbi sull'adozione del Sender Policy Framework (SPF), non c'era ancora un generale consenso sulla sua efficacia come soluzione per l'autenticazione delle email. Alcuni dei principali provider di servizi email non avevano ancora implementato SPF nei loro sistemi. Finché questi provider non adotteranno SPF, il protocollo SPF non sarà utile né per i loro clienti, che rappresentano una parte significativa della popolazione di utentR, né per altri, poiché gli indirizzi email potrebbero continuare a essere contraffatti. È importante notare che, da quando questa preoccupazione è stata espressa, servizi come Google Mail e AOL hanno adottato la politica SPF..<ref>{{Cita web |url=https://postmaster.aol.com/spf/ |titolo=SPF Information |editore=AOL Postmaster |accesso=4 ottobre 2007 |urlarchivio=https://web.archive.org/web/20070708214600/http://www.postmaster.aol.com/spf/ |dataarchivio=8 luglio 2007 |urlmorto=sì }}</ref>
* Le forti preoccupazioni di Bellowin riguardavano le ipotesi alla base di SPF, ovverosia al suo "modello semantico". Quando si utilizza SPF, i record DNS SPF determinano come ad un mittente è consentito inviare messaggi, il che significa che è compito del proprietario del dominio controllare come i mittenti sono autorizzati a inviare i messaggi. Le persone che fanno uso di indirizzi di posta elettronica "portatile" (come ad esempio indirizzi di posta elettronica creati da organizzazioni professionali) saranno tenuti a utilizzare il mittente SMTP del dominio del proprietario, che può anche non esistere. Le organizzazioni che forniscono questi indirizzi "portatili" potrebbero tuttavia creare i propri agenti di invio della posta (mail submission agents, MSAS)
Ci sono altre preoccupazioni circa l'impatto di un uso diffuso di SPF, in particolare l'impatto sulle varie forme legittime di email spoofing,<ref>{{Cita web|url=http://www.taugh.com/mp/lmap.html |titolo=Problems with Designated Sender |editore=Taughannock Networks |accesso=16 dicembre 2009}}</ref> come i servizi di spedizione, l'uso del SMTP da parte di persone con identità multiple, e altro (come
Il gruppo di lavoro IETF spfbis, con il compito di rielaborare le specifiche SPF puntando per lo stato "Proposta di standard" in una nuova RFC, durante l'aprile 2013 sembrava aver raggiunto un consenso per quanto riguarda il fatto di eliminare l'SPF tipo 99 a favore di un utilizzo continuo di record TXT.<ref>{{cita web|titolo=Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |url=https://tools.ietf.org/html/rfc6686|autore=Murray Kucherawy |anno=2012 |mese=luglio|editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013 }}</ref> Le persone del gruppo di lavoro DNSEXT si opposero fortemente a questo in una serie di discussioni email che riguardavano spfbis, dnsext e la discussione IETF in generale.<ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html |titolo=Obsoleting SPF RRTYPE |autore=S. Moonesamy |data=23 aprile 2013 |sito=DNSEXT Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref><ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/ietf/current/msg81939.html |titolo=Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard |autore=Dan Schlitt |data=29 agosto 2013 |sito=IETF Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref> Il capo del gruppo di lavoro spfbis, richiese di porre fine a quel torrente di proteste, dal momento che la discussione sul tipo di record (RRTYPE), nel gruppo di lavoro, era già stata risolta molto tempo fa<ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/spfbis/current/msg03833.html |titolo=The RRTYPE topic |autore=Andrew Sullivan |data=29 maggio 2013 |sito=SPFBIS Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref> (una mossa che è stata vista come un tentativo di mettere a tacere le proteste da parte di alcuni puristi DNS). Un progetto indipendente è stato proposto più tardi, e documenta come la ricorsione spuria di record TXT caratterizza l'attuale Internet.<ref>{{cita web|url=https://tools.ietf.org/html/draft-klensin-iana-txt-rr-registry|titolo=An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE|autore1=John Klensin |autore2=Andrew SUllivan |autore3=Patrik Fältström |anno=2013 |mese=agosto|editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref>
== Distribuzione ==
Software anti-spam come [[SpamAssassin]] versione 3.0.0 e ASSP
Caratteristiche principali di ASSP
Riga 157 ⟶ 155:
Piattaforma e compatibilità
ASSP è scritto in Perl, rendendolo indipendente dalla piattaforma, e supporta un'architettura multi-threading a partire dalla versione 2.x. Questa versatilità consente a ASSP di essere utilizzato su vari sistemi operativi senza necessità di modifiche significative.In sintesi, l'Anti-Spam SMTP Proxy rappresenta una soluzione robusta ed efficace per le organizzazioni che desiderano proteggere le proprie comunicazioni email dallo spam, garantendo al contempo una gestione flessibile e personalizzabile delle politiche anti-spam.</ref> implementano il protocollo SPF. Molti [[mail transfer agent]] (MTA) supportano direttamente SPF, tra cui [[Courier Mail Server|Courier]], [[CommuniGate Pro]], Wildcat
Caratteristiche principali di Wildcat
Riga 171 ⟶ 169:
Utilizzo
Wildcat è utilizzato principalmente da organizzazioni che necessitano di un MTA robusto e personalizzabile per gestire le comunicazioni via email. La sua flessibilità lo rende adatto sia per piccole imprese che per grandi aziende con esigenze complesse.In sintesi, l'MTA Wildcat rappresenta una soluzione efficace per la gestione delle email, combinando funzionalità avanzate con un alto grado di personalizzazione.
Caratteristiche principali di Postfix
Riga 187 ⟶ 185:
Utilizzo
Postfix è ampiamente utilizzato in molte distribuzioni Linux come MTA predefinito. È scelto da molti amministratori di sistema grazie alla sua facilità d'uso, configurabilità e robustezza. La sua architettura modulare e le funzionalità avanzate lo rendono adatto sia per piccole che grandi installazioni.In sintesi, Postfix rappresenta una soluzione affidabile e sicura per la gestione delle email, combinando prestazioni elevate con una configurabilità flessibile.
Caratteristiche principali di Exim
Riga 199 ⟶ 197:
Gestione della coda di posta: Exim gestisce efficacemente le code di messaggi in arrivo e in uscita, permettendo la consegna immediata dei messaggi non appena vengono ricevuti, senza attendere la chiusura della connessione SMTP.
Supporto per domini virtuali: Exim può gestire più domini locali sulla stessa macchina, consentendo una gestione indipendente delle cassette postali per ciascun dominio.
Caratteristiche principali di Qpsmtpd
Riga 213 ⟶ 211:
Utilizzo
Qpsmtpd è utilizzato principalmente in ambienti dove è richiesta una gestione flessibile delle email, come nei server di posta per piccole e medie imprese. La sua capacità di essere esteso tramite plugin lo rende adatto a scenari specifici, dove le esigenze possono variare notevolmente.In sintesi, Qpsmtpd rappresenta una soluzione versatile per la gestione delle email, combinando un'architettura modulare con funzionalità avanzate per garantire una comunicazione sicura ed efficiente.
Nell'agosto del 2005, è stato annunciato che [[EarthLink]] non avrebbe consentito ai domini ospitati di inserire record SPF.<ref>{{Cita web|url=http://www.circleid.com/posts/spf_loses_mindshare/ |titolo=SPF Loses Mindshare |anno=2005|accesso=4 aprile 2011 }}</ref>
Riga 219 ⟶ 217:
In un sondaggio pubblicato nel 2007, il 5% dei domini <kbd>.com</kbd> e <kbd>.net</kbd> risultava avere qualche tipo di politica SPF. Nel 2009, un'indagine condotta da Nokia Research ha riportato che il 51% dei domini testati specificava una politica SPF.<ref>{{Cita web|url=https://fit.nokia.com/lars/meter/spf.html|titolo=Nokia Research Report on SPF Adoption|urlarchivio=https://web.archive.org/web/20110920015908/https://fit.nokia.com/lars/meter/spf.html|sito=Fit.Nokia.com|editore=[[Nokia]]|data=19 settembre 2011|dataarchivio=20 settembre 2011|accesso=5 aprile 2016}}</ref> Questi risultati includevano anche politiche semplici come <kbd>v=spf1 ?all</kbd>.<ref>{{Cita web |url=http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |titolo=Handicapping New DNS Extensions and Applications |nome=Cricket |cognome=Liu |editore=ONLamp |data=gennaio 2007 |accesso=4 ottobre 2007 |dataarchivio=26 settembre 2007 |urlarchivio=https://web.archive.org/web/20070926234446/http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |urlmorto=sì }}</ref> Nell'aprile del 2007, BITS, una divisione del Financial Services Roundtable, pubblicò raccomandazioni di sicurezza per le email destinate ai suoi membri, tra cui l'adozione di SPF.<ref>{{Cita web |url=http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |titolo=BITS Email Security Toolkit |editore=BITS |data=aprile 2007 |accesso=13 giugno 2008 |formato=PDF |urlarchivio=https://web.archive.org/web/20080515131234/http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |dataarchivio=15 maggio 2008 |urlmorto=sì }}</ref>
Nel 2008, il Messaging Anti-Abuse Working Group (MAAWG)
Missione e Obiettivi
Riga 239 ⟶ 237:
Incontri
MAAWG organizza incontri regolari in Nord America ed Europa per discutere questioni relative alla sicurezza della messaggistica e alle politiche pubbliche.In sintesi, il Messaging Anti-Abuse Working Group (MAAWG) è un'importante iniziativa collaborativa che mira a combattere l'abuso online attraverso l'innovazione, la cooperazione e la condivisione delle migliori pratiche tra i leader del settore.
== Note ==
|