Kapittel 11. Nettverkstjenester: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Nettverkstjenester er de programmene brukerne samhandler med direkte i sitt daglige arbeid. De er toppen av informasjonssystemets isfjell, og dette kapittelet fokuserer på dem — de skjulte delene de er avhengige av er den infrastrukturen vi allerede har beskrevet. De krever vanligvis krypteringsteknologien beskrevet i Seksjon 10.2, «X.509-sertifikater».

11.1. E-posttjener

Administratorene i Falcot Corp har valgt Postfix som elektronisk posttjener, fordi den er pålitelig og har et enkelt oppsett. Den har en utforming som sikrer at hver oppgave utføres i en prosess som kun har et minimalt sett nødvendige tilganger. Dette er et godt forebyggende tiltak mot sikkerhetsproblemer.

ALTERNATIV Exim4-tjeneren

Debian bruker Exim4 som forvalgt e-posttjener (det vil si at den første installasjonen inkluderer Exim4). Oppsettet bestemmes av en egen pakke, exim4-config, og tilpasses automatisk på grunnlag av svar på et sett Debconf-spørsmål . Spørsmålene som stilles når postfix-pakken installeres, fungerer på tilsvarende måte.

Oppsettet kan enten være i én fil (/etc/exim4/exim4.conf.template), eller delt opp i en rekke oppsettssnutter som lagres under /etc/exim4/conf.d/. I begge tilfeller bruker update-exim4.conf filene som maler for å lage /var/lib/exim4/config.autogenerated. Det er denne sistnevnte filen som brukes av Exim4. Takket være denne mekanismen kan verdier hentet fra Exims debconf-oppsett — som er lagret i /etc/exim4/update-exim4.conf.conf — kan legges inn i Exims oppsettsfil, selv når administratoren eller en annen pakke har endret Exims forvalgte oppsett.

Syntaksen til Exim4s oppsettsfil har en viss læringskurve og sine særegenheter, men når en så har forstått disse er Exim4 en svært komplett og kraftig e-posttjener, noe som gjenspeiles av de titalls sidene med dokumentasjon.

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

11.1.1. Installasjon av Postfix

Pakken postfix omfatter den viktigste SMTP-bakgrunnsprosessen. Andre pakker (slik som postfix-ldap og postfix-pgsql) legger til ekstra funksjonalitet i Postfix, medregnet tilgang til koblingsdatabaser. Du bør kun installere dem hvis du vet at du trenger dem.

Flere Debconf-spørsmål stilles under installasjonen av pakken. Svarene gjør det mulig å generere en første versjon av oppsettsfilen /etc/postfix/main.cf.

Det første spørsmålet håndterer oppsettstypen. Bare to av de foreslåtte svarene passer for en tjenermaskin tilkoblet Internett, «Internet site» (Internett-nettsted) og «Internet with smarthost» (Internett med smartvert). Førstnevnte passer for en tjener som mottar innkommende e-post, og sender utgående e-post direkte til sine mottakere. Et oppsett av denne typen passer derfor godt i Falcot Corps tilfelle. Sistnevnte passer for en tjener som mottar innkommende e-post som normalt, men som sender utgående e-post via en mellomliggende SMTP-tjener - en «smartvert» - i stedet for direkte til mottakerens tjener. Dette er mest nyttig for personer med en dynamisk IP-adresse, siden mange e-posttjenere avviser meldinger som kommer rett fra en slik IP-adresse. I dette tilfellet vil en smartvert vanligvis være ISP-ens SMTP-tjener, som alltid er satt opp til å godta e-post som kommer fra ISP-ens (Internett-leverandørens) brukere, og videresende den på riktig måte. Dette oppsettet (med smartvert) passer også for tjenermaskiner som ikke er permanent tilkoblet Internett, fordi det ikke er nødvendig å håndtere en kø med meldinger som ikke kan leveres, for så å prøve å sende dem på nytt senere.

Det andre spørsmålet omhandler maskinen fulle navn, som brukes til å generere e-postadresser fra et lokalt brukernavn. Maskinens fulle navn blir den delen som kommer etter at-tegnet/krøllalfa («@»). For Falcots del bør svaret være mail.falcot.com. Dette er det eneste spørsmålet ved oppstart, men det gir et oppsett som ikke dekker behovene til Falcot. Derfor bruker administratorene dpkg-reconfigure postfix, slik at de kan tilpasse flere parametre.

Ett av de ekstra spørsmålene gjelder å innhente alle domenenavnene som er tilknyttet denne maskinen. Forvalgslisten inneholder maskinens fulle navn og noen få synonymer for localhost, men hoveddomenet falcot.com må legges inn for hånd. Som regel bør dette spørsmålet besvares med alle domenenavnene denne maskinen skal tjene som MX-tjener for; med andre ord, alle domenenavnene DNS sier at denne maskinen vil ta imot e-post for. Denne informasjonen ender opp i mydestination-variabelen i Postfixs hovedoppsettsfil - /etc/postfix/main.cf.

Figur 11.1. Rollen til DNS MX-oppføringer ved sending av e-post

I noen tilfeller kan installasjonen også spørre hvilke nettverk som skal få lov til å sende e-post via maskinen. I forvalgsoppsettet aksepterer Postfix kun e-postmeldinger som har sitt opphav fra maskinen selv; det lokale nettverket vil vanligvis bli lagt til. Falcot Corp-administratorene la til 192.168.0.0/16 til det forvalgte svaret. Hvis dette spørsmålet ikke stilles, er den relevante variabelen i oppsettsfilen mynetworks, slik som i eksemplet nedenfor.

Lokal e-post kan også leveres via procmail. Med dette verktøyet kan brukere sortere sin innkommende e-post etter regler som hver enkelt bruker kan lagre i sin ~/.procmailrc-fil. Både Postfix og Exim4 foreslår procmail som forvalg, men det finnes alternativer som maildrop, eller Sieve-filtre.

Etter dette første trinnet, fikk administratorene følgende oppsettsfil; den vil bli brukt som utgangspunkt for å legge inn ekstra funksjonalitet i de neste delene.

Eksempel 11.1. Innledende /etc/postfix/main.cf-fil

# 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

SIKKERHET «Slangeolje»-SSL-sertifikater

«Slangeolje»-sertifikatene har fått sitt navn fra slangeolje, som ble solgt som «medisin» av skruppelløse kvakksalvere i gamle dager, og de har absolutt ingen verdi. Du kan ikke stole på dem når de går god for tjeneren, siden de genereres automatisk med selvsignerte sertifikater. De kan likevel være nyttige for å gjøre utvekslingene mer private.

Generelt bør de kun brukes i testøyemed, der normal tjenestedrift krever ekte sertifikater. Let's Encrypt-initiativet tilbyr gratis og pålitelige SSL/TLS-sertifikater, som kan genereres ved hjelp av certbot-pakken som beskrevet i Seksjon 11.2.2, «Legge til støtte for SSL». Deretter kan de brukes i postfix på denne måten:

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

En annen måte å generere egne sertifikater på ved bruk av din egen sertifikatsmyndighet er beskrevet i Seksjon 10.2.2, «Offentlig nøkkel-infrastruktur: easy-rsa».

11.1.2. Oppsett av virtuelle domener

E-posttjeneren kan motta e-post adressert til andre domener i tillegg til hoveddomenet. Disse blir da kjent som virtuelle domener. I de fleste tilfeller der dette skjer, er e-postene i siste instans ikke ment for lokale brukere. Postfix gir to interessante funksjoner for håndtering av virtuelle domener.

11.1.2.1. Virtuelle alias-domener

Et virtuelt alias-domene inneholder kun aliaser, dvs. adresser som kun videresender e-post til andre adresser.

Et slikt domene aktiveres ved å legge til domenets navn i virtual_alias_domains-variabelen, og viser til en fil med adressetilordninger i virtual_alias_maps-variabelen.

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

Filen /etc/postfix/virtual beskriver en tilordning med en ganske grei syntaks: Hver linje inneholder to felter adskilt med mellomrom: Det første feltet er alias-navnet, det andre feltet en liste over e-postadresser det videresendes til. Den spesielle @domain.com-syntaksen dekker alle de andre aliasene innenfor et domene.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# Aliaset nedenfor er generisk og dekker alle adresser i domenet
# falcotsbrand.com som ikke finnes andre steder i denne filen.
# Disse adressene videresender e-post til brukeren med samme 
# navn i domenet falcot.com.
@falcotsbrand.com           @falcot.com

Når det er gjort endringer i /etc/postfix/virtual, må Postfix-tabellen i /etc/postfix/virtual.db oppdateres ved hjelp av sudo postmap /etc/postfix/virtual.

11.1.2.2. Virtuelle postboks-domener

Meldinger som adresseres til et virtuelt postboks-domene, lagres i postbokser som ikke er tilknyttet en lokal systembruker.

Når du skal aktivere et virtuelt postboks-domene, må du navngi dette domenet i virtual_mailbox_domains-variabelen, og vise til en fil med postbokstilordninger i virtual_mailbox_maps. Parameteret virtual_mailbox_base inneholder katalogen der postboksene vil bli lagret.

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

Parameteret virtual_uid_maps (og det lignende parameteret virtual_gid_maps) viser til filen som inneholder tilordningen mellom e-postadressen og systembrukeren (henholdsvis gruppen) som «eier» den tilsvarende postboksen. Syntaksen static:5000 gir en fast UID/GID (med verdien 5000) for å sørge for at alle postbokser eies av samme eier/gruppe.

Også her er syntaksen til /etc/postfix/vmailbox-filen ganske enkel: To felt adskilt med mellomrom. Det første feltet er en e-postadresse i ett av de virtuelle domenene, og det andre feltet plasseringen av den tilhørende postboksen (i forhold til katalogen spesifisert i virtual_mailbox_base). Hvis postboksen ender med en skråstrek (/), blir e-postene lagret i maildir-formatet; ellers blir det tradisjonelle mbox-formatet brukt. Formatet maildir bruker en hel katalog for å lagre en postboks, det vil si at hver enkelt melding blir lagret i én fil. I mbox-formatet, derimot, lagres hele postboksen i én fil, og hver linje som starter med «From » (altså From fulgt av et mellomrom), signaliserer starten på en ny e-post.

# E-posten til Jean lagres i maildir-formatet, med
# en fil per e-post i en egen katalog
jean@falcot.org falcot.org/jean/
# E-posten til Sophie lagres i en tradisjonell mbox-fil,
# der alle e-postene legges etter hverandre i en enkelt fil
sophie@falcot.org falcot.org/sophie

11.1.3. Restriksjoner for mottak og forsendelse

Det økende antallet uønskede e-poster (spam) krever økt nøkternhet når man bestemmer hvilke e-postmeldinger en tjener skal akseptere. Denne delen presenterer noen av de strategiene som inngår i Postfix.

Hvis avvisningsreglene er for strenge, kan det hende at selv legitim e-posttrafikk blir utestengt. Det er derfor en god vane å teste restriksjoner og forhindre permanent avvisning av forespørsler i den tiden soft_bounce = ja-anvisningen er i bruk. Ved å plassere warn_if_reject foran en avvisningsanvisning logges kun en melding i stedet for å avvise forespørselen.

KULTUR Søppelpost/spam-problemet

«Søppelpost» og «spam» er generelle begrep som brukes for å betegne all uønsket kommersiell e-post (også kjent som UCE-er) som oversvømmer våre elektroniske postkasser. De skruppelløse individer som sender dem, er kjent som spammere. De bryr seg lite om ubehaget de forårsaker, siden det å sende en e-post koster svært lite, og bare en svært liten andel av mottakerne trenger å dras mot tilbudene for at søppel-e-postoperasjonen tjener mer penger enn det koster. Prosessen er for det meste automatisert, og en offentliggjort e-postadresse (for eksempel på et nettforum, registrert på en adresseliste, eller på en blogg, og så videre) vil sannsynligvis bli oppdaget av spammernes robotkravlere, og utsatt for en endeløs strøm av uønskede meldinger. I tillegg vil hver kontakt funnet på et kompromittert system bli et mål.

Alle systemadministratorer prøver å møte dette ubehaget med spamfiltre, men selvfølgelig vil spammere holde seg oppdatert for å prøve å omgå disse filterne. Noen leier til og med nettverk av maskiner kompromittert med en orm fra ulike kriminelle organisasjoner. Nyere statistikk anslår at opptil 95 prosent av all e-post som sirkulerer på Internett er spam!

11.1.3.1. IP-baserte adgangsrestriksjoner

Anvisningen smtpd_client_restrictions styrer hvilke maskiner som får lov til å kommunisere med e-posttjeneren.

Når en variabel inneholder en regelliste, som i eksempelet nedenfor, blir disse vurdert i rekkefølge fra første til siste regel. Hver av dem kan akseptere meldingen, avvise den, eller overlate avgjørelsen til en påfølgende regel. Som konsekvens betyr rekkefølgen de er opplistet i noe, og å ganske enkelt å bytte om på to regler kan føre til helt forskjellig resultat.

Eksempel 11.2. Restriksjoner basert på klientadresse

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

Anvisningen permit_mynetworks, brukt som første regel, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av oppsettsvariabelen mynetworks).

Den andre anvisningen vil normalt avvise e-post fra maskiner uten et helt gyldig DNS-oppsett. Et slikt gyldig oppsett betyr at IP-adressen kan tilknyttes et navn, og at dette navnet i sin tur utledes til IP-adressen. Denne begrensningen er ofte altfor streng, siden mange e-posttjenere ikke har en omvendt DNS for deres IP-adresse. Dette forklarer hvorfor Falcot-administratorene la til warn_if_reject-modifikatoren til som forvalg for reject_unknown_client-anvisningen: Denne modifikatoren gjør avslaget til en enkel advarsel registrert i loggen. Administratorene kan deretter holde et øye med antall meldinger som ville blitt avvist hvis regelen faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.

TIPS access-tabeller

Restriksjonskriteriet omfatter administrator-modifiserbare tabeller som lister kombinasjoner av avsendere, IP-adresser, og tillatte eller forbudte vertsnavn. Disse tabellene kan opprettes ved å bruke en kopi av /usr/share/doc/postfix/examples/access-filen som er å finne i postfix-doc-pakken og forklart i tilgang(5). Denne modellen er selv-dokumentert i dens kommentarer, som betyr at hver tabell beskriver egen syntaks.

Tabellen /etc/postfix/access_clientip viser IP-adresser og nettverk; /etc/postfix/access_helo lister domenenavn; /etc/postfix/access_sender inneholder e-postadresser tilhørende avsendere. Alle disse filene må omgjøres til ordboktabeller (et format optimalisert for rask tilgang) etter hver endring med sudo postmap /etc/postfix/fil-kommandoen.

check_client_access-anvisningen lar administratoren å sette opp en svarteliste og en hvitliste over e-posttjenere, lagret i /etc/postfix/access_clientip-filen. Tjenere i hvitlisten anses som klarert, og e-poster som kommer derfra går derfor ikke gjennom følgende filtreringsregler.

De siste fire reglene avviser alle meldinger som kommer fra en tjener oppført i en av de indikerte svartelistene. RBL er et akronym for Remote Black List, og RHSBL står for Right-Hand Side Black List. Forskjellen er at førstnevnte lister IP-adresser, mens sistnevnte viser domenenavn. Det er flere slike tjenester. De viser domener og IP-adresser med dårlig omdømme, dårlig oppsatte tjenere som spammere bruker til å videresende e-postene sine, samt uventede e-postreléer som maskiner infisert med ormer eller virus.

11.1.3.2. Sjekking av gyldigheten til `EHLO` eller `HELO`-kommandoer

Hver SMTP-utveksling starter med en HELO (eller EHLO)-kommando, etterfulgt av navnet på e-posttjeneren som utfører forsendelsen. Det kan være interessant å sjekke gyldigheten for dette navnet. For å fullt ut håndheve restriksjonene oppført i smtpd_helo_restrictions må alternativet smtpd_helo_required aktiveres. Ellers kan klienter hoppe over restriksjonene ved å ikke sende HELO/EHLO-kommandoen.

Eksempel 11.3. Restriksjoner på navnet som er meldt i 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

Den første permit_mynetworks-anvisningen tillater alle maskiner på det lokale nettverket å fritt legge seg til. Dette er viktig, fordi noen e-postprogrammer ikke respekterer denne delen av SMTP-protokollen godt nok, og kan introdusere seg selv med meningsløse navn.

Regelen reject_invalid_helo_hostname avviser e-poster når EHLO-visningen lister et vertsnavn med feilaktig syntaks. Regelen reject_non_fqdn_helo_hostname avviser meldinger når annonserte vertsnavn ikke er et fullt kvalifiserte domenenavn (inkludert et domenenavn så vel som et vertsnavn). Regelen reject_unknown_helo_hostname avviser meldinger hvis det annonserte navnet ikke finnes i tilhørende DNS. Siden denne siste regelen dessverre fører til mange avslag, snudde administratorene denne virkningen til én advarsel ved hjelp av warn_if_reject-modifikatoren som første skritt; modifikatoren kan fjernes på et senere tidspunkt, etter at resultatet av å bruke regelen er gjennomgått.

reject_rhsbl_helo gjør det mulig å angi en svarteliste for å kontrollere vertsnavnet mot en RHSBL.

Å bruke permit_mynetworks som første regel har en interessant bieffekt: De påfølgende reglene gjelder kun verter utenfor det lokale nettverket. Dette tillater svartelisting av alle verter som varsler seg selv som en del av falcot.com-nettverket, for eksempel for å legge til en falcot.com REJECT You are not in our network!-linje til /etc/postfix/access_helo-filen.

11.1.3.3. Godkjenning eller nekting av e-poster basert på kunngjort avsender

Hver melding har en avsender, annonsert av MAIL FROM-kommandoen fra SMTP-protokollen; igjen, denne informasjonen kan bli validert på flere forskjellige måter.

Eksempel 11.4. Sjekking av sender

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

Tabellen /etc/postfix/access_sender gir en noe spesiell behandling for noen avsendere. Dette betyr vanligvis å liste noen av avsenderne i en hviteliste eller en svarteliste.

Regelen reject_unknown_sender_domain krever et gyldig avsenderdomene, siden det er nødvendig for en gyldig adresse. Regelen reject_unlisted_sender avviser lokale sendere hvis adressen ikke eksisterer; dette forhindrer at e-poster blir sendt fra en ugyldig adresse i falcot.com-domenet, og at meldinger som skriver seg fra joe.bloggs@falcot.com kun aksepteres dersom en slik adresse virkelig eksisterer.

Til slutt, reject_non_fqdn_sender-regelen avviser e-post som angivelig kommer fra adresser uten fullt kvalifisert domenenavn. I praksis betyr dette å avvise e-postmeldinger som kommer fra user@machine: Adressen må annonseres enten som user@machine.example.com, eller user@example.com.

reject_rhsbl_sender-regelen avviser avsendere basert på en (domenebasert) RHSBL-tjeneste.

11.1.3.4. Akseptering eller avvisning av e-poster basert på mottaker

Hver e-post har minst én mottager, kunngjort med RCPT TO-kommandoen i SMTP-protokollen. Disse adressene garanterer også validering, selv om det kan være mindre relevant enn kontrollene av avsenderadressen.

Eksempel 11.5. Sjekk av mottager

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

Regelen reject_unauth_destination er den grunnleggende regelen som krever at meldinger utenfra adresseres til oss; meldinger sendt til en adresse ikke betjent med denne tjeneren blir avvist. Uten denne regelen, blir tjeneren et åpent relé som tillater spammere å sende uønsket e-post. Denne regelen er derfor obligatorisk, og tas best inn nær begynnelsen av listen, slik at ingen andre regler kan autorisere meldingen før destinasjonen er kontrollert.

Regelen reject_unlisted_recipient avviser meldinger sendt til ikke-eksisterende lokale brukere, noe som gir mening. Til sist avslår reject_non_fqdn_recipient-regelen ikke-fullt-kvalifiserte adresser; dette gjør det umulig å sende e-post til jean, eller jean@machine, og krever bruk av hele adressen i stedet, som for eksempel jean@machine.falcot.com, eller jean@falcot.com.

permit-anvisning ved slutten er ikke nødvendig. Men det kan være nyttig på slutten av en begrensningsliste for å gjøre forvalgt praksis eksplisitt.

11.1.3.5. Restriksjoner knyttet til `DATA`-kommandoen

DATA-kommandoen til SMTP avgis før innholdet i meldingen. Den gir ikke noen informasjon per se (av seg selv), bortsett fra å annonsere hva som kommer etterpå. Den kan fortsatt være underlagt sjekk.

Eksempel 11.6. DATA-sjekk

smtpd_data_restrictions = reject_unauth_pipelining

reject_unauth_pipelining-anvisningene fører til at meldingen blir avvist hvis avsenderen sender en kommando før svaret på forrige kommando har blitt sendt. Dette beskytter mot en vanlig optimalisering som brukes av spamroboter, siden de vanligvis ikke bryr seg det grann om svar, og bare fokuserer på å sende så mange e-poster som fort som mulig.

11.1.3.6. Bruk av restriksjoner

Selv om ovennevnte kommandoene kontrollerer informasjon på ulike stadier av SMTP-utvekslingen, sender Postfix selve avslaget i et svar på RCPT TO-kommandoen som forvalg.

Dette betyr at selv om meldingen blir avvist på grunn av en ugyldig EHLO-kommando, kjenner Postfix avsenderen og mottakeren når avvisningen varsles. Den kan da logge et mer eksplisitt budskap enn om transaksjonen hadde blitt avbrutt fra starten. I tillegg trenger ikke en rekke SMTP-klienter å forvente feil med de tidlige SMTP-kommandoene, og disse klientene blir mindre forstyrret av dette ved denne senere avvisningen.

En siste fordel ved dette valget er at reglene kan akkumulere informasjon fra de ulike stadiene i SMTP-utvekslingen. Dette gjør det mulig å definere mer finmaskede tilganger, som for eksempel avvising av en ikke-lokal tilkobling hvis den melder seg med en lokal avsender.

Forvalgt virkemåte styres av regelen smtpd_delay_reject.

11.1.3.7. Filtrering basert på meldingsinnholdet

Gyldighets- og begrensningssystemet ville ikke være fullstendig uten å kunne sjekke meldingsinnholdet. Postfix skiller mellom sjekking av topptekster i e-postene - fra den som gjelder selve meldingskroppen.

Eksempel 11.7. Aktivering av innholdsbaserte filtre

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

Begge filer inneholder en liste med vanlige uttrykk (kjent som regexps eller regexes), og tilhørende tiltak som skal utløses når e-posthoder (eller kroppen) samsvarer med uttrykket.

Eksempel 11.8. Eksempelfil /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

DET GRUNNLEGGENDE Regulært utrykk

Betegnelsen regulært uttrykk (eng: regular expression) (forkortet til regexp, eller regex) refererer til en felles notasjon for å gi en beskrivelse av innholdet og/eller strukturen til en tegnstreng. Visse spesialtegn gjør det mulig å definere alternativer (for eksempel foo|bar treffer på enten «foo» eller «bar»), sett med tillatte tegn (for eksempel betyr [0-9] "hvilket som helst siffer", og . - et punktum - betyr "hvilket som helst tegn"), kvantifisering (s? samsvarer enten med s, eller den tomme strengen, med andre ord 0 eller 1 forekomsten av s; s+ samsvarer med en eller flere påfølgende s tegn; og så videre). Parenteser tillater gruppering av søkeresultater.

Den presise syntaksen til disse uttrykkene varierer mellom de verktøyene som bruker dem, men de grunnleggende funksjonene er like.

→ https://no.wikipedia.org/wiki/Regul%C3%A6rt_uttrykk

Den første sjekker toppteksten som viser til programvaren for e-postprogramvaren; hvis GOTO Sarbacane (en samling e-postprogramvare) blir funnet, blir meldingen avvist. Det andre uttrykket styrer meldingens emne; hvis det nevner et virusvarsel, kan vi bestemme oss for ikke å avvise meldingen, men straks å forkaste den istedenfor.

Bruk av disse filterne er et tveegget sverd, fordi det er lett å gjøre reglene for allmenne, og som resultat miste legitim e-post. I disse tilfellene vil ikke bare meldingene gå tapt, men avsenderne får uønskede (og irriterende) feilmeldinger.

11.1.4. Oppsett av grålisting

«Grålisting» («Greylisting») er en filtreringsteknikk der en melding som i utgangspunktet er avvist med midlertidig feilkode, og kun aksepteres etter et ytterligere forsøk etter en tid. Denne filtreringen er spesielt effektiv mot søppelpost som sendes av de mange maskinene som er infisert av ormer og virus, fordi denne programvaren sjeldent fungerer som full SMTP-agent (ved å kontrollere feilkode, og prøve meldinger som har feilet på nytt senere), spesielt fordi mange av de oppsamlede adressene virkelig er ugyldige, og prøve dem på nytt kun medfører tap av tid.

Postfix tilbyr ikke innebygd grålisting («greylisting»), men det er en funksjon, der beslutningen om å godta eller forkaste en gitt melding, kan delegeres til et eksternt program. Pakken postgrey inneholder nettopp et slikt program, laget for å være bindeleddet til denne delegerte adgangspolitikktjenesten.

Så snart postgrey er installert, kjører den som bakgrunnsprosess, og lytter til port 10023. Postfix kan så settes opp til å bruke den ved å legge til check_policy_service-parameteret som ekstra begrensning:

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

Hver gang Postfix treffer denne regelen i regelsettet, vil den koble til postgrey-bakgrunnsprosessen, og sende den informasjon om den aktuelle meldingen. På sin side, vurderer Postgrey trillingen/trippelen IP-«adresse/avsender/mottaker», og sjekker i sin database om den samme trillingen er sett i det siste. Hvis så er tilfelle, svarer Postgrey at meldingen skal godtas; hvis ikke, indikerer svaret at meldingen skal avvises midlertidig, og trillingen blir registrert i databasen.

Den største ulempen med grålisting er at legitime meldinger bli forsinket, noe som ikke alltid er akseptabelt. Det øker også belastningen på tjenerne som sender mange legitime e-poster.

I PRAKSIS Svakhetene med grålisting

Teoretisk bør grålisting kun forsinke den første e-posten fra en gitt sender til en gitt mottaker, og den typiske forsinkelsen er i størrelsesorden minutter. Dette kan i virkeligheten imidlertid avvike noe. Noen store ISP-er bruker klynger av SMTP-tjenere, og når en melding innledningsvis er avslått, er kanskje den tjeneren som prøver å gjenoppta overføringen ikke den samme som den opprinnelige. Når det skjer, får den andre tjeneren også en midlertidig feilmelding på grunn av grålisting, og så videre. Det kan ta flere timer før overføringen er forsøkt av en tjener som allerede har vært involvert, ettersom SMTP-tjenere ved hver feil vanligvis øker forsinkelsen.

Som en konsekvens kan innkommende IP-adressen variere i tid, selv for én avsender. Men det går videre; selv avsenderadressen kan endres. For eksempel; mange e-postlistetjenere koder inn ekstra informasjon i avsenderadressen, for å være i stand til å håndtere feilmeldinger (kjent som bounces). Hver ny melding sendt til en adresseliste kan så trenge å gå gjennom grålisting, noe som betyr at den må lagres (midlertidig) på senderens tjener. For svært store e-postlister (med titusenvis av abonnenter), kan dette fort bli et problem.

For å redusere disse ulempene administrerer Postgrey en hviteliste med slike steder, og meldinger som kommer fra dem, blir umiddelbart akseptert uten å gjennomgå grålisting. Denne listen kan lett tilpasses de lokale behov, ettersom den er lagret i /etc/postgrey/whitelist_clients-filen.

FOR VIDEREKOMMENDE Selektiv grålisting med milter-greylist

Ulempene med grålisting kan reduseres ved å kun bruke grålisting på undergruppen av klienter som allerede regnes som sannsynlige kilder til søppelpost (fordi de er oppført i en DNS-svarteliste). Dette er ikke mulig med postgrey men milter-greylist kan anvendes på en slik måte.

I sådant fall, ettersom DNS-svartelister aldri utløser en endelig avvisning, blir det naturlig å bruke aggressive svartelister, medregnet de som viser alle dynamiske IP-adresser fra ISP-klienter (for eksempel pbl.spamhaus.org, eller dul.dnsbl.sorbs.net).

Siden milter-greylist bruker Sendmails sitt milter-grensesnitt, er Postfix-siden av oppsettet begrenset til «smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock». Manualsiden greylist.conf(5) dokumenterer /etc/milter-greylist/greylist.conf, og de utallige måter å sette opp milter-grålisting på. Du vil også måtte redigere /etc/default/milter-greylist for faktisk å aktivere tjenesten.

11.1.5. Tilpasning av filtre basert på mottager

Seksjon 11.1.3, «Restriksjoner for mottak og forsendelse» og Seksjon 11.1.4, «Oppsett av grålisting» gjennomgikk mange av de mulige restriksjonene. De har alle sin nytte ved å begrense mengden mottatt søppelpost, men har alle også sine ulemper. Det er derfor mer og mer vanlig å tilpasse filtrene til mottageren. I Falcot Corp er grålisting interessant for de fleste brukere, men det hindrer arbeidet til noen brukere som har behov for korte forsinkelser for sine e-poster (som for eksempel teknisk brukerstøttetjeneste). Tilsvarende, den kommersielle tjenesten har noen ganger problemer med å motta e-post fra noen asiatiske leverandører som kan være oppført i svartelister; denne tjenesten trenger en ikke-filtrert adresse for å kunne utveksle e-poster.

Postfix gir en slik filtertilpasning med «restriction class»-konseptet. Klassene deklareres i smtpd_restriction_classes-parametret, og defineres på samme måten som smtpd_recipient_restrictions. Anvisningen check_recipient_access definerer deretter en tabell som legger en gitt mottaker til det riktige sett med begrensninger.

Eksempel 11.9. Definering av begrensningsklasser i 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

Eksempel 11.10. Filen /etc/postfix/recipient_access

# Adresser som ikke filtreres
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressiv filtrering for noen privilegerte brukere
joe@falcot.com         aggressive

# Spesialregel for den som styrer e-postlisten
sympa@falcot.com       reject_unverified_sender

# Grålisting som forvalg
falcot.com             greylisting

11.1.6. Integrering av antivirusfilter

Med mange virus som sirkulerer som e-postvedlegg, blir det viktig å sette opp en antivirusløsning ved første inngangspunkt til bedriftens nettverk, da, til tross for en holdningskampanje, vil noen brukere fortsatt åpne vedlegg i åpenbart tvilsomme meldinger.

SIKKERHET Kontrovers rundt antivirus-programvare

Bruken av virusskannere, eller såkalt antivirusprogramvare, er kontroversielt. Det er vanligvis et tidsgap mellom utgivelsen av noen deler av skadeprogramvare og tillegget med deteksjonsregler til antivirusdatabasen. I løpet av dette gapet er det ingen programvarebasert beskyttelse. Videre krever bruken ofte å kjøre ekstra programvare, for eksempel for å dekomprimere arkiver og skanne alle typer kjørbare filer, noe som drastisk øker utnyttelsespotensialet til selve antivirusprogramvaren. Bruk av slike programvareløsninger kan derfor aldri erstatte bevissthetskampanjer og enkle atferdsregler (som aldri å åpne uønskede sendte vedlegg og så videre).

Falcot- administratorene valgte clamav fra homonymous-pakken.

Oppgaven med å koble sammen antivirus og e-posttjeneren legges til clamav-milter. Et milter (kort for e-postfilter (mail filter)) er et filterprogram spesielt utviklet for å kommunisere med e-posttjenere. Et milter bruker et standard programmeringsgrensesnitt (API) som gir mye bedre ytelse enn eksterne e-posttjenerfiltre. Milters ble først introdusert av Sendmail, men Postfix kom snart etter.

Så snart pakken clamav-milter er installert, skal milter settes opp til å kjøre på en TCP-port i stedet for på forvalget som heter socket. Dette kan oppnås med dpkg-reconfigure clamav-milter. Når du blir bedt om «Kommunikasjonsgrensesnitt med Sendmail», svar «inet:10002@127.0.0.1».

Forvalgt ClamAV-oppsett passer til de fleste situasjoner, men noen viktige parametre kan fortsatt tilpasses med dpkg-reconfigure clamav-base.

Det siste trinnet er å be Postfix om å bruke det nylig oppsatte filteret. Det er en enkel sak å legge til følgende anvisning i /etc/postfix/main.cf:

# Virus-sjekk med ClamAV-milter
smtpd_milters = inet:[127.0.0.1]:10002

Hvis antivirusprogrammet skaper problemer, kan denne linjen kommenteres ut, og systemctl reload postfix skal kjøres slik at denne endringen er tatt hensyn til.

Alle meldinger som Postfix håndterer, går nå igjennom antivirusfilteret.

11.1.7. Kamp mot søppelpost med SPF, DKIM og DMARC

Det høye antallet uønskede e-poster sendt hver dag førte til opprettelsen av flere standarder, som tar sikte på å validere, at den sendende verten av en e-post er autorisert og at e-posten ikke har blitt tuklet med. Følgende systemer er alle DNS-baserte, og krever at administratorene ikke bare har kontroll over e-posttjeneren, men også over DNS for det aktuelle domenet.

VÆR VARSOM Kontroversiell diskusjon

Som alle andre verktøy, har de følgende standardene begrensninger og konkrete effekter når de tas i bruk. De kan (og bør) føre til at e-postmeldinger blir avvist eller kanskje bare kastet. Hvis det skjer med noen legitime e-postmeldinger (noen ganger sendt fra en feiloppsatt SMTP-tjener), forårsaker det vanligvis sinne og mangel på forståelse hos brukeren. Derfor brukes disse reglene ofte som en «myk feil» eller en «myk avvisning», noe som vanligvis betyr at det bare fører til å legge til et (hodefelt-) merke i den berørte e-posten. Det er folk som tror at dette gjør disse standardene er «feilutformet». Bestem selv og vær forsiktig med hvor strengt du velger å anvende disse standardene.

11.1.7.1. Integrasjon av forsendelsespraksisrammeverk (SPF)

Forsendelsespraksisrammeverk (SPF) brukes til å validere om en bestemt e-posttjener har lov til å sende e-post for et gitt domene. Det blir for det meste satt opp via DNS. Syntaksen for oppføringen som skal gjøres, forklares i detalj på:

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

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

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

Følgende er et eksempel på en DNS-oppføring som sier at alle domenets Mail Exchange Resource Records (MX-RRs) har lov til å sende e-post for det gjeldende domenet, og at det for alle andre forbys. DNS-oppføringen trenger ikke gis et navn. Men for å bruke include-anvisningen må det ha et.

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

La oss ta en kjapp titt på falcot.org-oppføringen.

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

Den sier at IP-adressen til avsenderen må samsvare med A-oppføringen for avsenderdomenet, eller må være oppført som en av Mail Exchange Resource Records for gjeldende domene, eller må være en av de tre nevnte IPv4-adressene. Alle andre verter skal merkes til å forby forsendelse av e-post til avsenderdomenet. Sistnevnte kalles en «myk feil» og er ment brukt til å sette et merke på e-posten, men fortsatt akseptere den.

postfix e-posttjeneren kan sjekke SPF-oppføringen for innkommende e-postmeldinger ved hjelp av postfix-policyd-spf-python-pakken, en regelagent skrevet i Python. Filen /usr/share/doc/postfix-policyd-spf-python/README.Debian beskriver de nødvendige trinnene for å integrere agenten i postfix, så vi vil ikke repetere det her.

Oppsettet gjøres i filen /etc/postfix-policyd-spf-python/policyd-spf.conf, som er dokumentert i sin helhet i policyd-spf.conf(5) og /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Hovedoppsettsparameterne er HELO_reject og Mail_From_reject, som setter opp om e-postmeldinger skal avvises (Fail) eller akseptert med en topptekst som legges til (False), hvis kontroller mislykkes. Sistnevnte er ofte nyttig, når meldingen behandles videre av et søppelpostfilter.

Hvis resultatet er ment å brukes av opendmarc (Seksjon 11.1.7.3, «Integrasjon av Domain-based Message Authentication, Reporting og Conformance (DMARC)»), må Header_Type settes til AR.

Merk at spamassassin inneholder et programtillegg for å sjekke SPF-oppføringen.

11.1.7.2. Integrasjon av DomainKeys (DKIM) Signering og sjekking

Domain Keys Identified Mail (DKIM)-standarden er et avsenderautentiseringssystem. Posttransportagenten, her postfix, legger til en digital signatur tilknyttet domenenavnet til hodet på en utgående e-postmeldinger. Den mottagende part kan validere meldingstekst- og hodefeltene ved å kontrollere signaturen mot en offentlig nøkkel, som hentes fra avsenderens DNS-oppføringer.

→ http://dkim.org/

De nødvendige programmene er tilgjengelig i opendkim og opendkim-tools-pakkene.

Først må den private nøkkelen opprettes ved hjelp av kommandoen opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR som må være et unikt navn for nøkkelen. Det kan være så enkelt som "e-post", eller opprettelsesdatoen, hvis du planlegger å rotere nøkler.

Eksempel 11.11. Opprettelse av privat nøkkel for signering av e-post fra falcot.com

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

Dette vil opprette filene /etc/dkimkeys/mail.private og /etc/dkimkeys/mail.txt og sette riktig eierskap. Den første filen inneholder den private nøkkelen. Sistnevnte inneholder den offentlige nøkkelen, som må legges til i DNS:

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

Forvalget for opendkim-pakken i Debian er 2048-bits nøkkelstørrelse. Dessverre kan noen DNS-tjenere kun håndtere tekstoppføringer med maksimal lengde på 255 tegn, som overskrides av den valgte forvalgsnøkkelstørrelsen. I dette tilfellet bruker du alternativet -b 1024 for å velge en mindre nøkkelstørrelse. Hvis opendkim-testkey lykkes, er oppføringen opprettet. Syntaksen for oppføringen er forklart her:

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

→ https://sv.wikipedia.org/wiki/DomainKeys_Identified_Mail

For å sette opp opendkim så må en velge SOCKET og RUNDIR /etc/default/opendkim. Vær oppmerksom på at SOCKET må være tilgjengelig fra postfix i sitt chroot-ede miljø. Det videre oppsettet gjøres i /etc/opendkim.conf. Følgende er et utdrag av oppsettet, som sørger for at Domain «falcot.com» og alle underdomener (SubDomain) er signert av Selector «mail» og den enkle private nøkkelen (KeyFile) /etc/dkimkeys/mail.private. Bruk av «relaxed» i Canonicalization for både overskrift og kropp tåler små endringer (for eksempel av en e-postlisteprogramvare). Filteret kjører både ved signering («s») og verifisering («v») Mode. Hvis en signatur ikke valideres (On-BadSignature), så settes e-posten i karantene («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

Det er også mulig å bruke flere velgere/nøkler (KeyTable), domener (SigningTable) og angi interne eller klarerte verter (InternalHosts, ExternalIgnoreList), som kan sende e-post via tjeneren som ett av signeringsdomenene uten legitimering.

Følgende anvisning i /etc/postfix/main.cf sørger for at postfix bruker filteret:

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

For å differensiere signering og verifisering er det i stedet noen ganger mer nyttig å legge til anvisningene som del av tjenestene i /etc/postfix/master.cf.

Mer info er tilgjengelig i katalogen /usr/share/doc/opendkim/ og i manualsidene opendkim(. 8) og opendkim.conf(5).

Merk at spamassassin inneholder et programtillegg for å sjekke SPF-oppføringen.

11.1.7.3. Integrasjon av Domain-based Message Authentication, Reporting og Conformance (DMARC)

Standarden Domain-based Message Authentication, Reporting and Conformance (DMARC) kan brukes til å definere en DNS TXT-oppføring med navnet _dmarc og informasjon om handlingen som bør utføres når e-postmeldinger, som inneholder domenet ditt som avsendervert, ikke klarer å validere ved hjelp av DKIM og SPF.

→ https://dmarc.org/overview/

La oss se på oppføringene til to store leverandører:

# 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 har en streng policy med å avvise alle e-postmeldinger som utgir seg for å bli sendt fra en Yahoo-konto, men mangler eller mislykkes med DKIM og SPF sjekker. Google Mail (Gmail) har en svært avslappet policy, der slike meldinger fra hoveddomenet fortsatt skal aksepteres (p=none). For underdomener bør de merkes som spam (sp=quarantine). Adressene som er oppgitt i rua-nøkkelen, kan brukes til å sende aggregerte DMARC-rapporter også. Den fullstendige syntaksen er forklart her:

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

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

E-posttjeneren postfix kan også bruke denne informasjonen. Pakken opendmarc inneholder det nødvendige e-postfilter. I likhet med for opendkim må SOCKET og RUNDIR velges i /etc/default/opendmarc (for Unix sockets må du sørge for at de er inne i postfix chrootet for å bli funnet). Oppsettfilen /etc/opendmarc.conf inneholder detaljerte kommentarer og er også forklart i opendmarc.conf(5). I utgangspunktet avvises ikke e-postmeldinger som ikke klarer DMARC-valideringen, men flagges, ved å legge til et passende hodefelt. Hvis du vil endre dette, kan du bruke RejectFailures true.

E-postfilteret blir deretter lagt til smtpd_milters og non_smtpd_milters. Hvis vi satte opp opendkim og opendmarc e-postfiltreret til å kjøre på porter 12345 og 54321, ser oppføringen i /etc/postfix/main.cf slik ut:

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

Milteret (e-postfilteret) kan også selektivt brukes på en tjeneste i /etc/postfix/master.cf i stedet.

11.1.8. Godkjent SMTP

Å kunne sende e-poster krever tilgang på en SMTP-tjener; det krever også nevnte SMTP-tjener for å sende e-post igjennom den. For flyttbare enheter kan det trenges jevnlig endring av oppsettet til SMTP-klienten, ettersom Falcots SMTP-tjener avviser meldinger som kommer fra IP-adresser som tilsynelatende ikke tilhører selskapet. To løsninger finnes: Enten installerer brukeren en SMTP-tjener på datamaskinen sin, eller de fortsetter å bruke selskapets tjener med noen metoder for å autentisere seg som en ansatt. Den første løsningen er ikke anbefalt siden maskinen ikke vil være permanent tilkoblet, og ikke være i stand til igjen å prøve å sende meldinger i tilfelle problemer. Vi vil fokusere på sistnevnte løsning.

SMTP-autentisering i Postfix hviler på SASL (Simple Authentication and Security Layer). Det krever installasjon av libsasl2-modules og sasl2-bin-pakker, deretter å registrere et passord i SASL-databasen for hver bruker som trenger autentisering på SMTP-tjeneren. Dette gjøres med saslpasswd2-kommandoen, som krever flere parametre. Valget -u definerer godkjenningsdomenet, som må samsvare med smtpd_sasl_local_domain-parameteret i Postfix-oppsettet. Valget -c tillater å lage en bruker, og -f kan spesifisere filen som skal brukes hvis SASL-databasen må lagres på et annet sted enn opprinnelig (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... skriv inn passordet til jean to ganger ...]

Merk at SASL-databasen ble opprettet i Postfix-katalogen. For å sikre sammenhengen, omgjør vi også /etc/sasldb2 til en symbolsk lenke som peker på databasen som brukes av Postfix, med ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2-kommandoen.

Nå trenger vi å sette opp Postfix til å bruke SASL. Først må postfix-brukeren legges til sasl-gruppen, slik at den kan få tilgang til SASL-kontoens database. Et par nye parametere må også til for å aktivere SASL, og smtpd_recipient_restrictions-parameteret må settes opp til å tillate at SASL-godkjente klienter fritt kan sende e-post.

Eksempel 11.12. Oppsett av SASL i /etc/postfix/main.cf

# Aktiver SASL-autentisering
smtpd_sasl_auth_enable = yes
# Spesifiser SASL-autentiseringsdomene som skal brukes
smtpd_sasl_local_domain = $myhostname
[...]
# Plassering av permit_sasl_authenticated før reject_unauth_destination
# tillater videresending av e-post sent av SASL-autentiserte brukere
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

Det er vanligvis en god idé å ikke sende passord over en ukryptert tilkobling. Postfix gjør det mulig å bruke separat oppsett for hver port (tjeneste) den kjører på. Alle disse kan settes opp med forskjellige regler og anvisninger i filen /etc/postfix/master.cf. Hvis du vil deaktivere godkjenning i det hele tatt for port 25 (smtpd-tjenesten), legger du til følgende anvisning:

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

Hvis klienter av en eller annen grunn bruker en utdatert AUTH-kommando (noen svært gamle e-postklienter gjør det) så kan en aktivere samvirke mellom dem ved hjelp av broken_sasl_auth_clients-anvisningen.

EKSTRA Autentisert SMTP-klient

De fleste e-postklienter er i stand til å autentisere til en SMTP-tjener før den sender utgående meldinger, og ved hjelp av denne funksjonen er det en enkel sak å sette opp de riktige parameterne. Dersom klienten som brukes ikke leverer den funksjonen, er den midlertidige løsningen å bruke en lokal Postfix-tjener, og sette den opp til å videresende e-post via den eksterne SMTP-tjeneren. I dette tilfellet vil den lokale Postfixen selv være klienten som autentiserer med SASL. Her er de nødvendige parameterne:

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

Filen /etc/postfix/sasl_passwd må inneholde brukernavnet og passordet for å autentisere på mail.falcot.com-tjeneren. Her er et eksempel:

[mail.falcot.com]   joe:LyinIsji

Som for alle Postfix-funksjoner, må denne filen bli omgjort til /etc/postfix/sasl_passwd.db med postmap-kommandoen.