Product SiteDocumentation Site

Capitolo 11. Network Services: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Mail Server
11.1.1. Installare Postfix
11.1.2. Configurare i domini virtuali
11.1.3. Restrizioni per ricezione ed invio
11.1.4. Impostare il greylisting
11.1.5. Personalizzare i filtri in base al destinatario
11.1.6. Integrare un antivirus
11.1.7. SMTP autenticato
11.2. Server web (HTTP)
11.2.1. Installare Apache
11.2.2. Configurare gli host virtuali
11.2.3. Direttive comuni
11.2.4. Analizzatori di log
11.3. Server di file FTP
11.4. Server di file NFS
11.4.1. Mettere in sicurezza NFS
11.4.2. Server NFS
11.4.3. Client NFS
11.5. Configurare condivisioni Windows con Samba
11.5.1. Server Samba
11.5.2. Client Samba
11.6. Proxy HTTP/FTP
11.6.1. Installazione
11.6.2. Configurare una cache
11.6.3. Configurare un filtro
11.7. Directory LDAP
11.7.1. Installazione
11.7.2. Riempire la directory
11.7.3. Gestire gli account con LDAP
11.8. Real-Time Communication Services
11.8.1. DNS settings for RTC services
11.8.2. TURN Server
11.8.3. SIP Proxy Server
11.8.4. XMPP Server
11.8.5. Running services on port 443
11.8.6. Adding WebRTC
Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described.
Many modern network services require encryption technology to operate reliably and securely, especially when used on the public Internet. X.509 Certificates (which may also be referred to as SSL Certificates or TLS Certificates) are frequently used for this purpose. A certificate for a specific domain can often be shared between more than one of the services discussed in this chapter.

11.1. Mail Server

Gli amministratori della Falcot Corporation hanno scelto Postfix come loro server di posta elettronica per via della sua affidabilità e per la semplicità di configurazione. Allo stesso modo il suo design assicura che ogni operazione sia eseguita in un processo con l'insieme minimo di permessi richiesti, cosa che garantisce una misura ottimale contro i problemi di sicurezza.

11.1.1. Installare Postfix

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.
Saranno posti diversi quesiti Defconf durante l'installazione del pacchetto. Le risposte consentono di generare una prima versione del file di configurazione /etc/postfix/main.cf.
La prima domanda riguarda la tipologia di configurazione. Solo due delle risposte proposte sono rilevanti nel caso in cui il server sia connesso ad Internet: «Sito internet» e «Sito internet con smarthost». La prima opzione è appropriata per un server che riceve la posta in arrivo ed invia le email in uscita direttamente ai rispettivi destinatari: pertanto si adatta bene al caso della Falcot Corporation. La seconda opzione è appropriata per un server che riceve le email in arrivo normalmente ma che invia le email in uscita attraverso un server SMTP intermedio, lo «smarthost», anziché consegnarle direttamente al server del destinatario. Questo è particolarmente utile per chi ha con un indirizzo IP dinamico poiché molti server di posta rifiutano i messaggi che arrivano direttamente da questo tipo di indirizzo. In questo caso lo smarthost sarà generalmente il server SMTP dell'ISP che a sua volta è configurato per accettare ed inoltrare in modo appropriato le email provenienti dai clienti. Questo tipo di configurazione (con smarthost) è rilevante anche per i server che non sono costantemente connessi ad internet poiché evita di dover gestire una coda di messaggi non consegnabili da dover riprovare a inviare in seguito.
La seconda domanda riguarda il nome completo della macchina, utilizzato per generare gli indirizzi email a partire dal nome utente locale. Il nome completo della macchina appare dopo la chiocciola («@»). Nel caso della Falcot, la risposta dovrebbe essere mail.falcot.com. Questa è l'unica domanda posta in via predefinita tuttavia la configurazione a cui porta non è sufficientemente completa per le necessità della Falcot: per questo motivo gli amministratori eseguono dpkg-reconfigure postfix per poter personalizzare altri parametri.
One of the extra questions asks for all the domain names related to this machine. The default list includes its full name as well as a few synonyms for localhost, but the main falcot.com domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says that this machine will accept email. This information ends up in the mydestination variable of the main Postfix configuration file — /etc/postfix/main.cf.
Ruolo del record MX nel DNS durante l'invio di un'email

Figura 11.1. Ruolo del record MX nel DNS durante l'invio di un'email

In alcuni casi l'installazione può anche chiedere quali reti devono essere autorizzate ad inviare email attraverso la macchina. Nella sua configurazione predefinita Postfix accetta unicamente email provenienti dalla macchina che lo ospita; la rete locale viene generalmente aggiunta. Gli amministratori della Falcot Corporation hanno aggiunto 192.168.0.0/16 alla risposta predefinita. Se la domanda non è posta, la relativa variabile nel file di configurazione è mynetworks come si vede nell'esempio qui sotto.
Le email locali possono anche essere consegnate con procmail. Questo strumento consente agli utenti di elaborare le loro email in arrivo attraverso le regole conservare nel file ~/.procmailrc.
Dopo questa prima fase gli amministratori dispongono del file di configurazione seguente; sarà utilizzato come punto di partenza per aggiungere alcune funzionalità addizionali nelle prossime sezioni.

Esempio 11.1. File /etc/postfix/main.cf iniziale

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

11.1.2. Configurare i domini virtuali

Il server di posta può ricevere anche email indirizzate ad altri domini oltre a quello principale: questi domini sono indicati come «domini virtuali». In molti casi, dove questo avviene, le email non sono destinate ad utenti locali. Postfix fornisce due funzionalità interessanti per gestire i domini virtuali.

11.1.2.1. Domini virtuali alias

Un dominio virtuale alias contiene solo indirizzi alias, cioè indirizzi che si occupano di inoltrare le email ad altri indirizzi.
Questo tipo di dominio sarà abilitato aggiungendo il suo nome alla variabile virtual_alias_domains ed indicando un file di mappatura indirizzi nella variabile virtual_alias_maps.

Esempio 11.2. Direttive da aggiungere nel file /etc/postfix/main.cf.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
The /etc/postfix/virtual file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special @domain.com syntax covers all remaining aliases in a domain.

Esempio 11.3. File /etc/postfix/virtual di esempio

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within 
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

11.1.2.2. Caselle di posta su domini virtuali

I messaggi indirizzati ad una casella su di un dominio virtuale sono conservati in caselle di posta non assegnate ad un utente locale del sistema.
Abilitare una casella di posta in un dominio virtuale richiede di inserire il dominio nella variabile virtual_mailbox_domains fornendo un file di mappatura caselle in virtual_mailbox_maps. Il parametro virtual_mailbox_base contiene la directory dove le caselle di posta saranno conservate.
The virtual_uid_maps parameter (respectively virtual_gid_maps) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the static:5000 syntax assigns a fixed UID/GID (of value 5000 here).

Esempio 11.4. Direttive da aggiungere nel file /etc/postfix/main.cf.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
Ancora una volta, la sintassi del file /etc/postfix/vmailbox è piuttosto lineare: due campi separati da uno spazio. Il primo campo è un indirizzo email all'interno di uno dei domini virtuali e il secondo campo è la posizione della casella di posta associata (relativamente alla directory specificata in virtual_mailbox_base). Se il nome della casella di posta termina con una barra (/) le email saranno conservate nel formato maildir, diversamente sarà utilizzato il formato tradizionale mbox. Il formato di maildir utilizza l'intera directory per conservare una casella di posta: ogni messaggio sarà conservato in un file separato. Diversamente, nel formato mbox, l'intera casella di posta elettronica è conservata in un file ed ogni riga che comincia con «From » (From seguito da uno spazio) segnala l'inizio di un nuovo messaggio.

Esempio 11.5. Il file /etc/postfix/vmailbox

# La posta di Jean è conservata come maildir, con
# un file per email in una directory dedicata
jean@falcot.org falcot.org/jean/
# La posta di Sophie è conservata in un tradizionale file «mbox»,
# dove tutte le email sono concatenate in un unico file
sophie@falcot.org falcot.org/sophie

11.1.3. Restrizioni per ricezione ed invio

Il crescente numero di email massive non richieste (spam) richiede di essere sempre più rigorosi quando si stabilisce quali email devono essere accettate da un server. Questa sezione presenta alcune tra le strategie incluse in Postfix.

11.1.3.1. Restrizioni d'accesso basate su IP

La direttiva smtpd_client_restrictions controlla quali macchine sono autorizzate a comunicare con il server di posta.

Esempio 11.6. Restrizioni basate sull'indirizzo del client

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org
Quando una variabile contiene una lista di regole, come nell'esempio qui sopra, queste regole sono valutate in ordine, dalla prima all'ultima. Ogni regola può accettare il messaggio, rifiutarlo o lasciare la decisione ad una regola seguente. Come conseguenza l'ordine è importante ed invertire due regole può causare un comportamento ampiamente differente.
La direttiva permit_mynetworks usata come prima regola accetta tutte le email provenienti da una macchina nella rete locale (così come definita nella variabile di configurazione mynetworks).
La seconda direttiva rifiuta normalmente le email provenienti da macchine che non dispongono di una configurazione DNS completamente valida. Una configurazione è valida quando l'indirizzo IP può essere risolto con un nome e questo nome a sua volta può essere risolto all'indirizzo IP. Questa restrizione è spesso troppo rigorosa poiché molti server di posta non dispongono di un DNS inverso per il loro indirizzo IP. questo spiega perché gli amministratori della Falcot hanno inserito il modificatore warn_if_reject prima della direttiva reject_unknown_client: questo modificatore trasforma il rifiuto in un semplice avviso registrato nei log. Gli amministratori possono poi controllare il numero di messaggi che sarebbero rifiutati se la regola fosse applicata e prendere successivamente una decisione informata riguardo l'opportunità di abilitare questa restrizione.
The third directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
The last two rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List; there are several such lists, but they all list badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

11.1.3.2. Controllare la validità dei comandi EHLO o HELO

Ogni scambio SMTP inizia con un comando HELO (o EHLO) seguito dal nome del server di posta mittente; controllare la validità di questo nome può risultare utile.

Esempio 11.7. Restrizioni sul nome annunciato in EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname
La prima direttiva permit_mynetworks consente a tutte le macchine nella rete locale di presentarsi liberamente. Questo è importante poiché molti programmi di posta non rispettano in modo adeguato questa parte del protocollo SMTP e possono presentarsi con nomi senza senso.
La regola reject_invalid_hostname rifiuta le email quando la presentazione EHLO annuncia un nome host sintatticamente scorretto. La regola reject_non_fqdn_hostname rifiuta i messaggi quando il nome host presentato non è un nome di dominio completamente qualificato (ovvero include un nome di dominio oltre al nome host). La regola reject_unknown_hostname rifiuta i messaggi se il nome presentato non esiste nel DNS. Poiché quest'ultima regola sfortunatamente porta a troppi rifiuti gli amministratori hanno modificato i suoi effetti ad un semplice avviso con il modificatore warn_if_reject come visto inizialmente; possono anche decidere di rimuovere questo modificatore in una fase successiva dopo aver monitorato gli effetti di questa regola.
Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

11.1.3.3. Accettare o rifiutare in base al mittente annunciato

Ogni messaggio ha un mittente annunciato dal comando MAIL FROM del protocollo SMTP. Ancora una volta questa informazione può essere verificata in diversi modi.

Esempio 11.8. Controlli sul mittente

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender
La tabella /etc/postfix/access_sender mappa alcuni trattamenti speciali riservati ad alcuni mittenti. Generalmente questo significa elencare alcuni mittenti in una whitelist oppure in una blacklist.
La regola reject_unknown_sender_domain richiede un dominio valido per il mittente poiché è necessario per un indirizzo valido. La regola reject_unlisted_sender rifiuta i mittenti locali se l'indirizzo non esiste: questo impedisce alle email di essere inviate da un indirizzo non valido nel dominio falcot.com ed i messaggi originati da joe.bloggs@falcot.com sono accettati esclusivamente se questo indirizzo esiste realmente.
Per concludere, la regola reject_non_fqdn_sender rifiuta le email che si presume provengano da un indirizzo senza un nome di dominio pienamente qualificato. In pratica questo significa rifiutare email provenienti da utente@macchina: l'indirizzo dev'essere annunciato come utente@macchina.example.com o utente@example.com.

11.1.3.4. Accettare o rifiutare in base al destinatario

Ogni email ha almeno un destinatario, annunciato con il comando RCPT TO del protocollo SMTP. Anche questi indirizzi concorrono alla validazione del messaggio, tuttavia sono meno rilevanti rispetto ai controlli effettuati sull'indirizzo del mittente.

Esempio 11.9. Controlli sul destinatario

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient
reject_unauth_destination is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked.
La regola reject_unlisted_recipient rifiuta ragionevolmente i messaggi inviati a utenti locali che non esistono. Infine reject_non_fqdn_recipient rifiuta gli indirizzi non completamente qualificati: questo rende impossibile l'invio di email a jean o jean@macchina e richiede invece l'uso dell'indirizzo completo come jean@macchina.falcot.com o jean@falcot.com.

11.1.3.5. Restrizioni associate con il comando DATA

Il comando DATA di SMTP è emesso prima dei contenuti del messaggio. Non fornisce alcuna informazione di per sé, a parte l'annunciare quello che viene immediatamente dopo. Tuttavia può a sua volta essere soggetto a controlli.

Esempio 11.10. Controlli su DATA

smtpd_data_restrictions = reject_unauth_pipelining
La direttiva reject_unauth_pipelining fa sì che il messaggio sia rifiutato se il mittente invia un comando prima che sia inviata una risposta al comando inviato in precedenza. Questo protegge da una ottimizzazione comunemente utilizzata dagli spammer automatizzati poiché a loro non importa un fico secco delle risposte e si concentrano unicamente nell'invio del maggior numero di email nel minor tempo possibile.

11.1.3.6. Applicare restrizioni

Nonostante i comandi precedenti verificano informazioni a diversi livelli dello scambio SMTP, Postfix invia l'effettivo rifiuto unicamente a seguito del comando RCPT TO.
Questo significa che anche se il messaggio viene rifiutato a causa di un comando EHLO non valido, Postfix conosce il mittente ed il destinatario quando annuncia il rifiuto e pertanto potrà poi inserire nel log un messaggio più esplicito di quanto avesse potuto fare nel caso la transazione si fosse interrotta all'inizio. Inoltre un certo numero di client SMTP non si attende problemi durante i primi comandi SMTP e questi client saranno meno disturbati da questo rifiuto posticipato.
A final advantage to this choice is that the rules can accumulate information during the various stages of the SMTP exchange; this allows defining more fine-grained permissions, such as rejecting a non-local connection if it announces itself with a local sender.

11.1.3.7. Filtrare in base al contenuto del messaggio

The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body.

Esempio 11.11. Abilitare filtri basati sul contenuto

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
Entrambi i file contengono una lista di espressioni regolari (spesso chiamate regexp o regex) e relative azioni da intraprendere quando l'intestazione (o il corpo) delle email corrisponde con l'espressione.

Esempio 11.12. File d'esempio /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT Io combatto lo spam (GOTO Sarbacane)
/^Subject: *La tua email contiene dei VIRUS/ DISCARD notifica di virus
La prima controlla l'intestazione che fa riferimento al software email; se viene individuato GOTO Sarbacane (un software per l'invio massivo di email) il messaggio viene rifiutato. La seconda espressione controlla l'oggetto del messaggio: se indica la notifica di un virus possiamo decidere di non respingere il messaggio ma di limitarci a scartarlo immediatamente.
Utilizzare questi filtri è un'arma a doppio taglio poiché è facile produrre regole troppo generiche e perdere di conseguenza email legittime. In questi casi i messaggi vanno perduti ed inoltre i rispettivi mittenti ricevono messaggi d'errore non desiderati (e fastidiosi).

11.1.4. Impostare il greylisting

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted on a further try after some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.
Postfix non fornisce il greylisting nativamente ma esiste una funzionalità che permette di delegare la decisione riguardo il rifiuto o l'accettazione di un messaggio ad un programma esterno. Il pacchetto postgrey contiene proprio un programma di questo tipo, progettato per interfacciarsi con questo servizio per la delega delle politiche di accesso.
Once postgrey is installed, it runs as a daemon and listens on port 10023. Postfix can then be configured to use it, by adding the check_policy_service parameter as an extra restriction:
smtpd_recipient_restrictions = permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
Ogni volta che Postfix raggiunge questa regola si connette al demone postgrey e gli invia informazioni a proposito del messaggio in questione. Postgrey prende quindi in considerazione i tre parametri IP/mittente/destinatario e controlla il suo database per verificare se sono già apparsi recentemente. Se è così Postgrey risponde autorizzando il messaggio, altrimenti risponde indicando che il messaggio dev'essere temporaneamente respinto ed i tre parametri vengono inseriti nel database.
Il principale svantaggio del greylisting è dato dal ritardo causato ai messaggi legittimi, cosa che non è sempre accettabile. Inoltre incrementa il carico sui server che inviano molte email legittime

11.1.5. Personalizzare i filtri in base al destinatario

Sezione 11.1.3, «Restrizioni per ricezione ed invio» and Sezione 11.1.4, «Impostare il greylisting» reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond.
Postfix fornisce la personalizzazione sui filtri tramite il concetto di «restrizione di classe». Le classi sono dichiarate nel parametro smtpd_restriction_classes e sono definite come in smtpd_recipient_restrictions. La direttiva check_recipient_access definisce quindi una tabella che associa un destinatario ad un insieme appropriato di restrizioni.

Esempio 11.13. Definire classi di restrizione in main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive = reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions = permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Esempio 11.14. Il file /etc/postfix/recipient_access

# Indirizzi non filtrati
postmaster@falcot.com  permissiva
support@falcot.com     permissiva
sales-asia@falcot.com  permissiva

# Filtraggio aggressivo per alcuni utenti privilegiati
joe@falcot.com         aggressiva

# Una regola speciale per il manager della mailing-list
sympa@falcot.com       reject_unverified_sender

# Greylisting predefinito 
falcot.com             greylisting

11.1.6. Integrare un antivirus

I molti virus che circolano come allegato email rendono importante impostare un antivirus al punto d'ingresso nella rete aziendale dal momento che, nonostante una costante campagna di sensibilizzazione, molti utenti continuano ad aprire anche i file allegati a messaggi palesemente loschi.
Gli amministratori della Falcot hanno scelto clamav come loro antivirus libero. Il pacchetto principale è clamav ma hanno installato alcuni altri pacchetti aggiuntivi come arj, unzoo, unrar e lha, poiché sono richiesti dall'antivirus per analizzare gli allegati archiviati in uno di questi formati.
Il compito di interfacciare l'antivirus ed il server di posta è affidato a clamav-milter. Un milter (abbreviazione dell'inglese mail filter) è un programma di filtraggio realizzato appositamente per interfacciarsi con i server di posta. Un milter utilizza un'interfaccia di programmazione standard (API) che fornisce prestazioni nettamente migliori rispetto ai filtri esterni ai server di posta. I milter sono stati introdotti inizialmente da Sendmail e Postfix ha presto seguito l'esempio.
Once the clamav-milter package is installed, the milter should be reconfigured to run on a TCP port rather than on the default named socket. This can be achieved with dpkg-reconfigure clamav-milter. When prompted for the “Communication interface with Sendmail”, answer “inet:10002@127.0.0.1”.
The standard ClamAV configuration fits most situations, but some important parameters can still be customized with dpkg-reconfigure clamav-base.
Come ultimo passo è necessario istruire Postfix affinché utilizzi i filtri appena configurati. Per farlo è sufficiente aggiungere la seguente direttiva a /etc/postfix/main.cf:
# Controllo virus con clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
If the antivirus causes problems, this line can be commented out, and service postfix reload should be run so that this change is taken into account.
Tutti i messaggi gestiti da Postfix passano ora attraverso il filtro antivirus.

11.1.7. SMTP autenticato

Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution.
L'autenticazione SMTP con Postfix fa affidamento su SASL (Simple Authentication and Security Layer). Richiede l'installazione dei pacchetti libsasl2-modules e sasl2-bin e la registrazione di una password nel database SASL per ogni utente che necessita di autenticarsi sul server SMTP. Questo è realizzabile per mezzo del comando saslpasswd2 che accetta diversi parametri. L'opzione -u definisce il dominio di autenticazione e deve corrispondere al parametro smtpd_sasl_local_domain nella configurazione di Postfix. L'opzione -c consente di creare un utente e -f permette di specificare il file da usare se il database SASL necessita di essere conservato in una posizione diversa da quella predefinita (/etc/sasldb2).
# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]
Notare che il database di SASL viene creato nella directory di Postfix. Per assicurare la coerenza modifichiamo /etc/sasldb2 in un collegamento simbolico che punta al database utilizzato da Postfix con il comando ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
A questo punto è necessario configurare Postfix affinché utilizzi SASL. Prima di tutto l'utente postfix dev'essere aggiunto al gruppo sasl così che possa accedere al database degli account SASL. Alcuni nuovi parametri sono inoltre necessari per abilitare SASL e il parametro smtpd_recipient_restrictions dev'essere configurato per consentire ai client autenticati da SASL di inviare email liberamente.

Esempio 11.15. Abilitare SASL nel file /etc/postfix/main.cf

# Abilita l'autenticazione SASL
smtpd_sasl_auth_enable = yes
# Definisce il dominio di autenticazione SASL da utilizzare
smtpd_sasl_local_domain = $myhostname
[...]
# Aggiungere permit_sasl_authenticated prima di
# reject_unauth_destination permette l'inoltro delle email inviate
# dagli utenti autenticati con SASL
smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]