Archivi tag: postfix

CentOS 6 e Postfix: tenere a bada il fenomeno denominato backscatter

In questo e questo post ho mostrato come configurare Postfix in modo da farlo funzionare come antispam. In quest’altro post, invece, ho illustrato la configurazione di postgrey e qui ho parlato di opendkim e di come integrarlo a Postfix.

Adesso vedremo come mitigare un fenomeno tipico dello spam e sempre più in aumento, ovvero il backscatter.

postfixUn po’ di teoria

Supponiamo che uno spammer voglia utilizzare il vostro dominio come mittente di una mail fraudolenta appositamente forgiata, da inoltrare ad un server SMTP autoritativo per un dominio X, che chiameremo dominiotarget.com.

La sequenza dei comandi che lo spammer utilizzerà sarà simile alla seguente:

ehlo mail.dominiotarget.com
mail from:<pluto@vostrodominio.com>
rcpt to:<pippo@dominiotarget.com>
data
some data
.
quit

Come potete notare, lo spammer ha utilizzato il vostro dominio (mail from:) come mittente della mail di spam che intende inviare ad utente@dominiotarget.com.

Supponiamo adesso che, per qualche ragione, il server SMTP di dominiotarget.com respinga la suddetta email fraudolenta (poichè, ad esempio, non esiste la mailbox pippo@dominiotarget.com), generando, successivamente, un messaggio apposito per indicare che tale email è stata respinta (mail bounced). Tale messaggio di “errore” verrà successivamente inoltrato al server SMTP autoritativo (ovvero quello specificato nei record MX della zona DNS) per vostrodominio.com.

A questo punto, se non opportunamente configurato, il vostro server SMTP riceverà il suddetto messaggio e lo inoltrerà alla casella di posta dell’utente spoofato dallo spammer, ovvero pluto@vostrodominio.com (se esiste), oppure verrà semplicemente scartata. Nel primo caso si rischia di saturare abbastanza velocemente la casella email del malcapitato utente (soprattutto se dotata di DISK QUOTA); nel secondo caso, invece, si rischia di creare eccessiva entropia, non consentendo all’amministratore della macchina di discernere (ad esempio attraverso l’analisi del file maillog) tra le email di backscatter e quelle che sono state respinte per un motivo lecito.

Come fare dunque per limitare tale fenomeno? Ecco alcune possibili soluzioni.

Utilizzare SPF

Se il server SMTP di dominiotarget.com è stato configurato in modo da utilizzare il framework SPF, e nella vostra zona DNS è presente un record di tipo TXT che specifica l’elenco dei server che possono inviare email utilizzando vostrodominio.com, esso sarà in grado di bloccare il tentativo di inoltro senza inviare alcun messaggio di errore al vostro server SMTP. Purtroppo però l’SPF non è configurato su tutti i server SMTP sparsi per la Rete, ergo bisogna correre ai ripari configurando opportunamente Postfix sul server antispam che intendiamo utilizzare.

Configurazione di Postfix

Per prima cosa occorre fare in modo che le email dirette a caselle di posta non esistenti vengano automaticamente respinte. Per fare ciò è possibile configurare la seguente direttiva all’interno del file /etc/postfix/main.cf:

unknown_local_recipient_reject_code = 550

Tale settaggio rappresenta comunque un’ottima prima difesa contro il backscatter, poichè, nella stragrande maggioranza dei casi, lo spammer forgerà delle email pseudorandomiche da utilizzare come mittente, del tipo AjsheUbjdX@vostrodominio.com. Esistono, però, dei casi particolari in cui lo spammer è a conoscenza di alcuni indirizzi leciti (ed attivi) su vostrodominio.com, ragion per cui occorre affinare ulteriormente la nostra opera di filtraggio. In particolare, è possibile impostare delle regole opportune basate su espressioni regolari in grado di “capire” quando un messaggio di mail bounced è stato causato dal backscatter e quando no. Tali regole potranno essere applicate durante l’analisi dell’header e del corpo del messaggio.

Ad esempio, possiamo popolare il file /etc/postfix/header_checks con le seguenti direttive:

if /^Received:/
/^Received: +from +(vostrodominio\.com) +/
        reject forged client name in Received: header: $1
/^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(vostrodominio\.com)\)/
        reject forged client name in Received: header: $2
/^Received:.* +by +(vostrodominio\.com)\b/
        reject forged mail server name in Received: header: $1
endif
/^Message-ID:.* <!&!/ DUNNO
/^Message-ID:.*@(vostrodominio\.com)/
        reject forged domain name in Message-ID: header: $1

Inoltre, le suddette entry dovranno essere collocate anche all’interno del file /etc/postfix/body_checks.

Infine, è necessario editare il file /etc/postfix/master.cf come segue:

body_checks = pcre:/etc/postfix/body_checks

header_checks = pcre:/etc/postfix/header_checks

Da notare che non occorre postmappare i suddetti file ed è sufficiente un semplice reload di Postfix per rendere effettive le modifiche apportate:

[root@antispam ~]# service postfix reload

Adesso il nostro server antispam sarà sicuramente in grado di filtrare un gran numero di messaggi di backscatter ma non sarà comunque a prova di bomba (ecco perchè ho parlato di “mitigare” e non di “bloccare” tale fenomeno). Ciò è dovuto al fatto i messaggi di mail bounced possono variare sia nella sostanza che nella forma in base all’applicativo che funge da SMTP, rendendo comunque possibile l’eventualità che esso non venga matchato dai filtri appena configurati.

A presto.

CentOS e Postfix: utilizzare smtp.gmail.com come smarthost

Premessa

In questo post ho mostrato come configurare uno degli MTA più utilizzati dalle distro *buntu (ovvero exim4) affinchè riesca a sfruttare un server SMTP pubblico (smarthost o relayhost) per l’invio delle nostre email.

Tale configurazione si rende necessaria nel caso in cui la nostra linea ADSL non sia dotata di un indirizzo IP pubblico statico da associare ad un FQDN (pubblico).

postfixConfigurazione di Postfix

La configurazione del nostro MTA si suddivide in 2 fasi: la prima riguarda la procedura di autentica allo smarthost; la seconda fa in modo che tutti gli indirizzi email locali vengano “tradotti” in indirizzi leciti (@gmail.com).

Per prima cosa creiamo il file relay_passwd all’interno della directory /etc/postfix:

[root@linuxbox postfix]# touch relay_passwd

il cui contenuto dovrà avere la seguente struttura:

[smtp.gmail.com]  username:password

A questo punto possiamo “postmappare” il suddetto file:

[root@linuxbox postfix]# postmap relay_passwd

Ora possiamo editare il file /etc/postfix/main.cf, aggiungendo le seguenti direttive:

relayhost = [smtp.gmail.com]
smtp_use_tls=yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd
smtp_sasl_security_options =

Il meccanismo di autentica utilizzato è SASL (vedi qui per approfondire). Inoltre, poichè le credenziali di autentica devono essere inviate allo smarthost tramite canale cifrato (STARTTLS), è stato necesario abilitare l’uso di tale protocollo da parte del client SMTP di Postfix.

A configurazione dell’autentica ultimata, possiamo editare il file /etc/postfix/generic, aggiungendo delle entry simili alle seguenti:

root@hostname.local.loc        vostro.indirizzo@gmail.com
nagios@hostname.local.loc       vostro.indirizzo@gmail.com

e più in generale:

username@hostname.local.loc        vostro.indirizzo@gmail.com

“Postmappiamo” anche il suddetto file:

[root@linuxbox postfix]# postmap generic

Ed aggiungiamo la seguente direttiva al file /etc/postfix/main.cf:

smtp_generic_maps = hash:/etc/postfix/generic

Ricarichiamo la configurazione di Postfix:

[root@linuxbox postfix]# service postfix reload

ed abbiamo finito.

Alla prossima.

Configurare DKIM come milter su Postfix e CentOS 6

Il DKIM (DomainKeys Indentified Mail) è un sistema per riconoscere univocamente le email provenienti dai domini che lo implementano, eliminando così il problema del mail spoofing e mitigando il problema del phishing/spamming. Esso si basa su un sistema di crittografia asimmetrica (RSA, chiave pubblica e privata), ed aggiunge all’header delle email (nel campo DKIM-Signature) alcuni tag necessari per l’identificazione delle stesse (ed eventualmente per la decifratura del corpo del messaggio).

dkim-process1

In soldoni, il destinatario dell’email ricava la chiave pubblica associata al dominio mittente da un record DNS di tipo TXT e la usa per decriptare il messaggio appena ricevuto (che era stato cifrato dal mittente utilizzando la chiave privata di quel dominio).

I dettagli sul funzionamento di tale sistema (con il segnificato dei vari tag aggiunti all’header) potete trovarli qui.

In questo post descriverò la procedura per integrare DKIM con Postfix su piattaforma CentOS 6.2 ed utilizzarlo come milter (con funzionalità di anti mail spoofing, anti phishing ed anti spam).

Per prima cosa installiamo il pacchetto opendkim:

[root@antispam ~]# yum install opendkim

ed impostiamo l’avvio automatico di tale servizio per i diversi runlevels:

[root@antispam ~]# chkconfig --levels 2345 opendkim on

Ora generiamo il keypair per il nostro dominio:

[root@antispam ~]# mkdir -p etc/opendkim/keys/vostrodominio.com/
[root@antispam ~]# /usr/sbin/opendkim-genkey -D /etc/opendkim/keys/vostrodominio.com/ -d vostrodominio.com -s default

e salviamo chiave pubblica e privata all’interno della giusta directory, previa definizione dell’owner:

[root@antispam ~]# chown -R opendkim:opendkim /etc/opendkim/keys/vostrodominio.com
[root@antispam ~]# mv /etc/opendkim/keys/vostrodominio.com/default.private /etc/opendkim/keys/vostrodominio.com/default

Editiamo il file /etc/opendkim.conf e settiamo per prima cosa il giusto pathname delle chiavi:

KeyFile /etc/opendkim/keys/vostrodominio.com/default

e successivamente definiamo la modalità di funzionamento di opendkim:

Mode v

ovvero, essendo installato su un server che funge da anti spam, il demone in questione dovrà solo verificare che le email provenienti dai domini che supportano DKIM siano autentiche (la v sta appunto per verify).

A questo punto editiamo il file /etc/postfix/main.cf ed aggiungiamo le seguenti direttive:

smtpd_milters           = inet:127.0.0.1:8891
non_smtpd_milters       = $smtpd_milters
milter_default_action   = accept

avviamo opendkim:

[root@antispam ~]# service opendkim start

e ricarichiamo la configurazione di postfix:

[root@antispam ~]# service postfix reload

Per verificare che tutto stia funzionando correttamente è sufficiente osservare l’output del comando:

[root@antispam ~]# tail -f /var/log/maillog | grep dkim

e fare delle prove di invio da domini che supportano DKIM (ad esempio gmail) e da domini che non lo supportano. Se in entrambi i casi la mail viene correttamente recapitata a destinazione allora abbiamo la certezza che il nostro nuovo sistema sta funzionando come dovrebbe.

Alla prossima.

Modificare l’MTA di default su CentOS 6

Ho già parlato più volte di exim, definendolo come uno degli MTA più performanti in circolazione.

Exim_logo.jpg

Essendo la mia formazione sui sitemi *nix derivata principalmente da Debian, preferisco usare il suddetto MTA piuttosto che postfix e qmail. Badate bene, però, che non sto facendo un paragone tra i software in questione: la mia è semplicemente una scelta di ordine pratico, ovvero preferisco avere a che fare con applicativi che già conosco perchè, in tal modo, posso ridurre notevolmente la percentuale di errori ed i tempi di troubleshooting.

Dopo questa breve premessa veniamo al dunque: da 3 anni a questa parte i server sotto la mia gestione sono principalmente dei CentOS/Red Hat, i quali si avvalgono di postfix come MTA di default.

Per sostituire postfix con exim occorre seguire questi step:

1) scaricare exim mediante il comando:

 [root@server exim]#  yum install exim

2) stoppare postfix e rimuoverlo dalla lista dei demoni da avviare al boot:

[root@server exim]#  service postfix stop 

[root@server exim]#  chkconfig –level 2345 postifx off

3) abilitare exim come MTA di default ed avviarlo:

[root@server exim]#  chkconfig –level 2345 exim on

[root@server exim]#  service exim start

A questo punto possiamo fare una prova di invio email. Per far ciò è sufficiente utilizzare il comando mail e dare un’occhiata al file di log associato ad exim, ovvero /var/log/exim/main.log.

Se effettivamente l’invio avviene mediante exim il suddetto file dovrebbe popolarsi di nuove entry. Nel caso in cui ciò non avvenga possiamo lanciare il comando:

[root@server exim]# alternatives –display mta

per visualizzare gli MTA disponibili e successivamente procedere con la scelta del Mail Transfer Agent da utilizzare:

[root@server exim]# alternatives –config mta

There are 2 programs which provide ‘mta’.

  Selection    Command
———————————————–
*+ 1           /usr/sbin/sendmail.postfix
   2           /usr/sbin/sendmail.exim

Enter to keep the current selection[+], or type selection number: 2

digitando semplicemente 2.

Tentiamo l’invio di una nuova email e tutto dovrebbe funzionare correttamente.

A presto.

Analisi di un attacco di phishing

Ormai stressato dalle n-mila email di phishing che puntualmente superano i filtri antispam, ho deciso di fare chiarezza su questa tipologia di attacco/truffa analizzando un caso specifico.

In particolare, l’email incriminata è la seguente:

Gentile Cliente,

la informiamo che e’ disponibile on-line  il suo estratto conto (riferito al codice del rapporto 05336-1999): potra’ consultarlo, stamparlo e salvarlo sul suo PC per creare un suo archivio personalizzato.

Le ricordiamo che ogni estratto conto rimane in linea fino al terzo mese successivo all’emissione.

Grazie ancora per aver scelto i servizi on-line di CartaSi.
I migliori saluti.

Servizio Clienti CartaSi

****************************************************************
VUOLE CONTESTARE SU UNA SPESA?
Easy Claim e il servizio che fa per lei!

****************************************************************
Per favore, non rispondere a questa mail: per eventuali comunicazioni accedi alla tua area riservata del Sito Internet di CartaSi e scrivici attraverso “Lo sportello del Cliente”:
e il modo piu semplice per ottenere una rapida risposta dai nostri operatori. Grazie per la collaborazione.

Bene, da un’analisi dell’header relativo al suddetto messaggio di posta elettronica si possono evincere diverse informazioni interessanti, tra cui indirizzo IP sorgente del messaggio ed il server SMTP da cui è partito l’inoltro, rispettivamente 37.59.204.181juodenas.com.

Per completezza, ecco la parte dell’intestazione a cui mi riferisco:

from User (unknown [37.59.204.181]) by juodenas.com (Postfix) with ESMTPA id CC72D7EE4335; Wed, 25 Apr 2012 16:21:48 +0400 (MSK)

Il from User (unknown [37.59.204.181]) mi lascia pensare che joudenas.com sia in realtà un open relay. Per averne la certezza ho provato ad inviare un messaggio fittizio alla mia casella di posta, usando la classica CLI via Telnet.

Per identificare l’MTA associato al dominio joudenas.com ho lanciato la seguente query con dig:

nightfly@nightbox:~$ dig juodenas.com mx

il cui output è il seguente:

; <<>> DiG 9.7.0-P1 <<>> juodenas.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; QUESTION SECTION:
;juodenas.com.                  IN      MX

;; ANSWER SECTION:
juodenas.com.           3383    IN      MX      10 juodenas.com.

;; AUTHORITY SECTION:
.                       86593   IN      NS      g.root-servers.net.
.                       86593   IN      NS      c.root-servers.net.
.                       86593   IN      NS      a.root-servers.net.
.                       86593   IN      NS      f.root-servers.net.
.                       86593   IN      NS      i.root-servers.net.
.                       86593   IN      NS      e.root-servers.net.
.                       86593   IN      NS      b.root-servers.net.
.                       86593   IN      NS      k.root-servers.net.
.                       86593   IN      NS      l.root-servers.net.
.                       86593   IN      NS      j.root-servers.net.
.                       86593   IN      NS      h.root-servers.net.
.                       86593   IN      NS      d.root-servers.net.
.                       86593   IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
juodenas.com.           3581    IN      A       79.98.31.21

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 26 09:12:42 2012
;; MSG SIZE  rcvd: 273

Ok, niente server MX specifico. L’unico record che può tornarmi utile è

juodenas.com.           3581    IN      A       79.98.31.21

quindi effettuo una query inversa (PTR) sull’IP 79.98.31.2

nightfly@nightbox:~$ host  79.98.31.21
21.31.98.79.in-addr.arpa domain name pointer server.juodenas.com.

Abbiamo finalmente un FQDN, ergo andiamo di nmap:

nightfly@nightbox:~$ sudo nmap -sS server.juodenas.com

Starting Nmap 5.00 ( http://nmap.org ) at 2012-04-26 09:39 CEST
Interesting ports on server.juodenas.com (79.98.31.21):
Not shown: 848 closed ports, 143 filtered ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
110/tcp open  pop3
443/tcp open  https
993/tcp open  imaps
995/tcp open  pop3s

Bene, ecco quello che mi interessa:

25/tcp  open  smtp

Sessione Telnet sulla porta 25 e proviamo ad inviare un messaggio di posta fittizio:

nightfly@nightbox:~$ telnet server.juodenas.com 25
Trying 79.98.31.21...
Connected to server.juodenas.com.
Escape character is '^]'.
220 juodenas.com ESMTP Postfix powered by Easy Hosting Control Panel (ehcp) on Ubuntu, www.ehcp.net
helo juodenas.com
250 juodenas.com
mail from: bobovieri@email.it
250 2.1.0 Ok
rcpt to: prova@email.it
554 5.7.1 <prova@email.it>: Relay access denied

Niente da fare, diversamente da quel che pensavo, non si tratta di un open relay. 

Vediamo se riesco a recuperare qualche informazione aggiuntiva mediante un whois:

nightfly@fw-scar:~$ whois juodenas.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: JUODENAS.COM
   Registrar: TUCOWS.COM CO.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net
   Name Server: NS1.SERVERIAI.LT
   Name Server: NS2.SERVERIAI.LT
   Name Server: NS3.SERVERIAI.LT
   Name Server: NS4.SERVERIAI.LT
   Status: ok
   Updated Date: 06-feb-2012
   Creation Date: 05-mar-2010
   Expiration Date: 05-mar-2013

>>> Last update of whois database: Thu, 26 Apr 2012 08:06:00 UTC <<<

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Registrant:
 Gytis Juodenas
 Taikos g. 79-76
 Vilnius,  -
 LT

 Domain name: JUODENAS.COM

 Administrative Contact:
    Hostmaster, IV  hostmaster@iv.lt
    J. Kubiliaus g. 6
    Vilnius,  08234
    LT
    +370.52324444
 Technical Contact:
    Hostmaster, IV  hostmaster@iv.lt
    J. Kubiliaus g. 6
    Vilnius,  08234
    LT
    +370.52324444

 Registrar of Record: TUCOWS, INC.
 Record last updated on 06-Feb-2012.
 Record expires on 05-Mar-2013.
 Record created on 05-Mar-2010.

 Registrar Domain Name Help Center:
    http://tucowsdomains.com

 Domain servers in listed order:
    NS2.SERVERIAI.LT
    NS4.SERVERIAI.LT
    NS3.SERVERIAI.LT
    NS1.SERVERIAI.LT

 Domain status: ok

e successivamente proviamo a contattare il server mediante protocollo HTTP:

http://www.juodenas.com/

Uhm, trattasi di un sito di grafica. Mi sa che questi cracker sono riusciti a caricare sul server in questione del codice (ad esempio PHP) in grado di aggirare le restrazioni di Postfix. 

Adesso dedichiamoci alla macchina sorgente dell’attacco. Per prima cosa vediamo quali servizi sono pubblicati all’esterno:

nightfly@nightbox:~$ nmap 37.59.204.181

Starting Nmap 5.00 ( http://nmap.org ) at 2012-04-26 10:41 CEST
Interesting ports on 37.59.204.181:
Not shown: 855 closed ports, 143 filtered ports
PORT     STATE SERVICE
1025/tcp open  NFS-or-IIS
3389/tcp open  ms-term-serv

Nmap done: 1 IP address (1 host up) scanned in 122.29 seconds

RDP è attivo, provo a lanciare una sessione dalla mia macchina:

rdp.png

Windows Server 2003 R2. Ecco da quale host partono le sessioni verso si server SMTP vittima.

Proviamo una query PTR:

nightfly@nightbox:~$ host  37.59.204.181
Host 181.204.59.37.in-addr.arpa. not found: 3(NXDOMAIN)

Niente da fare. Proviamo con un tracert:

C:\Users\eldo>tracert 37.59.204.181

Traccia instradamento verso XEVOHOST-067B7A [37.59.204.181]
su un massimo di 30 punti di passaggio:

  1     2 ms     1 ms     2 ms  * *
  2     *        *        *     Richiesta scaduta.
  3     *        *       41 ms  host45-66-static.41-88-b.business.telecomitalia.
it [88.41.66.45]
  4    43 ms    42 ms    43 ms  217.141.251.206
  5    64 ms    50 ms    50 ms  172.17.4.53
  6    62 ms    62 ms    62 ms  172.17.10.189
  7    61 ms    60 ms    60 ms  172.17.10.81
  8    62 ms    63 ms    63 ms  pos1-11-0-0.milano26.mil.seabone.net [195.22.192
.85]
  9    61 ms    61 ms    66 ms  te8-2.milano52.mil.seabone.net [195.22.205.241]

 10    62 ms     *      178 ms  mil-1-6k.it.eu [91.121.131.17]
 11    72 ms     *       84 ms  fra-1-6k.de.eu [213.251.128.66]
 12    80 ms    81 ms    81 ms  rbx-g1-a9.fr.eu [91.121.131.193]
 13    81 ms   285 ms   274 ms  vss-3-6k.fr.eu [94.23.122.237]
 14    81 ms    82 ms    81 ms  XEVOHOST-067B7A [37.59.204.181]

Traccia completata.

Ho individuato anche l’hosting provider, ovvero xevohosting.it. Esso offre un servizio un po’ “strano”, in quanto rimbalza i propri account su VPS gestiti da altri hosting provider. Ne è l’esempio lampante l’IP di destinazione della VPS, che fa riferimento ad un netblock made in France, ovvero OVH:

37.59.204.181
IP: 37.59.204.181
server location: France
ISP: Ovh Systems

Bene, basta così: segnalo l’abuso ad OVH ed informo il sysadmin di juodenas.com di quanto avvenuto.

Alla prossima.

Postfix: configurazione minimale

Premesso che esistono tantissimi mail agent per i sistemi *nix, questa guida ha come scopo quello di illustrare una configurazione minimale (ma funzionale) di postfix su CentOS.

Per prima cosa è necessiario installare tale applicativo. Per semplicità utilizzeremo yum:

[nightfly@centosbox ~]# yum install postfix

Una volta completata l’installazione del pacchetto occorre passare alla sua configurazione. In particolare, vogliamo che postfix invii ad un server SMTP esterno (smarthost) il nostro messaggio di posta, il quale verrà successivamente recapitato sulla nostra mailbox (ad esempio @email.it).

A tal proposito, sarà necessario creare il file sender_canonical all’interno della dir /etc/postfix:

[nightfly@centosbox postfix]# touch sender_canonical

La sintassi da utilizzare all’interno di questo file è la seguente:

<nome utente> <indirizzo di posta da usare come mittente>

Ad esempio:

nightfly nightfly@miodominio.it

Ovviamente il nome del dominio deve essere valido, altrimenti il server SMTP esterno risponderà picche.

A questo punto lanciamo il comando:

[nightfly@centosbox postfix]# postfix sender_canonical

attraverso il quale postfix creerà un file sender_canonical.db da utilizzare per individuare l’indirizzo di posta del mittente in fase di invio.

Modifichiamo infine il file main.cf aggiungendo la seguente stringa:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Riavviamo postfix:

[nightfly@centosbox postfix]#service postfix restart

ed inviamo una mail di prova utilizzando il comando mail:

[nightfly@centosbox postfix]# mail vostroindirizzo@email.it

Diamo un’occhiata al file messages nella dir /var/log, magari utilizzando un | grep postfix:

[nightfly@centosbox postfix]#cat /var/log/messages | grep postfix

e se otteremo un output simile al seguente:

Oct 29 10:24:42 test-monitor postfix/smtp[7611]: 80FC8301F1: to=<indirizzo@email.it>, relay=mx.email.it[212.97.34.36]:25, delay=0.32, delays=0.07/0/0.04/0.22, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C4F714400C)

vuol dire che la nostra mail è stata inviata con successo.

See ya.