Email-server med virtuelle brugere på Debian

, ,

***
Bemærk: Denne guide bliver ikke vedligeholdt mere. For en tilsvarende guide, om en mail-server med Postfix og Dovecot på FreeBSD og til dels Linux, kan du besøge aptget.dk/postfix.
***

*** Indholdsfortegnelse ***

Baggrund
Forord
Forudsætninger
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

Download af databasens struktur og alle konfigurationsfilerne kan ske her.


*** Baggrund ***
Velkommen til Nickys guide om Postfix, Dovecot, SpamAssassin, postfixAdmin 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 bliver 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 en kop kaffe, te, cola eller måske vand, en bunke tålmodighed, adgang til en fornuftig søgemaskine og mulighed for at tage notater. Et mailsystem vil være blandt noget af det mest komplekse du endnu har skulle sætte op, og selv hvis guiden følges til punkt og prikke, er det ikke sikkert at det endelige resultat virker.

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, så 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 over et ønske om at lære mere om e-mail, da min virksomhed og Ubuntu Danmark havde brug for en mailløsning. Jeg har sideløbende sat 2 identiske mailservere op, og efterhånden som jeg fik komponenterne installeret på den ene, har jeg taget notater til hvordan jeg så gjorde på den anden. Det betyder at guiden dækker opsætningen på et nyinstalleret Debian-system, som kun har et grundsystem med SSH installeret, og en fungerende Linux, Apache, MySQL og PHP, LAMP, opsætning, hvis webmail ønskes. MySQL er dog central i opsætningen, og kan ikke undværes.


*** 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 flere domæner, hver med deres egne grænseværdier for antallet af postkasser, aliases og quota. Den faktiske mængde af brugere og post 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.

Der vil også være et modul til selvbetjening, 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.

Dernæst er et kendskab til Linux nødvendigt, for jeg gennemgår ikke brugen af bash, SSH, nano og alt det andet, og serveren som bliver brugt, bør have 512 mb ram til rådighed til mail-programmerne. Adgang til Domain Name System, DNS, for de/t domæne/r som serveren skal drive er nødvendigt, og guiden inkluderer også oplysninger om opsætningen af DNS, ikke bare i forbindelse med MX records, men også i forbindelse med Sender Policy Framework, SPF. SPF er en simpel måde, at fortælle modtagere hvem der må sende emails fra de/t pågældende domæne/r.

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 udenfor denne guides formål.

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 gang kopiér og klistre ikke kan bruges. 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 ***
Debian er valgt af personlige grunde, og især på afledte distributioner, vil der være en god chance for at guiden kan bruges. Den chance vil nok falde, efterhånden som man bevæger sig længere væk fra Debian.

De programmer som indgår i opsætningen, er ikke som sådan valgt enkeltvis, men valgt ud fra det samlede resultat, hvor de arbejder godt sammen. Bruger man fx Courier fremfor Dovecot, så er det også nødvendigt at installere og sætte SASL manuelt op til godkendelse, fordi det er ikke bygget ind i Courier, som det er i Dovecot. Jeg har heller ikke specifikt valgt MySQL, men ofte er det den databaseserver der følger med LAMP, og det gør den mere tilgængelig end andre SQL-servere, da den allerede er installeret på en del systemer.

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.

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.


*** 1. kapitel – Databasen ***
Centralt i denne opsætning står databasen, og jeg valgte i sidste ende at bruge strukturen fra postfixAdmin, da den dækker behovet fint.

I guiden har jeg kaldt databasen for ‘postfix’, og jeg har oprettet 3 brugere til den, 1 med fuld adgang og 2 med læseadgang. De 3 brugere er ‘postfix’, ‘dovecot’ og ‘postfixadmin’ og det er brugerne ‘postfix’ og ‘dovecot’ som kun skal have læseadgang, altså SELECT, til databasen.

Databasen til MySQL kan hentes her.

Husk at Æ, Ø og Å kan give problemer, så sørg for at køre databasen med korrekt understøttelse, som fx latin1.


*** 2. kapitel – Certifikater ***
Det anbefales kraftigt at oprette og bruge certifikater til Transport Layer Security, TLS, ikke kun til IMAP og POP3 samt en eventuel webdel, men også til Postfix i sig selv, så den kan kryptere sine forbindelser til andre Mail Transfer Agents, 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 /etc/postfix/main.cf og /etc/dovecot/dovecot.conf.


*** 3. kapitel – Postfix ***
Jeg vil beskrive hvordan brugernes mail kan placeres i /home/vmail, og hvordan en systembruger uden privilegier kan bruges af Postfix og Dovecot til processen. Mail’en kan ligges hvor det passer bedst, inklusiv på Network File System, NFS, bare husk at rette til hver gang /home/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 MySQL-adgang:

# apt-get install postfix postfix-mysql

Besvar spørgsmålene:
“General type of mail configuration:” –> Internet Site
“System mail name” –> domæne.tld

Postfix har kun 2 konfigurationsfiler som standard, og de er:
/etc/postfix/main.cf
/etc/postfix/master.cf

main.cf = Alle overordnede indstillinger
master.cf = Oplysninger om den mere konkrete transport af 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 illustrer, 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 mails som matcher bestemte mønstre, eller 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://domæne.tld/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@domæne.tld';

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://domæne.tld/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:

domæne.tld.   600   IN   MX   10 mail.domæne.tld.
domæne.tld.   600   IN   MX   20 mail.andet_domæne.tld.

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:

domæne.tld.   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.domæne.tld 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 email ***
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@domæne.tld


Husk at køre kommandoen ‘newaliases’ og at genstarte Postfix efter redigering af /etc/aliases.


*** Links ***
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.

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


Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *