Filtra per argomento e data
Trasferimento dell'infrastruttura e-mail dell'IETF previsto per il 11 settembre- Dane Foster Nuovo Direttore Ingegneristico per New Machine Futures
28 agosto 2026
Una transizione verso una nuova infrastruttura moderna, modulare e containerizzata per i servizi di email forniti per ietf.org, iab.org, irtf.org, rfc-editor.org (inclusi gli elenchi di posta elettronica) è prevista per il 11 settembre 2026 alle 22:00 UTC, con un ritardo nella consegna dei messaggi fino a 60 minuti. Ulteriori aggiornamenti saranno forniti in prossimità della transizione.
L'interfaccia web per il software delle mailing list(Mailman3) sarà inoltre indisponibile durante la transizione; l'accessoagli archivi delle mailing liste all'accesso IMAP non sarà compromesso.
La nuova infrastruttura di posta elettronica include una completa refactoring dipostconfirm, un filtro di posta open source (milter) e strumento di elaborazione che funge da gatekeeper per le email, prevenendo il traffico indesiderato e gestendo le verifiche dei nuovi mittenti tramite un sistema di sfida-risposta basato su email.
Il nuovo software adotta un approccio modulare a queste funzioni, passando a nuovi software di rilevamento dello spam (daspamassassintorspamd), nuovosoftware di riscrittura degli indirizzie miglioramento della gestione dei certificati e di TLS perDANE(Autenticazione basata su DNS di Entità Nominate).
Il risultato sarà una migliore igiene delle email: miglior gestione dei bounce, riduzione delle opportunità di spam e rimozione della possibilità di fungere da relay aperto.
Ogni funzione discreta è implementata in un contenitore separato, programmata tramite Kubernetes in un cluster dedicato e comunica tramite il protocollomilterfornendo la funzionalità richiesta. Ciò ci consente di scalare orizzontalmente ogni componente in base alle necessità. L'eccezione ai container è l'invio di posta elettronica, che viene reindirizzata a più macchine virtuali in reti affidabili.
Ilpostconfirm milteresamina innanzitutto l'indirizzo di destinazione, confrontandolo con un'espressione regolare per determinare se è necessario un ulteriore passaggio di verifica. Successivamente, verifica una tabella di tutti gli indirizzi precedentemente approvati, inclusi tutti gli iscritti attuali all'elenco, per vedere se la verifica è già stata completata. Se è necessario un ulteriore passaggio di verifica, memorizza una copia dell'e-mail originale in attesa della risposta del mittente. Una volta che la verifica è stata completata correttamente, il messaggio memorizzato viene rilasciato come originariamente inviato e l'utente viene aggiunto all'elenco approvato per le e-mail future. Questo passaggio di verifica iniziale è fondamentale per garantire che tutti i partecipanti all'elenco di posta elettronica dell'IETF abbiano acconsentito alleNota Benedichiarazioni di politiche e procedure.
Theil filtro di riscrittura dell'indirizzoè più complesso, controllando le politiche DMARC e SPF del mittente per ogni email in uscita. Se il dominio "From" dell'enveloppe ha una politica SPF impostata che non include i nostri indirizzi IP, riscriviamo il dominio "From" da local-part@domain a $local-part=40$domain@$ietf-domain, dove $ietf-domain è basato sul dominio di destinazione originale prefissato con dmarc.; dmarc.ietf.org, dmarc.irtf.org, ecc., garantendo l'allineamento di SPF. Se il dominio di invio ha una politica DMARC p=reject o p=quarantine, riscriveremo anche l'intestazione "From" nello stesso modo, $local-part=40$domain@$ietf-domain. Quindi, applicheremo la firma DKIM con la chiave del dominio appropriata, garantendo un valido allineamento di DKIM e DMARC. Ad esempio, le email dadane@email.exampleinviate allatools-discuss@ietf.orgverrebbero riscritte sia l'enveloppe che l'intestazione "From" come dane=40email.example@dmarc.ietf.org, e ci sarebbe una firma DKIM con d=dmarc.ietf.org quando verrebbero consegnate agli iscritti alla lista. Se l'email in uscita è un messaggio di una mailing list, impostiamo anche l'intestazione "Return-Path" a un valore simile, consentendo la normale elaborazione dei rimbalzi della mailing list.
Il servizio di riscrittura delle email analizza anche le email in ingresso, gestendo l'elaborazione dei rimbalzi e il reindirizzamento agli indirizzi precedentemente riscrivuti, controllando un database per garantire che l'indirizzo riscritto sia valido, scoraggiando il reindirizzamento tramite il servizio di riscrittura.
Se non ci sono politiche SPF o DMARC sull'indirizzo "From", non verrà effettuato alcun riassegnamento dell'indirizzo.
Gestione dei certificativiene effettuata utilizzando unschema di rollover corrente + 3 mesi, ruotando e aggiornando i certificati quando necessario, garantendo che abbiamo sempre un certificato valido per DANE, anche durante la rotazione.
Rspamd fornisce la firma DKIM e la valutazione dello spam, con la possibilità di ulteriori ottimizzazioni dopo l'implementazione iniziale.
A lungo termine, la nuova infrastruttura sarà più robusta e scalabile, più facile da mantenere e aggiornare in futuro. Il software e l'infrastruttura per l'elaborazione delle e-mail attualmente in uso sono cresciuti nel corso degli anni per diventare estremamente complessi e difficili da gestire e aggiornare. L'e-mail è fondamentale per lavorare nell'IETF e questo aggiornamento fornisce una solida base per futuri miglioramenti.
Più in generale, la transizione dei servizi di posta elettronica fa parte delsforzo pluriennaleaaggiornare l'intera infrastruttura IT supportando l'IETFQuesto aggiornamento dei servizi di posta elettronica è un passo necessario per consentire ai partecipanti dell'IETF una gestione più integrata delle iscrizioni alle mailing list e tramite l'IETF Datatracker. Tutte le nuove versioni del software sono disponibili sul repository Github:ietf-toolsFeedback e segnalazioni sono benvenuti tramite Github, oppure direttamente tramite:tools-discuss@ietf.orgElenco di distribuzione.
ATTENZIONE: New Machine Futuresè un appaltatore dell'IETF Administration LLC che lavora su vari componenti della transizione dell'infrastruttura IT dell'IETF.