/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 presenti nel file ~/.procmailrc. Sia Postfix che Exim4 suggeriscono procmail per impostazione predefinita, ma ci sono alternative come maildrop od i filtri Sieve.
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
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# 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_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
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
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_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname
virtual_alias_domains ed indicando un file di mappatura indirizzi nella variabile virtual_alias_maps.
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.
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
/etc/postfix/virtual la tabella postfix /etc/postfix/virtual.db deve essere aggiornata eseguendo sudo postmap /etc/postfix/virtual.
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_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts
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.
/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.
# 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
soft_bounce = yes. Facendo precedere una direttiva di tipo reject da warn_if_reject verrà registrato solo un messaggio di log invece di rifiutare la richiesta.
smtpd_client_restrictions controlla quali macchine sono autorizzate a comunicare con il server di posta.
Esempio 11.2. Restrizioni basate sull'indirizzo del client
smtpd_client_restrictions =
permit_mynetworks,
warn_if_reject reject_unknown_client_hostname,
check_client_access hash:/etc/postfix/access_clientip,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_reverse_client rhsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.sorbs.netpermit_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: tale parametro trasforma il rifiuto in un semplice avviso registrato nei log. Gli amministratori possono, quindi, tenere d'occhio il numero di messaggi che sarebbero rifiutati se la regola fosse applicata e decidere successivamente riguardo l'opportunità di abilitare questa restrizione.
check_client_access consente all'amministratore di preparare una blacklist ed una whitelist di server di posta, memorizzate nel file /etc/postfix/access_clientip. I server nella whitelist sono considerati attendibili, quindi le email provenienti da questi non passano attraverso le successive regole di filtraggio.
HELO (o EHLO), seguito dal nome del server di posta elettronica di invio. Controllare la validità di questo nome può essere interessante. Per far rispettare pienamente le restrizioni elencate in smtpd_helo_restrictions dev'essere abilitata l'opzione smtpd_helo_required. In caso contrario i client potrebbero saltare le restrizioni non inviando alcun comando HELO/EHLO.
Esempio 11.3. Restrizioni sul nome annunciato in EHLO
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
check_helo_access hash:/etc/postfix/access_helo,
reject_rhsbl_helo multi.surbl.orgpermit_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_helo_hostname rifiuta le email quando l'annuncio EHLO elenca un nome host sintatticamente scorretto. La regola reject_non_fqdn_helo_hostname rifiuta i messaggi quando il nome host presentato non è un nome di dominio completamente qualificato (ovvero include il nome di dominio e il nome host). La regola reject_unknown_helo_hostname rifiuta i messaggi se il nome presentato non esiste nel DNS. Poiché quest'ultima regola, sfortunatamente, porta a molti rifiuti gli amministratori hanno trasformato il suo effetto in un semplice avviso usando il modificatore warn_if_reject come primo passo; possono decidere di rimuovere questo modificatore in una fase successiva, dopo aver verificato gli effetti di questa regola.
reject_rhsbl_helo permette di specificare una blacklist per controllare il nome dell'host rispetto a RHSBL.
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 della rete di falcot.com, per esempio aggiungendo la riga falcot.com REJECT Non sei nella nostra rete! al file /etc/postfix/access_helo.
MAIL FROM del protocollo SMTP. Ancora una volta questa informazione può essere verificata in diversi modi.
Esempio 11.4. 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,
reject_rhsbl_sender rhsbl.sorbs.net/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.
reject_rhsbl_sender rifiuta i mittenti basandosi su un servizio RHSBL (basato sul dominio).
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.5. Controlli sul destinatario
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
reject_non_fqdn_recipient,
permitreject_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.
permit non è strettamente necessaria. Tuttavia, può essere utile alla fine di una lista di restrizioni per rendere esplicita la politica predefinita.
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.
smtpd_delay_reject.
Esempio 11.7. Abilitare filtri basati sul contenuto
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
Esempio 11.8. 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: indirizzo IP, mittente e destinatario; e controlla il suo database per verificare se sono già apparsi recentemente. Se è così Postgrey risponde che il messaggio deve essere accettato, 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.9. 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.10. 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 dall'omonimo pacchetto.
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
systemctl reload postfix perché la modifica sia applicata.
include deve averne uno.
Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all
falcot.org.
#host -t TXT falcot.orgfalcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
postfix può controllare il record SPF per le email in arrivo usando il pacchetto postfix-policyd-spf-python, un agente di policy scritto in Python. Il file /usr/share/doc/postfix-policyd-spf-python/README.Debian descrive i passi necessari per integrare l'agente in postfix, quindi non li ripeteremo qui.
/etc/postfix-policyd-spf-python/policyd-spf.conf, che è completamente documentato in policyd-spf.conf(5) e /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. I principali parametri di configurazione sono HELO_reject e Mail_From_reject, che configurano se le email devono essere rifiutate (Fail) o accettate inserendo nell'intestazione (False), se i controlli falliscono. Quest'ultimo è spesso utile, quando il messaggio viene ulteriormente elaborato da un filtro antispam.
Header_Type dev'essere impostato su AR.
postfix, aggiunge nell'intestazione delle email in uscita una firma digitale associata al nome del dominio. La parte ricevente può convalidare il corpo del messaggio e i campi dell'intestazione controllando la firma con una chiave pubblica che viene recuperata dai record DNS del mittente.
opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR dev'essere un nome univoco per la chiave. Può essere semplice come "mail" o la data di creazione, se hai intenzione di ruotare le chiavi.
Esempio 11.11. Creare una chiave privata per firmare le e-mail da falcot.com
#opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys#chown opendkim.opendkim /etc/dkimkeys/mail.*
/etc/dkimkeys/mail.private e /etc/dkimkeys/mail.txt ed imposterà il corretto proprietario. Il primo file contiene la chiave privata, il secondo la chiave pubblica che dev'essere aggiunta al DNS:
Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
-b 1024 per scegliere una chiave più piccola. Se opendkim-testkey riesce, allora la entry è stata configurata correttamente. La sintassi è spiegata qui:
SOCKET e RUNDIR deve essere scelto in /etc/default/opendkim. Notare che SOCKET deve essere accessibile da postfix nel suo ambiente chroot. Le configurazioni aggiuntive sono fatte in /etc/opendkim.conf. Quello che segue è un estratto della configurazione, che assicura che il Dominio "falcot.com" e tutti i sottodomini (SottoDomini) siano firmati dal Selector "mail" e dalla chiave privata (KeyFile) /etc/dkimkeys/mail.private. La Canonicalizzazione "rilassata" per entrambe, intestazioni e body, tollerano lievi modifiche (ad esempio da un software della mailing list). I filtri sono eseguiti sia in Modalità firma ("s") che in modalità verifica ("v"). Se una firma non viene validata (On-BadSignature), la mail dovrebbe essere messa in quarantena ("q").
[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim
KeyTable), domini (SigningTable) e specificare host interni o di fiducia (InternalHosts, ExternalIgnoreList), che possono inviare mail attraverso il server come uno dei domini firmatari senza credenziali.
/etc/postfix/main.cf consentono a postfix l'uso del filtro:
milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345
/etc/postfix/master.cf.
/usr/share/doc/opendkim/ e le pagine del manuale opendkim(8) e opendkim.conf(5).
_dmarc e le azioni che devono essere intraprese quando le email che contengono il proprio dominio come host mittente falliscono la validazione tramite DKIM e SPF.
#host -t TXT _dmarc.gmail.com_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"#host -t TXT _dmarc.yahoo.com_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
rifiuta tutte le email che fingono di essere state spedite da account Yahoo ma sono mancanti o falliscono i controlli DKIM e SPF. Google Mail (Gmail) propaga una politica molto rilassata, nella quale tali messaggi provenienti dal dominio principale vengono ancora accettati (p=none). Per i sottodomini, dovrebbero essere contrassegnati come spam (sp=quarantine). Gli indirizzi indicati nella chiave rua possono essere utilizzati per inviare rapporti DMARC aggregati. La sintassi completa è spiegata qui:
postfix può usare anche questa informazione. Il pacchetto opendmarc contiene il milter necessario. In modo simile a opendkim SOCKET e RUNDIR devono essere impostate in /etc/default/opendmarc (per i socket Unix bisogna assicurarsi che siano visibili all'interno del chroot di postfix). Il file di configurazione /etc/opendmarc.conf contiene molti commenti ed ulteriori dettagli sono disponibili in opendmarc.conf(5). Per impostazione predefinita, i messaggi di posta elettronica che non superano la convalida DMARC non vengono rifiutati ma contrassegnati, aggiungendo un apposito campo di intestazione. Per modificare questo comportamento, utilizzare RejectFailures true.
smtpd_milters ed a non_smtpd_milters. Se si configurano i milter opendkim e opendmarc per restare in ascolto sulle porte 12345 e 54321, la voce in /etc/postfix/main.cf sarà qualcosa di simile a questo:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321
/etc/postfix/master.cf.
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.12. Abilitare SASL nel file /etc/postfix/main.cf
# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
[...]/etc/postfix/master.cf. Per disattivare l'autenticazione sulla porta 25 (serviziosmtpd ) inserire la seguente direttiva:
smtp inet n - y - - smtpd
[..]
-o smtpd_sasl_auth_enable=no
[..]
AUTH non aggiornato (alcuni client di posta molto vecchi lo fanno), l'interoperabilità con essi può essere abilitata utilizzando la direttiva broken_sasl_auth_clients.