Mjukvara på mx.kth.se

mx.kth.se

Denna tjänst implementerar större delen av KTHs epostsystem. Det är här epost tas emot ifrån omvärlden, genomsöks efter spam och virus och skickas sedan vidare inom KTH. mx.kth.se är ett servicenamn för flera maskiner som ingår i ett kluster. Alla dessa maskiner kör samma programvara och är likadant konfigurerade. De kör postfix som MTA samt Amavis för att hålla samman SpamAssassin och den antivirusmotor vi kör. De kör också grappy för att implementera grålistning.

Flödet genom epostsystemet

När ett brev tas emot och behandlas av epostsystemet behandlas det på följande sätt.

Avsändaren skickar kuvertet på brevet, dvs SMTP MAIL/FROM och RCPT TO för att signalera vilken mottagare som skall få brevet.
Postfix frågar ldap-servern om den angivne mottagaren existerar. Om den inte finns svara postfix med en SMTP 500-kod (permanent fel) och kommunikationen avslutas.
Postfix frågar greylistserven hurvida den har sett den här kombinationen av avsändare och mottagare tidigare. Om inte svarar postfix med en SMTP 400-kod (temporärt fel) och kommunikationen avslutas. Avsändaren skall då vänta ett tag och sedan försöka igen.
Avsändaren skickar innehållet i själva brevet.
Postfix svarar med en SMTP 200-kod som innebär att den övertar ansvaret för brevet och kommer försöka leverera det. I och med detta steg är konversationen med avsändaren avslutad och man kan inte längre kommunicera fel tillbaka.
Postfix frågar nu ldap-servern om all adresseringsinformation för mottagaren av brevet och skriver om mottagaradressen till den slutgiltiga adressen. Det är i detta steg som grupp-alias expanderas. Brev som skall levereras till mail1.kth.se kommer ha mottagare u1xxxxxxx@kth.se efter detta steg.
Postfix skickar vidare brevet till Amavis via SMTP för att göra anti-spam och anti-virus. Amavis svarar dock inte omedelbart med en 200-kod, utan väntar med detta till steg 10.
Amavis låter anti-virus-motorn processa brevet. Om brevet innehåller virus levereras det inte till mottagaren utan behålls i karantän.
Amavis kör sedan SpamAssassin på brevet för att se om det är ett Spam. Brevet märks sedan med hur många spam-poäng det fått i headern och levereras sedan till mottagaren.
När amavis är klar med brevet skickar den tillbaka det till postfix på en annan port via SMTP. Detta gör att postfix kan hålla ordning på vilka brev som redan processats av amavis och vilka som kommer in via ifrån andra servrar. Först när postfix svarar med en 200-kod ger amavis samma kod tillbaka i steg 7.
Postfix slår upp vilken server den skall leverera brevet till med hjälp av domändelen av mottagarens adress i ldap-servern.
Brevet levereras till den server som man slagit upp i steget innan.

Adresser

mx.kth.se består i dagsläget av tre maskiner, mx[1-3].kth.se. Det finns även en fjärde adress allokerad till mx4.kth.se och denna finns även med i DNS. Detta för att de som vill stoppa in access-filter i sina epostservrar skall kunna göra det.

mx3.kth.se har i dagsläget även en ipv6-adress i DNS. Tanken är att de andra servrarna i framtiden också skall få detta, men det vi vill testa det mer innan vi inför detta.

Postfix

Postfix konfigurationsfiler finns samlade i /etc/postfix samt här och i /afs/kth.se/admin/mail/filterserver/postfix/.

Relaying

Postfix är inställd på att reläa epost för våra lokala nät, både ipv4 och ipv6. De nät vi reläar för anges i variabeln mynetworks i main.cf. Den reläar även för andra nät, om man har authenticerat sig med SMTP-Auth först. Detta kan ske antigen genom GSSAPI eller genom att man skickar sitt lösenord genom en SSL/TLS-tunnel.

Användardatabas

Epostsystemet får all konfiguration som sker per användare via LDAP. Detta data lagras i KTHs centrala LDAP-träd under delträdet ou=Mail,dc=kth,dc=se. Mycket av detta data kommer ifrån UG via en propagator. Varje dator i mx.kth.se har en lokal kopia av den centrala LDAP-databasen. Det finns ingen information om enskillda användare på lokal disk på maskinerna.

Epostsystemet behöver ställa tre frågor till databasen för att kunna leverera ett brev. Dessa frågor är:

Existerar den här mottagaren över huvud taget?
Hur skall jag skriva om den här adressen?
Vart skall jag leverera brevet när jag är klar?

Existerar den här mottagaren över huvud taget?

Denna fråga ställs under SMTP-förhandlingen med avsändaren, direkt efter att man mottagit RCPT TO:-kommandot. Detta görs för att verifiera att man kommer kunna göra någonting med brevet i slutändan innan man ödslar energi på att ta hand om det.

I den här frågan tittar man bara på om det finns något objekt som har attributet mailLocalAddress satt till mottagaradressen på brevet.

Hur skall jag skriva om den här adressen?

Denna fråga ställs efter att SMTP-förhandlingen avslutats och brevet har tagits emot. Denna information används för att skriva om mottagaradressen så att brevet skall hamna rätt i slutändan. Om brevet skall stanna kvar på mail1.kth.se skrivs adressen om till <kthid@kth.se> och skall det vidarebefodras någon annanstans skrivs det om till den adressen. Om brevet var adresserat till något annat system på KTH som mx.kth.se är frontend för så skrivs inte adressen om alls.

Här plockar man ut alla objekt som har mailLocalAddress satt till mottagaradressen på brevet. Man tittar nu på attributen mailRoutingAddress, rfc822MailMember samt ugEmailMember och alla dessa blir nya mottagaradresser för brevet.

Semantiken för dessa attribut är som följer:

mailRoutingAddress - Detta är Email Forward - fältet i UG för användare som har detta attribut satt. Om användaren inte har något värde för detta satt blir det automatiskt u1xxxxxx@kth.se. Detta attribut används inte för grupper.
rfc822MailMember - Detta attribut används för grupper. Det sätts till u1xxxxxx@kth.se för alla personer som är medlemar i en grupp. På detta sätt får vi alias-expandering av grupper i UG. Detta attribut används även för grupper som inte kommer ifrån UG utan är direkt instoppade i LDAP.
ugEmailMember - I detta attribut hamnar det som står i fältet Email member i UG. Detta attribut är till för att lägga till epost-adresser för personer som inte är användare i UG till en epostgrupp.

Vart skall jag leverera brevet när jag är klar?

När mx.kth.se har behandlat brevet färdigt så har det en slutgiltig mottagaradress. Det är denna adress som bestämmer vart brevet skall levereras. Detta görs genom att man tar domändelen av mottagaradressen och slår upp i en tabell och får då reda på med vilket protokoll och till vilken dator brevet skall levereras.

I den här frågan tittar man på de objekt som har domändelen av en adress som attributet mailLocalAddress. När man har hittat ett sådant objekt tittar postfix på attributet mailHost för att se med vilket protokoll och till vilken dator den skall leverera brevet.

Databasobjekt

Epostsystemet använder tre olika typer av objekt i LDAP-databasen för att få information ifrån. Dessa är användare, grupper och leverans-objekt. Dessa objekt har en del gemensamma attribut och hanteras delvis på samma sätt, men de bör betraktas som olika klasser.

Användare

Ett användarobjekt kommer normalt ifrån UG och skrivs in i LDAP av en propagator. Ett exempel på en användargrupp är:


dn: cn=Mattias Amnefelt (mtatest2),ou=ugPeople,ou=People,ou=Local,ou=Recipien
 ts,ou=Mail,dc=kth,dc=se
objectClass: top
objectClass: ugAuxObject
objectClass: ugAuxUser
objectClass: nisMailAlias
objectClass: inetLocalMailRecipient
cn: Mattias Amnefelt (mtatest2)
ugAliasUsername: mtatest2@testdomain.kth.se
mailRoutingAddress: u1wxtr3v@kth.se
ugUsername: mtatest2
ugKthid: u1wxtr3v
mailLocalAddress: u1wxtr3v@kth.se
mailLocalAddress: mtatest2@kth.se
mailLocalAddress: mtatest2@testdomain.kth.se
ugClass: user

Detta innebär att denna mottagare har användarnamnet mtatest2, adresserna mtatest2@testdomain.kth.se, mtatest2@kth.se, u1wxtr3v@kth.se och kthid u1wxtr3v. Alla giltiga mottagaradresser för den här användaren finns listade i attributet mailLocalAddress.

Grupper

Grupper som finns i UG representeras i LDAP som grupp-objekt. Dessa skrivs också in av en propagator. Ett exempel på en grupp är:

dn: cn=org.e.mattiasa,ou=ugGroups,ou=Groups,ou=Local,ou=Recipients,ou=Mail,dc=
 kth,dc=se
objectClass: top
objectClass: nisMailAlias
objectClass: ugAuxObject
objectClass: ugAuxGroup
objectClass: inetLocalMailRecipient
cn: org.e.mattiasa
rfc822MailMember: u1n0btuv@kth.se
rfc822MailMember: u1wxtr3v@kth.se
ugEmailMember: test3@e.kth.se
ugEmailMember: mattiasatestar@amnefe.lt
ugEmailMember: test@mattiasatest.kth.se
ugKthid: u268i8pc
mailLocalAddress: mattiasa-testar@kth.se
ugClass: group

Transportobject

Transportobjekt används för att besvara frågan "Vart skall jag leverera brevet när jag är klar?". När postfix har gjort klar allt processande av brevet slår den upp mottagardomänen i ldap och tittar då på attributet mailHost för att komma fram till vilken adress och vilket protokoll den skall prata med för att skicka brevet vidare.

dn: cn=mattiasatest.kth.se,ou=domains,ou=conf,ou=mail,dc=kth,dc=se
objectClass: nisMailAlias
objectClass: inetLocalMailRecipient
cn: mattiasatest.kth.se
mailHost: smtp:[smtp.mattiasatest.kth.se]
mailLocalAddress: mattiasatest.kth.se

Grålistning

Grålistning är ett sätt att undvika SPAM. Det bygger på att de som spammar normalt inte implementerar SMTP-protokollet korrekt. Det fungerar på så sätt att första gången en viss avsändare skickar epost till en viss mottagare så svarar man med ett temporärt fel. Normalt skall en epostserver då vänta ett tag och sedan försöka igen. Detta gör normalt inte spammare.

Programvaran Grappy används för att implementera grålistning och Postfix kommunicerar med Grappy genom postfix policy_daemon-protokoll.

Grappy i sin tur lagrar vilka avsändare som skickat brev till vilka mottagare i en postgresql-databas som kör på datorn greydb.sys.kth.se.

Vår grappy är inställd så att den håller reda på trippeln

<Avsändande epostadress, Mottagande epostadress, Avsändande C-nät>

och första gången en mx ser den trippeln ger man ett temporärt fel under en minut. Detta verkar ha en väldigt bra effekt på spam men ger väldigt liten effekt på vanlig epost.

Spam

Det anti-spamsystem vi använder heter SpamAssassin och bygger på att man gör en sannorlikhetsbedömning för hurvida ett brev är spam eller inte. Varje brev poängbedöms efter ett antal regler som antingen kan ge possitiva eller negativa poäng. Om den totala summan överstiger ett visst tröskelvärde (som i vårat fall är 5.0 poäng) så anses brevet vara spam. Ju högre poäng brevet får desto mer troligt är det att det är spam. mx.kth.se gör ingenting mer än att bedömma sannorlikheten. Det är sedan upp till den individen eller den domänansvariga att bestämma om dessa brev skall hanteras på något speciellt sätt.

Virus

Som anti-virus-motor kör vi F-Secures produkt F-Secure Antivirus for Linux Gateways. Om ett brev bedöms vara virus skickas det till adressen virus@e.kth.se vilket hamnar i en brevlåda som heter org.staff.e.virus på mail1.kth.se

	$Id: mx.html,v 1.7 2006/02/24 10:54:57 mattiasa Exp $

postmaster@kth.se