Guide til e-mailserver

Guiden er under re-ombygning - sidst ændret d. 29/07-2019

Postfix' maskot

Indholdsfortegnelse

Baggrund for guiden
Forord
Forudsætninger
Hvad er e-mail
1. kapitel - Databasen
2. kapitel - Certifikater
3. kapitel - Postfix
--- * main.cf
--- * master.cf
4. kapitel - Dovecot
--- * dovecot.conf
5. kapitel - postfixAdmin
6. Kapitel - Webmail
7. kapitel - SQLGrey
8. Kapitel - DNS
9. kapitel - SPF
--- * Opsætning af SPF
--- * Opsætning af SRS
--- * Modtagervalidering
10. kapitel - Fejlfinding
Autosvar
Backup MX
Systembrugere
Links
Noter
Version

Baggrund

Velkommen til Nickys guide om Postfix, Dovecot, antispam og webmail, som bruger en SQL-database til virtuelle domæner og brugere, og som tillader quota, selvbetjening og en lang række af tilpasninger. Resultatet er en robust og konfiguérbar mailserver, som meget let kan udvides med flere domæner og brugere.

Inden vi fortsætter, vil jeg anbefale læseren at skaffe sig lidt at styrke sig på, en bunke tålmodighed, adgang til en fornuftig søgemaskine og mulighed for at tage noter. Et mailsystem ligger i den komplekse ende når det kommer til opsætning og drift, og selv hvis guiden følges til punkt og prikke, er det ikke sikkert at det endelige resultat virker som forventet.

Mit sprogbrug igennem guiden vil være "skal indeholde", "skal installeres" osv., men det er kun for at sætte et system op, som er 100% magen til det jeg beskriver, at man "skal noget som helst". Jeg vil derfor anbefale, at hele guiden læses grundigt igennem inden at arbejdet med at sætte mailserveren op begynder, og når guiden så følges imens mailserveren bliver sat op, kan der foretages ændringer, så mailserveren passer til det konkrete behov.

Min baggrund for at sætte en mailserver op er flerdelt, og dækker bl.a. et ønske om at lære mere om e-mail, da min virksomhed og Ubuntu Danmark begge havde brug for en bedre løsning. Jeg har indtil videre sat mailservere op på FreeBSD, Debian og Ubuntu, så guiden vil være rimelig system agnostisk, og kan sikkert bruges på de fleste UNIX-afledte systemer. Bemærk dog, at fokus vil være på FreeBSD's nuværende stabile udgave. Forudsætningen til det system som mailserveren skal køre på, er adgang til at installere software, og ikke rigtig andet. En fungerende webserver som Apache er nødvendig, hvis webmail ønskes. En SQL-server er central i denne opsætning, og kan ikke undværes, da den skal bruges til brugergodkendelse af Dovecot.

Forord

Det første vi nok er nødt til, er at afdække hvad en mailserver egentlig er for en størrelse, og hvad den kan. I den her sammenhæng bliver en mailserver en samlet løsning, som kan drive ét eller flere domæners e-mail, med deres egne grænseværdier for antallet af postkasser, aliases og quota. Den faktiske mængde af e-mail og brugere som systemet i sidste ende kan håndtere, vil delvist blive bestemt af hardwaren, og ikke kun softwaren, så løsningen kaldes i nogen sammenhænge for en Internet Service Provider, ISP, løsning.

Mailserver med Postfix og Dovecot

Klik for stor udgave. Billedet kan bruges/indlejres med tydelig kildeangivelse.

Der vil også være et modul til selvbetjening, alt efter databasetype, så brugerne får adgang til selv at sætte postkasser og aliases op, og mailserveren vil også kunne fungere som backup mailserver (ofte bare backup MX) for andre mailservere. Administratorer har også adgang til samme selvbetjeningsløsning, og kan tildele brugere forhøjede rettigheder, tilføje nye domæner til mailserveren og andre vedligeholdesopgaver.

Et godt kendskab til det system der bruges er nødvendigt, for jeg gennemgår ikke brugen af shell, SSH, editorer og alt det andet, og serveren bør have minimum 256-512mb ram til rådighed til mail-programmerne, alt efter hvor stor belastningen er. Adgang til Domain Name System, DNS, for det eller de domæner som serveren skal håndterer er nødvendigt, og guiden inkluderer også oplysninger om opsætningen af DNS, ikke bare i forbindelse med mailserveren, men også i forbindelse med Sender Policy Framework, SPF. SPF er en simpel måde, at fortælle modtagere hvem der må sende e-mails fra det eller de pågældende domæner.

Som allerede nævnt, hvis webmail ønskes, så vil et kendskab til webhosting også være nødvendigt, for det er heller ikke noget som jeg går i detaljer med. Grunden er blandt andet, at der med webhosting er nogle sikkerhedsaspekter som bør overvejes, og de ligger p.t. udenfor denne guides formål. Det er dog muligt at guiden udvides til også at dække hosting med Apache.

Så alt i alt er det her ingen begynderguide, og det hænger netop sammen med, at et mailsystem er så komplekst, at en simpel omgang kopiér og indsæt ikke virker ret godt. Igennem guiden prøver jeg at inkludere flest mulige detaljer og links til yderligere læsning. Ulempen er en meget lang guide, men det er i min mening prisen værd.

Forudsætninger

Som tidligere nævnt har jeg sat mailservere op på flere forskellige systemer, og selvom der er forskel på den præcise opsætning imellem systemerne, så er der også rigtig mange ligheder. De fleste forskelle ligger i filplaceringer, hvor FreeBSD fx har sin konfiguration liggende i

/usr/local/etc

imens Debian og Ubuntu bruger

/etc

Igennem guiden vil jeg vise disse forskelle, ved kun at skrive mappenavnet i /usr/local/etc eller /etc som:

postfix/

For en længere diskussion om forskellen, og hvorfor jeg har valgt at bruge /srv som placering til data, kan Filesystem Hierarchy Standard, FHS, med fordel læses.

Til installation af pakker på FreeBSD bruger jeg portmaster, imens apt-get bruges til Debian og Ubuntu. På FreeBSD vil jeg fraråde at bruge pkg, for pkg installerer Postfix uden understøttelse af SQL-servere. Om der bruges make, eller værktøjer som minder om portmaster, er underordnet.

De programmer som indgår i opsætningen er ikke som sådan valgt enkeltvis, men mere ud fra det samlede resultat, hvor de ender med at arbejde godt sammen. Bruger man fx Cyrus IMAP fremfor Dovecot, så er det også nødvendigt at installere og sætte SASL op til brugergodkendelse, for det er ikke bygget ind i Cyrus, som det er i Dovecot.

I sin nuværende udgave beskriver guiden ikke brugen af antivirus, og det kommer den sikkert aldrig til. Virus og spam er ofte 2 sider af samme mønt (eller lort i det her tilfælde), og guiden beskriver bekæmpelse af spam, og hvordan mails kan nægtes modtaget, hvis de fx indeholder exe-filer eller dll's, og/eller kommer fra en kendt spammer og/eller har en høj spamscore.

Linier der starter med en havelåge (#) er en kommando der skal køres, og om den skal køres som root eller ej, vil jeg lade være op til læseren.

De softwareversioner som guiden dækker over, kan findes i bunden sammen med revisionslisten.

Hvad er e-mail

En e-mail er en fil som indeholder ren tekst, og som er delt imellem oplysninger om indholdet, og indholdet i sig selv. Den første e-mail så dagens lys i midt-tresserne, imens at en en egentlig formalisering af e-mail først kom i midt-halvfjerdserne, som følge af problemer med at få det stigende antal af servere til at arbejde sammen. I dag beskriver RFC 5321 fra 2008 hvordan kommunikationen imellem to e-mail-servere som minimum skal ske, imens tilsvarende dokumenter eksisterer for diverse brugerprogrammer.

Oplysningerne om indholdet kaldes normalt for headers i en e-mail, hvilket løst oversat betyder noget der kommer før noget andet. Header-delen indeholder en række af header-linier, som hver især er bygget op med en venstre side og en højre side. Den venstre del er navnet på header-linien, og den højre del er værdien for det navn. Den header-linie der indeholder datoen, og er navngivet Date-headeren, kan fx se sådan her ud:

Date: Sun, 19 Aug 2018 09:01:31 +0000 (UTC)

Nogle header-linier skal være tilstede, hvis standarden skal overholdes, imens at andre er valgfri. En væsentlig pointe er dog, at header-delen ikke afgør hvor en e-mail bliver sendt hen, eller hvem der ender med at modtage den. Det meste af header-delen bliver lavet af afsenderns e-mail-program, og er ment til at give modtageren en række af oplysninger, der i blandt dato for afsendelse. Der kan derfor ikke stoles på den del af header-delen, for den er ikke lavet af et program under ens egen kontrol. Postfix tilføjer en Recieved-header, som indeholder afsenderens IP-adresse, og som står øverst i header-delen. Er der flere Recieved-headers under den, er de tilføjet af andre systemer, og der kan heller ikke stoles på dem.

Håndteringen af e-mail kan derfor siges at være håndteringen af tekst, og de tilhørende tekst-filer. Når en bruger skriver en e-mail og sender den, så opretter brugerens Mail User Agent, MUA'en, en forbindelse til en Mail Transfer Agent, MTA, som brugeren har adgang til. Populære MUA'er er fx Claws Mail, Evolution og Microsoft Outlook, men en MUA kan også være web-baseret sådan som Roundcube og Gmail er det. Når MTA'en, som er Postfix i denne her guide, har modtaget en e-mail, vil den først finde ud af hvilken server der har ansvaret for modtagerens e-mail, og så forsøge at forbinde og aflevere e-mail'en. Det er under denne transaktion imellem MTA'erne, at oplysninger om modtageren bliver udvekslet.

1. kapitel - Databasen

Centralt i denne opsætning står databasen, da den vil indeholde oplysninger om addreser, mailbokse og brugere. Tidligere ville jeg have anbefalet at bruge MySQL for nemhedens skyld, men i forhold til guiden er det underordnet hvilken database der bruges. Hvis valget falder på MySQL, så husk at sætte karaktersættet til utf8mb i stedet for utf8, da utf8 kun undersøtter et subsæt af UTF-8 standarden. Guiden er da også skrevet med udgangspunkt i PostgreSQL, ofte bare Postgres, men der vil også være eksempler der dækker MySQL. Jeg vil dog anbefale at fravælge MySQL, både af ovennænte årsag om UTF-8, men også som følge af Oracles beslutninger omkring OpenOffice.org. På et senere tidspunkt bliver guiden måske udvidet til at dække opsætning og daglig brug af Postgres.

Databasens struktur vil afhænge af om PostfixAdmin skal bruges, og dermed om der ønskes en hjemmeside som giver adgang til selvbetjening. Hvis PostfixAdmin skal bruges bør det blive installeret først, så databasen dækker de behov PostfixAdmin har. Udfordringen er, at hvis Postfixadmin ikke skal bruges, så giver det bedre mening at bruge en anden og simplere struktur i databasen, som igen betyder at Postfix og Dovecot skal forespørge databasen anderledes. Dertil ser det ikke ud til at PostfixAdmin kan installeres på PostgreSQL. Mere om det senere.

Underordnet om PostfixAdmin skal bruges, så kalder jeg databasen for 'vmail' i resten af guiden, og jeg har oprettet 2 eller 3 brugere, hvor den 3. er en evt. 'postfixadmin'-bruger, som skal have fuld adgang. Brugeren 'postfix' skal kun have læseadgang, imens brugeren 'dovecot', udover læseadgang, skal have skriveadgang til 'quota'-tabellerne. I PostfixAdmins struktur er der 2 tabeller med kvota imens den simplere struktur kun har én.

2. kapitel - Certifikater

Det anbefales kraftigt at oprette og bruge certifikater til Transport Layer Security, TLS, ikke kun til IMAP og POP3, og en eventuel webdel, men også til Postfix i sig selv, så den kan kryptere sine forbindelser til andre MTAs. Denne guide vil gøre brug af simple certifikater, som bliver underskrevet lokalt:

# mkdir /etc/ssl/self-signed && cd /etc/ssl/self-signed
# openssl genrsa -des3 -rand /etc/hosts -out smtpd.key 1024 && sudo chmod 600 smtpd.key

Angiv en passphrase

# openssl req -new -key smtpd.key -out smtpd.csr

Skriv passphrasen fra før og besvar spørgsmålene:

2 letter code --> DK
some state --> Tom
city --> Copenhagen
organization name --> Vælg eget
section --> Tom
your name --> Vælg selv
email --> Vælg selv
Kodeord (brug evt. passphrase)
Optional company name --> Tom
# openssl x509 -req -days 365 -in smtpd.csr -signkey smtpd.key -out smtpd.crt

Skriv passphrase igen

# openssl rsa -in smtpd.key -out smtpd.key.unencrypted

Skriv passphrase igen

# mv -f smtpd.key.unencrypted smtpd.key

Og det var det. Der er rigelige mængder af dokumentation på nettet omkring emnet, så hvis yderligere oplysninger ønskes, eller der er et købt certifikat, så vil en hurtig søgning på nettet, kunne ramme bedre end inkluderede links.

Hvis der bruges en anden placering eller navngivning end den beskrevet her, så skal ændringerne afspejles i postfix/main.cf og dovecot/dovecot.conf samt en eventuel webdel.

På sigt er det et mål at gøre brug af DNS-based Authentication of Named Entities, DANE, som giver mulighed for at udgive sit eget certifikat i DNS-systemet, og dermed fjerne behovet for købte certifikater. På samme måde bliver guiden udvidet til at dække Lets Encrypt med acme.sh, når revisionen er færdig.

3. kapitel - Postfix

Jeg vil beskrive hvordan brugernes mail kan placeres i /srv/vmail, og hvordan en systembruger uden privilegier kan bruges af Postfix og Dovecot til processen. E-mail kan ligges hvor det passer bedst, inklusiv på Network File System, NFS, bare husk at rette til hver gang /srv/vmail bliver nævnt.

Først oprettes mail-brugeren og dens tilhørende gruppe:

# groupadd -g 5000 vmail
# useradd -u 5000 -g vmail -s /sbin/nologin -d /home/vmail -m vmail

Og så installeres Postfix med *SQL-adgang:

# portmaster postfix-current
# apt-get install postfix {postfix-mysql|postfix-mysql}

Installation med apt-get udløser nogle spørgsmål:

General type of mail configuration --> Internet Site
System mail name --> example.org

Postfix har kun 2 konfigurationsfiler som standard, og de er:

postfix/main.cf = Alle overordnede indstillinger
postfix/master.cf = Konkrete oplysninger om transport af e-mails
Med den mængde af tilpasninger som skal laves til især main.cf, vil jeg anbefale at flytte de 2 filer, og oprette 2 nye:
# mv /etc/postfix/main.cf /etc/postfix/main.cf_old
# mv /etc/postfix/master.cf /etc/postfix/master.cf_old
# nano /etc/postfix/main.cf

main.cf kan ses her.

I LOCAL SETTINGS er det kun "myhostname" som skal ændres, og for at finde maskinnavnet, kan der fx kigges i /etc/hostname:

# cat /etc/hostname
I afsnittet med VIRTUAL DOMAINS får Postfix at vide, at hele showet skal køres virtuelt fra en database, og at Dovecot vil fungere som Local Delivery Agent, LDA. SASL PART dækker ikke overraskende over hvordan SASL skal bruges, og afsnittet fortæller Postfix at Dovecot's SASL skal bruges. Afsnittet med TLS skal ændres, hvis der bruges andre certifikater end dem denne guide gennemgår, og desuden bør det nævnes, at "smtpd_tls_security_level" og "smtp_tls_security_level" indstillingen "may", dækker over at Postfix foretrækker en krypteret forbindelse til andre MTAs, men ikke forlanger det. Se i dokumentationen for mere: http://www.postfix.org/postconf.5.html#smtp_tls_security_level RESTRICTIONS er sat ret standard op, og parametrene "smtpd_helo_required" og "disable_vrfy_command" er lige efter bogen (hvilket vil sige, at de overholder de gældende Request for Comments, RFCs, på området), og gør det lettere at pille spam fra. De 2 linier "header_checks" og "body_checks" kan bruges til at sortere i e-mails som matcher bestemte mønstre, eller som har bestemte vedhæftelser. Se i dokumentationen for mere: http://www.postfix.org/header_checks.5.html De 3 første linier under "smtpd_recipient_restrictions" anbefales generelt, og linierne der starter med "warn_if_reject" dropper mails der matcher den efterfølgende regel. De 2 linier med "reject_rbl_client" er antispam-lister som stilles gratis til rådighed, og listen fra gbudb.net er lidt mere forsigtig og konservativ end den fra spamhaus.org (ifølge dem selv). Se eventuelt Wikipedia for mere om listerne: https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists Flere lister kan bruges samtidig, men da en del af deres indhold må formodes at overlappe hinanden, er det ikke sikkert at det kan betale sig. "warn_if_reject" kan fjernes fra linierne, hvis der ikke ønskes en advarsel når en email bliver droppet. "smtpd_recipient_restrictions" skal afsluttes med enten "permit" eller "reject", alt efter hvordan ens restriktioner er sat op. I dette tilfælde er det "permit" som skal bruges, da restriktionerne ellers skulle acceptere emails, i stedet for at afvise dem. Desuden er mellemrummene fra liniestart til reglen meget vigtige, da Postfix ellers ikke kan læse reglen. Bemærk i øvrigt at Postfix ikke kommer med en fejl, hvis sådan noget som de mellemrum mangler, reglerne virker bare ikke. Reglerne under "smtpd_data_restrictions" er også lige efter bogen. Det var det for main.cf, så nu er det tid og fylde master.cf med indhold:
# nano /etc/postfix/master.cf
master.cf kan ses her. Bemærk igen, at mellemrummene i starten af linierne er meget vigtige. Indholdet af master.cf er noget mere avanceret end main.cf, og det meste af indholdet er da også det originale, bare uden kommentarer. Det er kun fra og med linien "dovecot unix - n n - - pipe" og ned, at er der tilføjet indhold. Det dækker over hvem der må sende igennem Postfix, hvilket vil sige brugere som er godkendt af Dovecot, og så systembrugere. Dernæst skal Postfix' adgang til databasen oprettes, og det kræver 5 MySQL-filer. De ligges alle 5 i /etc/postfix/ og deres indhold skal være: mysql_sender_login_maps.cf mysql_virtual_alias_maps.cf mysql_virtual_domains_maps.cf mysql_virtual_mailbox_limit_maps.cf mysql_virtual_mailbox_maps.cf Husk at filer oprettet som root automatisk får rettighederne 755, så hvis koden til databasen skal skjules, skal de oprettede filer ændres til 700 eller 600. Efter at Postfix er blevet genstartet, bør loggen kigges igennem for fejl. Vær opmærksom på at fejl i de enkelte mysql_*-filer, først bliver synlige når deres funktion bliver brugt.

4. kapitel - Dovecot

Dovecot er opbygget i moduler, og for at opnå guidens formål, er der brug for understøttelse af både IMAP og POP3. IMAP bruges både af webklienter og egentlige mail-programmer, imens at POP3 kun bruges, hvis et mail-program skal have mulighed for, at hente alle emails ned til klienten, og efterfølgende slette dem fra serveren. POP3 er derfor valgfri, og kan uden problemer undværes. Udover at dovecot-pop3d så ikke skal installeres, så er der nogle linier i /etc/dovecot/dovecot.conf som enten skal kommenteres ud, eller fjernes. Dovecot 1 i Debian 6 understøtter ikke Sieve, så hvis server-side sortering af mails ønskes, så kan Dovecot 2 installeres fra backports. Selvom Dovecot 1 understøtter quota, har jeg ikke ville bruge tid på at konfigurere det i begge versioner, så guiden dækker kun quota i version 2. Debian 7 har Dovecot 2 i sit stabile arkiv, så hoppet fra version 2 i Debian 6 backports, til version 2 i den stabile Debian 7, skulle ikke være ret stort. Derimod er hoppet fra version 1 til 2 stort. Kapitlet dækker begge versioner, så længe Debian understøtter version 1. Dovecot 1 - Debian 6 For at installere Dovecot køres:
# apt-get install dovecot-common dovecot-imapd dovecot-pop3d
Ligesom med Postfix, så anbefaler jeg at flytte Dovecots konfigurationsfil, og oprette en ny:
# mv /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf_old
# nano /etc/dovecot/dovecot.conf
Dovecot's konfigurationsfil kan ses her. Kig filen igennem, og vurdér blandt anden om logging skal aktiveres, og om alle protokollerne skal bruges. Husk at oprette logfilen, hvis logging aktiveres, og at ændre postmaster-adressen. Ønskes POP3 ikke, så skal pop3 og pop3s fjernes fra linien protocols i toppen, og sektionen med protocol pop3 { ... } skal enten fjernes eller kommenteres ud. Quota er sat meget konservativt, men kan tilpasses efter behov. Access Control Lists, ACLs, kan bruges sammen med Dovecot. For flere oplysninger, kan der læses mere om emnet på Dovecots wiki-side: http://wiki.dovecot.org/ACL Da Dovecot har brug for adgang til databasen, skal sql.conf oprettes og have indhold:
# nano /etc/dovecot/sql.conf
sql.conf kan ses her. Det eneste der skal erstattes er KODE, og så skal der tages stilling til, om sæt 1 eller 2 skal bruges. Et sæt består af én user_query og én password_query, og sæt 1 understøtter quota, imens at sæt 2 er uden quota. For at tilslutte med et eksternt mail-program, så bruges SMTP AUTH og STARTTLS sammen med den emailadresse og den adgangskode, som der kan oprettes fra næste kapitel. Husk at koden til databasen ligger åbent i sql.conf, og eventuelt at tjekke loggen for fejl, når Dovecot genstartes. Dovecot 2 - Debian 6 backports / Debian 7 stabil Den nye Dovecot kommer med en "feature", som splitter konfigurationen i 13 forskellige filer, der ligger i /etc/dovecot/conf.d/, og så bruges dovecot.conf til at angive indstillinger som ikke er standard. Det er ikke en model jeg bryder mig om, så den vil guiden ikke følge. Udover at det er besværligt, så introducerer det muligheden for, at man kan skrive den samme indstilling flere steder, og så undre sig over at den ikke virker som forventet. Indholdet af /etc/dovecot/conf.d/ skal derfor flyttes inden at der fortsættes, og der bør tages en kopi af dovecot.conf da der er en del ændringer. Installeres Dovecot fra backports, så kan det gøres med
apt-get -t squeeze-backports install dovecot-core dovecot-imapd\
dovecot-managesieved dovecot-mysql dovecot-pop3d dovecot-sieve
Installeres der fra Debian 7, kan jeg ikke hjælpe, da jeg ikke brugt systemet endnu. Så flyttes de overflødige filer
# mkdir /etc/dovecot/OLD
# mv /etc/dovecot/conf.d/* /etc/dovecot/OLD/
Og så oprettes dovecot.conf
# mv /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf_old
# nano /etc/dovecot/dovecot.conf
Dovecot's konfigurationsfil kan ses her. Kig filen igennem, og vudér bl.a. om POP3, sieve og quota skal bruges. Hvis ikke, så kan de tilhørende sektioner og plugins kommenteres ud eller helt fjernes. Dernæst oprettes Dovecots adgang til databasen
# nano /etc/dovecot/sql.conf
sql.conf kan ses her. Det eneste der skal erstattes er KODE, og så skal der tages stilling til, om sæt 1 eller 2 skal bruges. Et sæt består af én user_query og én password_query, og sæt 1 understøtter quota, imens at sæt 2 er uden quota. Skal quota bruges, så mangler der yderligere 2 filer. Først oprettes dict-user.conf, som giver Dovecot mulighed for, at holde databasen opdateret med den brugte quota
# nano /etc/dovecot/dict-user.conf
dict-user.conf kan ses her. Den anden fil er det shell-script som advarer om højt pladsforbrug (bruges en anden sti, så husk at opdater dovecot.conf)
# nano /home/vmail/scripts/quota-warning.sh
quota-warning.sh kan ses her. Husk at give scriptet +x og minimum 444, samt filendelsen .sh hvis scriptet gemmes direkte fra linket. Det er også nødvendigt at give Dovecot skriverettigheder til tabellen quota2 i postfix-databasen. Dovecot vil så læse mailboksens maksimalt tilladte quota i feltet quota, under tabellen mailbox, og når en mail bliver afleveret, opdatere felterne i tabellen quota2. Bemærk at alle værdier er i bytes. Det er desværre kun muligt at have én quota-værdi i Dovecot, hvilket vil sige at man enten skal håndhæve quota på mailboksene, eller på domænerne. Sidstnævnte er ovenikøbet fejlbehæftet, så i realitet kan Dovecot kun håndhæve quota på mailboksene. Det er forhåbenligt noget der bliver lavet på et senere tidspunkt. Hvis Sieve skal bruges sammen med SpamAssassin, så mangler det globale sieve-script også at blive oprettet. Scriptet vil sortere mails mærket som spam ud i brugernes spam-mappe, og altid blive kørt inden eventuelle scripts brugeren har oprettet
# nano /home/vmail/scripts/spam.sieve
Det globale spam-script kan ses her. Det anbefales at lave en binær udgave af scriptet, så Dovecot ikke skal oversætte det ved hver kørsel
# sievec /home/vmail/scripts/spam.sieve
Hvis sievec advarer om, at det ikke kan lave stat på spam.sieve, så prøv og sæt ejer:gruppe på /home/vmail/scripts/ til vmail, 744 på mappen og 644 på scriptet. Husk at genstarte, og eventuelt at tjekke loggen for fejl.

5. kapitel - postfixAdmin

Set fra en brugers synspunkt, så kan mailserveren ikke undvære et program som postfixAdmin. Det giver adgang til selvbetjening, så brugeren både kan oprette postkasser, aliases og eventuelle autosvar, og gør det samtidig let at administrere de domæner, som mailserveren skal betjene. postfixAdmin arbejder med 2 typer af administratorer: Dem der har adgang til alle domæner og brugere kaldes for superadmins, og dem der har adgang til 1 domæne kaldes for admins. I databasen ser postfixAdmin forskel på de to typer af administratorer, ved at tildele superadmins domænet "ALL". Programmet er ikke i Debians stabile softwarearkiv, men kan hentes fra testing ved hjælp af Debians apt-pinning, eller på programmets hjemmeside: http://postfixadmin.sourceforge.net/ Jeg har installeret postfixAdmin fra arkivet, og under installationen med apt-get svaret på nogle spørgsmål omkring opsætningen. Installeres programmet i stedet fra nettet, så spring spørgsmålene over, og vær opmærksom på at resten af opsætningen kan være lidt anderledes. Først installeres postfixAdmin:
# apt-get install postfixadmin
Tryk OK ved automatisk konfiguration af webserver uden at vælge nogen Vælg nej til at sætte databasen op I /etc/postfixadmin/apache.conf kommenteres eventuelle linier ud, og derefter køres:
# ln -s /usr/share/postfixadmin/ /webdir
Ønskes denne tilgang ikke, så kan /etc/postfixadmin/apache.conf med fordel bruges, til at opnå adgang til postfixAdmin. Åben /etc/postfixadmin/config.inc.php:
# nano /etc/postfixadmin/config.inc.php
Disse tre linier kommenteres ud:
require_once('dbconfig.inc.php'); --> // require_once('dbconfig.inc.php');
if (!isset($dbserver) || empty($dbserver)) --> // if (!isset($dbserver) || empty($dbserver))
$dbserver='localhost'; --> // $dbserver='localhost';
Disse rettes til, så postfixAdmin kan få adgang til databasen 'postfix':
$CONF['postfix_admin_url'] --> htpp://example.org/postfixadmin/
$CONF['database_type'] = $dbtype; --> $CONF['database_type'] = 'mysqli';
$CONF['database_host'] = $dbserver; --> $CONF['database_host'] = 'localhost';
$CONF['database_user'] = $dbuser; --> $CONF['database_user'] = 'postfixadmin';
$CONF['database_password'] = $dbpass; --> $CONF['database_password'] = 'KODE';
$CONF['database_name'] = $dbname; --> $CONF['database_name'] = 'postfix';
Dertil kan porten eventuelt ændres. Denne linie sættes til den administrative email for mailserveren:
$CONF['admin_email'] = 'postmaster@change-this-to-your.domain.tld'; --> 
$CONF['admin_email'] = 'postmaster@example.org';
md5 er ikke en kryptering, og dette er noget af grunden til, at det er vigtigt at bruge SSL på hjemmesiden:
$CONF['encrypt'] = 'md5crypt'; --> $CONF['encrypt'] = 'md5';
Resten af indstillingerne er i princippet valgfrie, men de bør revideres. Det inkluderer som minimum linierne:
$CONF['min_password_length'] = 5; -->
5 er ikke meget, noget mere bør overvejes
$CONF['generate_password'] = 'NO'; --> $CONF['generate_password'] = 'YES';
I dette array sættes standarddresser, og det anbefales at oprette dem. "change-this-to-your.domain.tld" ændres til ens eget domænenavn.
$CONF['default_aliases'] = array (
'abuse' => 'abuse@change-this-to-your.domain.tld',
'hostmaster' => 'hostmaster@change-this-to-your.domain.tld',
'postmaster' => 'postmaster@change-this-to-your.domain.tld',
'webmaster' => 'webmaster@change-this-to-your.domain.tld'
);
$CONF['domain_path'] = 'NO'; --> $CONF['domain_path'] = 'YES';
$CONF['domain_in_mailbox'] = 'YES'; --> $CONF['domain_in_mailbox'] = 'NO';
$CONF['quota'] = 'NO'; --> $CONF['quota'] = 'YES';
$CONF['vacation_control_admin'] = 'YES'; --> $CONF['vacation_control_admin'] = 'NO';
$CONF['alias_control'] = 'NO'; --> $CONF['alias_control'] = 'YES';
$CONF['alias_control_admin'] = 'NO'; --> $CONF['alias_control_admin'] = 'YES';
$CONF['special_alias_control'] = 'NO'; --> $CONF['special_alias_control'] = 'YES';
$CONF['user_footer_link'] = "http://change-this-to-your.domain.tld/main"; -->
Rettes til hvor forsiden af postfixadmin tilgås, fx http://domæne/postfixadmin/users/main.php
$CONF['footer_text'] = Rettes efter behov
$CONF['footer_link'] = Rettes efter behov
// Welcome Message --> Rettes efter behov
Det er måske nødvendigt at indsætte data i mysql:localhost/postfix/config manuelt. Indsæt følgende under setup, hvis postfixAdmin brokker sig over at databasen ikke kan opgraderes:
id=1
name=version
value=740
Hvis postfixAdmin også brokker sig over manglende IMAP-understøttelse, så kan der sikkert ses bort fra det, da det er Dovecots opgave at bruge IMAP, og ikke postfixAdmins. Når alt er ordnet, så gå til http://example.org/postfixadmin/setup.php, udfyld kodeordet og kopier md5-hashen ind i postfixadmins config.inc.php i linien $CONF['setup_password']. Siden opdateres så i browseren, og der kan nu oprettes en superadmin, som så kan logge på postfixAdmin, oprette domæner, flere admins osv. Bemærk i øvrigt at databasen på dette tidspunkt kun indeholder en superadmin, og ingen domæner/postkaser. Ikke før at et domæne og minimum 1 postkasse eller 1 alias er oprettet, vil serveren begynde at behandle emails. Tidspunktet for at teste opsætningen er optimal nu, for systemet er konfigureret med mindst muligt software. Er der ikke adgang til et mail-program, så kan der i stedet testes når webdelen er sat op efter næste kapitel.

6. kapitel - Webmail

Det er nu tid til at installere webmail - hvis det ønskes. Udvalget er meget stort, og chancen for at finde en webmail som passer til ens behov, er gode. Jeg har valgt Squirrel Mail fordi projektet er aktivt, programmet fylder utroligt lidt, er oversat til mange sprog og er let at sætte op. Squirrel Mail kan hentes fra projektets hjemmeside: http://www.squirrelmail.org/ Ved at køre /installdir/config/conf.pl med Perl (som så skal være installeret), bliver Squirrel sat (næsten) automagisk op:
# perl /installdir/config/conf.pl
Gennemgå menusystemet fra 1-10, husk at gemme jævnligt, og afslut når tilfreds. Kig især på punkt 2,1 - Domænenavn og punkterne 4,1+4,2 - Arbejdsmapper. Flyttes arbejdsmapperne ikke, så skal de oprettes. Det anbefales kraftigt at aktivere SSL for sin webmail.

7. kapitel - SQLGrey

Hvorvidt greylisting er en fordel eller en ulempe, vil komme an på hvordan mailserveren skal bruges, og jeg vil anbefale kun at sætte SQLGrey op hvis det er nødvendigt. Kapitlet er medtaget for at gøre guiden så komplet som muligt. For yderligere bekæmpelse af spam kan SQLGrey, og dets WebUI, SQLGrey Web Interface, sqwi, bruges. Brugen af sgwi i forbindelse med SQLGrey er selvfølgelig valgfri, da SQLGreys database er logisk bygget op, og let kan inspiceres manuelt. Greylisting er en simpel teknik som udnytter det faktum, at spam sendes ud på 2 forskellige måder: Løbende fra de samme adresser, og i store mængder fra skiftende adresser. Det sidste er et problem, for de antispam-lister som Postfix bruger, beskæftiger sig primært med den løbende spam, og har svært ved at tilpasse sig skiftende adresser. For at bekæmpe den skiftende situation, så opretter SQLGrey en indgang i databasen, når der modtages en mail fra en ukendt adresse. Derefter returneres email'en så til afsenderen med en midlertidig fejl, og ifølge bogen skal afsenderen så prøve igen senere. Kun hvis SQLGrey modtager en identisk mail, indenfor det tidsrum som bogen definerer, vil mail'en blive godkendt, og afsenderen whitelistet, altså godkendt, så der ikke i fremtiden sker en forsinkelse. Rationalet bag ideen, er at meget store mængder af spam kun sendes ud én gang. Af åbenlyse grunde er nogen afsendere ikke interesseret i at overholde den del af bogen, for det betyder ekstra arbejde for deres MTAs, hvorfor opsætningen af SQLGrey vil blive noget afslappet. Flere oplysninger om de 2 programmer kan findes på nettet: http://sqlgrey.sourceforge.net http://www.vanheusden.com/sgwi SQLGrey er i softwarearkivet:
# apt-get install sqlgrey
Det er nødvendigt at oprette en database til SQLGrey, og i /etc/sqlgrey/sqlgrey.conf afkommenteres linierne db_* og udfyldes så de afspejler systemet:
# nano /etc/sqlgrey/sqlgrey.conf
Det er kun nødvendigt at kigge på db_type, db_name, db_host, db_user og db_pass. For at undgå greylisting af ellers OK afsendere, og for at reducere risikoen for at greyliste en afsender der ikke overholder bogen, så kan/bør linien "Discriminating Greylisting" sættes til on. Læg også mærke til standardværdierne for greylisting, som er imellem 5 minutter og 24 timer. Det betyder at en email kan blive op til 24 timer forsinket, men de fleste MTAs prøver igen indenfor 10-20 minutter. Efter at SQLGrey er genstartet, kan det eventuelt tjekkes om databasen bliver fyldt. Som standard lytter SQLGrey på localhost:2501, så for at få Postfix til at bruge SQLGrey, skal dens linie under "smtpd_recipient_restrictions" i /etc/postfix/main.cf afkommenteres. Det anbefales at tjekke /var/log/mail.log efter at SQLGrey bliver genstartet, for at se om filerne /etc/sqlgrey/clients_fqdn_whitelist.local og /etc/sqlgrey/clients_ip_whitelist.local mangler. Hvis de gør, så kan de bare oprettes for at fjerne advarslen. For at bruge WebUI'en til SQLGrey, kan den hentes fra projektets hjemmeside. I /installdir/includes/config.inc.php er det nødvendigt at opdatere de 5 linier der er lige under "Database Settings", med de samme oplysninger som SQLGrey lige fik. Hvis standardindstillingerne blev brugt af SQLGrey, så er det kun "$db_pass" som skal opdateres. Bemærk at sgwi kommer uden adgangskontrol, så det vil kræve en form for beskyttelse, fx af apaches simple auth: http://httpd.apache.org/docs/2.2/programs/htpasswd.html eller den mere avanceret, som understøtter databaser: http://www.howtoforge.com/how-to-password-protect-directories-with-mod_auth_mysql-on-apache2-debian-squeeze Husk at genstarte SQLGrey.

8. kapitel - DNS

DNS er et omfattende område, men i forbindelse med en mailserver, er der i princippet kun 1 DNS-record som skal sættes, og det er MX. Det eneste som den record indeholder, er et domænenavn til den modtagende server af email for domænet, og det kan sagtens være en anden server, end den der hoster en eventuel hjemmeside. Se Wikipedia for en gennemgang af de forskellige records som DNS bruger/understøtter: https://en.wikipedia.org/wiki/List_of_DNS_record_types Typisk er der 2 eller flere MX-records for et domæne i DNS:
example.org.   600   IN   MX   10 mail.example.org.
example.org.   600   IN   MX   20 mail.andet_example.org.
Lig mærke til punktumerne efter domænenavnene, det er vigtigt at de er der. Læses linien fra venstre mod højre, så står først domænet listet, dernæst hvor længe oplysningerne må gemmes af DNS-servere (i sekunder), så hvilken record der er tale om (IN MX = i MX-record), så et tal der fortæller hvilken rækkefølge flere mailservere skal prøves i (lavest først), og til slut DNS-navnet på mailserveren, som skal modtage emails på vegne af domænet. For at bestemme hvilke/n mailserver/e som skal være listet i DNS, logger man ind i sin udbyders DNS-editor, og ændrer oplysningerne. Da der er stor forskel på hvordan udbydere gør, vil jeg anbefale at kontakte udbyderen ved tvivlsspørgsmål. Gode guides omkring opsætningen af DNS generelt, er desværre ikke lette at finde, og bliver hurtigt meget omfattende. En sådan guide kan fx findes her: http://www.zytrax.com/books/dns/

9. kapitel - SPF

En anden ting i forbindelse med opsætningen af en mailserver, som i princippet er valgfri, er brugen af SPF til simpel validering af emails. Systemet virker ved at DNS har en TXT eller SPF record, med oplysninger om hvilke/n server/e der må sende emails ud for det pågældende domæne, og modtageren kan så validere om det er en gyldig afsender. Systemet er dog ingen garanti for at indholdet af en email er ægte, og det bør bemærkes at spammere bruger gyldige SPF-domæner. Derfor kræver systemet at man kender afsenderens domæne, og til en vis grad, at man forventer en email fra dem. Men især hvis domænet ikke sender emails ud, er SPF arbejdet værd, da man dermed sikrer at andre kan tjekke om afsenderen er gyldig. I forbindelse med videresending er SPF dog ikke gnidningsløs, og det er nødvendigt at omskrive afsenderadressen for videresendte emails, for ellers knækker filmen. Problemet er tydeligt hvis mailserveren skal videresende emails fra én ekstern adresse til en anden, og både afsenderen og modtageren bruger SPF. I et sådan tilfælde vil modtageren afvise mailserverens emails, fordi det ser ud til at mailserveren står som afsenderen, hvilket den ikke er godkendt til af den oprindelige afsender.

Opsætning af SPF i DNS

Selvom den nye udgave af BIND understøtter en decideret SPF-record, så vil jeg anbefale at sætte en TXT-record til SPF, og understøtter udbyderen også SPF-records, så også at sætte den. En typisk linie med en TXT-record, som indeholder oplysninger om SPF, ser sådan her ud i programmet dig:
example.org.   600   IN   TXT   "v=spf1 mx -all"
Domænet er listet først, efterfulgt af hvor længe DNS-servere må gemme oplysningerne, så hvilken record der er tale om (denne gang TXT), og til slut den egentlige SPF. Bemærk at anførelsestegnene ikke skal indtastes i DNS. Selve SPF kan opbygges på flere måder, men jeg viser kun nogle få af dem her. For en komplet liste kan hjemmesiden besøges: http://www.openspf.org/SPF_Record_Syntax Den første måde jeg vil anbefale at sætte SPF på i DNS, er ved at fortælle modtagere at de/n mailserver/e som har MX-records for domænet, er godkendt til at sende emails ud. Den record ser sådan her ud:
v=spf1 mx -all
v=spf1 er SPF-versionen brugt. mx betyder de/n mailserver/e som er listet i domænets MX-records. -all (minus alle) at ingen andre end dem der blev nævnt indtil -all, må sende på vegne af domænet. Af flere grunde kan det være en fordel, at præcisere hvilke/n server/e som må sende emails ud for ens domæne. Dette kan gøres ved at bruge IP-adresser, i stedet for at pege på MX-records:
v=spf1 ip4:1.2.3.4 -all
Den anden måde jeg vil anbefale at sætte SPF på, er hvis man har et domæne som ikke sender emails ud. Der kan så sættes en SPF, som siger at ingen servere er godkendt til at sende emails ud for domænet:
v=spf1 -all
Husk at ændringer i DNS kan tage alt imellem nogle få minutter, til mange timer at blive gennemført. Hvis man vil være på den sikre side, så er 8 timer en god tommelfingerregel at regne med, før at en ændring er gået igennem hele DNS. Programmet dig kan bruges til at grave DNS-oplysninger frem, og en god guide kan læses her: http://www.madboa.com/geek/dig/ Og man-filen her: http://linux.die.net/man/1/dig

SPF-gyldig videresending af emails med SRS

Har mailserveren brug for at kunne videresende, så er det nødvendigt at sætte Sender Rewriting Scheme, SRS, op, for at undgå problemer med andre mailserveres brug af SPF. Selvom SPF, og dermed SRS, har eksisteret som RFC siden 2006, er det et fåtal af MTAs som har SRS indbygget, og Postfix er ikke en af dem. Den bedste løsning jeg har kunne finde, bruger en lille dæmon skrevet i C, som omskriver afsenderfeltet på alle emails der går ind og ud af mailserveren. Dæmonen hedder pfix-srsd og er en del af pakken pfixtools, og det er nødvendigt at bygge dæmonen fra kildekoden. Som eksperiment kan den binære dæmon hentes her. Den er bygget på et Debian 6, x86-64-system, og burde som minimum virke på tilsvarende systemer. Kilden kan hentes med wget, og så pakkes ud med tar:
# wget https://github.com/Fruneau/pfixtools/tarball/pfixtools-0.8
# tar -xzvf pfixtools-0.8
Dernæst er det nødvendigt at installere de afhængigheder, som kilden skal bygges op ad:
# apt-get install libev3 libev-dev libsrs2-0 libsrs2-dev libpcre3-dev
Med git kan det sidste hentes, og kilden kan eventuelt opdateres:
# git clone https://github.com/Fruneau/pfixtools.git
# cd pfixtools
# git submodule init
# git submodule update
Først bygges afhængighederne:
# cd common
# make
Og dernæst kan pfix-srsd bygges:
# cd ..
# cd pfix-srsd
# make
Det færdige program kan så flyttes eller kopieres til /usr/local/bin, hvorfra det kan køre som en dæmon. Placeringen er selvfølgelig underordnet, når bare den tilpasses i den følgende konfiguration. Husk at tildele dæmonen +x. Den letteste måde i Debian at køre et program som en dæmon, er ved at lave et sysV-script, som både init og rc.d kan bruge. Bruger serveren ikke Debian, så er det nødvendigt at konsultere systemets dokumentation, og finde den bedste løsning. I /etc/init.d oprettes scriptet:
# nano /etc/init.d/pfix-srsd
Dæmonens sysV init-script kan ses her. Husk at sætte +x på scriptet. For at få dæmonen til at starte automatisk med systemet, og for at tilføje links til de forskellige runlevels, kan update-rc.d bruges:
# update-rc.d pfix-srsd defaults
I /etc/default oprettes dæmonens konfigurationsfil:
# nano /etc/default/pfix-srs
Dæmonens konfigurationsfil kan ses her. Den nævnte secrets-fil bruges til at lave hashes, og placeres i /etc/postfix, eller hvad der vælges i /etc/default/pfix-srs:
# nano /etc/postfix/pfix-srs.secrets
Secrets-filen kan ses her. En ekskluderingsliste bør oprettes, fordi ikke alle adresser bør blive omskrevet af dæmonen:
# nano /etc/postfix/pfix-no-srs.cf
Ekskluderingslisten kan ses her. Afhængigt af serveren, så bør hostmaster og webmaster måske blive fjernet fra listen. pfix-no-srs.cf skal derefter hashes:
# postmap /etc/postfix/pfix-no-srs.cf
Og til sidst kan den nye dæmon aktiveres i Postfix, ved at afkommentere dens 4 linier:
# nano /etc/postfix/main.cf
# ---------------------- SRS Remapping ---------------------------
recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf, tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient
sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf, tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
Husk at starte pfix-srsd, genstarte Postfix, og eventuelt at tjekke mailloggen for problemer.

SPF-validering af modtagne emails

Det tredje og sidste aspekt omkring SPF som bør overvejes, er om indkomne emails skal valideres med SPF. Jeg har desværre ikke kunne finde en policy service skrevet i C, men der er lavet en i Python, som er nem at sætte op. Når en email bliver modtaget, så tjekker postfix-policyd-spf-python om afsenderens domæne har en SPF-record, og ud fra resultatet, reagerer den ved at * godkende emails hvis SPF findes og er OK * godkende emails hvis SPF ikke findes * godkende emails hvis DNS-serveren er nede * returenere emails hvis SPF findes, men afsenderen ikke er nævnt Godkendte emails får skrevet oplysningerne om SPF ind i headeren, så modtagerens MUA kan læse dem, og returneret emails indeholder et forklarende link til openSPF. Først installeres postfix-policyd-spf-python med apt-get:
# apt-get install postfix-policyd-spf-python
Dens konfigurationsfil ligger i /etc/postfix-policyd-spf-python, og for en liste over argumenter kan manualen besøges: http://manpages.ubuntu.com/manpages/lucid/man5/policyd-spf.conf.5.html For at integrere postfix-policyd-spf-python i Postfix, så afkommenteres følgende linier i Postfix' konfigurationsfiler:
# nano /etc/postfix/master.cf
---
policyd-spf  unix  -       n       n       -       0
  spawn user=policyd-spf argv=/usr/bin/policyd-spf
---
# nano /etc/postfix/main.cf
---
smtpd_recipient_restrictions =
...
	reject_unauth_destination
...
        check_policy_service unix:private/policyd-spf
...
        permit / reject
--- Rækkefølgen i master.cf er vigtig, da reject_unauth_destination skal komme før check_policy_service. For at overholde de gældende RFCs, bør tidsgrænsen for postfix-policyd-spf-python hæves en smule, og policy-spf_time_limit bør blive afkommenteret main.cf:
policy-spf_time_limit           = 3600s
Husk at genstarte, og tjek eventuelt mailloggen. Man-page for postfix-policyd-spf-python: http://manpages.ubuntu.com/manpages/lucid/man1/policyd-spf.1.html Der findes en tilsvarende policy service skrevet i Perl, men Python-versionen anbefales generelt, da den er mere komplet. Bruger man ikke Python, og gerne vil undgå at installere det for postfix-policyd-spf-python, så kan postfix-policyd-spf-perl bruges i stedet for. Scriptet kan hentes i Debians stabile softwarearkiv, og ellers er det inkluderet i den samlede pakke, som kan downloades fra toppen. Som med postfix-policyd-spf-python er Postfix' konfiguration gjort klar. Installeres postfix-policyd-spf-perl manuelt, er det nødvendigt at oprette en systembruger til formålet, og bruges /usr/sbin ikke som placering, så skal master.cf rettes til. Husk +x på scriptet. For detaljer kan Launchpad besøges: https://launchpad.net/postfix-policyd-spf-perl/

10. kapitel - Fejlfinding

Et decideret kapitel om fejlfinding bliver det her ikke, men derimod en påmindelse om altid at læse alle logfiler ved problemer. I denne her opsætning er der kun 4 centrale logfiler, og så Dovecots valgfrie logfil. De 5 filer ligger i /var/log/ og hedder mail.dovecot, mail.err, mail.info, mail.log og mail.warn. Ofte er det nok at kigge i mail.log for at følge med. Er problemet (måske) relateret til Postfix, så kig i dokumentationen: http://www.postfix.org/DEBUG_README.html Virker databasen ikke som forventet, så aktivér logning i /etc/mysql/my.cnf. Kommer emails ikke frem til mailserveren, så tjek om greylisting er et problem.

Autosvar

Igennem postfixAdmin er det muligt at aktivere autosvar, så en email sendt til en modtager med autosvar, automatisk udløser et svar til afsenderen, samtidig med at email'en gemmes i en eventuel postkasse. Løsningen bliver en del af selvbetjeningen for de enkelte brugere. Da autosvar er opbygget i Perl, afhænger det af en del pakker derfra, og der skal desuden oprettes en systembruger og en databasebruger til formålet. Først installeres afhængighederne:
# apt-get install libmail-sender-perl libdbd-pg-perl libemail-valid-perl \
libmime-perl liblog-log4perl-perl liblog-dispatch-perl libgetopt-argvfile-perl \
libmime-charset-perl libmime-encwords-perl
Bemærk at de 2 sidste pakker ikke er i Debian stable, men testing, så apt-pinning er nødt til at være aktiveret. Så oprettes systembrugeren:
# groupadd -g 8000 vacation
# useradd -u 8000 -g vacation -s /sbin/nologin -d /home/vacation -m vacation
Selve løsningen afhænger af et script, som ikke ser ud til at følge med i Debians udgave af postfixAdmin. Det er derfor enten nødvendigt at hente pakken på hjemmesiden: http://postfixadmin.sourceforge.net/ Eller at hente scriptet her. Den engelske manual kan læses her. I pakken ligger scriptet i /postfixadmmin-{version}/VIRTUAL_VACATION/ og hedder vacation.pl, og det skal flyttes ind i fx vacations hjemmemappe, med en filtilladelse af 700, så koden til databasen ikke kan læses af andre. Scriptet skal dog som minimum have +x. I databasen oprettes en bruger til formålet, og som minimum skal brugeren have fuld adgang til tabellen vacation_notification, og SELECT på resten af databasen. Det er desuden nødvendigt at tilføje nogle linier til Postfix, og ændre lidt i postfixAdmin. Først åbnes master.cf, og de følgende linier afkommenteres:
# nano /etc/postfix/master.cf
---
vacation    unix  -       n       n       -       -       pipe
  flags=Rq user=vacation argv=/home/vacation/vacation.pl -f ${sender} -- ${recipient}
--- I main.cf afkommenteres henvisningen til det fiktive relay:
# nano /etc/postfix/main.cf
---
transport_maps = hash:/etc/postfix/transport.cf
--- Dernæst oprettes filen transport.cf:
# nano /etc/postfix/transport.cf
transport.cf kan ses her. autosvar.example.org rettes til det ønskede, og eksisterer domænet ikke, så bør det skrives ind i /etc/hosts på linien med 127.0.0.1, for at undgå problemer. Før at Postfix kan læse filen, er det nødvendigt at hashe den:
# postmap /etc/postfix/transport.cf
I postfixAdmins konfiguration aktiveres autosvar, ved at ændre de 4 linier under "// Virtual Vacation" så de passer til behovet. Det sidste der mangler at blive gjort, er at rette vacation.pl til, så det kan få adgang til databasen. Det kan også anbefales at aktivere logning i starten, bare husk at oprette /var/log/mail.vacation, og gør den skrivebar af gruppen vacation. Husk at genstarte Postfix.

Backup MX

"Den klassiske model med en eller flere mailservere, og så en backup MX, er død. Spam slog den ihjel." Så enkelt beskrevet er ideen bag backup MX ifølge Gentoo. Det betyder desværre, at en mailserver og en backup MX er 2 forskellige ting i dag, og selvom det selvfølgelig kan løses på flere måder, så er den bedste måde jeg har kunne finde, opbygget efter en master og slave model. Centralt i den model står databasen igen, og den største udfordring ved at sætte en backup MX op, er at holde dens database opdateret med mailserverens. For kun på den måde kan en backup MX vide, hvilket adresser den skal modtage emails for. Er det kun nogle få domæner som serveren skal være backup MX for, så kan det sættes op manuelt, ved at oprette de pågældende domæner, postkasser og aliases i postfixAdmin. Husk at afkrydse backup MX ved domænet i postfixAdmin. Bruges der i stedet en dedikeret backup MX, så kommer MySQL med mulighed for replikation: http://dev.mysql.com/doc/refman/5.0/en/replication.html Vær opmærksom på, at replikation kan være yderst problematisk under andre andre forhold, end dem der er beskrevet her. I forbindelse med min egen opsætning, har jeg lavet et script som kan dele databasen imellem flere Postfix-servere, forudsat at de har en FTP-server til rådighed. Der kan ses mere her: https://ubuntudanmark.dk/forum/viewtopic.php?f=33&t=16880 Som udgangspunkt kan den samme opsætning også bruges til en backup MX, men alt efter omstændighederne, kan webmail og postfixAdmin undværes. Dertil skal den tilhørende linie i /etc/postfix/master.cf være udkommenteret, og derefter skal yderligere 2 filer oprettes i /etc/postfix. I master.cf sikres det at linien med "smtp_fallback_relay" er udkommenteret
# nano /etc/postfix/master.cf
---
#        -o smtp_fallback_relay=
--- Så oprettes /etc/postfix/relay_domains.cf
# nano /etc/postfix/relay_domains.cf
relay_domains.cf kan ses her. Og så /etc/postfix/relay_recipient_maps.cf
# nano /etc/postfix/relay_recipient_maps.cf
relay_recipient_maps.cf kan ses her. Til slut er det bare at afkommentere de 2 tilhørende linier i main.cf
# nano /etc/postfix/main.cf
---
relay_domains = proxy:mysql:/etc/postfix/relay_domains.cf
relay_recipient_maps = proxy:mysql:/etc/postfix/relay_recipient_maps.cf
--- Efter en genstart af Postfix skulle det være det. Så længe at modtageren står i databasen med både alias og domæne, vil Postfix tage imod posten, og holde den i en midlertidig kø indtil den kan leveres. I den forbindelse kan parametrene "maximal_queue_lifetime" og "delay_warning_time" være en undersøgelse værd.

Systembrugere og e-mail

Som opsætningen allerede er, er det muligt for systembrugere at sende og modtage post igennem Postfix. Adressen er bruger@maskinnavn.domænenavn.tld, og der kan også sendes til den. Postfix gemmer systembrugeres emails i standardplaceringen, som på Debian er tekstfilen /var/mail/brugernavn. Ønskes dette ikke, så kan Postfix i stedet indstilles til at aflevere en systembrugers email i en eksisterende postkasse. Det gøres ved først at afkommentere linien "alias_maps" i main.cf
# nano /etc/postfix/main.cf
---
alias_maps = hash:/etc/aliases
--- I aliases tilføjes så de systembrugere vis emails skal videresendes
# nano /etc/aliases
---
brugernavn: bruger@example.org
--- Husk at køre kommandoen 'newaliases' og at genstarte Postfix efter redigering af /etc/aliases. Blandt de mange guides som jeg læste, så endte det med at blive guiden på Dovecots wiki-side, som fik det til at virke for mig. En del af den opsætning jeg har beskrevet her, er inspireret fra den: http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL En komplet beskrivelse af alle indstillinger i Postfix: http://www.postfix.org/postconf.5.html Detaljeret beskrivelse af Dovecot 1 som LDA: http://wiki.dovecot.org/LDA/Postfix Beskrivelse af samspillet imellem Dovecot 2 og SQL: http://wiki2.dovecot.org/AuthDatabase/SQL Uddybende forklaring om Dovecot 2 dict og quota http://wiki2.dovecot.org/Dict Detaljer om integration af postfixAdmin og Dovecot: http://blog.yia.idv.tw/~roger/?p=203 Gentoo's tilføjelser til Postfix (quota, backup MX osv.): http://wiki.gentoo.org/wiki/Complete_Virtual_Mail_Server/Postfix_additions Opsætning af SRS omskrivning til Postfix: http://www.christophfischer.com/linux/15-mailserver/56-sender-rewriting-scheme-srs-fuer-postfix-unter-debian Ét synspunkt på mail anno 2012: http://blog.phusion.nl/2012/09/10/mail-in-2012-from-an-admins-perspective/

Noter og revisionsliste

Sådan en guide her er selvsagt meget omfattende at vedligeholde, og mindre ændringer som rettelser af sproglige fejl, vil ikke fremgå nogen steder. Først hvis der er tale om at ny information bliver skrevet på, eksisterende information bliver rettet, eller at guiden dækker nyere udgaver af softwaren, vil det blive skrevet på revisionslisten. Jeg modtager meget gerne rettelser og forslag til guiden, men spørgsmål om opsætning og så videre, hører til i Ubuntu Danmarks serverforum, eller andre relevante steder. Guiden er i version 0.1.4, og dermed i beta, og som nævnt i toppen, så følges den på eget ansvar. Emner der mangler at blive gennemgået Opsætning og brug af SpamAssassin. Brugen af danske svar fra mailserveren, fx hvis en email ikke kan afleveres. Se bounce(5) for detaljer: http://www.postfix.org/bounce.5.html Tvangsbrug af den adresse der er logget ind med som afsenderadresse. Se fx Server Fault for detaljer: http://serverfault.com/questions/318334/how-to-enforce-sender-address-to-be-logged-in-userexample-org-in-postfix Kan gennemføres med en webmail som RoundCube. Gennemgang af logrotate's konfiguration i forbindelse med Postfix, så der kan gemmes mere end 7 dages logfiler, hvilket åbenbart er standard i Debian. Ændring af SQL-koden så andre databaser end MySQL kan bruges. Licens Guiden er udgivet under GNU General Public License version 3, og ved hel eller delvis gengivelse, skal en notits om licensen offentliggøres sammen med guiden. Den fulde licens kan ses her: http://www.gnu.org/licenses/gpl.txt Software og versioner Som udgangspunkt vil guiden følge Debians nuværende stabile software, i det omfang det findes. Der kan dog være nogle ugers forsinkelse, inden at nye opdateringer testes. Debian 6 stable, med følgende software allerede installeret: * Apache 2.2.16-6+squeeze10 * libapache2-mod-php5 5.3.3-7+squeeze14 * PHP5 5.3.3-7+squeeze14 * MySQL 5.1.66-0+squeeze1 Dertil fuld SSH-adgang. Software der bliver brugt/installeret i løbet af guiden: * OpenSSL 0.9.8o-4squeeze13 * Postfix 2.7.1-1+squeeze1 * Dovecot common, imapd og pop3d 1.2.15-7 * Dovecot common, imapd og pop3d 2.1.7-2 * postfixAdmin 2.3.5-2 * SQLGrey 1.8.0rc2-1 * pfix-srsd 0.9.0 * postfix-policyd-spf-python 0.8.0-2 Og dertil eventuel webmail software efter eget ønske og version. Squirrel Mail 1.4.22 bliver brugt i guiden.

Revisionsliste

31/1 2017
Guiden er blevet skrevet helt om, og har fået både fjernet og tilføjet en del indhold.

24/01 2013
Dovecot 2 er tilføjet til kapitlet om Dovecot.

28/12 2012
En fejl i /etc/postfix/master.cf er blevet rettet, ved at fjerne linierne
-o smtpd_sender_login_maps=proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
-o smtpd_sender_restrictions=reject_sender_login_mismatch
Funktionaliteten er ikke en del af opsætningen, og kan give følgende fejl i loggen:
Dec 20 10:57:34 hostname postfix/proxymap[1221]: warning: request for unapproved table:
  "mysql:/etc/postfix/mysql_sender_login_maps.cf"

5/12 2012
Strukturen i guiden er blevet ændret, så konfigurationsfilerne ikke længere er indsat i guiden, men har et link. Samtlige filer brugt i opsætningen, kan nu downloades direkte fra toppen af guiden.

18/11 2012
Et link med forslag til distribuering af databasen er tilføjet sektionen med Backup MX, og et kort afsnit om "Systembrugere og email" er blevet tilføjet.

Kapitlet med greylisting har fået ændret ordlyden, således at det understreges at greylisting er valgfrit, og ikke nødvendigvis en fordel at bruge.

16/10 2012
Kapitlet med DNS har fået splittet oplysningerne om SPF fra, som så har fået sit eget kapitel. Desuden er der inkluderet flere oplysninger om SPF.

07/10 2012
Databasen kan nu downloades som et phpMyAdmin-dump direkte fra guiden. Afsnittet med Dovecot er udvidet til, hvordan man deaktiverer POP3-protokollen. Oplysningerne om SPF dækker nu også IP-adresser, og afsnittet med backup MX beskriver opsætningen mere præcist.

Desuden er Debians opdatering af Apache til version 2.2.16-6+squeeze8 testet og virker.

28/09 2012
Fra dovecot.conf er protokollen managesieve, og brugen af pam, blevet fjernet. managesieve er serverside sortering af emails, og pam er et godkendelsesmodul.

09/09 2012
Guiden oprettes.

Håndkodet i gyldig HTML5 HTML5 Badge