/etc/postfix/main.cf.
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.
localhost, ma il dominio principale falcot.com dev'essere aggiunto manualmente. Più generalmente, bisognerebbe rispondere a questa domanda con tutti i nomi di dominio per i quali la macchina agirà come server MX; in altre parole, tutti i nomi a dominio per cui il DNS dice che questa macchina accetterà email. Questa informazione finisce nella variabile mydestination del file di configurazione principale di Postfix, /etc/postfix/main.cf.
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.
procmail. Questo strumento consente agli utenti di elaborare le loro email in arrivo attraverso le regole conservare nel file ~/.procmailrc.
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 = allvirtual_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
/etc/postfix/virtual descrive le mappature con una sintassi piuttosto lineare: ogni riga contiene due campi separati da uno spazio; il primo campo è il nome dell'alias, il secondo campo è una lista di indirizzi email a cui reindirizza. La sintassi speciale @domain.com copre tutti i restanti alias di un dominio.
Esempio 11.3. File /etc/postfix/virtual di esempio
webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # L'alias qui sotto è generico e copre tutti gli indirizzi all'interno # del dominio flacotsbrand.com che non sono altrimenti coperti in questo file. # Questi indirizzi inoltrano le email allo stesso utente nel # dominio falcot.com. @falcotsbrand.com @falcot.com
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.
virtual_uid_maps e virtual_gid_maps forniscono le mappature tra un indirizzo email e l'utente di sistema (o gruppo rispettivamente) che "possiede" la casella di posta corrispondente. Per assegnare tutte le caselle di posta allo stesso proprietario/gruppo la sintassi è static:5000.
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
/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
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.orgpermit_mynetworks usata come prima regola accetta tutte le email provenienti da una macchina nella rete locale (così come definita nella variabile di configurazione mynetworks).
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.
/etc/postfix/access_clientip. I server nella whitelist sono considerati affidabili, e le email che provengono da loro non passano attraverso le successive regole di filtraggio.
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_hostnamepermit_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.
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.
permit_mynetworks come prima regola ha un interessante effetto collaterale: le regole seguenti si applicano unicamente agli host fuori dalla rete locale. Questo consente di inserire in blacklist tutti gli host che si presentano come parte di falcot.com, per esempio aggiungendo la riga falcot.com REJECT You are not in our network! al file /etc/postfix/access_helo.
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/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.
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.
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.
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_recipientreject_unauth_destination è la regola base che richiede ai messaggi provenienti dall'esterno di essere indirizzati ai noi: messaggi inviati ad indirizzi non gestiti da questo server saranno rifiutati. Senza questa regola un server diviene un open relay che permette agli spammer di inviare posta non richiesta; questa regola è quindi caldamente raccomandata, e dovrebbe essere posizionata preferibilmente vicino all'inizio della lista, per evitare che altre regole possano autorizzare l'inoltro del messaggio prima che la sua destinazione sia stata controllata.
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.
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.
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.
RCPT TO.
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.
Esempio 11.11. Abilitare filtri basati sul contenuto
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
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
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.
check_policy_service come restrizione aggiuntiva:
smtpd_recipient_restrictions = permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023postgrey 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.
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_accessEsempio 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
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.
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.
dpkg-reconfigure clamav-milter. Quando viene richiesta "L'interfaccia di comunicazione con Sendmail", verrà risposto “inet:10002@127.0.0.1”.
dpkg-reconfigure clamav-base.
/etc/postfix/main.cf:
# Controllo virus con clamav-milter smtpd_milters = inet:[127.0.0.1]:10002
service postfix reload perché la modifica sia applicata.
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 ...]
/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.
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,
[...]