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. Å sette opp 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. Å sette opp 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-settinger 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 SSLCertificates 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

Falcot Corp administratorer valgte ut Postfix som elektronisk post-tjener, på grunn av påliteligheten og en enkel konfigurasjon. Faktisk, designet sikrer at hver oppgave blir gjennomført i en prosess med et minimumsett av nødvendige tillatelser, noe som gir en stor minsking i sikkerhetsproblemer.

11.1.1. Å installere Postfix

postfix-pakken 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" og "Internet with 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 en lokal brukernavn; hele navnet på maskinen kommer opp som en del etter at-skiltet ("@"). 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. Stanardlisten inneholder dets fulle navn, samt noen få synonymer for localhost, men hoved-domenet falcot.com må legges for hånd. Mer generelt bør dette spørsmålet vanligvis besvares med alle domene-navnene som denne maskinen skal tjene som MX-tjener for; med andre ord, alle domene-navnene 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-registering ved sending av en e-post

Figur 11.1. Rollen til DNS MX-registering 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 relevant 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, får 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. Å sette opp 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 destinert til lokale brukere. Postfix gir to interessante funksjoner for håndtering av virtuelle domener.

11.1.2.1. Vituelle alias-domener

Et virtuell 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
/etc/postfix/virtual-filen 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 virtuell postboksdomene er lagret i postkasser som ikke er lagt til en lokal systembruker.
Aktivering av et virtuell postboks domene krever navngiving av dette domenet i virtual_mailbox_domains-variabelen, og refererer til en postkassekartleggingsfil i virtual_mailbox_maps. virtual_mailbox_base-parameteren inneholder katalogen der postkasser vil bli lagret.
virtual_uid_maps-parameteret (respektivt virtual_gid_maps) refererer til filen som inneholder kartleggingen mellom e-postadressen og system-brukeren (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 domene, og det andre feltet er plasseringen av den tilhørende postkasse (relativt 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. maildir-formatet 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. /etc/postfix/vmailbox-filen

# 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ønsket e-post (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

smtpd_client_restrictions-direktivet 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, relkefølge betyr noe, og ganske enkelt å bytte om på to regler kan føre til et vidt forskjellig resultat.
permit_mynetworks-direktivet, brukt som den første regelen, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av konfigureringsvariabelen mynetworks).
Den 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 løser til IP-adressen. Denne begrensningen er ofte altfor streng, siden mange e-posttjenere vil ikke ha en omvendt DNS for deres IP-adresse. Dette forklarer hvorfor Falcot administratorer forvalgte warn_if_rejectmodifikatoren 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 ble faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.
Den tredje direktivet lar 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 fra det derfor ikke gå gjennom følgende filtreringsregler.
De to siste regler avviser enhver melding som kommer fra en tjener oppført i en av de angitte i svartelisten. 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 at 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.
reject_invalid_hostname-regelen avviser e-poster når EHLO-visningen lister et vertsnavn med feilaktig syntaks. reject_non_fqdn_hostname-regelen avviser meldinger når annonserte vertsnavn er ikke et fullt kvalifisert domenenavn (inkludert et domenenavn så vel som et vertsnavn). reject_unknown_hostname regelen 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 av 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, kan denne informasjonen 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
/etc/postfix/access_sender-tabellen gir en noe spesiell behandling for noen avsendere. Dette betyr vanligvis å liste noen av avsendere i en hvitliste eller en svartliste.
reject_unknown_sender_domain-regelen krever et gyldig avsenderdomene, siden det er nødvendig for en gyldig adresse. reject_unlisted_sender-regel 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, avviser reject_non_fqdn_sender-regelen 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 sjekkene av avsenderadressen.

Eksempel 11.9. Sjekk av mottaker

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient
reject_unauth_destination er den grunnleggende regelen som krever at meldinger utenfra som adresseres til oss; men 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.
reject_unlisted_recipient-regelen 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 kreve 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, bortsett fra annonsere hva som kommer etterpå. Det kan fortsatt være underlagt sjekk.

Eksempel 11.10. DATA-sjekk

smtpd_data_restrictions = reject_unauth_pipelining
reject_unauth_pipelining-direktivene 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 spammeroboter, 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. Postfix kjenner 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, en rekke SMTP-klienter trenger ikke 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å meldingsinneholdet

Validerings- og begrensningsystemet 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" 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 bare ville bety å miste tid.
Postfix leverer ikke -pakken inneholder akkurat et slikt program, laget for å levere grensesnittet til denne delegerte adgangspolitikk-tjenesten. problemfritt, men det er en funksjon, der beslutningen om å godta eller forkaste en gitt melding, kan delegeres til et eksternt program. postgrey-pakken inneholder akkurat et slikt program, laget for å være bindeleddet til denne delegerte adgangspolitikk-tjenesten.
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 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 support-tjenesten). 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 filter-tilpasning med "restriction class"-konseptet. Klassene er deklarert i smtpd_restriction_classes-parameteret, og definert på den samme måten som smtpd_recipient_restrictions. check_recipient_access-direktivet 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,
        check_recipient_access hash:/etc/postfix/recipient_access

Eksempel 11.14. /etc/postfix/recipient_access-filen

# 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-post-vedlegg, 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 arkiveres i ett av disse formatene.
Oppgaven med å koble sammen antivirus og e-postserveren legges til clamav-milter. milter (kort for 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-posttjener-filtre. Milters ble først introdusert av Sendmail, men Postfix kom snart etter.
Så snart clamav-milter-pakken 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. -u-valget definerer godkjenningsdomenet, som må samsvare med smtpd_sasl_local_domain-parameteret i Postfix-oppsettet. -c-valget 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
[... type jean's password twice ...]
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. Flrst, 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,
[...]