Sähköpostista keskustelua

  • Viestiketjun aloittaja Viestiketjun aloittaja Arisoft
  • Aloituspäivämäärä Aloituspäivämäärä
Itsekin sähköpostioperaattorina tämä määräys kiinnostaa, kun en ole siitä kuullut ainakaan tässä muodossa. Mihin määräykseen tässä viittaat?
Olen käsittänyt, että operaattorit ovat järjestäneet keskenään kansainvälisiä viestinvälitysketjuja, jotka välittävät sertifioituna todellisen koneosoitteen, mistä viesti on putkahtanut tuohon luotettuun välitysketjuun. Toisaalta suomalaiset maili-operaattorit eivät saa välittää kuluttajien viestejä vapaasti smtp-protokollan kautta, vaan on käytettävä tiettyjä rajapintakoneita, jotta saa viestinsä tuohon ketjuun. Certti on pakottanut käyttämään Suomessa ko. ketjuja.

Eli vaikka lähettävä voi väittää olevansa kuka vain, lähettäjän tiedot näkyvät osoitekentässä. Itse operoiden toki voi pudota pois joistakin välitysketjun palasista. Toisaalta Suomeen ei ole ihan helppo saada julkisten operaattoreiden mailipalveluihin yleensä lähetetyksi mitään, jollei noudata tuon runkovälitysketjun speksejä.

Tuo siis epätäsmällisenä kuvauksena vain siitä, mihin viittaan.
 
Olen käsittänyt, että operaattorit ovat järjestäneet keskenään kansainvälisiä viestinvälitysketjuja, jotka välittävät sertifioituna todellisen koneosoitteen, mistä viesti on putkahtanut tuohon luotettuun välitysketjuun.

Sellaista ei ole olemassa kuin sisäisesti esim. Microsoftilta postipalvelua ostavat voivat suhteellisen hyvin luottaa muilta microsoftin postipalvelun käyttäjiltä tuleviin viesteihin, että lähettäjä on oikea muta vain jos lähettäjä käyttää samaa palvelua.

Postia saa ja voi edelleen lähettää varsin vapaasti. Google on julkisista kaikista nirsoin ottamaan vastaan viestejä lähettäjiltä, joita ei ole mitenkään rekisteröity. Yleensä osoitteen rekisteröimättämyys lähettäjäksi näkyy vain siinä ettei Google ota niitä vastaan.

Lähetäjästä ei rekisteröidä henkilöä vaan postiosoite ja ip-osoite, josta viesti on lähetetty ja nekin voi väärentää helposti.

Sähköpostissa olevaan "Lähettäjä" kenttään voi edelleen kirjoittaa mitä tahansa. Sitä ei tarkasteta juuri missään järjestelmässä, koska jos niin tehtäisiin, jäisi liki kaikki jakelulistat toimittamatta perille. Viestin otsikkotiedoista, joita käyttäjä ei yleensä näe, voi löytyä parempi vihje lähettäjästä. Ainakin se viimeisin IP-osoite, mistä viesti on tullut.

Google on ottanut käyttöön systeemin, jossa viestissä on kaksi lähettäjää. Toinen on se perinteinen feikki ja toinen on se, jonka osoitteella viesti on tosiasiassa lähetetty. Samaa toivoisi näkevän muuallakin.

Toisaalta suomalaiset maili-operaattorit eivät saa välittää kuluttajien viestejä vapaasti smtp-protokollan kautta, vaan on käytettävä tiettyjä rajapintakoneita, jotta saa viestinsä tuohon ketjuun. Certti on pakottanut käyttämään Suomessa ko. ketjuja.

Välittämistä ei ole kukaan kieltänyt maili-operaattoreilta. Sen sijaan sähköpostin lähettäminen smtp portin 25 kautta on oletusarvoisesti estetty kuluttaja-internet-littymissä. Postia voi kuitenkin lähettää muiden porttien kautta muunmuassa 587, 465 ja 2525.

Eli vaikka lähettävä voi väittää olevansa kuka vain, lähettäjän tiedot näkyvät osoitekentässä.

Tämä on väärinkäsitys. Esim. tältä foorumilta tuleviin sähköposteihin lähettäjäksi on merkitty "Elä vastaa tähän <noreply@lampopumput.info>" mikä ei ole se oikea lähettäjä. Sellainenkin sillä on, mutta en laita sitä tähän näkyviin.
 
^ Esimerkiksi Elisa Oyj:n välittämien viestien headereissa on kenttä. "DKIM-Signature". Tuo kulkee viestin mukana alkuperäiseltä vastaanottajalta. Välittävät lenkit voivat lisätä noita. Tuo käsittääkseni takaa, että jos viesti kulkee välittäjien keskenään hyväksymän välitysketjun kautta, viestin alkuperäisen lähettäjän domain-osoite on oikeaksi tunnistettu (moisten välittäjien käyttämät nimipalvelimet ovat nykyisin suhteellisen luotettavia, kun niissäkin on sertifikaattiprotokollat käytössä).

Muistelen lukeneeni, että Suomessa operaattorin pitää merkitä lähettäjän osoitteeksi tuosta DKIM-Signature'sta napattu lähettäjän osoite viestissä uskotellun lähettäjästringin perään ja moinenhan on se "aitoustodistus". Ei ole ainakaan itselleni vielä tullut vastaan huijausviestiä, joissa pelkästään tuo Suomessa lisätty jatko-osa ei kertoisi, että viesti on bluffia.

Omaa kokemusta on, että esimerkiksi EU-alueelta jotkut yrittävät lähetellä sähköpostejaan suoraan ao. operaattorille smtp-protokollalla, mutta sehän ei onnistu, koska viestin olisi pitänyt sisältää em. kaltainen sertifikaattiketju.
 
Ne DKIM allekirjoitukset kulkevat kaikkien sähköpostien headereissä. Ei kukaan viranomainen ole niitä vaatinut, vaan Google ottaakseen vastaan sähköpostia vaati. Eikä tässä ole mitää salaliitto-putkia mitä pitkin sähköpostit kulkevat salaseuran sisällä. Ihan SMTP-protokollan avulla kulkevat edelleen.
 
Eikä tässä ole mitää salaliitto-putkia mitä pitkin sähköpostit kulkevat salaseuran sisällä. Ihan SMTP-protokollan avulla kulkevat edelleen.
Mutta toki on kuljettava koko matkan luotettua putkea pitkin, sillä jos viesti kävisi välillä jollakin "epämääräisellä pajalla", nuohan voisivat vaihtaa sisällön ja mikä pahinta, tekaista aivan legitiimit signatuurit, miten ikinä lystäävät.
 
Muistelen lukeneeni, että Suomessa operaattorin pitää merkitä lähettäjän osoitteeksi tuosta DKIM-Signature'sta napattu lähettäjän osoite viestissä uskotellun lähettäjästringin perään ja moinenhan on se "aitoustodistus". Ei ole ainakaan itselleni vielä tullut vastaan huijausviestiä, joissa pelkästään tuo Suomessa lisätty jatko-osa ei kertoisi, että viesti on bluffia.

DKIM on ihan vapaaehtoinen lisäominaisuus eikä edes Google vaadi sitä tulevalta postilta. Sille kelpaa myös kevyempi SPF rekisteröinti, jossa lähettäjä itse määrittelee mitä kautta hän aikoo postia lähettää.

Operaattorin ei ole pakko näitä lisäillä. Menetelmä varmistaa, että viesti on todella peräisin kyseiseltä lähettäjältä eikä sitä ole muutettu matkan varrella. Lähettäjää se ei tosin varmista, ainoastaan sen, mistä palvelimelta viesti on lähetetty, koska palvelin lisää sen viestiin.
 
Menetelmä varmistaa, että viesti on todella peräisin kyseiseltä lähettäjältä eikä sitä ole muutettu matkan varrella. Lähettäjää se ei tosin varmista, ainoastaan sen, mistä palvelimelta viesti on lähetetty, koska palvelin lisää sen viestiin.
Käytännössä moisesta on suuri apu, koska huijausviestejä näköjään varsin tyypillisesti leivotaan Amazonin virtuaalikoneilla ja sen jäljet paistavat viestin headeristä. Tiedä sitten, miksi noin. Ehkä sieltä saa liittymistarjouksena ilmaisen virtuaalikoneen, jolla voi potkaista noita viestejä ympäri maailmaa, eikä touhuja logata kovin yksityiskohtaisesti, eli teosta ei jää kiinni eikä tekosia pysty jäljittämään. En tunne Amazonin tervetuliaistarjontaa.
 
Mutta toki on kuljettava koko matkan luotettua putkea pitkin, sillä jos viesti kävisi välillä jollakin "epämääräisellä pajalla", nuohan voisivat vaihtaa sisällön ja mikä pahinta, tekaista aivan legitiimit signatuurit, miten ikinä lystäävät.
Salaus ei toimi noin.
 
Käytännössä moisesta on suuri apu, koska huijausviestejä näköjään varsin tyypillisesti leivotaan Amazonin virtuaalikoneilla ja sen jäljet paistavat viestin headeristä. Tiedä sitten, miksi noin. Ehkä sieltä saa liittymistarjouksena ilmaisen virtuaalikoneen, jolla voi potkaista noita viestejä ympäri maailmaa, eikä touhuja logata kovin yksityiskohtaisesti, eli teosta ei jää kiinni eikä tekosia pysty jäljittämään. En tunne Amazonin tervetuliaistarjontaa.

Virtuaalikoneet eivät maksa paljoa. Esim. Hetznerin halvoilla pilvipalvelimilla on postin lähetys estetty samalla tapaa kuin kuluttajaliittymistä. Lähettäminen onnistuu vasta kun on ollut riittävän kauan asiakkaana. Tämä ihan siksi että roskapostittajat ostelee noita vähäksi aikaa lähettääkseen sitten kasapäin roskapostia.

Ei näistä roskapostia vastaan ole kuin jonkinlaine apu. Nimittäin vain osassa viestejä on DKIM ja jos sen puuttumisesta viestin suodattaa niin suuri osa oikeaa postia estyy. SPF on Googlen ansiosta päätynyt siihen tilanteeseen, että jos se puuttuu niin viestin voi suodattaa, koska jokaisella postia lähettävällä on se oltava kunnossa, jotta voi kommunikoida Googlen asiakkaille.

Google toteutti tuon hyvin nerokkaasti. Ensin alkoivat suodattaa vain satunnaisesti postia jos SPF ei ollut voimassa. Posti saattoi mennä läpi jos yritti uudelleen. Vähitellen vaatimus on voimistunut. Näin kaikki asialliset ehtivät huomata tilanteen ilman liian radikaaleja vaikutuksia.

SPF ei vaadi postipalvelimelimelta mitään. Siksi se on helpompi saada pystyyn. DKIM taas vaatii että palvelin suostuu tekemään allekirjoitukset. Kaikki eivät tee, joten DKIM puuttuu isosta määrästä postia.
 
Ei näistä roskapostia vastaan ole kuin jonkinlaine apu. Nimittäin vain osassa viestejä on DKIM ja jos sen puuttumisesta viestin suodattaa niin suuri osa oikeaa postia estyy. SPF on Googlen ansiosta päätynyt siihen tilanteeseen, että jos se puuttuu niin viestin voi suodattaa, koska jokaisella postia lähettävällä on se oltava kunnossa, jotta voi kommunikoida Googlen asiakkaille.
Ei tässä muuten ollut kysekään roskapostin välttämisestä, vaan lähettäjäspoofingin havaitsemisesta.
 
Ei tässä muuten ollut kysekään roskapostin välttämisestä, vaan lähettäjäspoofingin havaitsemisesta.

Eikös nämä ole paljolti sama asia? Huijausviestithän on roskapostia.

Jos itsellä olisi tilanne, että pitäisi selvitellä viestin aitoutta niin katselisin sähköpostin otsikkotietoja, onko siellä jotain epäilyttävää. Jos viesti on tullut suoraan lähettäjän domainista niin en olisi huolissani aitoudesta.

Esim: Osuuspankista tullut viesti oli lähetetty omaan osoitteseeni, mikä on hyvä merkki. Yleensä huijauksissa vastaanottajaksi on merkitty joku muu.

Viesti oli tullut palvelimelta 5ocilpsegaps04.op-palvelut.fi, mikä on myös hyvä juttu. Viestintäviraston mukaan sen omistaa OP Osuuskunta. Se osoittaa että viestissä ei ole väärennettyjä lähettäjätietoja, koska vain viimeisin (ylimpänä oleva) tieto on luotettava. Kaikki sen alla voi olla keksittyä.

Viestissä ei ollut yhtään linkkiä, mikä myös tukee sitä tulkintaa, että se on aito.
 
Eikös nämä ole paljolti sama asia? Huijausviestithän on roskapostia.
Omasta mielestäni on eroa sillä, jos roskapostiviesti sisältää kaikenlaista valhetta ja väitettä ja lähettäjätiedotkin ovat mitä sattuu kuitenkin, että tämä kaikki näyttää viestin laatijan aikaansaannokselta, ja sillä, että viestin välitykseen käytetty ammattimaisten tietoliikenneoperaattoreiden ketju ei välitä asiakkaalleen tiedoksi haltuunsa tulleiden varmennattavissa olevien viestin välitysketjun olennaisia viitetietoja. Tällä on erityisesti merkitystä, jos viestiin on valheellisesti leivottu otsakesisältö, jonka mukaan viesti edustaisi tunnettua ammattimaista luotettua tahoa, mutta viestiketjun välitystiedoista vastaansanomattomasti käy ilmi, että lähettäjän osoitetiedot eivät voi pitää paikkaansa (ts. luettava ja vastuullinen toimija ei ikinä hoitaisi viestintäänsä tuollaista ketjua pitkin).

Ja vain kommenttina, että nimenomaan viestin tuleminen luotettavasta domain-osoitteesta on keskeistä tässä, mutta sehän vaatii tarkistamista, eli käyttäjien itse perustamien domainien kautta kommunikoidessa melkein kaiken pystyy väärentämään nimipalveliminen tiedoista alkaen eikä ilman tarkistuksia millään oole merkitystä. Myös viestien hyppy jonkin epäilyttävän välipalvelimen kautta voi väärentää kaiken mahdollisen (jotakin saattaa toki selvitä otsakkeiden täydellisellä läpikäynnillä).
 
Viimeksi muokattu:
viestin välitykseen käytetty ammattimaisten tietoliikenneoperaattoreiden ketju

Ei siellä mitään ketjua pitäisi olla. Lyhykäisyydessään tänä päivänä, johtuen kaikista näistä rekisteröintivaatimuksista, "ketju" sisältää kaksi palvelinta. Lähettäjän valtuuttama palvelin ja vastaanottojan valtuuttama palvelin. Jos viestiä yrittäisi välittää jotenkin muuten, niin se ei enää mene helposti perille johtuen SPF:stä.

SPF tarkoittaa sitä, että viestin lähettäjä ilmoittaa etukäteen julkisesti, miltä palvelimelta hän lähettää viestejä. Määrityksen seurauksena muuta kautta lähetetyt viestit eivät aina mene perille johtuen roskapostisuodattimista. Tämä menettely estää sellaiset ketjut, joihin kenties viittasit. Toki kahdenkeskinenkin viestien välittely on "ketju", mutta mihinkään erityisiin välitysketjuhin ei siis ole enää paluuta.
 
Toki kahdenkeskinenkin viestien välittely on "ketju", mutta mihinkään erityisiin välitysketjuhin ei siis ole enää paluuta.
Kutsuisin minäkin tuota "ketjuksi". Olennaista on, että kuka tahansa ei voi enää lähetellä sähköposteja kenelle tahansa kunnolla operoidussa verkossa, koska Traficom on kieltänyt moisen (välillisesti seurauksena muista vaatimuksista). Käytännössä muut kuin tunnistetuista domain-osoitteista lähetetyt viestit heitetään matkalla roskiin ja ilman domain-osoitetta ja tähän liittyviä palvelinmäärittelyjä et pääse suoraan kiinni smtp-palveluihin julkisessa internetissä (kotiverkoissa ja vastaavissa toki).

Käytännössä viestit kuitenkin kulkevat pitkienkin ketjujen kautta (ainakin toistaiseksi), minkä näkee, kun katsoo viestien otsakeosuuksia kokonaisuudessaan. Valittevasti monilla mail-asikasohjelmilla tämä on vaikeaa tai jopa mahdotonta.
 
Kutsuisin minäkin tuota "ketjuksi". Olennaista on, että kuka tahansa ei voi enää lähetellä sähköposteja kenelle tahansa kunnolla operoidussa verkossa, koska Traficom on kieltänyt moisen (välillisesti seurauksena muista vaatimuksista).

Traficomilla ei ole tässä osaa eikä arpaa. "Internet" ratkaisi ongelman, jota Traficom yritti rajoittaa, siirtymällä tähän SPF menettelyyn.

Traficom ei vaadi SPF:n käyttöä - Google vaatii.

Edelleen kuka tahansa voi lähettää sähköpostia kenelle tahansa kenen tahansa nimissä, mutta JOS vastaanottaja suodattaa viestejä SPF:n avulla, niin viestin lähettäjäksi ei voi käyttää sellaista osoiteta, joka on rekisteröity muualle, ilman että se joutuu herkästi roskapostisuodattimen hampaisiin.

Käytännössä viestit kuitenkin kulkevat pitkienkin ketjujen kautta (ainakin toistaiseksi), minkä näkee, kun katsoo viestien otsakeosuuksia

Ne pitkät ketjut ovat operaattorin sisäisiä ketjuja. Esim. Osuuspankin lähettämässä viestissä oli useita Osuuspankille rekisteröityjä laitteita alkaen siitä laitteesta, joka viestin alunperin laati. Niiden tarkoitus oli siirtää viesti sille erityiselle palvelimelle, joka on rekisteröity viestien aidoksi lähettäjäksi, ja jonka vastaanottaja näkee lähettäjänä.

Esim. Osuuspankin viesti kulki seuraavan lenkin

84357-wls-u10.op.okobank.com (Tämä laite luo viestin)
5ociwpexgap07.op.okobank.com (Tämä laita otti sen välitettäväksi)
7ociwpexgap06.op.okobank.com (Tämä laite otti sen välitettäväksi)
5ocilpsegaps04.op-palvelut.fi (Tämä laite lopulta lähetti sen)

En tiedä miksi Osuuspankki siirteli vietiä noin paljon sisäisesti. Luultavasti siihen liittyy jotain palomuuritoimintoja. Jokainen siirto kenties ohitti yhden turvallisuuskerroksen. Yksikään viestiä sisäisesti välittäneistä laitteista ei sijaitse Internetissä, joten ne eivät olisi voineet sitä vielä edes lähettää yrityksen ulkopuolelle.
 
Niin ja edellisessä esimerkissä on huomattavaa, ettei välissä ollut oikeasti yhtäkään "sähköpostioperaattoria" vaan viestin lähetti Osuuspankki ihan itse ja minä otin sen vastaan ihan itse. Mikään Elisa, Telia tms. ei itse asiassa edes pysty selvittämään mitä viestissä luki, koska se välitettiin TLS salattuna suoraan osapuolten kesken.
 
Edelleen kuka tahansa voi lähettää sähköpostia kenelle tahansa kenen tahansa nimissä, mutta JOS vastaanottaja suodattaa viestejä SPF:n avulla, niin viestin lähettäjäksi ei voi käyttää sellaista osoiteta, joka on rekisteröity muualle, ilman että se joutuu herkästi roskapostisuodattimen hampaisiin.
Onko muka pakko käyttää jonkin domainin omistajan asiallisesti rekistereihin merkittyä välityspalvelinta poistettu, jotta verkko-operaattori saa reitittää smtp-porttiin yhteyttä ottavat TCP-yhteydenottopyynnöt eteenpäin? Eihän mailin lähetys onnistu, jollei pääse kiinni protokollan edellyttämiin palveluihin.
 
Ne pitkät ketjut ovat operaattorin sisäisiä ketjuja.
Siis sellaisia on sittenkin. Toki myös saman omistajan mahdollisesti hallitsemien erillisten organisaatioiden kautta, mutta näkyy olevan myös steppejä, jotka vaikuttaisivat olevan organisaatioiden välillä (ovatko nuo todellisia vai vain virtuaalisia esimerkiksi palomuurijärjestelyjen, roskapostisuodatuksen ym. ym. takia on vaikea ulkopuolisen päätellä).
 
Onko muka pakko käyttää jonkin domainin omistajan asiallisesti rekistereihin merkittyä välityspalvelinta poistettu, jotta verkko-operaattori saa reitittää smtp-porttiin yhteyttä ottavat TCP-yhteydenottopyynnöt eteenpäin? Eihän mailin lähetys onnistu, jollei pääse kiinni protokollan edellyttämiin palveluihin.

Ei sellaista pakkoa ole ollut eikä ole voinutkaan olla. Ainoa "pakko" on olllut se että kotiliittymästä on pitänyt estää postin lähettäminen porttiin 25. Tämä tehtiin roskapostin lähettämisen estämiseksi maallikon käyttämistä IP-osoitteista, Tämä on siis se virallinen määräys ja virasto on jopa pohtinut sen kumoamista, kuten seuraavassa muistiossa kerrotaan.

Koska portti 25 on ollut estettynä on ollut pakko lähettää posti jonkin välityspalvelun kautta. Juuri mikään käyttäjän sähköpostiohjelma ei edes tarjoa mahdollisuutta lähettää viestiä suoraan vastaanottajalle, koska niistä puuttuu postin reititysominaisuuudet. Esim. Outlook ja Thunderbird eivät osaa lähettää viestiä muualle kuin ennalta määrättyyn palvelimeen. Siihen voidaan käyttää muutakin kuin porttia 25, joten tuo rajoitus tulee kierrettyä ihan vain lähetysporttia vaihtamalla.


Kuluttajaliittymistä lähtevän sähköpostiliikenteen suodatusta koskevat toimenpiteet
Liikenne- ja viestintävirasto on arvioinut rajoittamattoman sähköpostiliikenteen eli por-
tin 25 suodatusvelvollisuuden a) säilyttämistä entisellään, b) velvollisuuden poistamista
ja suodatustoimenpiteen jättämistä ns. avoimen internetin asetuksen8 ja SVPL 272 §:n
perusteella ratkaistavaksi sekä c) poikkeuksen lisäämistä suodatusvelvollisuuteen niitä
tilanteita nähden, joissa kuluttaja pyytää suodatustoimenpiteen poistamista.

Liikenne- ja viestintävirasto selvitti syksyllä 2022 SMTP-liikenteen rajoittamisen tilan-
netta internetyhteyspalveluissa muissa Euroopan valtioissa. Muilta valvontaviranomai-
silta saatujen, ei-kattavien tietojen perusteella etenkin kuluttajaliittymistä porttiin 25
lähtevää sähköpostiliikennettä suodatetaan useissa maissa, mutta on myös maita,
joissa tätä liikennettä ei keskeisten operaattorien toimesta lainkaan suodateta. Silloin
kun suodatusta tehdään, tuli pääsääntöisesti samalla esille, että kuluttajalla on kuiten-
kin mahdollisuus pyytää suodatustoimenpiteen poistoa. Muissa valtioissa tämä suodatus
ei tiettävästi perustu velvoittavaan määräykseen kuten Suomessa.

Liikenne- ja viestintävirasto antoi vuonna 2022 päätöksen, joka määräyksestä poiketen
koski vastaavaa suodatustoimenpidettä eräissä yritysliittymissä, joiden osalta määräys
ei edellytä suodatusta.9 Päätöksessä arvioitiin sitä, oliko teleyrityksellä perusteet sovel-
taa kuluttajien osalta pakollisena ollutta tietoliikenneporttiin 25 lähtevän sähköpostilii-
kenteen rajoitusta myös tiettyihin yritysliittymiin. Päätöksessä arvioidussa tilanteessa
tälle ei ollut riittäviä perusteita, kun kyse oli sellaisista muista kuin kuluttajaliittymistä,
jotka oli tarkoitettu tiedonsiirtoon matkaviestinverkossa ja joilla oli kiinteä IP-osoite.
Päätöksessä ei otettu kantaa siihen, olisiko rajoitus perusteltu muissa tilanteissa yritys-
liittymissä.

Kesällä 2022 toteutetussa, määräyksen laatimista edeltäneessä kyselyssä kuluttajaliit-
tymistä lähtevän rajoittamattoman SMTP-liikenteen suodatusta pidettiin edelleen tar-
peellisena. Liikenne- ja viestintävirasto pyysi näkemyksiä myös siitä, pitäisikö mää-
räystä kehittää niin, että teleyrityksen tulisi kuluttajan pyynnöstä poistaa rajoitus liitty-
mästä. Kaksi asiasta lausunutta teleyritystä eivät pitäneet tätä perusteltuna. Eräässä
lausunnossa tuotiin esille, että erillisten, omilla säännöillään toimivien kuluttajaliitty-
mien tekeminen ei olisi hallinnallisesti tai kustannuksiltaan järkevää muutamaa käyttä-
jää varten.

Liikenne- ja viestintävirasto arvioi, että kuluttajaliittymiä koskevan, lähtökohtaisen suo-
datusvelvoitteen säilyttäminen määräyksessä on edelleen perusteltua tietoturvauhkien
torjumiseksi. Toimenpiteellä puututaan päätelaitteelta roskapostia lähettämään pyrki-
vien haittaohjelmien tai väärin konfiguroitujen sähköpostipalvelinten aiheuttamaan hait-
taliikenteen uhkaan. Velvoitteen poistamisen arvioitaisiin lisäävän roskapostin määrää,
joskin kuluttajaliittymistä lähtevän roskapostin leviämistä rajoittaa nykyisin yleistynyt
DKIM- ja SPF-menetelmien käyttö sekä erilaisten maineperusteisten järjestelmien hyö-
dyntäminen, jotka rajoittavat kuluttajaliittymien käytössä olevien IP-osoitteiden käyt-
tämistä sähköpostin lähettämiseen.


Velvoitteen säilyttämisen kannalta on kiinnitettävä huomiota myös rajoituksen vaiku-
tuksiin mahdollisuudelle tarjota sähköpostipalvelinta kuluttajaliittymästä. Voidaan arvi-
oida, että kuluttajakäytössä suodatustoimenpide hyvin harvoin aiheuttaa merkittävää
haittaa käyttäjille, vaikka se rajoittaa sähköpostipalvelimen toteuttamista liittymän
avulla. Ei ole mahdollista tarkasti arvioida, kuinka suuri osuus kuluttajista olisi halukas
käyttämään omaa sähköpostipalvelinta liittymässä tilanteessa, jossa suodatusta ei olisi
käytössä. Kyseessä voidaan kuitenkin arvioida olevan jokseenkin pieni käyttäjäryhmä,
mihin viittaa sekin, että Liikenne- ja viestintävirastolle on viime vuosina tullut vain muu-
tamia tiedusteluja portin 25 suodatuksen haittavaikutuksista. Asiakkaiden saatavilla on
lisäksi tyypillisesti sellaisia esimerkiksi yrityskäyttöön tarkoitettuja liittymiä, joissa suo-
datustoimenpiteitä ei ole käytössä.

Jos määräyksessä edellytettäisiin teleyrityksiä poistamaan suodatus käytöstä asiakkaan
pyynnöstä, aiheutuisi tästä kustannuksia yrityksille. Teleyrityksen olisi tarpeen toteut-
taa provisiointiympäristöön mahdollisuus muuttaa käytössä olevia suodatuksia liittymä-
kohtaisesti. Liittymätyypistä riippuen tämä ei välttämättä ole teknisesti kohtuullisesti
toteuttavissakaan. Liikenne- ja viestintäviraston työryhmätyöskentelyn aikana saamien
tietojen mukaan tämä olisi teleyrityksille työläs muutos. Muutoksella olisi kustannusvai-
kutuksia, jotka voisivat kohdistua koko asiakaskuntaan. Liikenne- ja viestintäviraston
tiedossa ei ole kuitenkaan tarkkoja tietoja teleyrityksille tosiallisesti aiheutuvista kus-
tannuksista. Lisäksi voidaan huomauttaa, että joissakin muissa valtioissa tällainen poik-
keusmahdollisuus näyttäisi kuitenkin jo olevan olemassa. Kuitenkin kun otetaan huomi-
oon edellä tietoturvasta ja rajoitusten vaikutuksista asiakkaisiin sanottu, vaikuttaa pe-
rustellulta arvioida mahdollisesta muutoksesta aiheutuvat haitat lähtökohtaisesti hyö-
tyjä suuremmiksi. Asiaa voidaan arvioida uudelleen esimerkiksi seuraavan määräyspäi-
vityksen yhteydessä.
 
Yhden tsekkiläisen asiointikumppanin kanssa oli äskettäin ongelmana, että Elisa ei suostunut ottamaan vastaan tämän itselleni lähettämiä viestejä. Kommunikaatio onnistui vain niin, että viestit lähettiin forwardina toisen tsekkiläisen asiointipisteen kautta käyttäen sikäläisen teleoperaattorin tarjoamaa sähköpostipalvelua. Saattoi olla, että heillä oli jokin SPF-ongelma (en nähnyt kuin kolmannen osapuolen lähettämän reject-rivin kopion sähköpostin rivinä).
 
Elisa ei suostunut ottamaan vastaan tämän itselleni lähettämiä viestejä.

Tavallisesti kyse on lähettäjän mustalle listalle joutumisesta tai tosiaan SPF-määrittleystä. Hylkäysviestissä pitäisi näkyä syy jollain tavalla. Välillä paremmin ja välillä heikommin.

Välillä Elisa itse on mustalla listalla eikä sen kautta voi silloin lähettää postia.
 
Miksi kysymästäni push-viestien turvallisuusseikoista ei tullut tällaista syvällistä keskustelua. Se jäi aivan alkutekijöihinsä ja epäselväksi ja puhuttiin ohi asian se mitä puhuttiin. Se varmasti olisi kaikkien mielestä ollut mielenkiintoisempi aihekin kuin tämä
 
Miksi kysymästäni push-viestien turvallisuusseikoista ei tullut tällaista syvällistä keskustelua. Se jäi aivan alkutekijöihinsä ja epäselväksi ja puhuttiin ohi asian se mitä puhuttiin. Se varmasti olisi kaikkien mielestä ollut mielenkiintoisempi aihekin kuin tämä

Koska selvitit nopeasti että viesti oli tullut pankin omasta applikaatiosta. Ei jäänyt mitään keskusteltavaa. Mutta sait myös sähköposteja. Onko niitä tallessa?
 
Taisin meilin jo deletoida, mutta se oli selvä huijaus. En sinänsä usko että liittyi tuohon push-viestiin, mutta hauska sattuma että S-pankki tuon mediassa varoitellun huijauskampanjan jälkeenkin viestittelee samoilla sanoilla
 
Taisin meilin jo deletoida, mutta se oli selvä huijaus. En sinänsä usko että liittyi tuohon push-viestiin, mutta hauska sattuma että S-pankki tuon mediassa varoitellun huijauskampanjan jälkeenkin viestittelee samoilla sanoilla

Ei se välttämättä ole sattumaa. Joku huomasi että S-pankki kiusaa käyttäjiä ja päätti tarttua tilaisuuteen lähettämällä samanluonteisia sähköposteja tutusta asiasta.
 
SMTP (Simple Mail Transfer Protocol) on jo yli 40 vuoden ikäinen protokolla, ei siihen voi ihan niin vain tehdä rikkovia muutoksia. Tuolla DKIM:llä (DomainKeys Identified Mail) tosiaan pyritään siihen, että postissa on digitaalinen allekirjoitus josta voidaan tarkistaa että sisältö on muuttumaton ja että lähettäjä on todella se taho jolta posti näyttää tulevan.

Mikään ei estä roskapostittajaa tekemästä rekisteröintiä, jolloin roskapostittajalla voi olla oma validi domain. Toki kenenkään toisen hallussa olevaa osoitetta ei voi rekisteröidä toiseen kertaan.

Monet suuremmat sähköpostipalvelut vaativat, että massapostittajien lähettämissä sähköposteissa pitää olla DKIM mukana.
 
Monet suuremmat sähköpostipalvelut vaativat, että massapostittajien lähettämissä sähköposteissa pitää olla DKIM mukana.

En tiedä yhtäkään sellaista Mutta SPF tai DKIM vaihtoehtoisesti halutaan. DKIM vaatii muutoksia postipalvelimeen.SPF ei vaadi. Kummallakin saavutetaan tavote, että postin lähde on rekisteröity jotenkin ja se tulee luvallisesta lähteestä. DKIM tuntuu jääneen kesken kun on jo kolmas, DMARC menettely, joka oikeasti vahvistaa että viestiin kirjoitettu lähettäjä voisi olla sen kirjoittaja.
 
DMARC:han on käytännössä DKIM+SPF (siis molemmat yhdessä) joillakin tarkennuksilla.

Ei se käytännössä ole ihan noin vaan sille täytyy tehdä oma rekisteröintinsä samalla tavallla kuin edellisillekin. Se määrittelee miten SPF ja DKIM tietojen avulla varmistetaan viestin aitous.

"A DMARC policy tells a receiving email server what to do after checking a domain's Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, which are additional email authentication methods."
 
Takaisin
Ylös Bottom