Postfix og venner

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.

Postfix og venner

Vi bruger et docker-image ved navn docker-mailserver ([https://store.docker.com/community/images/tvial/docker-mailserver](Docker Store), https://github.com/tomav/docker-mailserver/). Sektionen her giver overblik over de enkelte dele af imaget, men nævner ikke meget om konfiguration – det følger senere.

Postfix-suiten

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

Dovecot

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.

Filtering af spam og vira

amavis

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

SpamAssassin

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.

ClamAV

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åndting af pakkede filer; se opstartsloggen for Postfix i /var/log/mail.log.

Postgrey

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

Verifikation af afsender

OpenDKIM

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?

OpenDMARC

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

Konfiguration af docker-mailserver

Der er overordnet til måder at konfigurere på

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

docker-compose.yml

I ~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 rimeligt dokumentation af image-specifikke options i [https://store.docker.com/community/images/tvial/docker-mailserver](beskrivelsen af imaget) og ellers ved at læse koden til scriptet https://github.com/tomav/docker-mailserver/blob/master/target/start-mailserver.sh der starter daemons i containeren.

Magiske filer/mapper

Meget er muligt, men interessant for os er indholdet af mappen config i ~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.

• Filen ~docker/compose/config/postfix-accounts.cf, der fastsætter brugere, der har lokal delivery, dvs. hvis mails ender på prodekanus og som kan tilgås med IMAP. Disse brugere kan også logge ind på Postfix og bruge den som relay, lige bortset fra, at portene 25 og 587 er blokeret af AU IT for udefrakommende trafik – og sådan skal det forblive jf. en aftale med dem om, at de håndterer al mail, der går ind i og ud af AU's net.

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