Felles studentsystemKort oppskrift
- Finn ut om e-postutsending må gå via proxy
Dersom institusjonens e-posttenar ikkje ligg i UH-nettet, må databasen sende via ein proxy på UiO IT sitt nett. - Institusjonens e-posttenar må tillate e-post frå databasen (eller frå proxy)
- Kontakt oracle-drift@usit.uio.no for oppsett i FS
E-posttenarens hostname og port må settast opp i database eller i proxy - For kryptert e-post må institusjonens e-posttenar ha eit gyldig sertifikat og tilby STARTTLS
- Send e-posttest til ulike adresser og kontroller header-informasjon
Proxy eller ikkje
Databasane hos UiO får berre snakke med tenarar i UH-nettet. Dersom institusjonens e-posttenar er tilgjengeleg frå basen, kan veg A brukast.
Ligg institusjonens e-posttenar utanfor UH-nettet, til dømes i Microsoft 365, Google Workspace eller hos ein annan leverandør, må e-posten gå via ein proxy hos UiO (veg B).
E-post-flyt via veg A og B
Oppsett av institusjonens e-posttenar
IT-avdelinga ved institusjonen må opne e-posttenaren for mottak av e-post frå databasen, sjå veg A og veg B nedanfor.
E-post frå FS må sendast vidare på same måte som e-post frå dei tilsette. Systemet som sender e-posten ut på Internett, må signere med DKIM for domenet og sende frå IP-adresser, både IPv4 og IPv6, som har PTR og står i SPF-posten. For Microsoft 365 må DKIM vere slått på for domenet.
Veg A: direkte til e-posttenaren til institusjonen
E-post frå databasetenaren institusjonen tilhøyrer må godkjennast:
| VPD-database | Databasetenar |
|---|---|
| FS01PRD | dbora-fssek-prod01.uio.no |
| FS02PRD | dbora-fssek-prod02.uio.no |
| FS03PRD | dbora-fssek-prod03.uio.no |
| FS04PRD | dbora-fssek-prod04.uio.no |
| FS05PRD | dbora-fssek-prod05.uio.no |
| FS06PRD | dbora-fssek-prod06.uio.no |
Bruk mynetworks i Postfix eller ein Receive connector i Exchange Server. Dersom tenaren sender vidare til Microsoft 365, skal det ikkje vere nødvendig å gjere endringar i Exchange Online.
Veg B: via proxy hos UiO
E-post frå dbd-epost-proxy01.uio.no (IP-adresse 129.240.118.152) går over ein avtalt port. Denne kan godkjennast for Microsoft 365 / Exchange Online ved å lage ein inngåande connector (inbound connector):
(Merk at dersom de har ein hybrid-connector for eigne tenarar, så kan det vere nok å leggje IP-adressa til der.)
Gå til Exchange admin center -> Mail flow -> Connectors -> Add a connector
- Connection from skal settast til Your organization's email server
- Gje connectoren eit namn, til dømes FS via UiO-proxy
- Sørg for at connectoren er påslått og Retain internal Exchange email headers er slått av
- På wizard-sida Authenticating sent email, vel autentisering ved IP-adresse
Legg inn 129.240.118.152
Når connector er sett opp, må dette gjerast i tillegg:
- Legg til ip4:129.240.118.152 i SPF-posten for dykkar domene for at e-posten ikkje skal ende i spamfilter.
- Avsendaradressa i FS (sjå systemverdier i FS-klienten) må vere i eit domene som er verifisert som accepted domain av Microsoft 365-tenanten.
- Sørg for at DKIM er slått på for domenet, slik at e-post blir signert når han går ut frå e-posttenaren.
- Gi oracle-drift MX-namnet, t.d. institusjon-no.mail.protection.outlook.com. De finn det under Microsoft 365 admin center -> Settings -> Domains. Proxyen blir sett opp til å sende vidare dit, og i FS blir det forventa sertifikatnamnet (mail.protection.outlook.com for Microsoft 365) sett opp i kolonna Systemverdier.Smtp_Tls_Sertifikatnavn
Kva mottakande e-posttenar sjekkar
| Sjekk | Kva det betyr |
|---|---|
| SPF | Avsendardomenet har oppgitt i DNS kva tenarar som får sende e-post for det |
| DKIM | E-posten er digitalt signert av avsendardomenet |
| DMARC | Domenet seier kva mottakaren skal gjere med e-post som ikkje passerer SPF- eller DKIM-sjekken |
| PTR | IP-adressa til tenaren som sender ut, har eit namn som peikar tilbake til den same adressa |
Gmail avviser e-post som verken står SPF- eller DKIM-sjekken, og e-post frå tenarar utan PTR. Microsoft lever ofte slik e-post, men med ei åtvaring om at avsendaren ikkje kan kontrollerast.
Igjen: Det enklaste er å la e-post frå FS gå gjennom det same e-postsystemet som dei tilsette brukar. Der er sannsynlegvis SPF, DKIM, DMARC og PTR alt sett opp.
Kryptering
Databasen prøver å sende e-post kryptert til institusjonens e-posttenar. Dersom tenaren ikkje har eit gyldig sertifikat, eller ikkje tilbyr STARTTLS, går e-posten ukryptert. I så fall vil det dukke opp varsel med kode MAIL-UKRYPTERT i institusjonens varsellogg, som er synleg i FS-klienten.
Utsending frå smtp.uio.no er ikkje tilrådd
Mange institusjonar har sendt ut e-post frå FS via USIT sin e-posttenar smtp.uio.no, og ein del gjer det framleis i 2026. Dette har dei seinare åra blitt meir og meir problematisk, fordi mottakarane no krev at e-posten kan knytast til domenet i avsendaradressa.
Korleis utsending via smtp.uio.no likevel kan fungere
Dersom institusjonens oppføring i DNS inneheld include:spf.uio.no, kan det likevel gå å sende ut e-post. Vi frårår dette, og det same gjer UiOs postmaster, for det har vore problem med det, og det tillet alle e-posttenarar som kjem under spf.uio.no, ikkje berre databasane, å sende e-post som gir seg ut for å komme frå institusjonen.
Slik testar de
Send e-post frå FS-klienten til ulike adresser du har tilgang til og inspiser headerane i e-postklienten.
Sjå på linja Authentication-Results. Helst skal det stå spf=pass, dkim=pass og dmarc=pass.
Kjem e-posten ikkje fram, sjå etter ei avvisingsmelding i innboksen til avsendaradressa. Der står grunnen. (Dette føreset at du har tilgang til å lese e-post som kjem til avsendaradressa.)
Test av kryptering: Ein del e-posttenarar vidaresender ikkje informasjon om kommunikasjonen med databasen. For dei som gjer det, kan du sjå etter Received-linje frå databasen. Den skal ha version=TLS1_2, version=TLS1_3 eller with ESMTPS. Dersom e-post går utan kryptering, vil det dukke opp varsel i FS-klientens varsellogg.