• EpostDriftSendmail

Installasjon og konfigurering av Sendmail

Sendmail er et komplekst produkt og her blir det i hovedsak oversikt og informasjon om hvordan den er konfigurert og satt opp ved IDI. For å lære om sendmail kan boken "Sendmail" (NB! 3. edtition, den dekker også 8.12) av Bryan Costales og Eric Allman anbefales. Vi vil referere til denne boken flere steder i dette dokumentet. Se også sendmail.org og sendmail.com

1. Kompilering og Installasjon

Hos oss ligger alt som har med sendmail å gjøre under /src/sendmail/ og siste versjon under current(per september 2006 er dette en symlink til src-8.13.8).

1.1 Nedlasting, utpakking og overføre konfigurasjonsfiler fra forrige versjon

For å hente ned en ny versjon av sendmail kan du bruke /src/sendmail/getit.sh. Angi versjon som parameter. Scriptet vil laste ned sendmail-<ver>.tar.gz med wget og pakker det ut på riktig sted. Det spør så om du vil kopiere lokale konfigurasjonsfiler fra forrige versjon (devtools/Site/site*.m4 og cf/cf/IDI*). For den versjonen som brukes skal det være en symlink som heter current og man får derfor spørsmål om man vil sette den nye versjonen som current. Dette dokumentet har referanser via symlinker til filer under /src/sendmail/current.

Dersom det bare er en ”bugfiks oppgradering” (f. eks 8.13.6 til 8.13.8) holder det som regel at du leser RELEASE_NOTES. Er det en større oppgradering (f. eks 8.13.8 til 8.14.1) må du lese alle aktuelle filer før du setter i gang med kompilering (DOIT.sh). Da kan det også tenkes at du må endre site*.m4 filene også. Følgende filer bør du se gjennom:

RELEASE_NOTES INSTALL devtools/README libmilter/README

1.2 site konfigurasjonsfiler

Dette er m4-filer som inkluderes under byggingen av sendmail for å lage Makefiler. Normalt har man en os - og plattformuavhengig fil og en fil per OS/plattform.

site.config.m4 inneholder site-spesifikk konfigurasjon uavhengig av os og plattform. For 8.13.1 bruker vi:

prEPENDDEF(`confMAPDEF', `-DNEWMAP')
define(`confMBINDIR', `/usr/lib')
define(`confUBINDIR', `/usr/bin')
define(`confEBINDIR', `/local/mail/bin')
define(`confMANROOT', `/local/mail/man/cat')
define(`confSTDIR', `/etc/mail')
define(`confHFDIR', `/etc/mail')
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')
APPENDDEF(`conf_sendmail_ENVDEF', `-DIDENTPROTO')
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_MILTER_ROOT_UNSAFE')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
PREPENDDEF(`confENVDEF', `-D_PATH_SENDMAILPID=\"/etc/mail/sendmail.pid\" \
        -D_PATH_SENDMAILCF=\"/etc/mail/sendmail.cf\" \
        -DCMDDIR=\"/local/mail/sm.bin\"')

site.SunOS.5.10.m4 brukes ved kompilering på solaris10. Kan overstyre ting som er definert i site.config.m4.

APPENDDEF(`confINCDIRS', `-I/opt/SUNWconn/crypto/include -I/opt/csw/include \
   -I/opt/sasl/include -I/opt/sasl/include/sasl -I/local/named/include \
   -I/src/sendmail/BerkelyBD/include -I/store/include')
APPENDDEF(`confLIBDIRS', `-L/opt/SUNWconn/crypto/lib -L/opt/sasl/lib \
   -L/opt/sasl/lib/sasl2 -L/local/named/lib -L/src/sendmail/BerkelyBD/lib.solaris \
   -L/opt/csw/lib  -L/store/lib')
define(`confMAPDEF', `-DNEWDB -DNIS -DNISPLUS -DMAP_REGEX')

site.FreeBSD.m4 er lik, men er uten -DNIS på siste linje.

Se devtools/README, sendmail/README og libmilter/README for mer info. Der vil man også se at det er mye mer som kan settes, men sendmail har stort sett fornuftige standardverdier og derfor blir ikke disse m4-filene så veldig store. Nokså mye blir detektert automatisk.

1.3 Berkeley BD og lenking

Sendmail bruker BerkelyDB dersom vi har med -DNEWMAP og det er dette db-formatet vi bruker. Sendmail 8.13.1 kan bruke Bdb 4.1 (4.1.0 - 4.1.24 kan ikke brukes) eller nyere. For å unngå problemer ved oppgraderinger/avinstallering av BerkelyDB (under /opt, store eller (usr), så vil vi at denne skal lenkes statisk. Så lenge man ikke bruker -B static vil ld velge .so filer dersom både .a og .so finnes med samme navn i en katalog. Det er også viktig å huske at når ld kjøres så brukes LD_OPTIONS før kommandolinje-parametere (ld $LD_OPTIONS param1 param2....). Vi velger å nullstille LD_OPTIONS slik at bare det som er satt i site-konfig filene brukes. Hos oss kan vi ha BerkelyDB både under /opt og under /store/lib og det er derfor fort gjort at feil versjon blir brukt med mindre vi har full kontroll over -L referansene. For å være sikker på at vi får samme BerkelyDB versjon ved rekompilering bruker vi -I - og -L referanser til kataloger under/src/sendmail/BerkelyBD, se site.OS.platform.m4 filene (*.so filer er fjernet slik at vi får statisk lenking).

1.4 Kompilering og lage tarfil for installasjon.

Vi har laget et script, /src/sendmail/DOIT.sh som gjøre hele denne jobben. Det vil bygge sendmail og deretter kjører src/sendmail/mk_install_tarfile.sh for å lage en tarfil som kan brukes ved endelig installasjon. Det opprettes en tarfil under /src/sendmail/install og den vil få navnet install-<ver>.<os>.tar.gz. Det er kun denne filen som opprettes, ingenting kopieres til /usr og /local/mail. Ved endelig installasjon pakker man bare ut denne filen fra /. Pakk den gjerne ut på en testmaskin først og test med de konfigurasjonsfilene (sendmail.cf osv) som er aktuelle å bruke.

For at DOIT.sh skal fungere må det kjøres som root. Normalt går ikke dette dersom /src er nfs-montert. Derfor må man sjekke på serveren der /src ligger (for tiden lind) at man har root=kompileringsmaskin.idi.ntnu.no:... i /etc/dfs/dfstab for denne. Legg inn kun sikre maskiner som ingen har mulighet for å stjele ip-adressen til.

1.5 Distribusjon og endelig installasjon

Når den nye versjonen er testet med aktuelle konfigurasjonsfiler, så kan man pakke ut install-tar-filene. Men før man gjør dette må man sjekke følgende:

NB! På Solaris-maskiner må eventuelle sendmailpakker som følger med Solaris fjernes slik at ikke patcher overskriver ”vår” sendmail (fjernes med pkgrm SUNWsndmu SUNWsndmr).

Stopp sendmail først. Sjekk om cfengine brukes for distribusjon av sendmailfiler. I tilfelle så legg filer på riktig sted der. VIKTIG ved bruk av cfengine: sørg for at det bare distribueres til en testmaskin i første omgang. Men det anbefales ikke å bruke cfengine for filer til sendmail på primær mailserver, her må man ha manuell kontroll over endringer. Pass på at sendmail ikke stoppes på mer enn en av maskiner som er MX samtidig. Ta backup av filer fra den gamle versjonen slik at du raskt kan gå tilbake til denne dersom problemer med den nye versjonen. Lag en liste over filene på forhånd som kan brukes som filliste for tar. Når alt er klart, stopp sendmail, cd / ; /store/gnu/bin/tar xzvf /src/sendmail/install/install-<os>.tar.gz og start sendmail igjen. Overvåk nøye om alt fungerer (syslog m.m.) og send noen testmeldinger. Dersom det ser ut til å være problemer, legg tilbake forrige versjon og gjør mer testing på en testmaskin før du fortsetter.

2. FILER

2.1 sendmail.cf

Normalt skal man ikke endre/redigere sendmail.cf direkte. Den genereres via m4 og vi oppretter/vedlikeholder bare en relativt enkelt master-konfugurasjonsfil som i stor grad benytter seg av ferdig definerte makroer. Det er sjelden behov for å lage egne regler og det er heller ikke nødvendig å forstå i detalj alt som står i sendmail.cf eller hvordan reglene er bygd opp (men det skader ikke, spesielt ved feilsøking og testing).

2.2 Class-variabel filer

I sendmail.cf kan man angi class-variabler. Dette er matriser der man kan liste opp elementene direkte eller referere til en fil hvor elementene i variabelen befinner seg. Man kan søke etter slike filer med grep ^F /etc/mail/sendmail. Man bruker gjerne eksterne filer enten når de endres ofte og/eller når de består av mange elementer. I vår konfigurasjon har vi bare en slik fil med elementer i en class-variabelen og det er local-host-names (før sendmail.cw) for å legge til elementer i $=w. Disse filene blir lest kun når sendmail startes og sendmail må restartes etter en endring i disse filene.

2.3 Databasefiler

I sendmail.cf brukes det oppslag i databaserfiler flere steder. Noen av disse kan man kan man finne disse med grep ^K /etc/mail/sendmail.cf siden linjer der disse er definert starter med K. I motsetning til class-variabler i filer, leses ikke innholdet i disse databasefilene ved oppstart av sendmail, men ved oppslag under kjøring. Andre databasefiler defineres via egne opsjoner. Opsjonen AliasFile angir hvilke for eksempel db-filer som brukes for aliaser.

Det støttes mange ulike filformater, men vi har valgt å bruke BerkelyDB (btree) og det er vel det som er mest vanlig å bruke. Disse genereres av makemap (i Makefile) og har filtype .db. For eksempel:

makemap hash aliases < aliases (hash=BerkeyDB). Genererer aliases.db

Blant databasefilene er det aliasfilene som endres oftest Når det gjelder BerkelyDB skal man merke seg at filene ikke nødvendigvis er kompatible mellom ulike versjoner og ved oppgradering av sendmail må man sjekke om man må generere alle disse filene på nytt.

2.4 Andre filer

Disse er definert med egne opsjoner i sendmail.cf. Det er vel stort sett HelpFile ( /etc/mail/helpfile ) og StatusFile (/etc/mail/statistics). HelpFile brukes når man kopler seg opp mot port 25 på mailserver og skriver help. Sendmail skriver delivery-agent status i filen som er definert via StatusFile opsjonen.

3. Generere sendmail konfigurasjons (.cf) filer

Som nevnt genereres sendmail.cf som regel via m4 og m4-filer. I sendmail er navnet og plasseringen på denne filen en av de få stier som har hardkodet. Man bestemmer navn og plassering på denne under kompilering. Normalt er det /etc/mail/sendmail.cf.

Konfigurasjonsfiler for å generere sendmail.cf ligger under CFDIR/cf der CFDIR hos oss for tiden (sept 2006) er /src/sendmail/src-8.13.8/cf. Tabellen under viser hvilke kataloger vi har. Katalogene domain, feature, hack, mailer, ostype og siteconfig inneholder filer som importeres via makroer med samme navn med store bokstaver (unntatt SITE for siteconfig), f. eks betyr MAILER(generic) at CFDIR/mailer/generic.m4 importeres.

Vi bruker følgende mc-filer og de ligger under /src/sendmail/current/cf/cf:

Det ligger en del dokumentasjon som kommentarer i disse filene.

Man genererer cf-filer med ./Bulid FIL.cf. Da utføres følgende: cd $CFDIR m4 m4/cf.m4 cf/FIL.mc > cf/FIL.cf

cf.m4 inkluderer i sin tur m4/cfhead.m4 som inneholde makroer m.m brukes i mc-filene. Denne filen sørger også for at proto.m4 blir inkludert etter at mc-filen er lest. Det gjøres ved å bruke:

m4wrap(include(_CF_DIR_m4/proto.m4')')

m4wrap betyr at $1 (her include...) blir utført etter at alle filer er lest. Det betyr at proto.m4 kan bruke alle makroene som er definert i cfhead.m4 og i mc-filen. Når makroer ikke er definert vil den ofte sette inn en standardverdi.

En ting som er viktig å være klar over når det gjelder m4 og m4-filer er at output ikke nødvendigvis kommer i den rekkefølgen teksten står. Man kan ha 9 output-kanaler og disse slås samme til slutt. Til dette bruker man divert(n) der n er "output-stream" nummer. Laveste nummer kommer først. Av og til brukes divert(-1) som betyr ingen output. divert(0) er aktiv "stream" og denne må brukes får å få output igjen etter en divert(-1).

4. Sendmail-regler (for spesielt interessrte)

Sendmail bruker regler for å skrive om sender - og mottager-adresser og for å velge delivery-agent. Et regelsett består av flere enkeltregler og et regelsett kan kalles opp fra regler, omtrent som subrutiner i et program. I sendmail.cf begynner en regel-linje med bokstaven R. Navn på et regelsett starter med bokstaven S og etter S kommer et nummer. Man kan bruke symbolske navn istedenfor nummer, men de symbolske navnene gjøres om til et nummer når sendmail.cf leses. Regelsett S0 - S5 har spesiell betydning (de fleste andre regler brukes som "subrutiner" direkte eller indirekte for disse). Figuren under viser hvordan adresser behandles:

4.1 Ruleset 3 - preprosess

Alle adresser preprosesseres i S3. Adresser kan skrives på ulike måter og kan inneholde full navn og kommentarer i tillegg til selve adressen, f.eks Jan Grønsberg < jang@idi.ntnu.no > eller jang@idi.ntnu.no (Jan Grønsberg) som begge er lovlig. S3 sørger for å fjerne alt unntatt selve adressen og endrer eventuell domene-del til <@domene.>.

4.2 Ruleset 0 og Ruleset 5- velg delivery agent

Regelsett S0 brukes for å bestemme hvilken mailer som skal brukes og det viktigste kriteriet her er domene-delen av adressen. Den sjekker $=w som inneholder alle lokale navn. Finnes domene-delen av adressen der så betyr det at mailer local skal brukes. $=w vil alltid som minimum inneholde navn (eller IP-adresse) og alle alias til maskinen sendmail kjører på. På primær mailserver brukes gjerne innholdet i /etc/mail/local-host-named (eller sendmail.cw) i tillegg. I sendmail.cf kan man finne mailere ved hjelp av grep ^M /etc/mail/sendmail.cf eller via echo =M | /usr/lib/sendmail-bt. Mailere er ulikt definert på primær mailserver og de med subsidiary versjon av sendmail.cf. På disse vil alltid mailer relay bli valgt enten direkte etter S0 eller etter S5 (se Ruleset 5).

4.3 Ruleset 5 - endelig valg av mailer (etter at alias er ekspandert)

Ruleset 5 (S5) kan bli brukt for å velge en annen mailer etter S0. Dersom maileren har satt flagg 5 (F=5) og adressen ikke er et alias (ikke i noen aliasfil) eller ~/.forward brukes, så vil adressen man får etter S0 gå videre gjennom S5 for endelig valg av mailer. Dersom det er et alias må jo disse gå en ny runde gjennom regelsettene (rekursivt). Poenget med å ha både S0 og S5 er at ekspansjon av alias kun har mening dersom er mailer er local. Hos oss er ikke AliasFile definert på maskiner med subs. versjon (backupMX) av sendmail.cf og ForwardPath er aldri definert på disse. Derfor vil S5 alltid brukes på disse. S5 vil legge til $H, dvs "mailHub" som hos oss er smtp.idi.ntnu.no (DHsmtp.idi.ntnu.no i sendmail.cf) og dermed vil mailer relay velges. For alle adresser som har med domene vil S0 velge riktig mailer (relay) og S5 vil ikke gjøre noen endring. Kunne man ikke slå sammen S0 og S5?. Dersom vi hadde slått opp lokale alias har det kun mening når mailer local brukes og om S0 og S5 var slått sammen ville jo aldri den ha blitt valgt og alias hadde ikke fungert. S5 må derfor brukes først etter at eventuelle alias er ekspandert.

På primær mailserver er ikke $H satt (DHsmtp.idi.ntnu.no) satt og vil derfor heller ikke der ha noen effekt (eneste måtte være feil i input til S5, men det er lite trolig). Når man kjører f.eks sendmail -d21.12 jangr, så ser man at S5 brukes, men den vil så langt jeg kan se aldri ha noen effekt der.

Som figuren indikerer så velges "S=" og R=" ut fra hvilken mailer som brukes der S= brukes for Sender - og R for mottageradresser.

4.4 Ruleset 1

Ruleset 1 er i utgangspunktet ikke satt i en standard sendmail-konfigurasjon. I mc-filene legger man denne inn under LOCAL_RULE_1. Alle sender-adresser sendes gjennom S1 uavhengig hvilken mailer som velges, dette gjelder både envelope - og header adresse. Vi tar med regelsettet her siden det er enkelt og ikke helt standard sendmail-konfigurasjoner. Merk at etter S3 er adressene endret til: bruker<@domene.>

S1
R$~E < @ $=w . >                $: $1 < @ $2 . > ? $( virtuser $1 @ $2 $: $)
R$- < @ $=w . > ? $+            $: $1 < @ $2 . >
R$- < @ $=w . > ?               $: $1

Linje 1 vil matche dersom det ikke er en "Exposed user" ($~E. Exposed users er brukere der vi ikke skal maskere maskinnavnet. Det gjelder bl.a root siden root@idi.ntnu.no gir liten mening) og domene-delen finnes i $=w, dvs alle lokale navn på maskinen der sendmail kjører + de som er lagt inn i local-host-names (eventuelt sendmail.cw). Dersom adressen ikke finnes i virtusers.db skrives det om til bruker<@domene.> ? . Dersom den finnes i virtusers.db blir det bruker<@domene.> ? adr_fra_virtusers (f.eks vil drift@itdagen.no gi unix).

Linje 2 vil gi omskriving til bruker<@domene.> igjen dersom oppslaget i virtusers i line 1 returnerte noen verdi. Linje 3 vil gi omskriving til kun: bruker ikke ? ble fjernet ved omskriving i linje 2.

4.5 Ruleset 2

Se sendmailbok.

4.6 Ruleset 4

Dette brukes for å rydde opp etter andre regelsett og da spesielt 3 og 96. Det er noe vi aldri endrer på. Se sendmailbok for mer info.

4.7 Validering via check_* regelsett

Dette er regelsett som brukes for å godta eller avvise en melding og de kalles direkte av sendmail, ikke via andre regelsett.

4.7.1 check_mail

Validerer envelope-sender adressen som blir gitt ved en SMTP MAIL TO: kommando. Brukes til å avvise enkelte envelope-sender adresser. Den sjekker at formatet på adressen er riktig, for eksempel at domene-del ikke mangler og at det er et eksisterende domene. Du kan teste dette med telnet mail 25 og angi adresser med feil format etter MAIL TO: Feilmeldingene du får der kommer fra dette regelsettet. Adressen sjekkes også mot access (access.db) (kun user@domene innslag).

4.7.2 check_rcpt

Validerer envelope-mottager adresse som blir gitt via en SMPT RCPT kommando. Sjekker format på adresser slik som check_mail. Dersom det er en lokal adresse (uten domenenavn, adr@idi.ntnu.no eller domenedel er en maskin/domene som ligger i local-host-names), så sjekkes det om adressen finnes. Hvis ikke gir den feilkode 550.

Det er også chek_rcpt som gjøre relay-sjekk. På dette tidspunktet er ${client_name} og ${client_addr} satt og disse sjekkes mot $=w (innhold i local-host-names eller minimun navn på maskinen vi kjører sendmail på) og $=R (alle domener vi relayer for). Dersom navn eller ip-adresse er i $=w eller domene-delen av navnet er i $=R og adressen ikke er en lokal adresse returnerer den følgende: 550 Relaying denied.

4.7.3 check_relay.

Validerer maskinen som initierer en SMTP forbindelse og kalles med maskinnavn og ip-adresse som parameter. Navn og IP sjekkes mot access (access.db). check:relay sjekker access. I access kan vi legge inn maskiner og/eller domener vi tillater relay fra. Dette vil overstyre relay-sjekken i check_rcpt. Vi kan også legge inn maskiner vi ikke vil ta i mot fra (maskin/domene REJECT). Se sendmail bok eller annen dokumentasjon. for mer info om access-filen. Man bør bruke FEATURE(access_db) også på backupMX(er), hvis ikke utføres bare (den strengere) relay-testen i check_rcpt på disse.

Dersom vi bruker FEATURE(dnsbl) legges dette i på slutten av dette regelsettet. Dette er en tjeneste som NTNU abonnerer på. Den sjekker om en ip-adresse er svartelistet p.g.a. spamming. Det fungerer ved dns-oppslag på $4.$3.$2.$1.blackholes.mail-abuse.org gir et resultat (127.0.0.2) der $1.$2.$3.$4 er IP-adressen vi sjekker. ludvig.ntnu.no slaver denne sonefilen. Se http://mail-abuse.org for mer info. Denne testen gjøres ikke dersom det er match i access (det vil si maskiner relayer for), regelsettet returnerer da OK før denne testen.

4.7.4 check_compat.

Dette regelsettet brukes ikke i en standard sendmail-konfigurasjon, man må legge inn FEATURE(check_compat). Det kalles med envelope-sender – og mottager som parameter (en gang per mottager). I motsetning til de andre reglene som kalles ved SMTP transaksjoner, kalles check_compat ved alle leveranser. Regelsettet kalles like før rutinen checkcompat (i conf.c) kjøres. Dette er en rutine som man kan skrive/utvide dersom man trenger gjøre noe som ikke kan gjøres via check_compat regelsettet. I compat_check.m4 som følger med sendmail (8.13.x) gjøres det oppslag i access på Compat:sender<@>mottager. Det vil si at vi kan teste på kombinasjon av sender og mottager (sjekker om oppslaget returnerer DISCARD:, TEMP: eller ERROR:, alt annet er OK). Nytteverdien av dette kan diskuteres, men man står fritt til å modifisere dette regelsettet etter eget ønske. Vi har hittil ikke brukt check_compat.

5. SMTP AUTH og STARTTLS

Kort fortalt brukes SMTP AUTH for autentisering av sender og STARTTLS for kryptering mellom mailklient og SMTP-server. Stort sett er eneste grunn til å bruke SMTP AUTH at man har en maskin som brukes flere steder (les: bærbare) og ønsker å slippe å måtte endre SMTP-server i oppsettet av mailklienten. Vi tillater relaying for klienter som er autentisert uansett hvilken IP-adresse de har. Slik vi har satt det opp MÅ man samtidig bruke STARTTLS fordi vi bare har mulighet for å støtte "plain" mekanismen i SMTP AUTH. Ulempen med SMTP AUTH er selvsagt at man må angi brukernavn/passord første gang de sender en mail i en sesjon i mailklienten. Når man bruker SMTP AUTH/STARTTLS er man også garantert at meldingen går kryptert hele veien fra klient og frem til vår mailserver. Det er man ikke dersom man går via en lokal SMTP-server et annet sted, det er langt fra alle mailservere som har støtte STARTTLS (heller sjelden hos kommersielle ISPer ser det ut til).

En mulighet er også å kun bruke STARTTLS for å tillate relaying. Men da måtte hver bruker ha et sertifikat signert av vårt CA-sertifikat. Det er mulig, men neppe gjennomførbart annet enn når det er snakk om nokså få brukere.

5.1 Installasjon og konfigurering av SASL

SMTP AUTH krever at Cyrus SASL biblioteket er installert. Denne lastes ned fra http://asg.web.cmu.edu/cyrus/download/.

Følgende linjer må legges inn i /src/sendmail/current/devtools/Site/site.config.m4 før kompilering av sendmail:

APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')

I tillegg må includepath (-I) og libpath (-L) for sasl legges inn i site.SunOS.5.9.m4

5.1.1 Konfigurering av SASL for bruk i sendmail

SASL støtter flere mekanismer for autentisering: CRAM-MD5, DIGEST-MD5, KERBEROS, PLAIN og LOGIN. De to sistenevnte er stort det samme og vi bruker PLAIN. Årsaken er at det bare er den som virker sammen autentisering via shadow/passwd fil (brukes indirekte via PAM). PLAIN overfører passordet i klartekst, noe som selvsagt er nokså uheldig. Derfor har vi satt det opp slik at SMTP AUTH ikke tilbys før STARTTLS brukes. Følgende linjer i IDI-prim.mc har med SMTP AUTH å gjøre:

TRUST_AUTH_MECH(`PLAIN LOGIN')
dnl # AUTH_OPTIONS: A p y betyr (p) at STARTTLS *MÅ* brukes ved SMTP AUTH
dnl # mekanisme PLAIN og LOGIN. Dersom starttls ikke er slått på i klienten.
dnl # eller STARTTLS ikke virker p.g.a. sertifikatfeil vil ikke
dnl # SMTP AUTH virke. D.v.s. virker ikke STARTTLS virker heller ikke SMTP AUTH.
dnl
define(`confAUTH_OPTIONS',`A p y')dnl
define(`confAUTH_MECHANISMS',`PLAIN LOGIN')dnl

NB! Skal man teste kun SMTP AUTH ved telnet til port 25 må man midlertidig fjerne p-opsjonen i AuthOptions ellers vi man ikke se noe til SMTP AUTH og kan tro at det ikke fungerer.

I tillegg vil sendmail lese filen /opt/sasl/lib/sasl2/Sendmail.conf som hos oss inneholder følgende:

mech_list:LOGIN PLAIN
srvtab:/usr/lib/sendmail
pwcheck_method:saslauthd

Generelt skal det være en slik konfigurasjonsfil for hver applikasjon som bruker SASL, for eksempel Imap.conf (skal være stor forbokstav) for å bruke det i imap.

Se http://www.imc.org/ietf-sasl, http://www.melnikov.ca/mel/devel/Links.html (viser bruk av SASL i ulike sammenhenger) og eventuelt http://asg.web.cmu.edu/sasl for mer informasjon om SASL.

For mer informasjon om SMPT AUTH, se side 409 i sendmailboken fra O'Reilly (NB! 3. edition). Se ellers egen dokumentasjon om SASL.

5.1.2 STARTTLS - kryptering av en SMTP-forbindelse

I går ikke veldig i detalj om hvordan STARTTLS fungerer, vi viser igjen til vår kjære sendmailbok hvor dette er forklart på en grei måte (side 415). I motsetning for nettlesere som leser "https" sider kan man ikke vite om en melding vi sender fra en mailklient er kryptert hele veien frem, alle mailservere meldingen må naturligvis ha støtte for STARTTLS for at meldingen skal gå kryptert hele veien. Dessuten er det bare overføringen som er kryptert, når meldingen lagres eller legges i køer er den ikke kryptert. Det er derfor ikke noen erstatning for å kryptere selve melding (for eksempel .med PGP). Men sammen med SMTP AUTH som bruker passord i klartekst (mekanisme plain) er derimot kryptering viktig, faktisk så viktig at vi ikke tillater SMTP AUTH uten at man samtidig bruker kryptering. De fleste mailklienter støtter kryptering nå. Det er viktig å informere brukerne om bruk av både SMTP AUTH og kryptering og hvordan de slår det på i de mest vanlige klientene.

For å bruke STARTTLS må man ha OpenSSL installert. Denne lastes ned fra [www.openssl.org]. Men vår mailserver (Sun Fire-V240) har kryptokort og vi bruker derfor den versjonen av openssl som fulgte med dette kortet. I /src/sendmail/current/devtools/Site/site.config.m4 har må vi ha med følgende:

APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')

I site.SunOS.5.9.m4 må man ha med -I/opt/SUNWconn/crypto/include og -L/opt/SUNWconn/crypto/lib (programvaren for crypto-kortet må selvsagt være installert. Merk at kroptokortet må være konfigurert for at det skal fungere optimalt, se egen [dokumentasjon] om hvordan dette gjøres.

5.1.3 Sertifikater

Bruk av SSL/STARTTLS i sendmail krever at vi har sertifikater. Normalt skal slike sertifikater være signert av en sertifikatutsteder, for eksempel Verisign. Men for tiden må vi signere det selv. Ulempen med selvsignerte sertifikater er at brukeren får en melding om at det muligens ikke er å stole på fordi vi ikke er på listen den har over blant sertifikatutstedere den stoler på (den har deres offentlige nøkkel, men ikke vår). Men i tilfelle med sendmail er det neppe så stort problem. Det vil kun være egne brukere og relativt få av disse igjen som bruker dette. Det blir noe annet når tilfeldige brukere fra hele verden bruker websider hos oss og får opp en slik varsel.

I IDI-prim.mc (som sendmail.cf for mailserveren genereres fra) har vi lagt inn følgende linjer:

dnl # Trenger disse for å bruke STARTTLS:
define(`CERT_DIR', `/etc/certs')
define(`confCACERT_PATH',`CERT_DIR')
define(`confCACERT',`CERT_DIR'`/cacert.pem')
define(`confSERVER_CERT',`CERT_DIR'`/cert.pem')
define(`confSERVER_KEY',`CERT_DIR'`/key.pem')
define(`confCLIENT_CERT',`CERT_DIR'`/cert.pem')
define(`confCLIENT_KEY',`CERT_DIR'`/key.pem')

Alle filer som har med sertifikater å gjøre ligger under /etc/mail/certs (på pil).

• cacert.pem inneholder (root) CA (Certificat Authority) sertifikat. Vi har laget dette selv.

• cert.pem inneholde mailserverens sertifikat for inngående forbindelser.

• key.pem inneholder serverens private nøkkel.

Siden sertifikater er noe som brukes i flere sammenhenger henviser vi til dokumentasjonen for openssl/cryptocard for mer informasjon om hvordan vi enerere sertifikater for bl.a. sendmail.

6. MAILERE

Man kan få informasjon om hvilke mailere som er definert og hvilke flagg m.m. de er konfigurert med følgende opsjoner til sendmail:

• /usr/lib/sendmail -bt -d0.15.

Vi har laget et script, /local/mail/bin/show-mailflags som bruker dette for å vise en litt mer lettlest informasjon om mailere og hvilke flagg de bruker. Klikk her for å se output fra show_flags (NB! kan være endret siden denne filen ble laget).

Kap. 20 (side 698) i sendmailboken gir detaljert informasjon om hvordan mailere fungerer og hvilke flagg som kan brukes. Vi bruker procmail for lokal levering og bruker også denne for å filtrere ut meldinger som vårt spamfilter har merket med høy spamscore. Vi ser nærmere på dette i neste kapittel.

7 SPAMFILTERING

Vi sender all mail til en egen mailfilter-server. I tillegg til spamfiltrering tar denne seg også av virussjekk. Når meldinger leveres til brukere brukes headere lagt til av mailfilteret for eventuelt å skille ut spam i egne spamfoldere.

Se egen dokumentasjon om mailfilter (mimedefang, spamassassin, fsav m.m.). Vi ser her bare på den delen som sendmail har ansvar for.

7.1 Oppsett av MILTER

Som nevnt la vi inn støtte for "MILTER" (sendMail FILTER) ved kompilering av sendmail. I tillegg må det selvsagt være lagt inn noe i sendmail.cf eller rettere sagt i mc-filene den genereres fra. Vi legger det inn både i IDI-prim.mc og i IDI-backupMX.mc (veldig mye spam via backupMXer). Følgende er lagt inn:

dnl # ANTIVIRUS-FILTER via "MILTER" (Mail Input fILTER).
dnl # mimedfang er interface mellom MTA og programvare for innholdsksjekk.
dnl # Kj<F8>r mot port 2828 på server mimedefang.idi.ntnu.no. Opsjoner:
dnl # F=R "Reject connection" hvis filter ikke tilgjengelig (anbefales ikke).
dnl # F=T "Temporary feil connection" hvis filter ikke tilgjengelig.
dnl # Hvis F ikke er satt vil alt virker da som om vi ikke hadde filter
dnl # T=timeout_type:timeout (m=minutt,s=sekund) der:
dnl #   C Timeout for å kople opp (hvis 0, bruk system-timeout)
dnl #   S Timeout for å sende info fra MTA til filteret.
dnl #   R Timeout for å lese svar fra filteret.
dnl #   E Total timeout fra sending til "End-Of-Message" til filter.
dnl # Hos oss er E  tiden mimedefang-serveren bruker for <E5> behandle
dnl # meldingen.
INPUT_MAIL_FILTER(`mimedefang',`S=inet:2828@mimedefang.idi.ntnu.no,T=C:1m;S:1m;R:1m;E:5m ')

Det er satt opp med passende timeouts. Når filterserver er nede går meldingene gjennom filteret. Vi bruker port 2828 (tilfeldig valgt) på serveren mimedefang (CNAME for pisa). Meldinger som har virus legges i karantene på filterserveren og enkelte potensielt skadelige vedlegg kan også bli fjernet og lagt i karantene (info med referanser gis legges da i meldingen). Ellers legges det til noen headere, bl.a. X-Spam-Status hvor spamscore er angitt. Vi ser hvordan dette brukes per-bruker procmailfilter i neste underkapittel.

7.2 Bruk av Procmail for å sortere meldinger med høy spamscore

Meldinger som har gått gjennom spamfilteret på filterserveren (pisa) blir merket med hvor høy sannsynlighet det er for at meldingen er spam. Til lavere vi setter grensen til mer spam får vi filteret ut men til høyere er også sannsynligheten for falske positive. Vi ønsker å overlate til brukerne å bestemme denne terskelverdien. Brukerne gjør dette via følgende webside:

[www.idi.ntnu.no/antispam] (redirect til https://mailman.idi.ntnu.no/antispam )

Etter å ha tastet inn brukernavn og passord kan brukeren legge ønsket terskelverdi og hvilken folder det lagres i. Det blir foreslått en terskelverdi på 3.5 og standard spamfolder heter "spam". Dersom terskelverdien settes lavere enn 3.0 vil alt mellom denne og 3 lagres i folderen spam-likely siden sannsynligheten for falske positive da er relativt høy. Brukerne bør naturligvis sjekke spamfoldere, spesielt dersom de har satt lave terskelverdier.

Slik fungerer filtreringen:

I brukerens .procmailrc inkluderes en fil som genereres av mail:/local/httpd/htdocs/antispam/index.php (antispam-siden) for hver enkelt bruker. Brukerens .procmailrc vil normalt se slik ut:

INCLUDERC=/etc/mail/procmail/antispam/$LOGNAME
INCLUDERC=$HOME/.procmailrc.inc

En bruker kan opprette denne ved å kjøre scriptet addspamfilter. Dersom brukeren allerede har en .procmailrc som ikke har disse includefilene, renames den originale til .procmailrc.inc og en .procmailrc som vist over legges inn. Når nye brukere legges inn legges det også inn en slik .procmailrc. Slik det er nå varsles ikke ny brukere om spamfilteret (finnes bare en link på intranettsiden), det bør endres slik at de får info om dette i en velkomstmail. Forward med filtrering kunne med fordel også vært lagt inn som en mulighet på websiden, det er bare snakk om en litt annen versjon av includefilen.

Includefilen som genereres per bruker kan se slik ut:

# Spamlevel=2.6 - folder=spam - last change: April 21. 2004 15:03
# Score 3 og høyere:
:0:
* ^X-Spam-Status:.+\{[C-Z]
$HOME/mail/spam
# Score 2.6 - 2.9. En viss sannsynlighet for ikke-spam:
:0:
* ^X-Spam-Status:.+\{([C-Z]|B[6-9]\})
$HOME/mail/spam-likely

Vi bruker som man ser headeren X-Spam-Status. På filterserveren har vi lagt inn noen få linjer med kode for å skrive om scoreverdien slik at vi bruker A-Z for heltallsdelen der A=1 og Z=26. Da blir procmailfilteret litt enklere siden det alltid er kun et tegn for heltallsdelen (A-Z). Vi bruker bare et siffer etter komma. I dette tilfelle er 2.6 og det blir da B6. Som man ser brukes spam-likely for det som er mellom 2.6 og 3 her og alt over går til spamfolderen.

Brukeren skal normalt bare bruke .procmailrc.inc, men noen ganger kan det være ønskelig å filtrere før spamfiltrering. Da må dette selvsagt legges først i .procmailrc, eventuelt via en INCLUDE der.

8. Aliaser og postlister

Hvilke aliasfiler sendmail skal bruke er definert i sendmail.cf. Vi legger dette inn i /src/sendmail/current/cf/cf/IDI-prim.mc. Når dette skrives er følgende lagt inn der:

define(`ALIAS_FILE',`/etc/mail/aliases,/etc/mail/paliases,/etc/mail/mailman.aliases')

I /etc/mail/aliases ligger alle ordinære alias (postmaster, hostmaster osv), i /etc/mail/paliases ligger "Fornavn.Etternavn" aliaser for brukere og i /etc/mail/mailman.aliases ligger alias for lister som administreres av Mailman. Se egen [../mailman dokumentasjon] om Mailman. Alle disse filene er .db (BerkelyDB) filer. Du kan liste ut innholdet i en .db fil med makemap -u hash filnavn (helst ikke som root, det går ikke bra om du glemmer -u...).

8.1 Ordinære alias

Vi redigerer ikke (asci-versjonen av) alias-filene direkte. For ordinære alias brukes scriptet /local/mail/bin/mkaliases.pl for å generere /etc/mail/aliases (ascii-versjon). Dette scriptet leser filer fra katalogen /local/mail/src/aliases/. I denne katalogen leses først filen aliases som i sin tur importerer andre filer. Den ser slik ut:

# $Id: aliases,v 1.2 2003/01/30 13:26:37 jang Exp $
# $Locker:  $
# Master aliasesfil. Denne filen er input til /local/mail/bin/mkaliases.pl
# Man kan bruke import (begrenset til 4 nivå). Det sjekkes at en fil bare
# importeres en gang.
#
import system     # System alias som root, postmaster osv.
import newname    # Alle som har endret brukernavn.
import redirect   # Gir melding om hva nye adresse er, men forwarden ikke.
import forward    # Aliaser for videresending (når de har sluttet for eksempel).
import diverse    # Resten, det som ikke passer andre steder.

Et alias vil naturligvis virke uansett i hvilken av disse filene det legges, det brukes ulike filer bare for å gjøre det mer ryddig. Alle filene bruker versjonskontrol. Etter endring: kjør make fra /local/mail/src (dette kjører mkaliases.pl, makemap m.m.).

8.2 "Fornavn.Etternavn" alias for brukere

For de fleste brukere har vi et "Fornavn.Etternavn" alias, eventuelt med mellomnavn også. Det kan diskuteres om dette er nødvendig, men det var et ønske for mange år siden at vi skulle ha dette. Det var også et ønske den gangen at avsender-adressen skulle skrives om til "fornavn.etternavn" format. Det er flere problemer med en slik omskriving og det legges derfor nå ikke inn for nye brukere (siden begynnelsen av 2003). Et problem med å fjerne det igjen når det først er tatt i bruk er problemer for en bruker å melde seg ut av lister siden det må ofte må gjøres med samme adresse som når man meldte seg inn.

Vi bruker scriptet /local/mail/bin/paliases for å generere

• etc/mail/paliases og scriptet bruker følgende filer i katalogen

/local/mail/src/paliases.

• extra - Ekstra alias for bruker i tillegg til Fornavn.Etternavn fra /etc/passwd.

• ignore - Ikke lag personlig alias for brukerne som er nevnt der. Systembrukere lages det aldri alias for.

• nogeneric Ikke legg bruker inn i generics (omskriving av sender-adressen).

• replace - Dersom Fornavn/Etternavn i /etc/passwd ikke er det brukeren ønsker skal være alias så kan man legge inn"brukernavn:Fullt Navn" i denne filen.

For omskriving av æøå brukes a=æ,o=ø,å=a. Dette kan noen ganger skape problemer siden det kan gi like navn selv om de ikke var det med norsk tegn. Det hadde vært bedre med ae=æ,oe=ø og aa=å, men det er ikke i tråd med vanlig praksis (vet ikke om det er en offisiell standard, men UNINETT anbefaler denne omskrivingen). Er det konflikt blir det ikke laget noe alias for disse.

9 BackupMX

Med backupMX menes mailservere som tar i mot - og køer opp mail mens den primære mailserveren er nede eller har for mye å gjøre (er også disse nede køes de opp på mailservere det sendes fra rundt om i verden, i alle fall en viss tid). For bedre redundans er en av backupMX serverne plassert utenfor vårt serverrom. Det gjelder serveren osp.idi.ntnu.no som står på serverrommet i elektrobygget (der vi holdt til før).

En backupMX har en egen versjon av sendmail.cf og den vi bruker er generert ut fra /src/sendmail/current/cf/cf/IDI-backupMX.mc. Dessverre misbruker spammere slik backupMX servere, ofte sender det heller til disse enn den primære i håp om at det skal være enklere å omgå spamfilter-regler (det er det ikke hos oss). Normalt sjekker ikke en backupMX om en mottager-adresse er gyldig, den sender alt videre til primære mailserver. Mange spammere og de som lager adresselister de selger til spammere prøver seg ofte rett og slett fram (jana,janb,janc,...,jang - BINGO!, eller de bruker store lister over vanlige brukernavn/adresser). Vi ønsker å gi melding om at slike ugyldige adresser ikke finnes og dessuten spare primær mailserver fra å måtte behandle alle disse adressene og all bounce/doble-bounce det medfører. Vi har også konfigurert at det innføres 1 sek forsinkelse for hver ugyldig adresse når antallet ugyldige adresser i en melding overstiger 5 (BAD_RCPT_THROTTLE), men det er bare på primære mailserver.

For å få lagt inn sjekk av (lokale) mottager-adresser også på backupMX servere var det nødvendig å lage en ny regel i sendmail.cf. Vi la inn følgende regel i IDI-backupMX.mc:

# valid-addresser er alle gyldige brukernavn/alias og genereres av et script.
Kvalidate_address hash -T<TMPF> `/etc/mail/valid-addresses'
 .
 .
 .
SLocal_check_rcpt
R<$*>                   $1
R$* @ $*                $: $1 @ $2 <$(validate_address $1@$2 $: 0 $)>
R$* <1>                 $@ $1
R$* @ $={LH} <$*>       $: $1 @ $2 <$(validate_address $1 $: 0 $)>
R$* <0>                 $#error $@ 5.5.1 $: "550 Unknown user or alias"
R$* <1>                 $@ $1
R$*                     $@ $1

Som man ser leser den db-filen /etc/mail/valid-addresses. Den filen inneholder alle gyldige adresser vi har, det vil si alle brukernavn og alle alias i alle aliasfiler. Dersom adressen ikke finnes der returneres "550 Unknown user or alias". Filen /etc/mail/valid-addresses.db må selvsagt oppdateres når det har skjedd en endring som vil påvirke innholdet i den. Oppdateringen skjer via en cronjobb som kjører noen ganger per døgn. Det er nokså kritisk at dette scriptet fungerer slik at vi ikke har en flere uker gammel versjon den dagen primær mailserver går ned. En egen cronjobb overvåker derfor filen og sender en mail (til jang) dersom den er usannsynlig gammel (kunne kanskje sendt en SMS I tillegg). Scriptet cronjobben bruker er:

/etc/mail/check_valid-addresses.pl.

Det oppdaterer filen bare dersom det faktisk har vært en endring vil vil påvirke den.