Peter ble forbannet da bounce-meldingen fra Altinn tikket inn

[Redaksjonen.]

– Dette kan fikses på en time!

Peter ble forbannet da bounce-meldingen fra Altinn tikket inn

[pitrh]

Min bloggpost med muligens oppklarende opplysninger om saken finnes her: http://bsdly.blogspot.com/2016/10/is-spf-simply-too-hard-for-application.html

[nomore]

Dette er skuffende vanlig. Utviklere bryr seg ofte ikke så mye mer om e-post en at om det fungerer i test så er det ok.

[Jens Evensen]

Dette er skuffende vanlig. Utviklere bryr seg ofte ikke så mye mer om e-post en at om det fungerer i test så er det ok.

 

Med den ansvarspulveriseringen du finner i større statlige prosjekter så har ofte ikke utviklerne mulighet til å vite om det fungerer i test en gang, langt mindre produksjon. Dessuten så bør dette være en konfigurasjon eller konfigurerbar tilpasning i et system i denne skalaen. Utviklerne er i stor grad redusert til apekatter som må respondere på instruksjoner fra en x-manager (du kan bytte ut x med nesten hva du vil og treffe en person i prosjektorganisasjonen), så ikke vær for snar med å skylde på utviklerne når ting ikke fungerer slik du vil. Hadde utviklerne fått lov til (og vært vant til) å ta større ansvar ende-ende så ville dette kanskje ikke vært et problem.

[nomore]

Nå har eg ikke erfairng fra staten men mye av det du sier er likt andre steder og - og da blir det ett mer generelt problem slik eg ser det.

 

Men eg skal ikke skylde på alle utviklere. Men en slik sak som blir meldt inn utvikler seg som ofte som følger:

- Feil funnet i skjema og kunde eller utvikler blir informert om hvordan feilen skal løses.

- Utvikler henviser til at det fungerer for andre så dette må være noe nytt som har skjedd eller en feil for denne kunden.

- En grundigere forklaring gis med enda flere eksterne kilder.

- Utvikler ser på saken og på alternative løsninger. Estimert pris på å løse problemet gis til kunde.

- Kunde vil ikke betale for endringen da dette har fungert før og mener at skjemaet enten er endret(og nå feil) eller at e-postløsningen er endret(og nå feil).

 

Så har vi det gående...

[IceBlitz]

"Ola er forbannet", "Kari raser", "Jens ser rødt", "han begynte å skjelve av sinne når han så meldingen", "Skammelig frekt sier hun" etc.

 

Dette er vanlige overskrifter, som tilsynelatende gjør folk mer interesserte i å lese.

Trist å se hvor mye sinne og aggresjon det finnes i samfunnet over små og enkle ting for tiden.

 

https://www.google.no/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#tbm=nws&q=forbannet

 

https://www.google.no/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#tbm=nws&q=raser

 

https://www.google.no/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#tbm=nws&q=%22ser+r%C3%B8dt%22

[tommyb]

Jeg er webutvikler og har aldri (før dette) hørt om SPF, DKIM eller DMARC. Det var aldri nevnt i pensum i noe fag, og jeg har aldri (før dette) sett det diskutert på noe sted jeg frekventerer heller. Og hvis jeg forstår saken riktig så hadde jeg heller aldri noen gang kommet til å høre om det hvis utviklerne brukte reply-to feltet her, som kanskje er mer logisk enn avsender-feltet uansett. Jeg tør vedde en nordnorsk glose på at bortimot alle som kjenner til SPF, DKIM og DMARC drifter eller har driftet en epost-server.

Hvorvidt det er for vanskelig for oss utviklere å forstå vet jeg ikke, siden jeg aldri har sett på det, men epostdriftere har definitivt ikke klart å kommunisere SPF-funksjonaliteten godt nok til utviklerne - eller de som setter opp pensum for disse.

Og når jeg har lest dette er min lærdom mer enn annet at mail-protokollene er dårlig egnet til sin primæroppgave: å flytte beskjeder fra A til B, helst tilstrekkelig med driftssikkerhet og informasjonssikkerhet. Men det visste vi vel fra før.

Endret 24. oktober 2016 av tommyb

[Jørgen Ferkingstad]

Bare en liten kommentar:

• Dette dreier seg IKKE om Altinn-løsningen/Altinn-skjemaer som sådan, men et vanlig kontaktskjema i CMS-løsningen (Episerver) for å sende melding til brukerservice.

• Det utgjør ingen sikkerhetsrisiko for brukeren, men han får feilmelding og skjemaet blir ikke sendt inn

• Det er alltid hyggelig å få konstruktive tilbakemeldinger fra konsulenter i det norske driftsleverandørmarkedet. Dere kan jo mye om dette

[_Nils_]

Jeg er webutvikler og har aldri (før dette) hørt om SPF, DKIM eller DMARC. Det var aldri nevnt i pensum i noe fag, og jeg har aldri (før dette) sett det diskutert på noe sted jeg frekventerer heller. Og hvis jeg forstår saken riktig så hadde jeg heller aldri noen gang kommet til å høre om det hvis utviklerne brukte reply-to feltet her, som kanskje er mer logisk enn avsender-feltet uansett. Jeg tør vedde en nordnorsk glose på at bortimot alle som kjenner til SPF, DKIM og DMARC drifter eller har driftet en epost-server.

 

Husker ikke om det ble nevnt spesifikt SPF, men teorien ble i alle fall nevnt på DPH/NITH da jeg gikk der - hvor du gikk vet jeg ikke....

[tommyb]

Husker ikke om det ble nevnt spesifikt SPF, men teorien ble i alle fall nevnt på DPH/NITH da jeg gikk der - hvor du gikk vet jeg ikke....

 

 

Det er positivt, da. Hvilket fag ble det nevnt i? Jeg kan se om jeg finner noe i lærebøkene hjemme. 

Endret 24. oktober 2016 av tommyb

[Xantippe]

Den garantert beste måten å fikse problemer på er å vedta at det ikke er feil.

Dette fungerer 100%.

Det offentlige har brukt metoden opptil flere ganger.

[Lars-Erik]

Akkurat som at utviklere ikke har oversikt over noe så grunnleggende som topp-domener. Får stadig "ugyldig e-post adresse" for min e-post er i toppdomenet ".name" (og da gjelder det sikkert alle de andre nye topp-domenene også).

[Slartibart]

Jeg er webutvikler og har aldri (før dette) hørt om SPF, DKIM eller DMARC. Det var aldri nevnt i pensum i noe fag, og jeg har aldri (før dette) sett det diskutert på noe sted jeg frekventerer heller. Og hvis jeg forstår saken riktig så hadde jeg heller aldri noen gang kommet til å høre om det hvis utviklerne brukte reply-to feltet her, som kanskje er mer logisk enn avsender-feltet uansett. Jeg tør vedde en nordnorsk glose på at bortimot alle som kjenner til SPF, DKIM og DMARC drifter eller har driftet en epost-server.

 

Hvorvidt det er for vanskelig for oss utviklere å forstå vet jeg ikke, siden jeg aldri har sett på det, men epostdriftere har definitivt ikke klart å kommunisere SPF-funksjonaliteten godt nok til utviklerne - eller de som setter opp pensum for disse.

 

Og når jeg har lest dette er min lærdom mer enn annet at mail-protokollene er dårlig egnet til sin primæroppgave: å flytte beskjeder fra A til B, helst tilstrekkelig med driftssikkerhet og informasjonssikkerhet. Men det visste vi vel fra før.

 

A) Som du selv sier så er du er webutvikler, dette er ikke webutvikling.

B) Snakk for deg selv, ikke prøv å være talerør for alle utviklere med å tittelere deg med "oss utviklere". Jeg og mange av mine kollegaer (og noen av dem er endog "webutviklere" også) har hørt om dette.

C) Studiene lærer deg å lære, det er ikke meningen man skal vite om alt når man er ferdig (bare hvor og hvordan man skal lete).

D) En annen lærdom du (og mange andre) burde tatt ut av dette er at det er mye du ikke vet. Enda.

[tommyb]

A) Som du selv sier så er du er webutvikler, dette er ikke webutvikling.

B) Snakk for deg selv, ikke prøv å være talerør for alle utviklere med å tittelere deg med "oss utviklere". Jeg og mange av mine kollegaer (og noen av dem er endog "webutviklere" også) har hørt om dette.

C) Studiene lærer deg å lære, det er ikke meningen man skal vite om alt når man er ferdig (bare hvor og hvordan man skal lete).

D) En annen lærdom du (og mange andre) burde tatt ut av dette er at det er mye du ikke vet. Enda.

 

 

A) Ja, det er jo det jeg sier. 

B) Jeg snakker for meg selv, det jeg har fått med meg av pensum, men gjør også en godt definert gjetning ("jeg vedder") på at de fleste som har hørt om dette, har vært involvert i drifting. Du har vært involvert i serveroppsett og drifting, ja? 

C) Hvor og hvordan man skal lete er greit, men når og hvorfor man skal lete etter noe man ikke vet man trenger vite, er også interessant. For meg ville dette klart falt inn under kategorien "epostserver-oppsett", og jeg visste inntil nå ikke at det fantes et SPF som egentlig virker ganske nyttig for meg. Det man ikke blir eksponert for og heller ikke virker å være i nærheten av arbeidsfelt, er ikke det man bruker tiden på. Når jeg nå leste denne artikkelen, ble jeg naturlig interessert i om det berører våre kontaktskjemaer, og om det videre kan være nyttig å kunne noe om de andre to nevnte protokollene i forhold til utsending av mail fra webapplikasjonene. Men SPF er ikke akkurat det mest omtalte temaet på jobb, og ikke her på forumet heller. 

D) Jeg vet ingenting, med noen få unntak. 

Endret 24. oktober 2016 av tommyb

[ksvenheim]

Fødsels- og personnummer er ikke sensitive personopplysninger, så han kunne spart seg henvendelsen i utgangspunktet

[BareGjest]

Fødsels- og personnummer er ikke sensitive personopplysninger, så han kunne spart seg henvendelsen i utgangspunktet

 

+1

 

https://www.datatilsynet.no/personvern/personopplysninger/

 

Folk hopper i taket med en gang personnummer er involvert i forhold til kommunikasjon med enten offentlig eller privat forvaltning, men fødsels- og personnummer er altså ikke sensitive opplysninger om en person. 

[Lars-Erik]

 

Fødsels- og personnummer er ikke sensitive personopplysninger, så han kunne spart seg henvendelsen i utgangspunktet

 

+1

 

https://www.datatilsynet.no/personvern/personopplysninger/

 

Folk hopper i taket med en gang personnummer er involvert i forhold til kommunikasjon med enten offentlig eller privat forvaltning, men fødsels- og personnummer er altså ikke sensitive opplysninger om en person. 

 

 

Men det skal IKKE sendes i e-post heller (eller SMS). Så det er litt spesiellt.

Men jeg er enige i at vi har for "panikk" om fødselsnummer.

I andre land er "social security id" etc helt offentlig.

 

Fra https://www.datatilsynet.no/personvern/Personopplysninger/Fodselsnummer/

Sending av fødselsnummer

Når fødselsnummer inngår i en forsendelse, skal det ikke være tilgjengelig for andre enn deg som mottaker. Nummeret må derfor sikres når det sendes per brev, i e-post eller sms.

• Når fødselsnummer sendes som post skal det sendes i lukket konvolutt. Fødselsnummeret skal ikke være synlig i konvolutt-vinduet eller være skrevet på utsiden av konvolutten.
• Når fødselsnummer sendes i e-post eller ved hjelp av annen telekommunikasjon, skal det krypteres.
• Fødselsnummer kan i enkelte tilfeller kommuniseres over sms, fordi denne kommunikasjonsformen har en viss informasjonsikkerhet.

Endret 24. oktober 2016 av Lars-Erik

[0laf]

Som nevnt ovenfor anses ikke fødselsnummer å være konfidensiell informasjon, men generelt sett ville det være vanskelig å få tilgang til Peters telefon og tekstmeldinger.

 

Det finnes mange enklere måter å finne ut fødselsnummeret til Peter, enn å fange opp tekstmeldingene hans.

 

Peter, som ser ut til å være i midten av femtiårene en plass, er gammel nok til å ha betalt skatt den gangen skattelistene oppga fødselsdato, og han er også en ivrig bruker av sosiale medier.

På hans åpne facebookside, kan man finne kona, datteren, alderen og stillingen til Peter relativt enkelt.

 

Vet man for eksempel når Peter er født, for å ta en dato helt ut av luften, for eksempel 28 august det herrens år 1963, i Drammen, og at Peter selvfølgelig er mann, så har man bare et par hundre muligheter for resten av fødselsnummeret.

 

Uten å detaljere fremgangsmåten her, så finnes formlene tilgjengelige på Wikipedia, og når man har generert tallene, kan de enkelt sjekkes opp på nettsider som selger diverse abonnementer og sjekker fødselsnummer mot folkeregisteret, og ja, det finnes fremdeles en rekke av disse som ikke er særlig godt sikret.

 

Dette er jo langt enklere enn å få tilgang til telefonen til Peter.

 

Nå er det vel slik at det er Evry som har rammeavtale med Skatteetaten om levering av UNIX servere og tjenester, og derfor også Evry som må fikse dette.

 

For ordens skyld, så jobber altså Peter i Evry, nettopp med UNIX og infrastruktur, slik at han kunne vel helt fint ha fikset dette selv, og det kan nesten se ut som det er han selv som har gjort feil her?

Endret 24. oktober 2016 av adeneo

[Bjørn A. Johansen]

Jeg er webutvikler og har aldri (før dette) hørt om SPF, DKIM eller DMARC. Det var aldri nevnt i pensum i noe fag, og jeg har aldri (før dette) sett det diskutert på noe sted jeg frekventerer heller. Og hvis jeg forstår saken riktig så hadde jeg heller aldri noen gang kommet til å høre om det hvis utviklerne brukte reply-to feltet her, som kanskje er mer logisk enn avsender-feltet uansett. Jeg tør vedde en nordnorsk glose på at bortimot alle som kjenner til SPF, DKIM og DMARC drifter eller har driftet en epost-server.

 

Hvorvidt det er for vanskelig for oss utviklere å forstå vet jeg ikke, siden jeg aldri har sett på det, men epostdriftere har definitivt ikke klart å kommunisere SPF-funksjonaliteten godt nok til utviklerne - eller de som setter opp pensum for disse.

 

Og når jeg har lest dette er min lærdom mer enn annet at mail-protokollene er dårlig egnet til sin primæroppgave: å flytte beskjeder fra A til B, helst tilstrekkelig med driftssikkerhet og informasjonssikkerhet. Men det visste vi vel fra før.

 

Jeg er webutvikler og SFP fantes ikke når jeg gikk på skolen. Jeg vet likevel godt hva SFP, DKIM og DMARC er, og vet veldig godt at jeg uansett ikke skal spoofe en avsender av en e-postmelding. Noe så enkelt som at en bounce-melding kommer til korrekt mottaker er grunn nok.

 

Skal du implementere noe mot et API eller bruke en protokoll, er det ganske grunnleggende å først lære seg hvordan APIet/protokollen fungerer.

[0laf]

Jeg er webutvikler og SFP fantes ikke når jeg gikk på skolen.

Det finnes fremdeles ikke, det heter SPF (Sender Policy Framework), og de fleste utviklere, selv webutviklere, som har vært borti PHPMailer, System.Net.Mail i C# eller lignende, burde også ha vært borti SPF, det har vært forholdsvis elementær kunnskap de siste 5-10 årene.