MTA Queue come scegliere la durata del Lifetime

MTA Queue Lifetime è il numero di giorni che un messaggio che non è stato consegnato a business-man-1002781_1920causa di un errore temporaneo, deve rimanere in coda di consegna, in modo che quando il sistema del destinatario riprende a funzionare possiamo consegnare il messaggio.

Come dicevamo nell’articolo riferito alla configurazione di LibraESVA il valore di default di 5 giorni è stabilito dal RFC 5321 che regola gli standard di funzionamento del protocollo SMTP, ma che per esigenze particolari LibraESVA ci permette di estenderlo o ridurlo.

La modifica di un parametro definito da un RFC non andrebbe mai fatta, perché rende il comportamento del nostro sistema inatteso ed incomprensibile, tuttavia ci sono dei pro e dei contro da analizzare, sia nel ridurre che nell’estendere questo tempo.

Riducendo il parametro MTA Queue Lifetime abbassiamo la dimensione delle code di consegna e di conseguenza l’impiego di risorse della macchina ma corriamo il rischio di non consegnare dei messaggi di posta nel caso il servizio non venisse ripristinato per tempo.

Aumentando il parametro MTA Queue Lifetime, abbiamo maggiori probabilità che il servizio venga ripristinato e quindi riuscire a consegnare effettivamente il messaggio, ma aumentiamo la dimensione della coda, aumentiamo le risorse impegnate sulla macchina (visto che avvengono continui tentativi di consegna) ed infine non notifichiamo per molto tempo al mittente che il messaggio che ha spedito non è stato consegnato pur essendo stato accettato.

26 Agosto 2016

Cryptshare per inviare allegati di grandi dimensioni

Quando è nata la posta elettronica i file pesavano pochissimi kilobyte, con l’evoluzione tecnologica e cryptsharela conseguente riduzione dei costi, le dimensioni dei file sono aumentate ed anche l’esigenza di spedirli tramite posta elettronica.

Purtroppo non sempre è possibile inviarli, non esistendo un limite massimo standard alla dimensione degli allegati, ciascun amministratore può dare un proprio limite alla dimensione massima.
Questa dimosogeneità ha come conseguenza immediata l’impossibilità di prevedere con certezza se il messaggio verrà consegnato.

Questa situazione è particolarmente fastidiosa, perché dopo aver trascorso molto tempo nel tentativo di inviare il messaggio, potrebbe tornare indietro un messaggio che indica il rifiuto.

Il file sharing su Cloud ha ridotto in parte questo problema, ma ne ha introdotti di diverso tipo, l’operazione non è trasparente ma deve essere fatta in tre fasi: il caricamento, la concessione dei diritti e l’inserimento del link nel messaggio, ed inoltre non garantisce la privacy.11-0

Cryptshare invece è la soluzione ideale a questo problema, integrato nei più diffusi client di posta (ad esempio Outlook) permette di allegare il file di qualsiasi dimensione al messaggio.

Quando il messaggio viene inviato, i file in allegato vengono salvati sul proprio server Cryptshare e crittografati in modo da garantire la privacy.

Il destinatario potrà scegliere di scaricare direttamente dal server cryptshare i file di grandi dimensioni, utilizzando una password che verrà fornita dal mittente, senza dover necessariamente far recapitare il messaggio sul proprio mailserver.

Cryptshare è la soluzione completa per rendere moderna la posta elettronica.

argonavislab

Argonavis ed i suoi tecnici sono a tua disposizione. Contattaci per richiedere una demo del prodotto e rendere moderna la tua posta elettronica.

Richiedi Informazioni

22 Aprile 2016

Cryptshare

La posta elettronica nonostante alcune previsioni nel passato l’hanno data per obsoleta e che cryptsharein breve tempo sarebbe stata superata da nuovi strumenti: IM (whatsapp, telegram, facebook) e cloud storage su tutti, è ancora particolare presente e fondamentale nelle nostre abitudini, nonostante qualche limite emerga.

In particolare sono quattro le problematiche a cui si vorrebbe porre rimedio: privacy, allegati di grandi dimensioni, sicurezza e controllo del flusso del messaggio.

Cryptshare è una piattaforma che può essere utilizzata sia come servizio, sia installata sui propri server, che permette di inviare dei messaggi di posta elettronica crittografando sia il contenuto del messaggio che gli allegati presenti.

making_e-mail_better

Il messaggio anziché essere consegnato direttamente nella casella, viene conservato sul server

Cryptshare in maniera sicura e garantire la privacy del contenuto viene crittografato usando l’algoritmo AES a 256 bit, mentre al destinatario arriva una notifica che lo avvisa della presenza di un messaggio inviato in maniera sicura che attende di essere scaricato.

Quando l’utente preme sul link presente nella notifica, può accedere al contenuto del messaggio incluso l’allegato, e può scaricarlo direttamente dalla piattaforma Cryptshare oppure farsi consegnare il messaggio sulla propria casella. In questo modo non avremo difficoltà nello scambiare allegati di grandi dimensioni.

Le operazioni di consultazione del messaggio vengono loggate ed è così possibile superare un noto problema dei classici messaggi email, ovvero avere la certezza che il destinatario abbia anche letto il messaggio. In questo caso avremo evidenza di data ed ora in cui il messaggio è stato aperto.

Cryptshare può essere utilizzato anche per ricevere messaggi, utilizzando o strumenti automatici resi disponibili da API, oppure tramite interfaccia web. Su tutti gli allegati può essere effettuata una scansione anti-malware, per garantire maggior sicurezza.

Cryptshare è il prodotto giusto per dare una risposta efficace e migliorare il funzionamento della posta elettronica.

argonavislab

Argonavis ed i suoi tecnici sono a tua disposizione per rispondere a quesiti tecnici e/o commerciali, contattaci subito per avere informazioni.

Richiedi Informazioni

20 Aprile 2016

Backscattering

Il backscatter è il termine utilizzato per indicare la diffusione di messaggi di mancato recapito di un messaggio di spam originato da altri, ma utilizzando l’indirizzo email della vittiamo come mittente.

Questo genere di messaggio viene generato perché l’indirizzo email a cui lo spammer, a tentato di inviare il messaggio non esiste, o comunque il server che gestisce quel dominio non è stato in grado di consegnare il messaggio che aveva accettato in precedenza (per approfondire reject vs bounce)

Il problema fondamentale è che il protocollo SMTP impone ad un server che ha ricevuto un messaggio e che per qualsiasi ragione non è stato in grado di consegnarlo, di generare una mail di errore, per avvertire il mittente. Quindi bloccare o limitare questi messaggi sarebbe una violazione del protocollo, vale a dire che la soluzione è molto peggiore del problema.

La chiave per arrivare ad una soluzione è nel passaggio “un server che ha ricevuto un messaggio” infatti il problema si supera evitando che il nostro server riceva (reject) messaggi che non è in grado di recapitare. Il messaggio si intende ricevuto, nel momento in cui viene permessa la trasmissione della parte DATA del messaggio, di conseguenza basterebbe verificare prima di permettere la trasmissione l’esistenza dell’indirizzo per ridurre notevolmente il rischio di backscatter.

Una domanda legittima è del perché devo preoccuparmi di non inviare messaggi che sono richiesti dal protocollo.
Le motivazioni sono:

  1. Perché è molto fastidioso per chi riceve il messaggio ritrovarsi la casella inondata di messaggi di ritorno per email che non sono mai stati inviati.
  2. Perché è altissimo il rischio di finire in RBL e vedersi rifiutata la maggior parte della posta inviata dal server.
  3. Perché il nostro server dovrebbe lavorare per smistare posta che non potrà consegnare e di conseguenza utilizzerà risorse e banda per messaggi inutili.

Zimbra permette di difendersi dal backscatter, il controllo dei recipient si attiva con i seguenti comandi

su zimbra
zmlocalconfig -e postfix_smtpd_reject_unlisted_recipient=yes
zmmtactl upgrade-configuration

Argonavis è in grado di fornire supporto tecnico e commerciale su Zimbra, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

26 Giugno 2015

Sender Policy Framework

Sender Policy Framework (SPF), è una tecnica utilizzata per limitare gli abusi nell’invio di messaggi di posta elettronica. Al contrario di altre tecniche che servono a limitare lo spam ricevuto dal dominio, SPF evita che qualcuno possa inviare messaggi utilizzando il nostro dominio come mittente.

La tecnica, codificata nel RFC 4408, consiste nel dichiarare quali sono i server autorizzati a spedire posta per il nostro dominio, ne consegue che un messaggio inviato da qualsiasi altro server a nostro nome si configura come un abuso e di conseguenza il messaggio verrà rifiutato (per appronfondire puoi leggere reject vs bounce) dal destinatario.

Le informazioni sui server autorizzati vengono pubblicate su un record TXT della configurazione del dominio.

Il record viene composto in questa maniera:

"v=spf1 <qualificatore1><meccanismo1> <qualificatore#><meccanismo#>"

I meccanismi possibili sono:

all  ip4 | ip6 | a | mx | ptr | exists | include

ciascun meccanismo può essere preceduto da un qualificatore

"+" | "-" | "~" | "?"

Vediamo alcuni esempi:

E’ valida esclusivamente la posta inviata dalla rete identificata dal record A

"v=spf1 a/24 a:offsite.example.com/24 -all"

E’ valida esclusivamente la posta inviata dall’indirizzo identificato dal record MX

"v=spf1 mx/24 mx:offsite.domain.com/24 -all"

E’ valida esclusivamente la posta inviata dalla rete 192.168.0.1/16

"v=spf1 ip4:192.168.0.1/16 -all"

Argonavis è in grado di fornire supporto tecnico per configurare correttamente il vostro server di posta, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

25 Giugno 2015