Product SiteDocumentation Site

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

11.1. Posttjener
11.1.1. Å installere Postfix
11.1.2. Konfigurering av virtuelle domener
11.1.3. Restriksjoner for å motta og sende
11.1.4. Å sette opp greylisting
11.1.5. Å tilpasse filtre basert på mottakeren
11.1.6. Å integrere en antivirus
11.1.7. Godkjent SMTP
11.2. Nett-tjener (HTTP)
11.2.1. Å installere Apache
11.2.2. Å konfigurere virtuelle verter
11.2.3. Vanlige direktiver
11.2.4. Logg-analysatorer
11.3. FTP-filtjener
11.4. NFS-filtjener
11.4.1. Å sikre NFS
11.4.2. NFS-tjener
11.4.3. NFS-klient
11.5. Oppsett av Windows Shares med Samba
11.5.1. Samba-tjener
11.5.2. Samba-klient
11.6. HTTP/FTP-mellomtjener
11.6.1. Å installere
11.6.2. Å konfigurere et hurtiglager
11.6.3. Å sette opp et filter
11.7. LDAP-mappe
11.7.1. Å installere
11.7.2. Å fylle ut mappen
11.7.3. Å håndtere kontoer med LDAP
11.8. Sanntids kommunikasjonstjenester
11.8.1. DNS-innstillinger for RTC-tjenester
11.8.2. TURN-tjener
11.8.3. SIP-mellomtjener
11.8.4. XMPP-tjener
11.8.5. Å kjøre tjenester på port 443
11.8.6. Å legge til WebRTC
Nettjenester er de programmene som brukerne direkte samhandler med 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.
Mange moderne nettverkstjenester krever krypteringsteknologi for å fungere på en pålitelig og sikker måte, spesielt når de brukes på det offentlige Internettet. X.509-sertifikater (som også kan refereres til som SSL-sertifikater) eller TLS-sertifikater) brukes ofte til dette formålet. Et sertifikat for et bestemt domene kan ofte deles mellom mer enn en av tjenestene som er omtalt i dette kapittelet.

11.1. Posttjener

Administratorer i Falcot Corp valgte ut Postfix som elektronisk posttjener, på grunn av påliteligheten og en enkel konfigurasjon. Designet sikrer fakstisk at hver oppgave blir gjennomført i en prosess med et minimum sett av nødvendige tillatelser, et godt forebyggende tiltak mot sikkerhetsproblemer.

11.1.1. Å installere Postfix

Pakken postfix omfatter den viktigste SMTP-nissen. Andre pakker (slik som postfix-ldap og postfix-pgsql) legger til ekstra funksjonalitet til Postfix, medregnet tilgang til kartdatabaser. Du bør bare installere dem hvis du vet at du trenger dem.
Flere Debconf-spørsmål stilles under installasjonen av pakken. Svarene tillater å generere en første versjon av /etc/postfix/main.cf-konfigureringsfil.
Det første spørsmålet håndterer typen oppsett. Bare to av de foreslåtte svarene passer for en Internett-tilkoblet tjener, «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, og er derfor godt tilpasset 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 ISPs SMTP-tjener, som alltid er konfigurert til å godta e-post som kommer fra ISPs brukere, og videresende den på riktig måte. Dette oppsettet (med smartvert) passer også for tjenere som ikke er permanent koblet til Internett, da det unngår å måtte håndtere en kø med ikke-leverbare meldinger som ikke kan leveres, og som må prøves igjen senere.
Det andre spørsmålet omfatter det fulle navnet på maskinen, som brukes til å generere e-postadresser fra et lokalt brukernavn; hele navnet på maskinen kommer opp som en del etter at-skiltet/krøllalfa («@»). For Falcots del bør svaret være mail.falcot.com. Dette er det eneste spørsmålet ved oppstart, men oppsettet den fører til er ikke komplett nok for behovene til Falcot, noe som er grunnen til at administratorene kjører dpkg-reconfigure postfix, slik at man er i stand til å tilpasse flere parametre.
Ett av de ekstra spørsmålene gjelder å få alle domenenavn knyttet til denne maskinen. Standardlisten inneholder dets fulle navn, samt noen få synonymer for localhost, men hoveddomenet falcot.com må legges for hånd. Mer generelt bør dette spørsmålet vanligvis besvares med alle domenenavnene som denne maskinen skal tjene som MX-tjener for; med andre ord, alle domenenavnene for hvem DNS sier at denne maskinen vil akseptere e-post. Denne informasjonen ender opp i mydestination-variabelen i Postfixs hovedoppsettsfil - /etc/postfix/main.cf.
Rollen til DNS MX-registrering ved sending av en e-post

Figur 11.1. Rollen til DNS MX-registrering ved sending av en e-post

I noen tilfeller kan installasjonen også spørre hvilke nettverk som skal få lov til å sende e-post via maskinen. I standardkonfigurasjonen aksepterer Postfix kun e-postmeldinger som kommer fra selve maskinen; det lokale nettverket vil vanligvis bli lagt til. Falcot Corp-administratorene la til 192.168.0.0/16 til standardsvaret. Hvis spørsmålet ikke er spurt, er den relevante variabel i konfigurasjonsfilen mynetworks, slik som i eksemplet nedenfor.
Lokal e-post kan også leveres via procmail. Dette verktøyet tillater brukere å sortere sin innkommende e-post etter regler som er lagret i deres ~/.procmailrc-fil.
Etter dette første trinnet, fikk administratorene den etterfølgende konfigurasjonsfil; den vil bli brukt som et utgangspunkt for å legge til noe ekstra funksjonalitet i de neste seksjonene.

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

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

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

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

11.1.2. Konfigurering av virtuelle domener

E-posttjeneren kan motta e-post adressert til andre domener i tillegg til hoveddomenet. Disse er da kjent som virtuelle domener. I de fleste tilfeller der dette skjer, blir 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. Vituelle alias-domener

Et virtuelt alias-domene inneholder kun aliaser, dvs. adresser som bare videresender e-post til andre adresser.
Et slikt domene aktiveres ved å legge navnet sitt til virtual_alias_domains-variabelen, og vise til en adressekartleggingsfil i virtual_alias_maps-variabelen.

Eksempel 11.2. Direktiver til å legge i /etc/postfix/main.cf-filen

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
Filen /etc/postfix/virtual beskriver en kartlegging med en ganske grei syntaks: Hver linje inneholder to felt adskilt med mellomrom: Det første feltet er alias-navnet, det andre feltet er en liste over e-postadresser der det omdirigeres. Den spesielle @domain.com-syntaksen dekker alle gjenstående aliaser i et domene.

Eksempel 11.3. Eksempel /etc/postfix/virtual-fil

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

11.1.2.2. Virtuelle postboksdomener

Meldinger adressert til et virtuelt postboksdomene er lagret i postkasser som ikke er lagt til en lokal systembruker.
Aktivering av et virtuelt postboksdomene krever navngiving av dette domenet i virtual_mailbox_domains-variabelen, og refererer til en postkassekartleggingsfil i virtual_mailbox_maps. Parameteren virtual_mailbox_base inneholder katalogen der postkasser vil bli lagret.
Parameteret virtual_uid_maps (respektivt virtual_gid_maps) refererer til filen som inneholder kartleggingen mellom e-postadressen og systembrukeren (henholdsvis gruppen) som «eier» den tilsvarende postkassen. For å få alle postkasser som eies av samme eier/gruppe tilordner static:5000 syntaksen en fast UID/GID (med verdien 5000 her).

Eksempel 11.4. Direktiver til å legge i /etc/postfix/main.cf-filen

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
Igjen, syntaksen til /etc/postfix/vmailbox-filen er ganske enkel: To felt adskilt med mellomrom. Det første feltet er en e-postadresse i et av de virtuelle domenene, og det andre feltet er plasseringen av den tilhørende postkasse (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 postkasse, hver enkelt melding blir lagret i en egen fil. I mbox-formatet, på den andre siden, er hele postboksen lagret i en fil, og hver linje som starter med «From » (From fulgt av et mellomrom) signaliserer starten på en ny e-post.

Eksempel 11.5. Filen /etc/postfix/vmailbox

# Jean's email is stored as maildir, with
# one file per email in a dedicated directory
jean@falcot.org falcot.org/jean/
# Sophie's email is stored in a traditional "mbox" file,
# with all mails concatenated into one single file
sophie@falcot.org falcot.org/sophie

11.1.3. Restriksjoner for å motta og sende

Det økende antall uønskede e-poster (spam) krever større strenghet når man bestemmer hvilke e-postmeldinger en tjener bør akseptere. Denne seksjonen presenterer noen av de strategiene som inngår i Postfix.

11.1.3.1. IP-baserte adgangsrestriksjoner

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

Eksempel 11.6. Restriksjoner basert på klientadresse

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org
Når en variabel inneholder en liste med regler, som i eksempelet ovenfor, er disse reglene evaluert i rekkefølge fra den første til den siste. Hver regel kan akseptere meldingen, avvise den, eller overlate avgjørelsen til en følgende regel. Som en konsekvens, rekkefølge betyr noe, og ganske enkelt å bytte om på to regler kan føre til et vidt forskjellig resultat.
Direktivet permit_mynetworks, brukt som den første regelen, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av konfigureringsvariabelen mynetworks).
Det andre direktivet vil normalt avvise e-post fra maskiner uten en helt gyldig DNS-konfigurasjon. En slik gyldig konfigurasjon betyr at IP-adressen kan løses til et navn, og at dette navnet i sin tur går over til IP-adressen. Denne begrensningen er ofte altfor streng, siden mange e-posttjenere ikke vil ha en omvendt DNS for deres IP-adresse. Dette forklarer hvorfor Falcot administratorer forvalgte warn_if_reject-modifikatoren til reject_unknown_client-direktivet: Denne modifikatoren gjør om avvisningen til en enkel varsling registrert i loggene. Administratorene kan deretter holde et øye med antall meldinger som ville bli avvist hvis regelen faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.
Den tredje direktivet tillater administratoren å sette opp en svarteliste og en hviteliste med e-postservere, lagret i /etc/postfix/access_clientip-filen. Tjenere i hvitelisten anses som klarert, og e-poster som kommer derfra går derfor ikke gjennom følgende filtreringsregler.
De to siste regler avviser enhver melding som kommer fra en tjener oppført i en av de angitte svartelister. RBL er en forkortelse for Remote Black List. Det er flere slike lister, men alle lister dårlig konfigurerte tjenere som spammere bruker for å videresende sin e-post, samt uventede post-formidlere, for eksempel maskiner infisert med ormer eller virus.

11.1.3.2. Sjekke validiteten til EHLO eller HELO-kommandoer

Hver SMTP-utveksling starter med en HELO (eller EHLO)-kommando, etterfulgt av navnet på e-posttjeneren som sender; det kan være interessant å kontrollere gyldigheten av dette navnet.

Eksempel 11.7. Restriksjoner på navnet som er meldt i EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname
Det første permit_mynetworks-direktivet 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 de kan legge seg til med meningsløse navn.
Regelen reject_invalid_hostname avviser e-poster når EHLO-visningen lister et vertsnavn med feilaktig syntaks. Regelen reject_non_fqdn_hostname avviser meldinger når annonserte vertsnavn ikke er et fullt kvalifisert domenenavn (inkludert et domenenavn så vel som et vertsnavn). Regelen reject_unknown_hostname avviser meldinger hvis det annonserte navnet ikke finnes i DNS. Siden denne siste regelen dessverre fører til altfor mange avslag, snudde administratorene denne virkningen med en enkel advarsel ved hjelp av warn_if_reject-modifikatoren som et første skritt; de kan fjerne denne modifikatoren på et senere tidspunkt, etter å ha gjennomgått resultatene av å bruke regelen.
Å bruke permit_mynetworks som den første regelen har en interessant bieffekt: De følgende regler gjelder kun verter utenfor det lokale nettverket. Dette tillater svartelisting av alle verter som varsler seg selv som en del av falcot.com, 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. Godta eller nekte basert på annonsert 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.8. 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
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 e-poster å blir sendt fra en ugyldig adresse i falcot.com-domenet, og meldinger som skriver seg fra joe.bloggs@falcot.com aksepteres kun dersom en slik adresse virkelig eksisterer.
Til slutt, reject_non_fqdn_sender-regelen avviser e-post som angivelig kommer fra adresser uten et fullt kvalifisert domenenavn. I praksis betyr dette å avvise e-postmeldinger som kommer fra user@machine: Adressen må bli annonsert som enten user@machine.example.com, eller user@example.com.

11.1.3.4. Akesept eller avvising basert på mottaker

Hver e-post har minst én mottaker, 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.9. Sjekk av mottaker

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient
Regelen reject_unauth_destination er den grunnleggende regelen som krever at meldinger utenfra adresseres til oss; meldinger sendt til en adresse som ikke er 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 den er 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 som sendes til ikke-eksisterende lokale brukere, noe som gir mening. Endelig avslår reject_non_fqdn_recipient-regelen ikke-fullt-kvalifiserte adresser; dette gjør det umulig å sende en 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.

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.10. DATA-sjekk

smtpd_data_restrictions = reject_unauth_pipelining
Direktivene reject_unauth_pipelining fører til at meldingen blir avvist hvis avsender sender en kommando før svaret på den forrige kommando er 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 mulig på så kort tid som mulig.

11.1.3.6. Å bruke restriksjoner

Selv om de ovennevnte kommandoene validerer informasjon på ulike stadier av SMTP-utvekslingen, sender Postfix bare selve avslaget som et svar på RCPT TO-kommandoen.
Dette betyr at selv om meldingen blir avvist på grunn av en ugyldig EHLO-kommando, kjenner Postfix avsenderen og mottakeren da avvisningen ble varslet. 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 stadier i SMTP-utvekslingen. Dette tillater å definere mer finkornede tillatelser, som for eksempel avvise en ikke-lokal tilkobling hvis den melder seg med en lokal avsender.

11.1.3.7. Filtrering basert på meldingsinnholdet

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

Eksempel 11.11. Å aktivere 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.12. Eksempelfil /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification
Den første sjekker toppteksten som viser til programvaren for e-mail; hvis GOTO Sarbacane (en samling e-post-programvare) blir funnet, blir meldingen avvist. Det andre uttrykket styrer meldingens subjekt; hvis det nevner et virusvarsel, kan vi bestemme oss for ikke å avvise meldingen, men straks å forkaste den i stedet.
Bruk av disse filtrene 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. Å sette opp greylisting

«Grålisting» («Greylisting») er en filtreringsteknikk der en melding som i utgangspunktet er avvist med en midlertidig feilkode, og bare aksepteres etter et ytterligere forsøk etter noen tid. Denne filtreringen er spesielt effektiv mot spam som sendes av de mange maskinene som er infisert av ormer og virus, fordi denne programvaren sjelden fungerer som en 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 bare ville bety å miste tid.
Postfix leverer ikke grålisting (greylisting) fritt, men det er en funksjon, der beslutningen om å godta eller forkaste en gitt melding, kan delegeres til et eksternt program. Pakken postgrey inneholder akkurat et slikt program, laget for å være bindeleddet til denne delegerte adgangspolitikktjenesten.
Så snart postgrey er installert, kjører den som en nisse, og lytter på port 10023. Postfix kan så konfigureres til å bruke den ved å legge til check_policy_service-parameteret som en 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-nissen, og sende den informasjon om den aktuelle meldingen. På sin side, vurderer Postgrey trillingen/trippelen IP-«adresse/avsende/mottaker», og sjekker i sin database om det samme trillingen er sett i det siste. Hvis ja, 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.

11.1.5. Å tilpasse filtre basert på mottakeren

Seksjon 11.1.3, «Restriksjoner for å motta og sende» og Seksjon 11.1.4, «Å sette opp greylisting» gjennomgikk mange av de mulige restriksjonene. De har alle sin nytte ved å begrense mengden mottatt spam, men har alle også sine ulemper. Det er derfor mer og mer vanlig å tilpasse filtrene til mottakeren. På Falcot Corp er grålisting interessant for de fleste brukere, men det hindrer arbeidet til noen brukere som har behov for korte forsinkelser på sine e-poster (som for eksempel teknisk supporttjeneste). 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; trenger denne tjenesten en ikke-filtrert adresse for å kunne utveksle e-poster.
Postfix gir en slik filtertilpasning med «restriction class»-konseptet. Klassene er deklarert i smtpd_restriction_classes-parameteret, og definert på den samme måten som smtpd_recipient_restrictions. Direktivet check_recipient_access definerer deretter en tabell som legger en gitt mottaker til det riktige settet med restriksjoner.

Eksempel 11.13. Definere 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,Defining restriction classes in
        check_recipient_access hash:/etc/postfix/recipient_access

Eksempel 11.14. Filen /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Å integrere en antivirus

Med mange virus som sirkulerer som e-postvedlegg, blir det viktig å sette opp et antivirus på inngangspunktet til bedriftens nettverk, da, til tross for en holdningskampanje, vil noen brukere fortsatt åpne vedlegg i åpenbart frynsete meldinger.
Falcot administrators valgte clamav som sin frie antivirus. Hovedpakken er clamav, men de installerte også noen få ekstra pakker, som arj, unzoo, unrar og lha, siden de er nødvendige for at antiviruset skal analysere vedlegg arkivert i ett av disse formatene.
Oppgaven med å koble sammen antivirus og e-postserveren legges til clamav-milter. Et milter (kort for 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 konfigureres til å kjøre på en TCP-port i stedet for på standarden som heter socket. Dette kan oppnås med dpkg-reconfigure clamav-milter. Når du blir bedt om «Communication interface with Sendmail», svar «inet:10002@127.0.0.1».
Standard ClamAV-konfigurasjon passer til de fleste situasjoner, men noen viktige parametere kan fortsatt tilpasses med dpkg-reconfigure clamav-base.
Det siste trinnet er å be Postfix å bruke det nettopp konfigurerte filteret. Det er en enkel sak å legge følgende direktiv til /etc/postfix/main.cf:
# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
Hvis antivirus skaper problemer, kan denne linjen kommenteres ut, og service postfix reload 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. 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 konfigurasjonen 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å konfigureres til å tillate at SASL-godkjente klienter fritt kan sende e-post.

Eksempel 11.15. Å sette opp SASL i /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]