På prodekanus kører Postfix som klister mellem AU IT's indgående Exchange-servere og vores egne SMTP-servere, og videre fra vores egne og ud til AU IT's udgående Exchange-servere. Postfix kører i et docker-image.

Denne side dokumenterer opsætningen af Postfix og de tilhørende filter-services. Hvis ikke du kender til docker og docker-compose, kan det være en fordel at lære en smule herom, men ellers er det til sidst en kort intro til relevante docker-kommandoer for dette setup.

Vi bruger et docker-image ved navn docker-mailserver (Docker Store, GitHub). Sektionen her giver overblik over de enkelte dele af imaget, men nævner ikke meget om konfiguration – det følger senere.

Postfix er en suite af daemons, der står for håndtering af indgående og udgående mails, og som håndterer at levere mails til (eventuelle) lokale modtagere. Daemons, der altid kører, er fx

• smtpd (leverance af mails mellem servere)
• trivial-rewrite (omskrivning af header-felter særligt ift. modtagere)
• qmgr (håndting af mailkø)
• pickup (opsamling af mail lagt som filer i maildrop-mappe)
• tlsmgr (håndtering af TLS secrets)
• anvil (rate limiting og statistik)

Håndtering af alle disse daemons styres af daemonen master, hvis konfiguration findes i /etc/postfix/master.cf, men som kan overrides.

Postfix er elegant sat sammen og kan løse rigtigt mange udfordringer ift. at bringe mails fra afsender til modtagere, herunder kan man håndtere aliasser og videresende hele domæner, men så stopper festen også. Postfix er ikke designet til filtrering af mails, og hertil benytter man i stedet amavis og lignende.

IMAP-server, der sørger for at give adgang til mails, der er leveret lokalt. Siden ingen mails for nuværende leveres lokalt, er denne ret uinteressant.

Dovecot udbyder ikke POP3-service, da dette specifikt er slået fra.

Daemonen amavis er lavet som klister mellem Postfix og diverse filtre. Postfix ved intet om filtre, men kan levere mails til amavis, som så står for at køre mailen gennem et antal filtre (konkret her gennem SpamAssassin og ClamAV). Efter filtrering dirigerer amavis Postfix til enten at bounce mailen eller levere den videre som intet var hændt.

Vi konfigurerer ikke selv amavis, men forlader os på de rimelige defaults, der er en del af docker-imaget. Ønsker vi at ændre i denne konfiguration, skal vi have fat i dokumentationen for docker-imaget, men det er næppe nødvendigt, med mindre vi ønsker at tilføje yderligere filtre.

Selvom AU IT's Exchange-servere tager sig af indgående filtrering, så har vi også SpamAssassin til at filtrere indgående mails. Den benytter imagets defaults, hvilke er rimeligt forsigtige.

Får man falske positiver (eller vil man af andre årsager slå SpamAssassin fra) kan det gøres med en enkelt ændring af docker-compose.yml. Eventuel tilretning af konfigurationen af SpamAssassin kan ske i både docker-compose.yml og ved override; læs dokumentation for imaget.

Igen tager AU IT sig af det, men som en del af imaget har vi også scanning for vira med ClamAV (der også dagligt henter opdateringer til virusdefinitioner). Igen kan dette slås fra ved brug af docker-compose.yml.

TODO: Hvis vi mener virusskanning seriøst, bør der i imaget installeres flere programmer til håndtering af pakkede filer; se opstartsloggen for Postfix i /var/log/mail.log.

Greylisting kan ske med postgrey, men det er ikke slået til; det gøres i docker-compose.yml.

Domain keys kører som standard, men har ingen reel funktion, da smtp01.uni.au.dk accepterer alle mails fra os. Det er muligt, at vi vil se behov for at lægge vores domain key i DNS, når vi agerer mailliste for TÅGEKAMMERET?

Håndtering af DMARC (SPF og DKIM tilsammen). Se ovenstående.

Der er overordnet to måder at konfigurere på

1. Opstartsparametre og environment i docker-compose.yml
2. Specifik override via magiske filer/mapper

Ja, hertil er det også muligt at ændre i filer i en kørende container, og ja, ændringerne overlever containerens start/stop, men vil ikke overleve opdateringer af image! Det frarådes på det kraftigste at ændre filer i den kørende container!

I /home/docker/compose ligger docker-compose.yml, der er central ved opstart af Postfix, da den fastsætter det environment, som gives til containeren. Der er en rimelig dokumentation af image-specifikke options i beskrivelsen af imaget og ellers ved at læse koden til scriptet start-mailserver.sh der starter daemons i containeren.

Meget er muligt, men interessant for os er indholdet af mappen config i ~docker/compose (dvs. /home/docker/compose):

• Filen ~docker/compose/config/postfix-main.cf, der overrider Postfix-konfigurationen i imaget. Hvis man vil ændre ved Postfix, skal det altså ske i denne fil og ikke fx ved brug af postconf i containeren!

• Filen ~docker/compose/config/smtp_transport, der fastsætter, hvordan domæner routes til specifikke SMTP-servere, for eksempel og i særdeleshed videredelegering af vores domæner til vores SMTP-servere. Der gælder særlige forhold for denne fil; se nedenfor om konfigurationen.

• Filen ~docker/compose/config/postfix-accounts.cf, der fastsætter brugernavne og hashede kodeord der bruges til at logge ind via SMTP/STARTTLS port 587 (åben for internettet) og via IMAPS port 993 (blokeret i AU ITs firewall). Denne fil genereres ud fra ~docker/compose/config/postfix-accounts/postfix-accounts.txt af ~docker/compose/config/postfix-accounts.sh.

• Filen ~docker/compose/config/sender_login_map, der kobler SMTP-brugere til kuvert-afsender-adresser.

• Filen ~docker/compose/config/postfix-virtual.cf, der angiver aliasser for mailadresser, der ellers ville have lokal delivery.

• Mappen ~docker/compose/config/opendkim, der indeholder nøgler (både privat og public) for DKIM.

• Mappen ~docker/compose/letsencrypt, der indeholder certifikat og nøgler til TLS-kommunikation.

Mails, der sendes til et domæne, som vi skal håndtere mail for, rammer først AU IT's indgående Exchange-servere, hvilket naturligvis kræver, at MX-records er sat op for domænet; det har ~rav styr på. Af Exchange filtreres mails i et ukendt omfang, og herefter ledes de videre til prodekanus.

Alle mails, der leveres til Postfix (portene 25 (SMTP) og 587 (SMTPS)), filtreres jf. konfigurationen af blandt andet SpamAssassin og ClamAV. Herefter vil Postfix (overordnet set!):

• ekspandere aliasser fra ~docker/compose/config/postfix-virtual.cf og genstarte leverancen,
• levere mails lokalt til folk i ~docker/compose/config/postfix-accounts.cf,
• sende mailen til én af vores SMTP-servere, hvis domænet er kendt i ~docker/compose/config/smtp_transport,
• sprøjte mailen videre ud på nettet via smtp01.uni.au.dk grundet ukendt domæne.

Postfix er ikke et åbent relay: Mailen videresendes kun via smtp01.uni.au.dk hvis mailen oprindeligt er sendt til et domæne, som vi håndterer, og dermed videresendt af et program på prodekanus, eller hvis mailen er sendt af en SMTP-bruger der er logget ind.

Hvis man ændrer i overstående filer er det strengt nødvendigt at genstarte hele containeren! Man kunne tænke, at bruge postfix reload inde i containeren, men det er ikke tilfældet, idet filerne kun læses af opstartsscriptet start-mailserver.sh

UNDTAGELSE 1: Ved ændringer af ~docker/compose/config/smtp_transport eller ~docker/compose/config/sender_login_map er det ikke nødvendigt at genstarte containeren, men det er nødvendigt at køre postmap på filen. Det kan gøres uden for containeren (når den kører) med en af kommandoerne:

docker-compose -f ~docker/compose/docker-compose.yml exec mail postmap /tmp/docker-mailserver/smtp_transport

docker-compose -f ~docker/compose/docker-compose.yml exec mail postmap /tmp/docker-mailserver/sender_login_map

UNDTAGELSE 2: Jf. man docker-compose bør man ved ændringer af docker-compose.yml ikke bare genstarten men genbygge containeren.

Med systemd er docker daemonen sat til at starte ved boot, og ved hjælp af vores eget systemd unit docker-compose.service køres docker-compose start ved boot af prodekanus.

Tjek vha. systemctl list-units | grep docker-compose om docker-compose.service kører i systemd. I så fald kan den stoppes, startes, eller genstartes, med en af kommandoerne sudo systemctl stop/start/restart docker-compose.

Når man har stoppet docker-compose.service vha. kommandoen sudo systemctl stop docker-compose, kan man administrere containeren/imaget med kommandoen docker-compose således:

Kommandoen docker-compose skal kunne se filen ~docker/compose/docker-compose.yml, så enten skal dit workdir være ~docker/compose eller også skal du køre kommandoen docker-compose med docker-compose -f ~docker/compose/docker-compose.yml. Videre er det nødvendigt at være medlem af gruppen docker (eller bruge sudo).

Tip-top tip: alias docker-compose=docker-compose -f ~docker/compose/docker-compose.yml.

Start af containeren: systemctl start docker-compose (som kører docker-compose start mail)

Stop af containeren: systemctl stop docker-compose (som kører docker-compose stop mail)

Genstart af containeren: systemctl restart docker-compose (som kører docker-compose stop mail; sleep 5; docker-compose start mail. Af uransaglige årsager virker docker-compose restart mail ikke, da det gør at der ikke skrives til mailloggen)

Se containerens log: docker-compose logs mail der viser både dockers log og maillog. Hvis man bruger docker-compose logs -f mail vil man følge loggen live. Hvis man alene vil grepe mailloggen, bør man nok bruge docker-compose exec mail grep <pattern> /var/log/mail/mail.log.

Myrd containeren: docker-compose kill mail.

Kører containeren?: docker-compose ps.

Start shell i containeren: docker-compose exec mail bash og du kører som root(!)

Opdater image: docker pull tvial/docker-mailserver:latest og genbyg så containeren.

Genbyg container: docker-compose up -d mail, hvor -d gør, at man detacher.

sudo mkdir -p /home/docker/log/mail
sudo touch /home/docker/log/mail
sudo chown 106:111 /home/docker/log/mail /home/docker/log/mail/mail.log
sudo chmod g+w /home/docker/log/mail /home/docker/log/mail/mail.log
docker-compose up -d mail

Grunden til at /home/docker/log/mail.log laves inden man kører docker-compose up, er at mailserveren ellers vil stoppe og genstarte lige efter den er færdig med at starte op.

Logfilerne skal være skrivbare af syslog:syslog i containeren; dvs. uanset hvem der er uid 106 og gid 111 på host-maskinen, skal filen chownes til 106:111, hvilket er syslog:syslog i containeren.