Completata la transizione dell'infrastruttura di posta elettronica IETF il 11 settembre

Il titolo e l'introduzione di questo post sono stati aggiornati l'11 settembre 2026 per riflettere la transizione riuscita. Le informazioni di seguito rimangono invariate dalla pubblicazione del 28 agosto 2026. Segnalare eventuali problemi a support@ietf.org.

L'interfaccia web del software di elenco di posta(Mailman3) sarà inoltre inaccessibile durante la transizione; accesso agliarchivi di elenco di postae l'accesso IMAP rimarrà impregiudicato.

La nuova infrastruttura di posta elettronica include una completa ristrutturazione dipostconfirm, che è un filtro di posta open source (milter) e strumento di elaborazione che agisce come guardiano della posta elettronica - prevenendo il traffico fastidioso e gestendo le verifiche dei nuovi mittenti tramite sfide basate su email e risposte.

Il nuovo software adotta un approccio modulare a queste funzioni, passando a nuovi software di rilevamento dello spam (daSpamassassinarspamd)nuovo software di riscrittura degli indirizzigestione migliorata dei certificati e del TLS perDANE (Autenticazione basata su DNS di entità nominate)Testo: DANEOgni funzione discreta è implementata in un contenitore separato, programmata tramite Kubernetes in un cluster dedicato e comunica tramite il protocollo milter

software di riscrittura degli indirizzi

gestione migliorata dei certificati e del TLSprotocollo milterFornire la funzionalità richiesta. Ciò consente di scalare orizzontalmente ogni componente come necessario. L'eccezione per i contenitori è la posta in uscita, che viene inoltrata a più macchine virtuali in reti note come affidabili.

Ilpostconfirm milterEsamina per primo l'indirizzo di destinazione, confrontandolo con un'espressione regolare per determinare se è necessario un challenge. Successivamente, controlla in un tavolo di tutti gli indirizzi precedentemente approvati, inclusi tutti gli abbonati attuali alla lista, per vedere se il challenge è già stato risposto. Se è necessario un challenge, memorizza una copia della posta elettronica originale mentre si attende la risposta del mittente al challenge. Una volta risposto adeguatamente al challenge, il messaggio memorizzato verrà rilasciato come inviato originariamente e l'utente verrà aggiunto alla lista di consentiti per future email. Questa sfida iniziale è vitale per garantire che tutti i partecipanti alla lista di mailing IETF abbiano accettato laNota BeneDichiarazione di politiche e procedure.

Iladdress rewriting milterÈ più complesso, controllando le politiche DMARC e SPF del mittente per ogni email in uscita. Se il dominio "From" dell'invio 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 si basa sul dominio di destinazione originale preceduto da dmarc. dmarc.ietf.org, dmarc.irtf.org, e così via, garantendo l'allineamento SPF. Se il dominio di invio ha una politica DMARC con p=reject o p=quarantine, riscriviamo in modo simile l'intestazione "From", $local-part=40$domain@$ietf-domain. Firma quindi il messaggio con la chiave del dominio appropriata, garantendo l'allineamento valido tra DKIM e DMARC. Per esempio, la posta da...Dane@email.exampleTesto: "Inviato a"tools-discuss@ietf.orgL'elenco riceverà sia l'intestazione che l'invio da dane=40email.example@dmarc.ietf.org, e ci sarà una firma DKIM con d=dmarc.ietf.org al momento della consegna ai sottoscrittori dell'elenco. Se la posta in uscita è un post di una lista di distribuzione, impostiamo anche l'intestazione Return-Path a un valore simile, consentendo al processo di rimbalzo della lista Mailman di funzionare normalmente.

Il servizio di riscrittura della posta elettronica analizza anche le email in entrata, gestendo il trattamento dei rimbalzi della lista e inoltrando agli indirizzi riscritti in precedenza, controllando rispetto a un record del database per garantire che l'indirizzo riscritto sia aggiornato, scoraggiando l'inoltro aperto attraverso il servizio di riscrittura.

Se non ci sono politiche SPF o DMARC sull'indirizzo "From", non verrà effettuata alcuna riscrittura dell'indirizzo.

Gestione dei certificatiÈ fatto utilizzando unschema di rollover corrente + successivo 3 1 1, riavvolgendo e aggiornando i certificati secondo necessità, garantendo di avere sempre un certificato valido per DANE, anche durante un rollover.

Rspamd fornisce la firma DKIM e le valutazioni anti-spam, con la capacità di regolare ulteriormente dopo il dispiegamento iniziale.

Nel lungo termine, la nuova infrastruttura sarà più robusta e scalabile, più facile da mantenere e aggiornare in futuro. Il software e l'infrastruttura di elaborazione delle email attualmente in uso si sono sviluppati nel corso di molti anni fino a diventare estremamente complessi e difficili da gestire e aggiornare. L'email è fondamentale per il lavoro nell'IETF e questo aggiornamento fornisce una solida base per i miglioramenti futuri.

In modo più generale, la transizione dei servizi email fa parte dellosforzo pluriennaleperaggiornare l'intera infrastruttura IT supportare l'IETFQuesto aggiornamento dei servizi email è un passo necessario per consentire ai partecipanti IETF una gestione più integrata delle iscrizioni alle liste di posta tramite l'IETF Datatracker. Tutto il nuovo software è disponibile sul repository GitHub di ietf-tools.ietf-tools GitHub repositoryFeedback e problemi sono benvenuti tramite GitHub, o direttamente via la lista di posta tools-discuss@ietf.org.tools-discuss@ietf.orglista di posta.

NOTA: Nuove Future MacchineÈ un appaltatore per l'Amministrazione IETF LLC che lavora su vari componenti della transizione dell'infrastruttura IT dell'IETF.