IKI kutsui joulukuussa 2006 koolle eri sähköpostiohjelmien guruja sekä sähköpostijärjestelmien ylläpitäjiä. Tässä tiedoksi muillekin tapaamisen antia.

Erikseen esitetään vielä suuret kiitokset IKI:n puolesta tapaamiseen saapuneille sähköpostiguruille.

Lopulta saatiin aikaan varsin järkeviä ja jalat maassa ajatuksia aiheen piiristä.

Allaoleva muistio sisältää hyvinkin teknisiä detaljeja ja termejä sähköpostiin liittyen. Muille kuin sähköpostiguruille tämä voi toimia vaikka esimerkkinä siitä, minkälaisia asioita sähköpostiylläpitäjien pitää sujuvasti osata ja hallita jotta meidän kaikkien postit kulkisivat luotettavasti perille.

Mitä päätettiin kokeilla IKI:ssä käytännössä:

1. dnscache bindin sijaan resolvauskäyttöön
   • löytyy netbsd packagesta kai, eli sen kun asentaa ja vaihtaa ajoon
2. Kokeillaan postfixiä ja/tai eximiä
   • vanha silppuri1 testikoneeksi alemmalla MX-prioriteetilla ja lyhyeksi aikaa rinnalle
   • yllämainitut löytyy NetBSD packageista
   • /etc/mailertable tms:llä voidaan kätevästi vaihtaa mikä käytössä
   • ensin varmaan postfix, se on ehkä laajemmassa käytössä?
3. Spamassassin suomisäännöt→negatiivipisteitä -kokeilua:
   • omia suomi-spesifisiä sääntöjä voitaisiin kokeilla
   • Bayes fiksattu opetettu suomi-kinkku-dictionary mikä antaa miinuspisteitä suomalaiselle postille (kinkku = ham = ei spam)
   • Pitäisikö suomi-spamassassin-sääntöjen jakeluun perustaa joku maililista (kinkku@listat.iki.fi?) tms missä niistä voitaisiin keskustella ja jakaa?
4. Master DNS-softaksi voisi laittaa muun kuin bindin, tinydns?

Seuraavassa muita muistiinpanoja agendan lomassa:

IKI-mailisessio 14.12. asioita

[ ] Sähköpostiohjelmat, mitä on, hyvää ja huonoa?
[ ] MTA Featureista

• iki:ssä kulkee noin 300k mailia päivässä
• näistä noin 1/4 (77k) menee iki:n roskapostisuodattimen kautta
• iki tarvitsee aika perusjuttuja
• monta alias filettä (löytyy)
• host sort order (postfix/exim tekee kai defaulttina näin)
• alias ⇒ virheilmoitusteksti (löytyy)
• 31k aliasta (ei ongelma)
• kaikki konffit generoidaan tietokannasta, ei ongelma generoida useassa formaatissa jos tarve

[ ] Per vastaanottaja RBL-blokkaus (rcpt to → ei kelpaa)

• ei ehkä toimi käytännössä hyvin pipeliningin vuoksi

[ ] RFC:n vastaisesti nopeampi retry (greylisting) isoillakin jonoilla luotettavasti

• ei kannattane vaivautua

[ ] IKI: SMTP in - SMTP out; jonoissa joskus paljonkin kamaa
[ ] Sendmail, vanha tekijä, mutkikas, isot jonot vaatisi paljon käsitunetusta

• sendmail ei ruleta silloin kun jonoon kertynyt paljon kamaa, tulee turhan pitkiä viiveitä ja korjaus vaatisi paljon käsituunausta, jonojen jakamista useiksi ja muuta
• kokeillaan postfix/eximiä jos olisivat parempia

[ ] Postfix, monen suosikki, hyvä vai vakioasennuksena Linuxdistroissa?
[ ] EXIM

• Postfix ja EXIM vaikuttaa lupaavilta, molemmat saivat kehuja
• featuret riittää, jotain optioita pitää laittaa päälle defaulttien lisäksi
• netbsd paketit löytyy suoraan

• Postfixiin löytyi porukasta status-scripti joka näyttää jonojen tilaa www:ssä
• ⇒ Jos saataisiin suoraan käyttäjille näkyviin jonon ongelmatapaukset automaattisesti?

[ ] Zmailer

• myös potentiaalinen
• ei käytössä niin laajalti kuin yllämainitut
• I/O optimoitu
• ei valmista netbsd-pakettia

[ ] Qmail

• pysytään kaukana
• mailien splittaus yksittäisiksi on iso ongelma qmailissa
• hylkää <> envelope frommit = rikki

[ ] Mailivolyymin käsittely
[ ] Kokemuksia ja ajatuksia
[ ] Pahimmat pullonkaulat – eri softien ongelmat ja ratkaisut

• keskusteltiin siitä mikä tahmaa, I/O, CPU (suodatus tms), DNS, RAM, piuha?
• I/O jossain määrin issue
• DNS bindin kanssa ongelma
• RAM sallii ajaa paljon rinnakkain (hitaat TCP-avaukset ja roundtripit yms)
• piuha ei rajana nykyään

• vertailua NNTP:hen missä käytössä omat ”filesysteemiviritykset”
• maili on eri juttu: transaktiomaista pientä dataa
• nyyssin tullessa tiedetään kauanko sitä halutaan säilyttää → varastofileeseen
• filesysteemit ei oikeasti kovin suuri ongelma mailien kanssa
• write + fsync ennen ”kiitos maili saatu” voi olla kallis (i/o-bandwidth + seekkaus)
• jollakin oli myös kokemuksia huonon syslogd:n fsynccien kalleudesta

[ ] Alias-resolvointi alussa vai uudestaan jonossa oleville viesteille?

• kun jonot täyttyy, miten siivotaan
• mikään softa ei tee tätä suoraan, aliakset yms katsotaan ensin ja sitten deliveröidään sen mukaan ilman muutoksia
• zmailer tallettaa rcpt to: alkuperäiset osoitteet, mutta ei käytä niitä mihinkään

[ ] Bounce-viestit – tärkeä osa mailin luotettavuutta vai liian iso ongelma väärien osoitteiden takia?

• bounceja pitää käyttää
• bouncet voisi lähettää toisesta domainista ja ip-osoitteesta/verkosta jotta oikeat serverit ei joudu tiukkapipoisille bounce-blacklistoille (nimiehdotuksia: portsari, bounsseri, bouncer, valitusosoite.fi, valitusosasto.fi tms).

[ ] DNS bind vai joku muu? Muistinkäyttö?

• erota master-DNS ja resolvaus-serverit toisistaan
• resolvausta voi ajaa 127.0.0.1:ssä paikalliseen käyttöön
• dnscache on hyvä resolvaukseen
• tinydns voisi olla hyvä master-DNS:n jakamiseen
• bind on huono ja vuotaa muistia
• iki dns-hosts file noin 200k, noin 200 secondarya - ei kovin isoa

[ ] Onko mahdollista ja/tai varaa tehdä spämmitarkistus SMTP-tulovaiheessa? (eli 5xx ei kelpaa)

• tämä olisi hienoa, mutta ei taida onnistua jos maili tulee kerralla monelle vastaanottajalle
• käytännössä jos samoja sääntöjä ajetaan kaikille, silloin tämä toimii kyllä ihan OK ja on järkevää (saadaan heti sanottua 5XX ei kelpaa eikä viesti tule lainkaan sisälle häiritsemään).

[ ] Roskapostisuodatus
[ ] Tuunatut spamassassinsäännöt joltakin taholta muille käyttöön (kohtuukorvauksella) – keskitetty tuunaus, hajautetut kustannukset. Jos tuunataan Suomessa spämmerit ei jaksa reagoida?

• Yritetään keräillä näitä käyttöön
• sa-update tekee automaattisia päivityksiä
• rules emporium (sp?) tarjoaa lisäsääntöjä läjäpäin

• sen sijaan fixed bayes joka antaa hyville viesteillä miinuspisteitä voisi olla hyvä (ham koulutettu jostain sopivasta matskusta)
• mistä saataisiin hyvä ham/spam kokoelma?
• olisiko joku paikka jonka bayes-tietokannasta voisi ottaa snapshotin tällaiseen käyttöön?

[ ] Per-käyttäjä spamassassinasetukset isommassa välityskäytössä (silppuri)

• ei taida onnistua koska maili menee samalla kerralla monelle käyttäjälle eikä tästä haluta tinkiä

[ ] Erikoisrulet, esim. kuvaspämmi (löytyykö 100% testi?) → DROP

• ei voida päättää mikä on kenenkin mielestä spämmiä
• kaikki kuvamailit eivät ole spämmiä

[ ] Kaksoissuodatus? Esim. spamassassin serverissä + Mail Junk filter?
[ ] Pitäiskö olla suomessa / jollakin sopivan pienellä porukalla oma RBL jota päivitetään meidän spamassineista ja/tai honeypoteista?
[ ] Tekisikö joku spamassiniin lisäyksen että se uskoisi kohdekoneessa kerrottujen ”luotettujen tahojen” (esim. iki) Received: -headereita ja tekisi niiden perusteella blacklist-tarkistuksen?

• yllämainittuja ei havaittu kovin järkeviksi ajatuksiksi

[ ] Saako viestejä koskaan hävittää jälkiä jättämättä? (5XX ei kelpaa vs kiitos & drop)

• Älä hävitä, oikeatakin menee hukkaan

[ ] Spämmiongelman ratkaisuideoita?
[ ] Mailin välitys → laatikko-provideri -ongelmat (esim. laatikkoproviderin enemmän tai vähemmän kummalliset filtteröinnit)
[ ] Hotmail -ongelma, vanhat IKI-serverit OK, uusi ei kelpaa (IP)???
[ ] Vrt. Yahoo-mailit ongelma syyskuussa

• muitakin esimerkkejä tuli esille
• viestinvälitystä ”viritetään” eri paikoissa usein turhankin innokkaasti, aina ei huomata laajemmin mitä on kyse
• erilaisia omia virityksiä on monessa paikassa
• iki:ssä on forwardeja 3094 eri kohdedomainiin, suurin oli gmail

[ ] SPF, Domain Keys ja muut vastaavat? Pitäisikö jotain ajaa Suomen sisällä käyttöön?

• SPF sucks, vastusta sitä
• DKIM (Domain Keys for Internet Mail?) hieman parempi
• Nämä vaatisi että IKI tarjoaisi submissionia (autentikoitu SMTP lähetys portissa 587) ja SMTPS (outlookin haluama protokolla?)

[ ] Viestintäviraston raportointivaatimukset

• viestintävirastosta esitettiin erilaisia kokemuksia ja mielipiteitä
• hieman kommentoitiin iki:lle tullutta kyselyä, kummasteltiin mailiservereiden muutoksista tiedottamista
• pari lisäasiaa tuli esille iki-vastaukseen laitettaviksi

PS. Jos ymmärsit mistä yllä puhuttiin, lähde mukaan iki:n hallitukseen hoitamaan iki:n yhteisiä asioita

Päivitetty 17.1.2007.