Avviksrapport: E-postlevering til Universitetet i Agder
| Kontakt: | postmaster-core@usit.uio.no |
|---|---|
| Oppdatert: | INSERT-DATE |
| Skrevet av: | Marte Svalastoga |
Det har vært problemer med levering av noe av e-post som er sendt fra UiO til UiA i perioden 26. februar til 30. april. De som har vært påvirket av feilen vil ha fått en feilmelding i retur som beskriver at e-posten ikke kunne leveres. Som en kunde av UHMX-tjenesten vil e-post sendt til UiA routes gjennom egne tjenere på UiO for spamscanning før de leveres til UiAs e-postsystem.
Innhold:
Beskrivelse av problemet og feilrettingsprosess
Hendelsesforløp :
- 2024-03-20 En ansatt ved UiA kontakter postmaster ved UiO vedrørende problemer med levering til én konkret adresser på UiA fra UiO. Ved graving i logger oppdages det at meldingen har blitt levert gjennom UHMX som normalt, deretter blitt sendt videre til Exchange Online for UiA som vanlig, men at meldingen deretter har blitt levert tilbake til UHMX fra Exchange Online. Dette fortsetter en stund frem til meldingen stoppes pga for mange meldingshoder av UHMX, avsenderen får feilmelding. Inntrykket til Postmaster er at Exchange Online ikke har kjent igjen adressen. Det observeres at levering har gått fint til samme adresse både før og siden. Postmaster antar en midlertidig hikke i Exchange Online, og rapporterer dette tilbake til UiA.
- 2024-04-16 Ny rapport kommer om en ny enkeltadresse på UiA som ikke får e-post sendt fra UiO. Postmaster på UiO følger meldingen, og ser at den slik som i forrige runde ender opp i en løkke før den til slutt avvises grunnet for mange meldingshoder. Postmaster sender detaljer til UiA med forespørsel om de kan se på hvordan det ser ut i deres meldingslogger i Exchange Online.
- 2024-04-19 UiA finner ikke igjen de konkrete meldingene som har vært frem og tilbake, men ser vellykkede leveringer til samme mottakeradresse, og fra samme avsenderadresse. Siden en av meldingene har vært en kalenderinvitasjon gjøres det litt ad-hoc testing av invitasjon frem og tilbake mellom UiO og UiA, ingen problemer oppstår under testingen.
- 2024-04-22 Postmaster etterspør ny status fra UiA, logger utveksles frem og tilbake, uten at noe blir klarere hva årsaken er. UiA spør om det sees noe mønster med avsendertjenere på UiO, men enkelttjenere kan ikke identifiseres som problematiske.
- 2024-04-25 UiA ber om bekreftelse på IP-adresser i bruk av UHMX, for å verifisere at oppsettet på deres Exchange Online er riktig. Postmaster svarer bekreftende, de to nettene som er i bruk av UHMX-tjenere ser riktige ut.
- 2024-04-26 UiA oppretter sak mot Crayon (supportleverandør av Microsoftprodukter).
- 2024-04-29 UiA bemerker at flere rammede e-poster virker å være sendt til flere mottakere. Postmaster tester e-poster til flere mottakere på UiA, og klarer å gjenskape feilsituasjonen på 7/10 e-poster. Det oppdages at e-post som slipper gjennom til UiA har gått gjennom de samme UHMX-tjenerne på det ene subnettet, mens e-postene som går i løkke forøkes leveres fra det andre subnettet.
- 2024-04-30 UiA forsøker å fjerne connectoren med subnettet som feiler fra sin Exchange Online, for så å legge det til på nytt. Dette ser ut til å løse problemet.
Konsekvenser
I en periode fra 26. februar (ukjent årsak til start) frem til og med 29. april 2024 var det problemer med noe e-postlevering til UiA fra UiO. Personene eller systemene ved UiO som har sendt e-post som har feilet vil ha fått en feilmelding som har inkludert linjen Too many "received" headers. Dette gjelder totalt 1282 e-post, til 457 forskjellige mottakeradresser, fra 40 avsendere ved UiO.
Hva skulle vi gjort for at situasjonen ikke oppsto?
Dette virker ikke å være en feil relatert til UiO eller UHMX, men heller en feil oppstått av ukjent årsak i Exchange Online.
Hva kunne USIT gjort bedre?
Vi kunne oppdaget omfanget av feilen på et tidligere tidspunkt, når de første rapportene dukket opp.
Tiltak
Med mindre det oppdages at det er feil gjort på vår side som har ført til feilsituasjonen vil vi ikke iverksette noen tiltak. Det å oppdage at e-poster blir sendt tilbake fra avsendersystem på denne måten er ikke trivielt, og forutsetter sporing av hver enkelt meldings-ID. Volumet har i tillegg vært lavt nok over tid til at det ikke har opplevdes som kritisk for noen involverte parter.