Capítol 11. Serveis de xarxa: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Els serveis de xarxa són els programes amb els quals els usuaris interaccionen directament en el seu treball diari. Són la punta de l'iceberg del sistema d'informació, i aquest capítol se centra en ells; les parts ocultes en les quals es basen són la infraestructura que ja hem descrit. Generalment requereixen la tecnologia d'encriptació descrita a Secció 10.2, «Certificats X.509».

11.1. Servidor de correu

Els administradors de Falcot Corp van seleccionar Postfix com a servidor de correu electrònic, degut a la fiabilitat i a la facilitat de configuració. De fet, el seu disseny força que cada tasca s'implementi en un procés amb el conjunt mínim de permisos requerits, que és una gran mesura de mitigació contra els problemes de seguretat.

ALTERNATIVA El servidor Exim4

Debian utilitza Exim4 com a servidor de correu electrònic per defecte (per això la instal·lació inicial inclou Exim4). La configuració és proporcionada per un paquet separat, exim4-config, i es personalitza automàticament basant-se en les respostes a un conjunt de preguntes Debconf molt similars a les preguntes plantejades pel paquet postfix.

La configuració pot estar en un sol fitxer (/etc/exim4/exim4.conf.template) o dividir-se en fragments de configuració emmagatzemats sota /etc/exim4/conf.d/. En ambdós casos, els fitxers són utilitzats per update-exim4.conf com a plantilles per a generar /var/lib/exim4/config.autogenerat. Aquest últim és el fitxer utilitzat per Exim4. Gràcies a aquest mecanisme, els valors obtinguts a través de la configuració debconf d'Exim — que s'emmagatzemen en /etc/exim4/update-exim4.conf.conf — es poden injectar al fitxer de configuració d'Exim, fins i tot quan l'administrador o un altre paquet ha alterat la configuració per defecte d'Exim.

La sintaxi del fitxer de configuració Exim4 té les seves peculiaritats i la seva corba d'aprenentatge; no obstant això, una vegada que aquestes peculiaritats són enteses, Exim4 és un servidor de correu electrònic molt complet i potent com ho demostren les desenes de pàgines de documentació.

→ https://www.exim.org/docs.html

11.1.1. Instal·lació de Postfix

El paquet postfix inclou el dimoni SMTP principal. Altres paquets (com ara postfix-ldap i postfix-pgsql) afegeixen funcionalitat addicional a Postfix, incloent-hi accés a bases de dades. Només cal instal·lar-los si se sap que es necessiten.

Durant la instal·lació del paquet es fan diverses preguntes Debconf. Les respostes permeten generar una primera versió del fitxer de configuració /etc/postfix/main.cf.

La primera pregunta es refereix al tipus de configuració. Només dues de les respostes proposades són rellevants en el cas d'un servidor connectat a Internet, «Internet site» i «Internet with smarthost». El primer és adequat per a un servidor que rep correu electrònic entrant i envia correu electrònic sortint directament als seus destinataris, i per tant està ben adaptat al cas Falcot Corp. El segon és adequat per a un servidor que rep un correu electrònic entrant normalment, però que envia el correu electrònic sortint a través d'un servidor SMTP intermedi — l'«smarthost»— en lloc de fer-ho directament al servidor del destinatari. Això és en gran part útil per a persones amb una adreça IP dinàmica, ja que molts servidors de correu electrònic rebutgen missatges que venen directament des d'una adreça IP. En aquest cas, l'«smarthost» normalment serà el servidor SMTP de l'ISP, que sempre està configurat per acceptar el correu electrònic procedent dels clients de l'ISP i per reenviar-lo adequadament. Aquesta configuració (amb un «smarthost») també és rellevant per als servidors que no estan connectats permanentment a Internet, ja que evita haver de gestionar una cua de missatges pendents d'entrega que s'han de tornar a provar d'enviar més tard.

La segona pregunta tracta sobre el nom complet de la màquina, que s'utilitza per generar adreces de correu electrònic a partir d'un nom d'usuari local; el nom complet de la màquina esdevé la part després de l'arrova ("@"). En el cas de Falcot, la resposta hauria de ser mail.falcot.com. Aquesta és l'única pregunta formulada per defecte, però la configuració a la qual condueix no és prou completa per a les necessitats de Falcot, per la qual cosa els administradors executen dpkg-reconfigure postfix per tal de poder personalitzar més paràmetres.

Una de les preguntes addicionals demana tots els noms de domini relacionats amb aquesta màquina. La llista per defecte inclou el seu nom complet, així com alguns sinònims de localhost, però el domini principal falcot.comha de ser afegit a mà. En general, aquesta pregunta s'ha de respondre normalment amb tots els noms de domini pels quals aquesta màquina hauria de servir com a servidor MX; en altres paraules, tots els noms de domini pels quals el DNS diu que aquesta màquina acceptarà el correu electrònic. Aquesta informació acaba a la variable mydestination del fitxer de configuració principal de Postfix — /etc/postfix/main.cf.

Figura 11.1. Rol del registre DNS MX a l'enviar un correu

En alguns casos, la instal·lació també pot preguntar des de quines xarxes es permet enviar correus electrònics a través de la màquina. En la configuració per defecte, Postfix només accepta correus electrònics procedents de la pròpia màquina; la xarxa local també s'hi afegirà normalment. Els administradors de Falcot Corp van afegir 192.168.0.0/16 a la resposta per defecte. Si la pregunta no es fa, la variable rellevant en el fitxer de configuració és mynetworks, com es veu a l'exemple següent.

El correu electrònic local també es pot lliurar a través de procmail. Aquesta eina permet als usuaris ordenar el seu correu electrònic entrant d'acord amb les regles emmagatzemades al seu fitxer ./.procmailrc. Tant Postfix com Exim4 suggereixen procmail per defecte, però hi ha alternatives com ara maildrop o els filtres Sieve.

Després d'aquest primer pas, els administradors van obtenir el següent fitxer de configuració; s'utilitzarà com a punt de partida per afegir alguna funcionalitat addicional en les següents seccions.

Exemple 11.1. Fitxer /etc/postfix/main.cf inicial

# 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

SEGURETAT Certificats SSL Snake oil

Els certificats «snake oil», o d'oli de serp, com els medicaments d'oli de serp venuts per tipus sense escrúpols en temps antics, no tenen cap valor: no es pot confiar en ells per autenticar el servidor ja que són certificats “autosignats” generats automàticament. No obstant això, són útils per millorar la privacitat dels intercanvis.

En general, només haurien d'utilitzar-se amb finalitats per fer proves, i el servei normal ha d'utilitzar certificats reals. La iniciativa Let's encrypt ofereix certificats SSL/TLS gratuïts i de confiança que es poden generar utilitzant el paquet certbot tal com es descriu a Secció 11.2.2, «Afegir suport per a SSL» i després es poden usar amb postfix així:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMINI/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMINI/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in Secció 10.2.2, «Infraestructura de clau pública: easy-rsa».

11.1.2. Configuració de dominis virtuals

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. Àlies de domini virtual

Un domini d'àlies virtual només conté àlies, és a dir, adreces que només reenvien correus electrònics a altres adreces.

Un domini d'aquesta mena s'habilita afegint el seu nom a la variable virtual_alias_domains, i fent referència a un fitxer de correspondència d'adreces amb la variable virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

El fitxer /etc/postfix/virtual descriu una correspondència amb una sintaxi bastant simple: cada línia conté dos camps separats per espais en blanc; el primer camp és el nom de l'àlies, el segon camp és una llista d'adreces de correu electrònic a on redirigeix. La sintaxi especial @domain.com cobreix tots els àlies restants en un domini.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# L'àlies següent és genèric i abasta totes les adreces del domini
# falcotsbrand.com que no s'explicitin en aquest fitxer.
# Aquestes adreces redirigeixen el correu cap al mateix nom d'usuari
# del domini falcot.com.
@falcotsbrand.com           @falcot.com

Després de canviar /etc/postfix/virtual, la taula de postfix /etc/postfix/virtual.db necessita ser actualitzada utilitzant l'ordre sudo postmap /etc/postfix/virtual.

11.1.2.2. Dominis de bústies virtuals

Els missatges adreçats a un domini de bústies virtuals s'emmagatzemen en bústies que no estan assignades a un usuari local del sistema.

L'activació d'un domini de bústies virtuals requereix citar aquest domini a la variable virtual_mailbox_domains, i fer referència a un fitxer de correspondència de bústies a virtual_mailbox_maps. El paràmetre virtual_mailbox_base conté el directori sota el qual s'emmagatzemaran les bústies.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

El paràmetre virtual_uid_maps (i respectivament virtual_gid_maps) fa referència al fitxer que conté la correspondència entre l'adreça de correu electrònic i l'usuari del sistema (i respectivament el grup) que «posseeix» la bústia corresponent. Per obtenir totes les bústies d'un mateix propietari/grup, la sintaxi static:5000 assigna un UID/GID fix (amb un valor de 5000 aquí).

De nou, la sintaxi del fitxer /etc/postfix/vmailbox és bastant senzilla: dos camps separats per espais en blanc. El primer camp és una adreça de correu electrònic dins d'un dels dominis virtuals, i el segon camp és la ubicació de la bústia associada (relativa al directori especificat a virtual_mailbox_base). Si el nom de la bústia acaba amb una barra (/), els correus electrònics s'emmagatzemaran en el format maildir; en cas contrari, s'utilitzarà el format tradicional mbox. El format maildir utilitza tot un directori sencer per emmagatzemar una bústia, on cada missatge individual s'emmagatzema en un fitxer separat. En el format mbox, d'altra banda, tota la bústia s'emmagatzema en un sol fitxer, i cada línia que comença amb “From ” (From seguit d'un espai) indica l'inici d'un nou missatge.

# El correu electrònic de Jean és desat com a maildir,
# amb un fitxer per correu en un directori dedicat
jean@falcot.org falcot.org/jean/
# El correu electrònic de Sophie és desat en un fitxer «mbox»
# tradicional, amb tots els correus concanenats en un sol fitxer
sophie@falcot.org falcot.org/sophie

11.1.3. Restriccions per rebre i enviar

El nombre creixent de correus electrònics massius no sol·licitats («spam») requereix ser cada vegada més estricte quan es decideixen quins correus electrònics un servidor hauria d'acceptar. Aquesta secció presenta algunes de les estratègies incloses al Postfix.

Si les regles de rebuig són massa estrictes, pot succeir que fins i tot el trànsit de correu electrònic legítim quedi bloquejat. És un bon costum provar les restriccions i evitar el rebuig permanent de les peticions durant un temps utilitzant la directiva soft_bounce = yes. Al precedir una directiva de tipus rebuig amb warn_if_reject només es generarà un missatge de registre en lloc de rebutjar la sol·licitud.

CULTURA El problema de l'«spam»

“Spam” és un terme genèric utilitzat per designar tots els correus electrònics no sol·licitats (també coneguts com a UCE de l'anglès «Unsolicited Commercial Emails» o “correus electrònics comercials no sol·licitats”) que inunden les nostres bústies electròniques; els individus sense escrúpols que els envien es coneixen com a «spammers». No els importa gaire la molèstia que causen, ja que enviar un correu electrònic costa molt poc, i només cal que un percentatge molt petit de destinataris se senti atret per les ofertes perquè l'operació d'«spamming» faci guanyar més diners del que costa. El procés és majoritàriament automatitzat, i qualsevol adreça de correu electrònic feta pública (per exemple, en un fòrum web, o en els arxius d'una llista de correu, o en un blog, etc.) serà probablement descoberta pels robots dels «spammers», i sotmesa a un flux interminable de missatges no sol·licitats. També són destinataris cada contacte trobat en un sistema compromès.

Tots els administradors del sistema intenten enfrontar-se a aquesta molèstia amb els filtres d'«spam», però, per descomptat, els «spammers» s'estan adaptant per intentar esquivar aquests filtres. Alguns fins i tot lloguen xarxes de màquines atacades per algun “cuc” per part de sindicats criminals. Les estadístiques recents estimen que fins al 95% de tots els correus electrònics que circulen per Internet són «spam»!

11.1.3.1. Restriccions d'accés basades en IP

La directiva smtpd_client_restrictions controla les màquines que tenen permès comunicar-se amb el servidor de correu electrònic.

Quan una variable conté una llista de regles, com en l'exemple següent, aquestes regles s'avaluen per ordre, des de la primera fins a l'última. Cada regla pot acceptar el missatge, rebutjar-lo, o deixar la decisió a una regla següent. En conseqüència, l'ordenació influeix i simplement intercanviar dues regles pot implicar un comportament molt diferent.

Exemple 11.2. Restriccions basades en l'adreça 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.net

La directiva permit_mynetworks, utilitzada com a primera regla, accepta tots els correus electrònics procedents d'una màquina a la xarxa local (segons com es defineixi a la variable de configuraciómynetworks).

La segona directiva normalment rebutjaria els correus electrònics procedents de màquines sense una configuració DNS completament vàlida. Una configuració vàlida significa que l'adreça IP es pot resoldre amb un nom, i que aquest nom, al seu torn, es resol amb l'adreça IP. Aquesta restricció és sovint massa estricta, ja que molts servidors de correu electrònic no tenen un DNS invers per a la seva adreça IP. Això explica per què els administradors de Falcot han precedit amb el modificador warn_if_reject la directiva reject_unknown_client: aquest modificador converteix el rebuig en un simple avís desat als registres. Els administradors poden vigilar el nombre de missatges que es rebutjarien si la norma s'apliqués realment i prendre una decisió informada més tard si desitgen activar aquesta restricció.

SUGGERIMENT taules access

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

La taula /etc/postfix/access_clientip llista xarxes i adreces IP; /etc/postfix/access_helo llista noms de domini; /etc/postfix/access_sender conté adreces de correu electrònic de remitents. Tots aquests fitxers s'han de convertir en taules «hash» (un format optimitzat per a un accés ràpid) després de cada canvi amb l'ordre sudo postmap /etc/postfix/fitxer.

The check_client_access 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.

Les quatre últimes regles rebutgen qualsevol missatge que vingui d'un servidor llistat en una de les llistes negres indicades. RBL és un acrònim de «Remote Black List» o “llista negra remota”, i RHSBL significa «Right-Hand Side Black List» o “llista negra de mà dreta”. La diferència és que la primera llista adreces IP, mentre que la darrera llista noms de domini. Hi ha diversos serveis d'aquest tipus. Llisten dominis i adreces IP amb pobra reputació, servidors mal configurats que els «spammers» utilitzen per retransmetre els seus correus electrònics, així com relés de correu inesperats com màquines infectades amb cucs o virus.

SUGGERIMENT Llistes blanques i RBLs

Les llistes negres de vegades inclouen algun servidor legítim que ha patit un incident. En aquestes situacions, tots els correus electrònics procedents d'un d'aquests servidors serien rebutjats llevat que el servidor estigui llistat en una llista blanca definida per /etc/postfix/access_clientip.

Per tant, la prudència recomana incloure a les llistes blanques tots els servidors de confiança dels quals es rebin molts correus electrònics.

11.1.3.2. Comprovació de la validesa de les ordre `EHLO` o `HELO`

Cada intercanvi SMTP comença amb una ordre HELO (o EHLO), seguida pel nom del servidor de correu electrònic que envia. Comprovar la validesa d'aquest nom pot ser interessant. Per aplicar plenament les restriccions llistades a smtpd_helo_restrictions l'opció smtpd_helo_required cal que estigui habilitada. En cas contrari, els clients podrien saltar-se les restriccions sense enviar cap comanda HELO/EHLO.

Exemple 11.3. Restriccions en el nom anunciat a 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.org

La primera directiva permit_mynetworks permet que totes les màquines de la xarxa local es presentin lliurement. Això és important, perquè alguns programes de correu electrònic no respecten prou adequadament aquesta part del protocol SMTP, i poden presentar-se amb noms absurds.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

El reject_rhsbl_helo permet especificar una llista negra per comprovar el nom de l'amfitrió contra una RHSBL.

Usar permit_mynetworks com a primera regla té un efecte secundari interessant: les següents regles només s'apliquen als amfitrions fora de la xarxa local. Això permet rebutjar tots els amfitrions que s'anuncien com a part de la xarxa falcot.com, per exemple afegint una línia falcot.com REJECT Tu no ets de la nostra xarxa! a l'arxiu /etc/postfix/access_helo.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Cada missatge té un remitent, anunciat per l'ordre MAIL FROM del protocol SMTP; de nou, aquesta informació es pot validar de diverses maneres diferents.

Exemple 11.4. Comprovacions del remitent

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

La taula /etc/postfix/access_sender assigna un tractament especial a alguns remitents. Això normalment significa tenir alguns remitents en una llista blanca o en una llista negra.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.

Finalment, la regla reject_non_fqdn_sender rebutja els correus electrònics que pretenen venir d'adreces sense un nom de domini plenament qualificat. A la pràctica, això significa rebutjar els correus electrònics procedents d'usuari@màquina: l'adreça s'ha d'anunciar com usuari@màquina.exemple.com o usuari@exemple.com.

La regla reject_rhsbl_sender rebutja els remitents basats en un servei RHSBL (basat en domini).

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Cada correu electrònic té com a mínim un destinatari, anunciat amb l'ordre RCPT TO del protocol SMTP. Aquestes adreces també justifiquen validació, encara que això pugui ser menys rellevant que els controls realitzats en l'adreça del remitent.

Exemple 11.5. Comprovacions del destinatari

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination és la regla bàsica que requereix que els missatges externs siguin adreçats a nosaltres; els missatges enviats a una adreça no servida per aquest servidor són rebutjats. Sense aquesta regla, un servidor es converteix en un relé obert que permet als «spammers» enviar correus electrònics no sol·licitats; aquesta regla és, per tant, obligatòria, i s'inclourà preferiblement prop del començament de la llista, de manera que cap altra regla pot autoritzar el missatge abans que la seva destinació hagi estat verificada.

La regla reject_unlisted_rerecipient rebutja els missatges enviats a usuaris locals no existents, la qual cosa té sentit. Finalment, la regla reject_non_fqdn_recipient rebutja adreces no completament qualificades; això fa que sigui impossible enviar un correu electrònic a jean o jean@ordinador, i requereix l'ús de l'adreça completa, com ara jean@ordinador.falcot.com o jean@falcot.com.

La directiva permit al final no és necessària. Però pot ser útil al final d'una llista de restriccions per fer explícita la política per defecte.

11.1.3.5. Restriccions associades amb l'ordre `DATA`

L'ordre DATA de SMTP s'emet abans del contingut del missatge. No proporciona cap informació per se, a part d'anunciar què ve després. Tot i així pot sotmetre's a controls.

Exemple 11.6. Controls de DATA

smtpd_data_restrictions = reject_unauth_pipelining

Les directives reject_unauth_pipelining fan que el missatge sigui rebutjat si la part emissora envia una ordre abans que s'hagi tornat la resposta a l'ordre anterior. Això protegeix d'una optimització comuna usada pels robots dels «spammers», ja que normalment no els importen les respostes i només se centren en enviar tants correus com sigui possible en el menor temps possible.

11.1.3.6. Aplicació de restriccions

Tot i que les ordres anteriors validen informació en diverses etapes de l'intercanvi SMTP, Postfix envia per defecte el rebuig en si com a resposta a l'ordre RCPT TO.

Això significa que encara que el missatge sigui rebutjat a causa d'una ordre invàlida EHLO, Postfix coneix el remitent i el destinatari quan anuncia el rebuig. Així pot registrar un missatge més explícit del que podria si la transacció s'hagués interromput des del principi. A més, hi ha una sèrie de clients SMTP que no esperen fallades en les ordres SMTP inicials, i aquests clients seran menys destorbats per aquest rebuig tardà.

Un avantatge final d'aquesta elecció és que les regles poden acumular informació durant les diverses etapes de l'intercanvi SMTP; això permet definir permisos més refinats, com ara rebutjar una connexió no local si s'anuncia amb un remitent local.

El comportament per defecte és controlat per la regla smtpd_delay_reject.

11.1.3.7. Filtratge basat en el contingut del missatge

El sistema de validació i restricció no seria complet sense una manera d'aplicar comprovacions al contingut del missatge. Postfix diferencia les comprovacions que s'apliquen a les capçaleres del correu electrònic de les que s'apliquen al cos del correu electrònic.

Exemple 11.7. Habilitació de filtres basats en el contingut

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Ambdós fitxers contenen una llista d'expressions regulars (comunament conegudes com a «regexps» o «regexes») i les accions associades que s'han d'activar quan les capçaleres del correu electrònic (o el cos) concorden amb l'expressió.

Exemple 11.8. Fitxer /etc/postfix/header_checks d'exemple

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *El vostre correu conté VIRUS / DESCARTAR la notificació de virus

TORNAR A LES BASES Expressions regulars

El terme expressió regular (abreujat en anglès com a regexp o regex) fa referència a una notació genèrica per expressar una descripció del contingut i/o estructura d'una cadena de caràcters. Certs caràcters especials permeten definir alternatives (per exemple, foo|bar coincideix o bé amb «foo» o bé amb «bar»), conjunts de caràcters permesos (per exemple, [0-9] significa “qualsevol dígit”, i . — un punt — significa “qualsevol caràcter”), quantificació (s? tant pot correspondre amb s com amb una cadena buida, en altres paraules, una o cap ocurrència de s; s+ coincideix amb un o més caràcters s consecutius; i així successivament). Els parèntesis permeten agrupar els resultats de la cerca.

La sintaxi precisa d'aquestes expressions varia segons les eines que les utilitzen, però les característiques bàsiques són similars.

→ https://ca.wikipedia.org/wiki/Expressi%C3%B3_regular

El primer comprova la capçalera que esmenta el programari de correu electrònic; si es troba GOTO Sarbacane (un programari de correu electrònic massiu), el missatge és rebutjat. La segona expressió controla l'assumpte del missatge; si esmenta una notificació de virus, podem decidir no rebutjar el missatge, sinó descartar-lo immediatament.

Aquests filtres són una espasa de doble tall, perquè és fàcil fer que les regles siguin massa genèriques i perdre correus electrònics legítims com a conseqüència. En aquests casos, no només es perdran els missatges, sinó que els seus remitents rebran missatges d'error no desitjats (i molestos).

11.1.4. Configuració de greylisting o “llistes grises”

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with 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 no proporciona llista grisa nativament, però hi ha una característica per la qual la decisió d'acceptar o rebutjar un missatge donat pot ser delegada a un programa extern. El paquet postgrey conté aquest programa, dissenyat per interactuar amb aquest servei de delegació de la política d'accés.

Una vegada instal·lat el postgrey, s'executa com un dimoni i escolta al port 10023. El Postfix es pot configurar per utilitzar-lo, afegint el paràmetre check_policy_service com a restricció addicional:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

El principal desavantatge de la llista grisa és que els missatges legítims es retarden, la qual cosa no sempre és acceptable. També augmenta la càrrega sobre els servidors que envien molts correus electrònics legítims.

A LA PRÀCTICA Inconvenients de les llistes grises

Teòricament, les llistes grises només haurien de retardar el primer correu d'un remitent donat a un destinatari donat, i el retard típic és en l'ordre de minuts. No obstant això, la realitat pot diferir lleugerament. Alguns grans ISP utilitzen grups de servidors SMTP, i quan un missatge es rebutja inicialment, el servidor que reintenta la transmissió pot no ser el mateix que l'inicial. Quan això passa, el segon servidor rep un missatge d'error temporal també a causa de la llista grisa, i així successivament; poden passar diverses hores fins que no es torna a provar la transmissió amb un servidor prèviament involucrat, ja que els servidors SMTP normalment augmenten el retard entre reintents després de cada fallada.

Com a conseqüència, l'adreça IP entrant pot variar en el temps fins i tot per a un sol remitent. Però va més enllà: fins i tot l'adreça del remitent pot canviar. Per exemple, molts servidors de llistes de correu codifiquen informació extra a l'adreça del remitent per poder gestionar missatges d'error (coneguts com a «bounces» o “rebots”). Cada nou missatge enviat a una llista de correu pot haver de passar per la llista grisa, cosa que significa que s'ha d'emmagatzemar (temporalment) en el servidor del remitent. Per a llistes de correu molt grans (amb desenes de milers de subscriptors), això aviat es pot convertir en un problema.

Per mitigar aquests inconvenients, Postgrey gestiona una llista blanca d'aquests llocs, i els missatges que vénen d'ells són acceptats immediatament sense passar per la llista grisa. Aquesta llista es pot adaptar fàcilment a les necessitats locals, ja que s'emmagatzema al fitxer /etc/postgrey/whitelist_clients.

ANANT MÉS ENLLÀ Llistes grises selectives amb milter-greylist

Els inconvenients de la llista grisa es poden mitigar només utilitzant-la en el subconjunt de clients que ja es consideren fonts probables de correu brossa (perquè apareixen llistats en una llista negra de DNS). Això no és possible amb postgrey però milter-greylist es pot utilitzar d'aquesta manera.

En aquest escenari, ja que les llistes negres de DNS mai no impliquen un rebuig definitiu, es fa raonable utilitzar llistes negres agressives, incloent-hi aquelles que incloguin totes les adreces IP dinàmiques de clients ISP (com ara pbl.spamhaus.org o dul.dnsbl.sorbs.net).

Atès que milter-greylist usa la interfície de «milter» de Sendmail, la configuració per la part de postfix es limita a “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. La plana del manual greylist.conf(5) documenta /etc/milter-greylist/greylist.conf i les nombroses maneres de configurar milter-greylist. També haureu d'editar /etc/default/milter-greylist per activar realment el servei.

11.1.5. Personalització dels filtres basant-se en el destinatari

A Secció 11.1.3, «Restriccions per rebre i enviar» i Secció 11.1.4, «Configuració de greylisting o “llistes grises”» es van revisar moltes de les possibles restriccions. Totes tenen la seva utilitat per a limitar la quantitat de correu brossa rebut, però també totes tenen els seus inconvenients. Per tant, cada vegada és més habitual personalitzar el conjunt de filtres depenent del destinatari. A Falcot Corp, la llista grisa és interessant per a la majoria d'usuaris, però dificulta el treball d'alguns usuaris que necessiten baixa latència en els seus correus electrònics (com el servei de suport tècnic). De la mateixa manera, el servei comercial de vegades té problemes per rebre correus electrònics d'alguns proveïdors asiàtics que poden ser aparèixer en llistes negres; aquest servei va demanar una adreça no filtrada per poder intercanviar correus.

Postfix proporciona una personalització dels filtres amb un concepte de “classe de restricció”. Les classes es declaren amb el paràmetre smtpd_rerestriction_classes, i es defineixen de la mateixa manera que smtpd_recipient_restrictions. La directiva check_recipient_access defineix una taula que relaciona un destinatari concret amb un conjunt adequat de restriccions.

Exemple 11.9. Definició de les classes de restricció a 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

Exemple 11.10. El fitxer /etc/postfix/recipient_access

# Addresses no filtrades
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Filtratge agressiu per a alguns usuaris privilegiats
joe@falcot.com         aggressive

# Regla especial per a l'administrador de la llista de correu
sympa@falcot.com       reject_unverified_sender

# Per defecte ús de llista grisa
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SEGURETAT Discussió polèmica sobre el programari antivirus

L'ús d'escàners de virus, o programari antivirus, és controvertit. Normalment passa un temps entre l'alliberament d'algun «malware» i l'addició de normes de detecció a la base de dades antivirus. Durant aquest interval de temp no hi ha protecció basada en programari. A més, l'ús sovint requereix executar programari addicional, per exemple, per descomprimir arxius i escanejar tota mena d'executables, la qual cosa augmenta dràsticament el potencial per atacar el propi programari antivirus. L'ús d'aquestes solucions de programari mai pot reemplaçar les campanyes de sensibilització i les regles de comportament bàsiques (mai s'han d'obrir els adjunts enviats en missatges no sol·licitats, etc.).

The Falcot administrators selected clamav from the homonymous package.

La tasca d'intermediar entre l'antivirus i el servidor de correu electrònic va a càrrec de clamav-milter. Un «milter» (abreviat de l'anglès «mail filter» o filtre de correu) és un programa de filtratge dissenyat especialment per interactuar amb servidors de correu electrònic. Un «milter» utilitza una interfície de programació d'aplicacions estàndard (API) que proporciona un rendiment molt millor que els filtres externs als servidors de correu electrònic. Aquests filtres van ser introduïts inicialment per Sendmail, però Postfix aviat en va seguir l'exemple.

Una vegada instal·lat el paquet clamav-milter, el filtre s'hauria de reconfigurar per funcionar en un port TCP en lloc del sòcol per defecte. Això es pot aconseguir amb dpkg-reconfigure clamav-milter. Quan es demana per la “interfície de comunicació amb Sendmail”, responeu amb “inet:10002@127.0.0.1”.

La configuració estàndard de ClamAV s'ajusta a la majoria de situacions, però alguns paràmetres importants encara es poden personalitzar amb dpkg-reconfigure clamav-base.

L'últim pas consisteix a dir a Postfix que utilitzi el filtre configurat recentment. Això és qüestió de senzillament afegir la següent directiva a /etc/postfix/main.cf:

# comprovació de virus amb clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Si l'antivirus causa problemes, aquesta línia es pot comentar i executar systemctl reload postfix perquè aquest canvi es tingui en compte.

A LA PRÀCTICA Provant l'antivirus

Un cop s'ha configurat l'antivirus s'ha de provar el correcte comportament. La manera més simple de fer-ho és enviar un correu electrònic de prova amb un adjunt que conté el fitxer eicar.com (o eicar.com.zip) que es pot descarregar en línia:

→ https://2016.eicar.org/86-0-Intended-use.html

Aquest arxiu no és un veritable virus, sinó un arxiu de prova que tot el programari antivirus del mercat diagnostica com un virus per efectuar la comprovació d'instal·lacions.

Tots els missatges manejats per Postfix ara passen pel filtre antivirus.

11.1.7. Lluitar contra el correu brossa amb SPF, DKIM i DMARC

L'elevat nombre de correus electrònics no sol·licitats enviats cada dia va dur a la creació de diversos estàndards que tenen com a objectiu validar que l'enviament d'un correu electrònic està autoritzat i que el correu electrònic no s'ha manipulat. Els següents sistemes estan basats en DNS i requereixen que els administradors no només tinguin control sobre el servidor de correu, sinó també sobre el DNS per al domini en qüestió.

COMPTE Discussió polèmica

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrant el marc de polítiques del remitent (SPF o «Sender Policy Framework»)

El Marc de Política del Remitent (SPF «Sender Policy Framework») s'utilitza per validar si es permet que un cert servidor de correu enviï correus electrònics per a un domini donat. Està majoritàriament configurat a través de DNS. La sintaxi de l'entrada a fer s'explica detalladament a:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Fem un cop d'ull ràpid a l'entrada falcot.org.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Estableix que la IP del remitent ha de coincidir amb el registre A per al domini d'enviament, o ha de ser llistat com un dels «Mail Exchange Resource Records» pel domini actual, o ha de ser una de les tres adreces IP4 esmentades. Tots els altres amfitrions s'haurien de marcar com si no se'ls permet enviar correu electrònic per al domini del remitent. Aquest últim s'anomena un “error suau” i té la intenció de marcar el correu en conseqüència, malgrat que l'accepta.

El servidor de correu postfix pot comprovar el registre SPF dels correus entrants utilitzant el paquet postfix-policyd-spf-python, un agent “normatiu” escrit en Python. El fitxer /usr/share/doc/postfix-policyd-spf-python/README.Debian descriu els passos necessaris per integrar l'agent amb postfix, així que no el repetirem aquí.

La configuració es fa al fitxer /etc/postfix-policyd-spf-python/policyd-spf.conf, que està plenament documentat a policyd-spf.conf(5) i a /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Els paràmetres de configuració principals són HELO_reject i Mail_From_reject, que configuren si els correus electrònics han de ser rebutjats (Fail), o acceptats però amb una capçalera afegida (False) si fallen les comprovacions. Aquest últim és útil sovint, quan el missatge és processat per un filtre de correu brossa.

Si el resultat està previst que sigui utilitzat per opendmarc (Secció 11.1.7.3, «Integració de l'utenticació de missatges basats en domini, Informes i Conformitat (DMARC)»), llavors Header_Type ha de ser establert a AR.

Tingueu en compte que spamassassin conté un connector per comprovar el registre SPF.

11.1.7.2. Integrant les signatures i comprovacions DomainKeys (DKIM)

L'estàndard «Domain Keys Identified Mail» (DKIM) és un sistema d'autenticació del remitent. L'agent de transport de correu, en aquest cas postfix, afegeix una signatura digital associada amb el nom del domini a la capçalera dels correus sortints. La part receptora pot validar el cos del missatge i els camps de capçalera verificant la signatura contra una clau pública, que s'obté dels registres DNS del remitent.

→ http://dkim.org/

Les eines necessàries es troben als paquets opendkim i opendkim-tools.

COMPTE Programari de llistes de correu i DKIM

Els gestors de llistes de correu sovint reescriuen algunes capçaleres de correu electrònic, la qual cosa porta a signatures DKIM no vàlides. Fins i tot l'ús d'una canonització relaxada no sempre impedeix que això succeeixi. Així que els administradors han de prestar molta atenció als fitxers de registre dels servidors de correu per identificar aquestes qüestions. En cas contrari aquests correus podrien ser marcats com a correu brossa i podrien ser rebutjats.

Primer s'ha de crear la clau privada utilitzant l'ordre opendkim-genkey -s SELECTOR -d DOMINI. SELECTOR ha de ser un nom únic per a la clau. Pot ser tan simple com “correu” o la data de creació, si es planeja renovar les claus.

Exemple 11.11. Creació una clau privada per signar els correus de falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

Això crearà els fitxers /etc/dkimkeys/mail.private i /etc/dkimkeys/mail.txt i establirà la propietat adequadament. El primer fitxer conté la clau privada, i el segon la clau pública que s'ha d'afegir al DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

El paquet opendkim a Debian té per defecte una mida de clau de 2048 bits. Malauradament alguns servidors DNS només poden gestionar entrades de text amb una longitud màxima de 255 caràcters, que queda superada per la mida per defecte de les claus. En aquest cas useu l'opció -b 1024 per triar una mida de clau més petita. Si opendkim-testkey té èxit, l'entrada s'ha configurat correctament. La sintaxi d'aquesta entrada s'explica aquí:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Per configurar opendkim, s'han de triar SOCKET i RUNDIR a /etc/default/opendkim. Tingueu en compte que SOCKET ha de ser accessible des de postfix en el seu entorn «chroot». La configuració addicional es fa a /etc/opendkim.conf. El següent és un extracte de configuració que s'assegura que el Domain “falcot.com” i tots els subdominis (SubDomain) estan signats pel Selector “mail” i la clau privada (KeyFile) /etc/dkimkeys/mail.private. La “relaxada” Canonicalization per a la capçalera i el cos tolera modificacions lleus (per exemple, per una llista de correu). El filtre s'executa tant en la signatura (“s”) com en la verificació (“v”) Mode. Si una signatura no es valida (On-BadSignature), el correu s'ha de posar en 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

També és possible utilitzar múltiples selectors/claus (KeyTable), dominis (SigningTable) i especificar amfitrions interns o de confiança (InternalHosts, ExternalIgnoreList), que poden enviar correu a través del servidor com un dels dominis de signatura sense credencials.

Les següents directives a /etc/postfix/main.cf fan que postfix utilitzi el filtre:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

Per diferenciar signatura i verificació, de vegades és més útil afegir les directives als serveis de /etc/postfix/master.cf.

Hi ha més informació disponible al directori /usr/share/doc/opendkim/ i a les pàgines del manual opendkim(8) i opendkim.conf(5).

Tingueu en compte que spamassassin conté un connector per comprovar el registre DKIM.

11.1.7.3. Integració de l'utenticació de missatges basats en domini, Informes i Conformitat (DMARC)

L'estàndard d'autenticació de missatges basat en dominis, Informes i Conformitat (en anglès «Domain-based Message Authentication, Reporting and Conformance» o DMARC) es pot utilitzar per definir una entrada DNS TXT amb el nom _dmarc i l'acció que s'ha de prendre quan els correus electrònics que contenen el vostre domini com a amfitrió d'enviament no passen la validació utilitzant DKIM i SPF.

→ https://dmarc.org/overview/

Fem un cop d'ull a les entrades de dos grans proveïdors:

# 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;"

Yahoo té una política estricta per a rebutjar tots els correus electrònics que fingeixen ser enviats des d'un compte de Yahoo però que manquen o fallen els controls DKIM i SPF. Google Mail (Gmail) propaga una política molt relaxada, en la qual aquests missatges del domini principal encara haurien de ser acceptats (p=none). Per als subdominis s'han de marcar com a «spam» (sp=quarantine). Les adreces donades a la clau rua es poden utilitzar per enviar informes DMARC agregats. La sintaxi completa s'explica aquí:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

El servidor de correu postfix també pot utilitzar aquesta informació. El paquet opendmarc conté el «milter» necessari. Com amb opendkim, SOCKET i RUNDIR s'han de decidir a /etc/default/opendmarc (per a sòcols d'Unix haureu d'assegurar-vos que es troben dins del «chroot» del postfix). El fitxer de configuració /etc/opendmarc.conf conté comentaris detallats i també s'explica a opendmarc.conf(5). Per defecte, els correus electrònics que no compleixin la validació DMARC no són rebutjats, sinó marcats, afegint un camp apropiat a la capçalera. Per canviar-ho, utilitzeu RejectFailures true.

El filtre de correu s'afegeix a smtpd_milters i non_smtpd_milters. Si hem configurat els «milters» opendkim i opendmarc per funcionar en els ports 12345 i 54321, l'entrada de /etc/postfix/main.cf seria així:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

En lloc seu, el «milter» també es pot aplicar selectivament a un servei a /etc/postfix/master.cf.

11.1.8. SMTP autenticat

Per poder enviar correus electrònics cal que un servidor SMTP sigui accessible; també cal dir que el servidor SMTP pot enviar correus electrònics a través d'ell. Per als usuaris d'itinerància, això pot necessitar canviar regularment la configuració del client SMTP, ja que el servidor SMTP de Falcot rebutja els missatges procedents d'adreces IP que aparentment no pertanyen a l'empresa. Existeixen dues solucions: o bé l'usuari d'itinerància instal·la un servidor SMTP al seu ordinador, o bé utilitza el servidor d'empresa amb alguns mitjans per autenticar-se com a empleat. La solució anterior no es recomana perquè l'ordinador no estarà connectat permanentment, i no podrà reintentar enviar missatges en cas de problemes; ens centrarem en l'última solució.

L'autenticació SMTP amb Postfix es basa en SASL («Simple Authentication and Security Layer» o “Capa de seguretat i autenticació simple”). Requereix instal·lar els paquets libsasl2-modules i sasl2-bin, i després registrar una contrasenya a la base de dades SASL per a cada usuari que necessita autenticar-se al servidor SMTP. Això es fa amb l'ordre saslpasswd2, que agafa diversos paràmetres. L'opció -u defineix el domini d'autenticació, que ha de coincidir amb el paràmetre smtpd_sasl_local_domain a la configuració de Postfix. L'opció -c permet crear un usuari, i -f permet especificar el fitxer a utilitzar si la base de dades SASL necessita ser emmagatzemada en una ubicació diferent de la predeterminada (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]

Adoneu-vos-en que la base de dades SASL es crea al directori de Postfix. Per tal de garantir la coherència, també convertim /etc/sasldb2 en un enllaç simbòlic que apunta a la base de dades utilitzada per Postfix, amb l'ordre ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Ara hem de configurar Postfix per utilitzar SASL. Primer l'usuari postfix ha de ser afegit al grup sasl, de manera que pugui accedir a la base de dades del compte SASL. També es necessiten alguns paràmetres nous per permetre SASL, i el paràmetre smtpd_recipient_restrictions s'ha de configurar per permetre que els clients autenticats amb SASL enviïn correus electrònics lliurement.

Exemple 11.12. Habilitar SASL a /etc/postfix/main.cf

# Activar l'autenticació amb SASL
smtpd_sasl_auth_enable = yes
# Defineix el domini d'autenticació SASL a usar
smtpd_sasl_local_domain = $myhostname
[...]
# Afegir permit_sasl_authenticated abans de reject_unauth_destination
# permet reencaminar el correu enviat pels usuaris autenticats amb SASL
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

Normalment és bona idea no enviar contrasenyes a través d'una connexió sense xifrar. Postfix permet utilitzar diferents configuracions per a cada port (servei) on s'executa. Tots aquests es poden configurar amb diferents regles i directives al fitxer /etc/postfix/master.cf. Per desactivar l'autenticació al port 25 (servei smtpd) afegiu la següent directiva:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

Si per alguna raó els clients utilitzen una ordre obsoleta AUTH (alguns clients de correu molt vells), la interoperabilitat amb ells es pot activar utilitzant la directiva broken_sasl_auth_clients.

EXTRA Client SMTP autenticat

La majoria dels clients de correu electrònic són capaços d'autenticar-se amb un servidor SMTP abans d'enviar missatges sortints, i utilitzar aquesta característica és simple qüestió de configurar els paràmetres apropiats. Si el client en ús no proporciona aquesta característica, la solució és utilitzar un servidor Postfix local i configurar-lo per retransmetre el correu electrònic a través del servidor SMTP remot. En aquest cas, el propi Postfix local serà el client que s'autentiqui amb SASL. Aquí estan els paràmetres necessaris:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

El fitxer /etc/postfix/sasl_passwd ha de contenir el nom d'usuari i la contrasenya per a l'autenticació al servidor mail.falcot.com. Heus aquí un exemple:

[mail.falcot.com]   joe:LyinIsji

Com a tots els fitxers d'associacions de Postfix, aquest fitxer s'ha de convertir en /etc/postfix/sasl_passwd.db amb l'ordre postmap.