Kyllä ketjua on tullut seurattua alusta asti. Sinä se tässä olet itsepintaisesti kieltäytynyt hyväksymästä vastauksia ja pidät väkisin kiinni omasta kannastasi.
Ei ole mitään maagista koodia, tässä on nyt kyse alan standadeista ja yhteisesti sovituista pelisäännöistä. Oikeastaan tässä ei ole enää kyse edes roskapostisuodatuksesta siinä mielessä mitä suodatuksella perinteisesti tarkoitetaan.
Lähettäjäpalvelimien mustalista on ensimmäinen ja vähiten resursseja vievä tarkistus sähköpostin toimitusketjussa. Näitä mustia listoja on sekä julkisia, että palveluntarjoajan omia listoja, kukaan (ulkopuolinen) ei varmuudella tiedä mitä listoja kukakin käyttää (jos käyttää laisinkaan). Esim. Microsoftilla on todella agressiivinen oma mustalistansa, riittää, että samasta net-blockista on lähetetty liikaa roskapostia, niin Microsoft mustalistaa koko blockin kerralla.
Vasta jos lähettävä palvelin läpäisee mustalista-tarkistuksen, päästään varsinaiseen roskapostisuodatukseen. Tähän vaiheeseen useimmilla palveluntarjoajilla on myös loppukäyttäjillä mahdollisuus vaikuttaa. (esim. lisäämällä lähettäjäosoite kontakteihin tai erityiselle sallitut lähettäjät listalle)
Oman kokemukseni mukaan Gmailissakin on peräti käyttäjäkohtaista oppimista suodatuksessaan. (Käyttäjä A merkkaa lähettäjän B postit roskapostiksi, jatkossa B:n lähettämät postit menee automaattisesti A:n roskapostikansioon. Sensijaan käyttäjä C:llä lähettäjä B:n postit päätyy edelleen varsinaiseen postilaatikkoon. Vasta kun riittävän moni käyttäjä on merkanut B:n roskapostittajaksi, alkaa B:n postit päätymän roskapostikansioon myös C:llä, ellei C ole lisännyt B:tä kontakteihinsa tai tehnyt erillistä suodatinsääntöä)
Käytettäessä näitä mustalistoja sähköpostien välityksessä, postin kulku on yksinkertaistaen jotakuinkin tämän kaltainen:
1. lähettävä palvelin ottaa yhteyttä vastaanottavaan palvelimeen
2. vastaanottava palvelin tekee mustalista-tarkistuksen ja katkaisee yhteyden virheen kera jos lähettäjä on mustalistalla
3. jos päästiin tänne asti, niin lähettävä palvelin kertoo vastaanottajapalvelimelle, että "mulla olisi sähköposti osoitteesta '
abc@example.com'"
4. vastaanottaja tekee toisen mustalista-tarkistuksen lähettäjäosoitteen perusteella ja katkaisee yhteyden virheen kera jos lähettäjäosoite on mustalistalla
5. tässä vaiheessa lähettäjä kertoo vastaanottajapalvelimelle, että "postin vastaanottaja on '
def@domain.com'
6. vastaanottaja tarkistaa löytyykö haluttua käyttäjää ja katkaisee yhteyden virheen kera jos ei löydy
7. vastaanottajapalvelin ottaa postin vastaan ja kuittaa lähettäjälle postin vastaanotetuksi
8. lähettäjä toetaa, että homma kunnossa ja katkaisee yhteyden
9. vastaanottajapalvelin analysoi postin sisällön ja toimittaa sen joko roskapostikansioon tai varsinaiseen postilaatikkoon (tai joidenkin palveluntarjoajien kohdalla pistää postin karanteeniin ja lähettää lähettäjälle ilmoituksen karanteenista ja ohjeet postin vapauttamiselle)
Reaalimaailmassa ylläolevaan vielä lisää alakohtia esimerkiksi aiemmin mainittujen SPF, DKIM ja DMARC tarkastusten osalta. Ja esim tuo 6. kohdan käyttäjän tarkistus saattaa tapahtua vasta myöhemmässä vaiheessa. Vielä monimutkaisemmaksi asia muuttuu siinä vaiheessa kun ketjuun lisätään erillinen postin välityspalvelin (relay)
Vasta kohdassa 9. ollaan tilanteessa, jossa vastaanottajalla voi olla vaikutusmahdollisuus siihen, mihin posti päätyy. Ja sinä siis haluaisit, että tätä hyväksi havaittua käytäntöä muutettaisiin niin, että jokaikinen lähetetty sähköposti päästettäisiin vähintään vaiheeseen 6.5 asti, jossa sitten voitaisiin tarkistella vastaanottajan omia preferenssejä.
Nopea googlettelu kertoo, että vuonna 2020 lähetettiin ja vastaanotettiin 300 miljardia sähköpostia päivittäin. Vastaavasti Gmailin markkinaosuus on 20% luokkaa. Tuo tarkoittaa keskimäärin sitä, että vuonna 2020 Google lähetti ja vastaanotti 60 miljardia sähköpostia joka päivä, mikä tarkoittaa noin 700 000 sähköpostia jokaikinen sekunti. Jatkuvasti.
Tästä voi tehdä jonkinlaisia päätelmiä siitä, kuinka valtavasti lisää prosessointitehoa, verkkoliikennettä yms. vaadittaisiin jotta päästäisiin sinun haluamaan tilanteeseen. Ja kukaan ei tiedä sitä sähköpostien määrää mikä blokataan jo noissa alkuvaiheissa mustalistojen ansiosta, eivätkä siis sisälly tuohon 300 miljardiin.
Ymmärrän kyllä mitä tuolla ajat takaa, mutta jälleen osoittelet sormella turhan kärkkäästi gmailia.
Jos nyt unohdetaan se tosiasia, että muutamaa megatavua isompien liitetiedostojen lähettäminen sähköpostitse on suorastaan järjetöntä*, niin tässäkin suurin syypää on se sinun palveluntarjoajasi.
Ensinnäkin siksi, että se sallii liian isojen sähköpostien lähettämisen. Viive taas johtuu siitä, että kun lähetät sähköpostia, sitä ei lähetetä reaaliaikaisesti eteenpäin, vaan se jää palveluntarjoajasi palvelimelle lähetysjonoon. Ja asetuksista riippuen lähetysjonossa saatetaan priorisoida pieniä viestejä, isompien jäädessä jonoo pidemmäksi aikaa.
Kun se sinun palveluntarjoajasi aikanaan yrittää lähettää sitä ylisuurta sähköpostia gmailille, niin jos muuten kaikki on kunnossa, niin ylläolevan listan 7.5 kohdaksi voidaan lisätä "vastaanottajapalvelin toteaa, että nyt on tullut liikaa dataa ja katkaisee yhteyden virheviestin kera" jonka jälkeen sitten se sinun palveluntarjoajasi lähettää virheviestin postilaatikkoosi.
Väittäisin, että yksikään palveluntarjoaja ei näissä virheviesteissä sisällytä koko lähetettyä sähköpostia liitteineen mukaan. Yleensä pelkkä virheviesti riittää, joskus mukana voi olla esim. ensimmäinen kilotavu lähetetystä viestistä, joskus koko viesti ilman liitteitä. Eli tämäkin raflaava kommentti pitäisi muuttaa: "PALVELUNTARJOAJASI VIE VIDEOSI"
*) Mitä tulee tuohon isojen liitteiden lähettelyyn yleisesti, niin pelkästään sen takia, että teknisistä syistä johtuen 1Mt liitetiedosto sähköpostissa kasvattaa postin koon n. 1,3Mt kokoiseksi, on tuo isommassa mittakaavassa järjetöntä tuhlausta. Nykyisin kun on olemassa vaikka kuinka paljon erilaisia pilvipalveluja, niin parempi ladata ne tiedostot johonkin sellaiseen ja liittää siihen sähköpostiin pelkkä linkki.
Kautium tuossa yllä jo perusteellisesti asian selvittikin.
