Note to self:

Nyt näyttäisivät spämmerit löytäneen uuden tavan tuottaa ylläpitäjille harmaita hiuksia. Ilmeisesti lähettävät clientit eivät osaa katkaista yhteyksiä, ja niinpä vastaanottaville koneille jää tuhansia "cmd read"-tilassa olevia sendmaileja roikkumaan. Tämä taas lisää muistin kulumista ja mikä aikanaan johtaa swappaukseen, loadien nousuun ja siihen, että sendmail ei ota vastaan uusia viestejä. Ilmiö on maailmanlaajuinen ja taas jonkun botnetin aiheuttama.

Kokeiltiin laskea Timeout.command 1h -> 15m, jos vaikka sendmail katkaisisi yhteyden nopeammin. Sendmailin ohjeista on apua.

Kandityötä tehdessäni perehdyin jonkun verran viimeisimpään tilanteeseen siitä, kuinka paljon yliopistolle tulevasta sähköpostista on spämmiä. Havaintoni oli huima: viime aikoina on pelkästään SMTP-vaiheessa torjuttu noin 3–4 miljoonaa lähetysyritystä vuorokaudessa. Läpi päässeestä postiliikenteestä vielä noin puolet on tunnistettu spämmiksi.

Tämä tarkoittaa, että heinäkuun alusta lähtien roskapostin osuus on ollut yli 95, jopa yli 96 prosenttia. Osittain se tietysti selittyy lomilla: oikeata postia on vain vähän. Mutta myös absoluuttiset määrät huimaavat päätä. Näissä tilastoissa olen laskenut yhden (tyypillisesti DNS-listojen avulla) blokatun yhteyden yhdeksi viestiksi, vaikka sen aikana voitaisiinkin välittää monta viestiä ja ennen kaikkea monelle eri vastaanottajalle.

Samalla olen opetellut vapaan tilasto-ohjelmisto R:n käyttöä. Se on aika kinkkistä, mutta nyt luulen jo vähän oppineeni lukemaan sen manuaaleja. Kas tässä:

Huomasin konfiguroineeni erään asentamani www-palvelimen (Apache 2.2) väärin: siellä oli oletuksena päällä "AddDefaultCharset UTF-8". Koska tiesin, että suurin osa palvelimen kautta näytettävistä tiedostoista ei ole UTF-8:a, laitoin sen sijaan "AddDefaultCharset ISO-8859-1". Tämä oli virhe.

Palvelimella osa dokumenteista kun on jotain aivan muuta, esimerkiksi windows-1251-merkistöä. Monissa HTML-dokumenteissa on asianmukainen meta-elementti, joka kertoo, mitä merkistökoodausta dokumentissa käytetään. Selain osaa sitten näyttää dokumentin sen mukaan. Mutta jos oletusmerkistökoodaus on päällä, palvelin julistaa lähettämänsä vastauksen headereissa oletusmerkistökoodauksen (ISO-8859-1 tässä tapauksessa). Tämän seurauksena muita koodauksia olevat dokumentit, esimerkiksi kyrillisiä aakkosia sisältävät dokumentit näkyivät väärin.

Lesson learned: älä käytä Apachessa AddDefaultCharsettia, ellet tiedä, mitä olet tekemässä.