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

LibraESVA configurare il tempo di permanenza in coda di un messaggio

LibraESVA permette all’utente esperto di personalizzare il comportamento della propria appliance, anche in aspetti molto avanzati del sistema di gestione del flusso delle email.

L’elemento fondamentale del sistema, detto Mail Transfert Agent (MTA) è quel componente che si occupa di ricevere i messaggi e consegnarli al server destinatario. Di questo componente è possibile effettuare una configurazione avanzata.

libraesva mta

Quando LibraESVA non riesce a consegnare il messaggio a causa di un errore temporaneo (ad esempio il server di destinazione non è disponibile) questo messaggio rimane in coda di consegna per un periodo massimo stabilito dai parametri MTA Queue Lifetime.

Il valore di default di 5 giorni è stabilito dal RFC 5321 che regola gli standard di funzionamento del protocollo SMTP, tuttavia per esigenze particolari LibraESVA ci permette di estenderlo o ridurlo. Questa operazione è tuttavia sconsigliata ed andrebbe effettuata solo in casi eccezionali e per il periodo strettamente necessario a risolvere l’emergenza.

24 Agosto 2016

Un brutto esempio di phishinig

La diffusione dei Ransomware ha portato molta attenzione al tema della sicurezza informatica ed in particolare verso tutti i metodi di protezione dai ransomware, trascurando l’esistenza di altre pericolose minacce.

Fra queste c’è senza dubbio in Phishing, che continua attraverso campagne mirate a sottrarre dati personali da rivendersi nel mercato nero.

Stamattina mi è capitato di osservare un messaggio di phishing correttamente classificato, ma che mi ha fatto riflettere su alcuni aspetti caratterizzanti di questo messaggio.

Vediamo come era composto:

Delivered-To: <rimosso>
Received: by 10.202.62.131 with SMTP id l125csp2191720oia;
        Tue, 31 May 2016 14:13:07 -0700 (PDT)
X-Received: by 10.194.173.132 with SMTP id bk4mr110281wjc.92.1464729186993;
        Tue, 31 May 2016 14:13:06 -0700 (PDT)
Return-Path: <root@mail.yervaguena.com>
Received: from mail.yervaguena.com (mail.yervaguena.com. [5.56.57.43])
        by mx.google.com with ESMTPS id o84si39196803wmb.94.2016.05.31.14.13.06
        for <angelopenduzzu@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 31 May 2016 14:13:06 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of root@mail.yervaguena.com designates 5.56.57.43 as permitted sender) client-ip=5.56.57.43;
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of root@mail.yervaguena.com designates 5.56.57.43 as permitted sender) smtp.mailfrom=root@mail.yervaguena.com
Received: by mail.yervaguena.com (Postfix, from userid 0)
	id 3DFF513A22A; Tue, 31 May 2016 22:44:06 +0200 (CEST)
To: <rimosso>
Subject: Accesso bloccato al tuo account CheBanca associato con l'indirizzo e-mail angelopenduzzu@gmail.com .
X-PHP-Originating-Script: 0:ch3.php
From: CheBanca! <noreply.5206@ingdirectitalia.it>
Reply-To: noreply.5206@ingdirectitalia.it
Content-Type: text/html
Message-Id: <20160531204406.3DFF513A22A@mail.yervaguena.com>
Date: Tue, 31 May 2016 22:44:06 +0200 (CEST)


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<a href="http://www.chebanca.it.voKUCJ.thearborist.co.nz/.chebanca.it/?sicurezza=voKUCJ">
<img src="http://www.chebanca.it.Rzfuwt.thearborist.co.nz/images/chebancalogo205.png" height="261" width="632" border="0"></a> <text-align:center;margin-top: -19px;\"><b> </b></p></div
</html>'

Gli aspetti interessanti sono due:

  • L’indirizzo del mittente usa il dominio ingdirectitalia.it di proprietà di una nota banca online che opera a livello internazionale, purtroppo da una rapida analisi scopriamo che non hanno registrato un record SPF e quindi il messaggio non è stato bloccato.
    dig ingdirectitalia.it TXT
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> ingdirectitalia.it TXT
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41050
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;ingdirectitalia.it.        IN    TX
    ;; AUTHORITY SECTION:
    ingdirectitalia.it.    3600    IN    SOA    dns1.fastweb.it. dnsmaster.fastweb.it. 2015121001 10800 900 604800 86400
    ;; Query time: 1133 msec
    ;; SERVER: 127.0.1.1#53(127.0.1.1)
    ;; WHEN: Wed Jun 01 07:10:48 CEST 2016
    ;; MSG SIZE  rcvd: 95
  • L’indirizzo a cui punta il collegamento inizia con http://www.chebanca.it che ad una lettura superficiale potrebbe anche far credere che si tratti dell’indirizzo giusto, mentre invece il vero dominio è: thearborist.co.nz

Infine un’ultima considerazione, nelle intestazioni possiamo trovare che il messaggio è stato spedito da uno script php:

X-PHP-Originating-Script: 0:ch3.php

Il furto di identità è ancora una pratica molto diffusa e le campagne di Phishing quotidiane. Un incidente di sicurezza causato dalla perdita di credenziali di accesso può produrre danni economici più ingenti rispetto al BitCoin solitamente necessario per acquistare la chiave di decrittazione per un ransomware (acquisto che continuiamo a sconsigliare perchè significherebbe incrementare le disponibilità economiche e la motivazione dei gruppi che sviluppano e diffondono ransomware).

L’unico modo per risparmiare è dotarsi di un antispam efficace in grado di bloccare i messaggi più pericolosi.

Logo_Esva

LibraESVA è la soluzione Italiana ai problemi di spam e phishing, in grado di ridurre drasticamente del 99,99% la presenza di messaggi di spam nelle nostre mailbox ed ridurre quasi a zero la presenza di malware negli allegati potendo effettuare la scansione con più motori antispam.

argonavislab

Argonavis é partner LibraESVA e può fornirti tutte le informazioni commerciali e tecniche per implementare LibraESVA e migliorare la sicurezza della tua infrastruttura ed in particolare della posta elettronica.

Richiedi Informazioni

1 Giugno 2016

Zimbra, spostare le mail da una cartella

A volte può capitare di dover spostare le mail contenute in una cartella, in un’altra dello stesso account.

Questo semplice script mostra come è possibile

#!/bin/bash
# ./move.sh <utente@dominio> <cartella partenza> <cartella destinazione>
user=$1
folder1=$2
folder2=$3
list=$(zmmailbox -z -m ${user} search -t message in:/${folder1} | grep mess | awk 'BEGIN {FS=" "}{print $2}')
array=($list)
riga=0
righe=${#array[@]}
while [ $riga -lt $righe ]; do
    echo ${array[riga]}
    zmmailbox -z -m ${user} mm ${array[riga]} /${folder2}
    let riga+=1
done

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

Richiedi Informazioni

29 Giugno 2015

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