SecurityGateway for Email Servers v4.5 Release Notes

Developed with over 20 years of proven email security expertise, SecurityGateway provides affordable email security. It protects against spam, viruses, phishing, spoofing, and other forms of malware that present an ongoing threat to the legitimate email communications of your business.

Click here to learn more about SecurityGateway for Email Servers.

SecurityGateway 4.5.1 - martedì 9 maggio 2017

NUOVE FUNZIONI

[15657] SecurityGateway si integra con il servizio RMail™ di RPost®

RMail™ è intuitivo da utilizzare e non richiede che i destinatari dispongano di alcun software speciale. RMail™ potenzia l'utilizzo dei sistemi di posta elettronica per consumer e aziende di qualsiasi dimensione, in tutti i settori e reparti.

Il servizio RMail™ è basato sulla tecnologia Registered Email® di RPost, lo standard globale per la verifica del recapito della posta elettronica. Il servizio RMail™ estende la piattaforma di posta elettronica in uso offrendo le seguenti funzioni:

Con un account RPost gratuito, ogni utente può inviare o ricevere massimo 10 messaggi crittografati al mese. È possibile acquistare altri messaggi con RPost. Fare clic qui per maggiori informazioni sui piani e i prezzi per limiti di messaggi superiori.

Il servizio RMail™ può essere attivato dalla pagina Sicurezza | RMail™ o come azione di una regola di filtro del contenuto del messaggio.

MODIFICHE E NUOVE FUNZIONI

ERRORI CORRETTI

SecurityGateway 4.5.0 - martedì 4 aprile 2017

INFORMAZIONI SPECIALI

[18161] L'opzione "Consenti metodo di autenticazione CRAM-MD5" trovata in Impostazioni / Utenti | Configurazione posta | Protocollo e-mail è ora disattivata per impostazione predefinita per motivi di sicurezza e tecnici. Si consiglia l'utilizzo di TLS per evitare la trasmissione di password in chiaro.

MODIFICHE E NUOVE FUNZIONI

ERRORI CORRETTI

SecurityGateway 4.0.1 - 26 luglio 2016

MODIFICHE E NUOVE FUNZIONI

ERRORI CORRETTI

SecurityGateway 4.0.0 - 14 giugno 2016

NUOVE FUNZIONI

[15999] Interfaccia Web aggiornata per l'uso di un Mobile First Responsive Design

L'interfaccia Web è stata aggiornata per l'uso di un Mobile First Responsive Design. Il supporto dei browser si limita a IE 10 o versione successiva, Firefox e Chrome più recenti e l'ultimo Safari su Mac e iOS. Il browser standard di Android causa problemi nello scorrimento, mentre Chrome sui dispositivi Android funziona bene.

Questo design è interamente basato sulle dimensioni della finestra in uso. A prescindere che si utilizzi un telefono, un tablet o un PC, a parità di dimensioni della finestra, l'aspetto sarà lo stesso. La variazione più importante riguarda il menu. Se la larghezza è inferiore ai 956 pixel, il menu viene nascosto nel lato sinistro del browser. Per visualizzare il menu è possibile utilizzare due metodi. Con un dispositivo touch, se si fa scorrere il dito verso destra si visualizza il menu secondario. Se invece il dispositivo non è touch, è disponibile anche un pulsante "menu" nell'angolo superiore sinistro che consente di visualizzare il menu secondario. Se si tocca o si fa clic sul titolo del menu con la freccia verso sinistra accanto alla parte superiore del menu, viene visualizzato il menu principale. Anche le opzioni di menu Guida, Informazioni su ed Esci nell'angolo superiore destro cambiano in base alla larghezza dello schermo. Oltre i 768 pixel vengono visualizzate le parole Guida, Informazioni su ed Esci, da 481 a 767 pixel vengono visualizzate solo le icone e in meno di 480 pixel viene visualizzata l'icona dell'ingranaggio che, se cliccata o toccata, visualizza un menu a discesa con le opzioni Guida, Informazioni su ed Esci. Le viste dell'elenco con una o più colonne presentano pulsanti per attivare/disattivare le colonne.

[11232] DMARC

È stato aggiunto il supporto per DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC definisce un meccanismo scalabile in base al quale un'organizzazione che invia messaggi di posta elettronica può esprimere, tramite Domain Name System, criteri e preferenze a livello di dominio per la convalida, l'eliminazione e il reporting dei messaggi e un'organizzazione che riceve messaggi di posta elettronica può utilizzare tali criteri e preferenze per migliorare la gestione della posta. Le specifiche di DMARC e le informazioni dettagliate su cosa fa e come funziona sono disponibili qui: http://www.dmarc.org/.

DMARC consente ai proprietari di domini di definire dei criteri relativi alla gestione dei messaggi che affermano di provenire dai domini posseduti ma che non sono stati inviati da loro. Alcune possibili opzioni per la gestione dei messaggi sono "none" (in questo caso SecurityGateway non interviene), "reject" (in questo caso SecurityGateway non accetta il messaggio durante la sessione SMTP) e "quarantine" (in questo caso SecurityGateway aggiunge la seguente intestazione in ogni messaggio per facilitare il filtraggio nella cartella della posta indesiderata): "X-SGDMARC-Fail-policy: quarantine". Questa intestazione viene aggiunta solo se il risultato del controllo DMARC è "fail" e il criterio DMARC è diverso da "none". È possibile configurare SecurityGateway in modo da accettare i messaggi anche se DMARC ne richiede il rifiuto. In effetti, questa è la modalità di funzionamento predefinita. In questi casi SecurityGateway aggiunge un'intestazione "X-SGDMARC-Fail-policy: reject" al messaggio nel caso si intenda filtrare in maggior dettaglio.

DMARC sostituisce ADSP per le funzionalità di eliminazione dei messaggi di SPF. Tuttavia, è ancora possibile utilizzarle tutte insieme a DMARC. I rifiuti dei messaggi ADSP e SPF ora avvengono dopo l'elaborazione DMARC, se la verifica DMARC è abilitata.

DMARC dipende in parte dall'uso di un "elenco di suffissi pubblici". Un "suffisso pubblico" è un suffisso sotto il quale gli utenti di Internet possono registrare direttamente dei nomi. Alcuni esempi di suffissi pubblici sono .com, .co.uk e pvt.k12.ma.us. Un "elenco di suffissi pubblici" è un elenco di tutti i suffissi noti. SecurityGateway utilizza quello gestito per la comunità dalla Mozilla Foundation che si trova qui: https://publicsuffix.org/. Una copia dell'elenco è installata nella cartella \App\ e denominata effective_tld_names.dat. Non esiste attualmente alcuna fonte autorevole completa o singola per tale elenco, un problema che la comunità Internet dovrà risolvere. Nel corso del tempo questo file tenderà a diventare obsoleto e dovrà essere sostituito con un nuoco download da https://publicsuffix.org/list/effective_tld_names.dat e il salvataggio nella cartella \App\. SecurityGateway scaricherà e installerà questo file periodicamente e automaticamente, come parte dell'evento di manutenzione quotidiana circa una volta ogni due settimane. Alcuni comandi per governare questa funzione sono disponibili nelle nuove schermate di configurazione DMARC. Il registro di DMARC e la nuova finestra DMARC all'interno della scheda della sicurezza dell'interfaccia utente principale conterrà i risultati dell'aggiornamento e tutte le altre operazioni di elaborazione DMARC. È possibile impostare un URL di download del file diverso, se necessario, ma i dati scaricati devono essere conformi al formato specificato da Mozilla per il file. È possibile ottenere ulteriori informazioni all'URL sopra citato. SecurityGateway si attiene rigorosamente all'algoritmo di analisi specificato da Mozilla. Creare un file (possibilmente vuoto) denominato "PUBLICSUFFIX.SEM" e collocarlo nella cartella \App\ di SecurityGateway se si intende sostituire o modificare manualmente il file effective_tld_names.dat e si desidera che SecurityGateway lo ricarichi senza un riavvio.

Per utilizzare DMARC come mittente di posta elettronica, è necessario pubblicare un record DMARC TXT all'interno della configurazione DNS del proprio dominio. Informazioni su come definire e strutturare il record sono disponibili all'indirizzo http://www.dmarc.org. Quando si pubblica un record DMARC per il DNS, è possibile iniziare a ricevere i report DMARC provenienti da diverse fonti tramite e-mail. I report vengono forniti come file XML compressi, il cui formato è disciplinato dalle specifiche DMARC. L'utilizzo dei report non è incluso nell'ambito dell'implementazione di DMARC di SecurityGateway. Tuttavia, i dati all'interno dei report possono fornire importanti informazioni sul flusso di posta in un dominio, sull'uso improprio del dominio, sull'integrità della firma DKIM e sulla precisione e completezza del percorso dei messaggi SPF. Gli indirizzi a cui vengono inviati i report è configurato dall'utente al momento della creazione del record DMARC.

Durante l'impostazione di un record DMARC per uno o più domini, prestare particolare attenzione all'uso di p=reject, specialmente se il dominio fornisce account di posta elettronica per un uso generale da parte di utenti umani. Se gli utenti hanno sottoscritto delle liste di distribuzione, utilizzano un servizio di inoltro della posta oppure prevedono di utilizzare opzioni comuni come "condividi questo articolo con un amico", è necessario sapere che un criterio DMARC p=reject può rendere impossibili queste cose. Il criterio DMARC p=reject è perfettamente idoneo e utile, ma solo quando viene applicato ai domini che controllano l'utilizzo dei relativi account di posta elettronica (ad esempio, posta elettronica transazionale, account automatizzati (cioè non umani) o per applicare i criteri aziendali contro l'uso dell'account all'esterno dei confini dell'organizzazione).

Al fine di supportare i report aggregati di DMARC, SecurityGateway memorizzerà i dati da utilizzare in seguito per generare i report aggregati secondo la specifica DMARC. SecurityGateway ignora il tag DMARC "ri="; e produce solo report aggregati DMARC che coprono dalle 00:00:00 UTC alle 23:59:59 UTC per un determinato giorno. In corrispondenza della mezzanotte UTC (che non è necessariamente la mezzanotte ora locale) SecurityGateway utilizza i dati memorizzati per generare i report. SecurityGateway deve essere in esecuzione in tale momento oppure i dati memorizzati continueranno a crescere senza essere mai utilizzati. Quindi, se non si esegue SecurityGateway 24/7, non è consigliabile abilitare i report DMARC aggregati. I report DMARC aggregati sono disattivati per impostazione predefinita.

Al fine di supportare i report sui problemi di DMARC, sono stati pienamente implementati RFC 5965 "Un formato estensibile per i report di feedback sulla posta elettronica", RFC 6591 "Report sugli errori di autenticazione mediante l'uso del formato di segnalazione degli abusi", RFC 6652 "Report sugli errori di autenticazione del Sender Policy Framework (SPF) mediante l'uso del formato di segnalazione degli abusi", RFC 6651 "Estensioni di DomainKeys Identified Mail (DKIM) per la segnalazione degli errori" e RFC 6692 "Porte di origine nei report in formato ARF (formato di segnalazione degli abusi)". I report sugli errori vengono creati in tempo reale, come gli incidenti che li determinano. SecurityGateway implementa i report sugli errori di tipo DMARC AFRF e non i report di tipo IODEF. Pertanto, vengono accettati solo i valori di "afrf" nel tag DMARC "rf=". Per i dettagli completi, vedere la specifica DMARC. Si possono generare più report sugli errori da un singolo messaggio, in base al numero dei destinatari nel tag "ruf=" del record DMARC e al valore del tag "fo=" moltiplicato per il numero di errori di autenticazione indipendenti causati dal messaggio durante l'elaborazione. Quando il tag "fo=" di DMARC richiede la generazione di report per gli errori SPF, SecurityGateway invia i report sugli errori SPF in base a RFC 6522. Ne consegue che le estensioni della specifica devono essere presenti nel record SPF del dominio. I report sugli errori SPF non vengono inviati indipendentemente dall'elaborazione DMARC o in assenza delle estensioni RFC 6522. Quando il tag "fo=" di DMARC richiede la generazione di report per gli errori DKIM, SecurityGateway invia i report sugli errori DKIM e ADSP in base alle specifiche RFC 6651. Pertanto, le estensioni della specifica devono essere presenti nel campo di intestazione DKIM-Signature e il dominio deve pubblicare un record TXT dei report DKIM valido nel DNS e/o estensioni ADSP valide nel record TXT di ADSP. I report sugli errori DKIM e ADSP non vengono inviati indipendentemente dall'elaborazione DMARC o in assenza delle estensioni RFC 6651. Per ulteriori informazioni, vedere le diverse specifiche a cui si fa riferimento qui. I report sugli errori DMARC sono disattivati per impostazione predefinita.

Nota importante: Un record DMARC può specificare che i report devono essere inviati a un intermediario che opera per conto del proprietario del dominio. Questo è utile quando il proprietario del dominio affida a un'entità esterna il monitoraggio dei flussi della posta per il rilevamento di abusi e problemi di prestazioni. La ricezione da parte di terzi di tali dati può o non può essere consentita dal regolamento sulla privacy interno, dai termini e condizioni d'uso o da altri documenti di regolamentazione simili. È necessario considerare e comprendere se i criteri interni limitano l'uso e la trasmissione di report DMARC e, in tal caso, è necessario disattivare i report DMARC.

DMARC richiede l'uso di STARTTLS ogni volta che questo viene offerto dai destinatari dei report, tuttavia non c'è modo di prevedere o controllare questa caratteristica. È tuttavia necessario attivare STARTTLS se non è già attivo (vedi Impostazioni / utenti | Sistema | Crittografia).

L'intestazione Authentication-Results è stata estesa in modo da includere i risultati dell'elaborazione DMARC. Authentication-Results contiene alcuni dati nei commenti a scopo di debug, incluso il criterio DMARC richiesto dal proprietario del dominio che non è necessariamente l'azione eseguita sul messaggio. Ad esempio, quando il risultato di controllo DMARC è "pass", non è importante ciò che prevede il criterio DMARC, poiché questo viene applicato solo ai controlli DMARC con stato "fail". Allo stesso modo, quando il risultato di un controllo DMARC è "fail" e il criterio è "reject", il messaggio può essere accettato per ragioni di politica locale. Per l'uso di questa intestazione per il filtraggio si deve tenere conto di tutto ciò. In alternativa, utilizzare "X-SGDMARC-Fail-policy: quarantine" o "X-SGDMARC-Fail-policy: reject" per filtrare i messaggi nelle cartelle di spam o per qualsiasi altro scopo. SecurityGateway elimina l'intestazione "X-SGDMARC-Fail-policy:" da ogni messaggio in arrivo.

I messaggi devono essere conformi a DMARC sezione 15.1 rispetto all'intestazione RFC 5322.From oppure non vengono elaborati, che sostanzialmente significa che l'assenza di un unico (anche uno solo) campo RFC5322 From adeguatamente formato (secondo le specifiche RFC) rende il messaggio non valido in generale e quindi non valido per l'elaborazione DMARC.

Sono state aggiunte alcune nuove schermate a Sicurezza | Anti-spoofing in cui è possibile impostare diverse opzioni correlate all'utilizzo di DMARC.

Per l'abilitazione di DMARC è necessario il controllo SPF e/o DKIM, poiché DMARC è basato sulle identità verificate fornite da questi due meccanismi. Non è possibile utilizzare in modo produttivo DMARC per la posta in entrata senza una o entrambe le tecnologie. L'interfaccia utente cercherà di applicare questa limitazione.

[3961] Associa dominio a un indirizzo IP

Per i server a cui sono stati assegnati più indirizzi IP, ciascun dominio è associabile a un indirizzo IP specifico. La posta del dominio verrà inviata da questo indirizzo IP.

È anche possibile specificare un nome host SMTP per il dominio. Questo valore rappresenta il nome di dominio completo (FQDN, Fully Qualified Domain Name) utilizzato nell'istruzione SMTP HELO/EHLO al momento di inviare la posta relativa al dominio. Per le connessioni in ingresso, verrà utilizzato questo valore a meno che all'indirizzo IP non siano associati più domini, in tal caso il nome di dominio completo utilizzato sarà quello associato al dominio che è primo in ordine alfabetico.

MODIFICHE E NUOVE FUNZIONI

ERRORI CORRETTI

Copyright ©2008-2016 Alt-N Technologies, Ltd.