Ylläpitäjä, avaa sähköpostipalvelimesi!

Ongelmaksi muodostuu tuossa se, että monesti SMTP-portti on suljettu myös ulospäin (taitaa olla käytännössä tällä hetkellä kaikilla muilla kuluttajatason liitymällä Suomessa kuin Nebulan Advanced liittymillä?). Tällöin ei voida käyttää edes authitikoivaa SMTP-palvelinta ainakaan default portissa.

Itse pystyn lähettämään mailia oman palvelimen kautta (lähiverkossa SMTP-palvelin (VPN yhteys kun tulee kuitenkin yleensä muodostettua jos lähettelen postia läppärillä muualta kuin kotoa) ja siitä on SSH-tunneli eräälle virtual serverille josta voi lähettää mailia vain localhostin kautta).

SMTP portti suljettu ulospäin ei ole ongelma, jos konfiguroit oman kotiliittymässä sijaitsevan palvelimesi SMTP relayksi, joka välittää postit operaattorin SMTP palvelimelle. Koska onhan tuo SMTP liikenne kuitenkin sallittu operaattorin SMTP palvelimelle.

Todennäköisesti tuo oli suhteellisen helppoa jos operaattorit jaksaisivat noin tehdä.

Lisäksi vastaanottavan palvelimen pitäisi tarkistaa että sähköposti on lähetetty "oikeasta" smtp palvelimesta. Mahdollisesti ottamalla yhteyttä alkuperäiseen palvelimeen että löytyykö kyseistä osoitetta oikeasti?

Buzer:
Itsellä on kokemuksia Welhon, Soneran ja Elisan liittymistä, jokaisesta pääsee kyllä käyttämään muitakin SMTP-palvelimia ihan ongelmitta, jos vain itse ulkopuoliselta SMTP-palvelimelta ei löydy rajoituksia.

talo:
En oikein keksi mitä käytännön hyötyä ideastasi olisi, haittoja sen sijaan montakin. Tämä ensinnäkin on juuri päin vastainen menettelytapa kuin tekstissä esitin, lisäksi itse koen amatöörivoimin ylläpidetyn SMTP-palvelimen väärinkäytöksille alttiina jo itsessään.

eol:
Postipalvelin kyllä tietää miltä koneelta se vastaanottaa viestin, tätä ip-osoitetta on ymmärtääkseni hyvin hankala väärentää. Tätä tietoa voidaan sitten hyödyntää lähettäjän domainia tarkastettaessa. Itse lähettäjän osoitteen olemassaolon tarkastusta en itse koe niin hyödylliseksi, toki tämä hankaloittaisi olemattomien osotteiden käyttöä mutta muilta osin lähettäjän aitouden tarkastaminen ei taida olla kovin helposti mahdollista enää tässä vaiheessa.

Ihan ongelmaton ratkaisuhan tämä esittämäni ei suinkaan ole muutenkaan, esim. postin uudelleenohjaukset ja postituslista tuottavat omat ongelmansa.

anger: Jos käytät ihan normaalia SMTP-porttia, niin ei onnistu ainakaan Welholla nykyisin.
Welhon yhteyden päästä:
C:Usersuzer>telnet louise.buzer.net 25
Yhdistetään kohteeseen louise.buzer.net...Yhteyttä ei voitu muodostaa isäntään, portissa 25: Yhteyden muodostaminen epäonnistui.
C:Usersuzer>telnet smtp.welho.com 25
220 smtp6.pp.htv.fi ESMTP Postfix
QUIT
221 2.0.0 Bye

Yhteys isäntään menetettiin.
Ulkomailta:
buzer@nagi:~$ telnet louise.buzer.net 25
Trying 194.169.192.145...
Connected to louise.buzer.net.
Escape character is '^]'.
220 louise.buzer.net ESMTP
QUIT
221 louise.buzer.net
Connection closed by foreign host.

Olen aika varma, että ei myöskään onnistunut Soneralla noin puoli vuotta sitten. En usko, että heidän puoleltaan asetuksia on vaihdettu.

Ja tuosta eol:n ehdotuksesta, osa palvelmista tarkistaa lähettäjän. Itselläni loppullinen mailipalvelin tekee niin.
Nov 23 12:57:07 louise qmail: 1195822627.996699 status: local 0/10 remote 1/20
Nov 23 12:57:07 louise qmail: 1195822627.996772 starting delivery 19208: msg 1082865 to remote xxxx@xxxxx.net
Nov 23 12:57:11 louise qmail: 1195822631.742490 delivery 19208: deferral: 69.72.132.58_does_not_like_recipient./Remote_host_said:_451_Could_not_complete_sender_verify_callout/Giving_up_on_69.72.132.58./

Jahas. Tämä ei nähtävästi oikein pidä merkistä (ja siltä varalta, että nytkään ei mene läpi, niin viittasin siis kenoviivaan)

Buzer:
Voi toki olla että tilanne on muuttunut. Sinänsä portin 25 sulkeminen ulospäin voi olla ihan ymmärrettävääkin koska a) se on salaamattomalle liikenteelle ja b) http://tools.ietf.org/html/rfc2476 mukainen sähköpostin lähetys määrittelee portiksi 587.

Aiheen jatkoksi, itse toivoisin myös Push-IMAP (tai IMAP-IDLE) tuen yleistyvän sekä palvelimissa että asiakasohjelmistoissa. Ihan vaan siksi että tieto uudesta sähköpostista saadaan ilman säännöllistä pollaamista. Myös sähköpostin lähettäminen imapin avulla toisi sähköpostia vähän käyttäjäystävällisemmäksi kun pärjäisi jatkossa yhden palvelimen määrittelemisellä.

Kun itse aikoinaan törmäsin siihen, että Elisa ei salli omasta verkostaan yhteyksiä porttiin 25 muualle kuin omille palvelimilleen, selvitin hieman asiaa. Tästä on muistaakseni aikaa pari vuotta. Kävi ilmi, että Elisa on spämmien ja virusten leviämisen rajoittamiseksi ryhtynyt 25-portin liikennettä sulkemaan, mutta oli kuitenkin valmis sulkua pyynnöstä avaamaan, mikä onkin mielestäni oikein. Elisa olisi tarjonnut autentikoitua (ja muistaakseni salattua, eikä 25 portissa pyörivää) smtp-käyttöä myös verkkonsa ulkopuolelta asiakkailleen, jolloin lähtevän postin palvelinta ei pitäisi aina muuttaa, kun vaihtaa verkosta toiseen

Mutta koska 25-portin liikennöintirajoitukset ovat voimassa monessa paikkaa muuallakin, enkä halua sekaantua operaattorisidonnaiseen sähköpostiin ja minulla on vaihtoehtoon mahdollisuus, käytän omaa palvelinta. Tämä "roadwarrior" ongelma postiensa kanssa on tullut eteen monella tuttavallakin, ja kovin ovat olleet tyytyväisiä tarjoamaani palveluun, jonka pistin tuolloin pystyyn.

En silloin pelannut vielä VPN-yhteyksien kanssa, mutta halusin kaiken liikenteen kuitenkin olevan salattua salasanojen ja ylipäätään yksityisyyden vuoksi. Koska olen tykästynyt Applen Mail -ohjelmaan, ei pelkkä TLS -tuki riittänyt SMTP:n osalta. Mail kun ei tue salattuja yhteyksiä kuin puhtaana SSL:nä, joten pistin jo hieman harvinaisen smtps -palvelun pyörimään 465-porttiin. Salaus toimii toki TLS-muodossakin 25-portissa, submission (587) -porttia en ole ottanut käyttöön toistaiseksi. En vielä ole törmännyt asiakasohjelmaan, joka ei pelkkää smtps:ää tukisi.

Tuo TLS näyttää muuten olevan nykyisin jo melko yleinen sähköpostipalvelimien välisissäkin keskusteluissa, kannattaa ottaa käyttöön, jos vielä ei ole. Jonain päivänä salaamaton sähköpostiliikenne on vain ruma muisto menneisyydestä (kyllä se helvettikin vielä jonain päivänä jäätyy, uskokaa pois).

Spämmiongelman olen omasta mielestäni ratkaissut varsin näppärästi. Pari hyväksi havaittua RBL:ää käyttöön, pieni validointi HELO -komennon parametreihin ja harmaalistaus. SPF:n otin myös joitakin kuukausia sitten käyttöön tarjoamissani ei-kaupallisessa sähköpostipalvelussa, kyllä silläkin perusteella pari hylkyä päivässä nykyisin tulee. SPF-tietueet olen toki määritellyn kaikkiin domaineihin, joista tiedän varmaksi, että postit lähetetään vain tiettyjen palvelinten kautta. Nolistinginistä, eli siitä että domainin primary MX-tietueessa oleva palvelin katkaisee yhteydet heti alkuunsa ja seuraava palvelin ne sallii, on myös erittäin hyviä kokemuksia.

Näitä ehkä hieman radikaalejakin menetelmiä käytän myös ylläpitämissäni firmojen sähköpostipalvelimissa, ja käytännössä mitään ongelmia ei ole tullut. Kaikki eivät noista reaaliaikaisten mustienlistojen käytöstä perusta, mutta itselläni ei vuosien aikana ole ollut vielä ainuttakaan ongelmaa. Kerran on yhden asiakkaan yhteistyökumppani päätynyt spamcopin listalle, ja silloinkin täysin aiheesta. Hauskaa tuossa nimenomaisessa tapauksessa oli se, että tuo lähettävä osapuoli käytti vielä erikseen ostettua sähköpostipalvelua, jonka nimenomaan piti suojata spämmiltä ynnä viruksilta.

Hotmailin ja vastaavien kautta tulevan spämmin ja mahdollisten läpipääsevien virusten vuoksi olen yhdessä firmassa ottanut myös sisältöpohjaisen skannauksen käyttöön, mutta muuten en sitä suosi. Siinä on vähän turhan paljon ylläpidollista vaivaa ja hyöty on melko marginaalinen.

Monet valittavat smtp:n standardin rikkomisesta heti, kun jotain tekee spämmeja vastaan taistellakseen, mutta itse en ainakaan ainuttakaan RFC:n vastaista menetelmää ole ottanut käyttöön. Mistään callback-systeemeistä en myöskään ole kovin innostunut, vaikka ne näyttävätkin nykyään olevan yleistymässä.

Ja sähköpostin maksullisuudesta sen verran, että ei se koskaan ole ilmaisia. Kyllä siitä aina joku maksaa, muodossa tai toisessa. Itse maksan perskohtaisesta virtuaaliserveristä (jossa toki pyörii paljon muutakin kuin sähköpostit) parin kaverin kanssa 33e/kk, ja olen lukemattomia iltoja käyttänyt asioiden selvittämiseen ja järjestelmän pystyttämiseen. Vastineeksi siinä moni saa hyvän ja ilmaisen sähköpostin, mutta ei se silti siellä ilman kuluja pyöri. Nykytilanne on spämmien ja vastaavien vuoksi sellainen, että ainakin moni yritys on valmis maksamaan siitä, että sähköposti toimii niinkuin pitää. Yksityisillä tilanne voi tietenkin olla toinen, mutta kyllä gmail ainakin toistaiseksi on pitänyt pintansa melko hyvin.

Miten voi olla mahdollista että minä itse lähetän itselleni spämmiä. En voi torjua itseäni lähettäjänä. Aihesisällönkin niukkuuden mukaan ei oikein löytynyt sanoja koska oli kyse kuvasta ja siinä olevasta viestistä. Mailini ei näyttänyt kuvaa. En myöskään sallinut sitä. osittain siis spämmitorjunta toimi. Kysymys on että miten näitä lähettäjän osoitteita voi mulkata sellaisiksi kuin haluaa.

jukkeli:
Tuo on roskapostittajien yleisesti käyttämä kikka. Homma voi olla parillakin tavalla toteutettu, mutta kyse on siitä, että kun roskapostittaja toimittaa roskapostia sinulle, hän yksinkertaisesti valehtelee sähköpostipalvelimelle, että lähettäjänä olet sinä. SMTP-protokollassa ei ole itsessään mitään tapaa varmentaa, pitääkö tuollainen vale kutinsa. Tähän on kuitenkin olemassa lukuisia torjuntakeinoja palvelinpuolella ilman, että mitään sisältöpohjaista suodatusta tarvitsee edes ajatella.