Lakiblogi

Viestintävirasto ohjeistaa operaattoreita sähköpostista

Viestintävirasto antoi taannoin määräyksen 11/2004, joka tulee voimaan 1.12.2004. Sen olennainen teleoperaattoreita velvoittava sisältö on seuraava:

Teleyrityksen on kytkettävä verkosta irti kone, joka toimii avoimena sähköpostinvälittäjänä (open relay), jos se häiritsee liikennettä.

Kuluttajaliittymään ei saa päästää SMTP-liikennettä, ellei kuluttajaa ole erikseen informoitu avoimen liikennöinnin riskeistä.

Kuluttajaliittymästä lähtevä SMTP-liikenne on tukittava, ellei kuluttajaa ole erikseen informoitu asiaan liittyvistä riskeistä. Tällöinkin lähtevän SMTP-liikenteen määrää on valvottava.

Teleoperaattorin on seurattava "viestintäverkkonsa ja sähköpostijärjestelmänsä tapahtumia sellaisen haittaohjelmia sisältävän sähköpostiliikenteen havaitsemiseksi, joka aiheuttaa vaaraa viestintäverkon tai -palvelun käytettävyydelle." Operaattorilla on oltava valmiudet haittaohjelmien karkeaan suodatukseen ongelmatapauksissa, ja asiakkaille on dokumentoitava haittaohjelmien suodatusperiaatteet. Muuhun verkon toimintaa vaarantavaan sähköpostiliikenteeseen voidaan soveltaa samoja sääntöjä.

Teleoperaattorin on valvottava sähköpostituotannon laatua ja varmuutta mm. läpimenoviiveet, kuormatilanteet ja käyttökatkokset tilastoiden. Lisäksi on erikseen määrätty, että sähköpostipalvelun viestien säilytysjärjestelmän on oltava "vikasietoinen", joka sinänsä kyllä on ilmaisuna aika hämärä. Mutta loppua kohti vain paranee: "Teleyrityksellä on oltava valmiudet sähköpostipalvelun uudelleen rakentamiseksi."

Ja sokerina pohjalla, Viestintävirasto määrää nyt virallisesti, että security@, abuse@, noc@- ja postmaster@-osoitteita on luettava "säännöllisesti".

Web-sivujen refererien kaivaminen perlillä

"Miltä sivuilta on linkki tälle yhdelle käytössäni olevalle sivulle?" on mielenkiintoinen kysymys. Siihen vastaavat monet webbilokianalysaattorit, mutta tarvitsin itse hyvin yksinkertaisen työkalun, siispä tein sen Perlillä. Käyttäminen vaatii Perl-tulkkia, vähän ohjelmakoodin ymmärrystä ja mahdollisuuden- saada omaan sivustoon liittyvä http-palvelimen lokitiedosto käyttöönsä.

Koodi on kaikessa kauneudessaan tässä:

#!/usr/bin/perl -w

# Skriptin perustietorakenne: hash, jossa avaimina
# sivujen urlit. Arvoina on viittaus hashiin, jossa
# puolestaan avaimena refererit ja arvoina kunkin
# refererin esiintymislukumäärä
my %urlit;

while (<STDIN>) {
  
  my @f = split;

  # Url esiintyy lokissa 7. sarakkeessa -- muuta tarvittaessa
  my $url = $f[6];

  # Referer-osoite on 11. sarakkeessa (lainausmerkkeihin suljettuna)
  my $ref = $f[10]; $ref =~ s/\"//g;

  next if ($ref eq '-');

  # Jos haluat nähdä myös oman saittisi sisäiset viittaukset,
  # kommentoi seuraava rivi:
  next if ($ref =~ /^http:\/\/(www\.)?heikniemi\.net\//i);

  # Onko Google-haun tulos?
  if ($ref =~ /http:\/\/www\.google.*q=([^&]+)/) {
    my $hakusana = $1;
    $hakusana =~ tr/[+]/[ ]/;
    $ref = "Google-haku: $hakusana";
  } 
  # Onko Google-kuvahaun tulos?
  elsif ($ref =~ /http:\/\/images\.google.*imgurl=([^&]+)/) {
    $ref = "Google-kuvaosuma: $1";
  }

  # Jos tätä urlia ei vielä ollut esiintynyt, luodaan
  # sille tyhjä ali-hash
  if (!defined $urlit{$url}) {
    $urlit{$url} = {};
  }

  if (!defined $urlit{$url}->{$ref}) {
    $urlit{$url}->{$ref} = 1;
  }
  else {
    $urlit{$url}->{$ref}++;
  }
}

# Tulostetaan tulokset urleittain aakkosissa, ja
# niiden sisällä refererit esiintymiskertojen mukaan

foreach $url (sort keys %urlit) {
  print "$url\n" . "-" x length($url) . "\n";
  my %refs = %{$urlit{$url}};

  foreach $ref (sort {$refs{$b} <=> $refs{$a}} keys %refs) {
    printf("%5d  %s\n", $refs{$ref}, $ref);
  }

  print "\n";
}

Ja syntaksiksi käy esimerkiksi: type munloki.txt | perl tilasto.pl

Tuloksena tulee tämännäköisiä tulosteita:

/rikoslaki/rl49.html
--------------------
    2  http://www.cs.tut.fi/~jkorpela/tekoik/tekl.html
    1  Google-haku: rikoslaki 49
    1  Google-haku: Teollisoikeusrikos

Heikentääkö RSS-feedi blogin sijoitusta listalla?

Vaihteeksi havainto blogimaailmasta: Tässä päivänä eräänä ajauduin miettimään RSS-virtojen kätevyyttä. Näppärää, suorastaan yllättävän. Mutta johtaako se siihen, ettei blogia ole mielekästä lukea Pinserin Päivän Pamauksen kautta, eivätkä nämä aktiivilukijat siten rekisteröidy top-listasijoituksen kohottajiksi? Onko siis tämä bloginlukijoiden helliminen itsetuhoista, jos tausta-ajatuksena kuitenkin on blogilistalla mahdollisimman korkealle kipuaminen?

(ei vastausta, vain pohdintaa)

Windows 2000:n lähdekoodi läpivalaisussa

Kuro5hin analysoi Windows 2000:n lähdekoodia. Erittäin kiinnostava artikkeli, jossa hyviä havaintoja mm. kommentointityylistä ja monesta muusta asiasta. Kiitos Visa.

.net ja omat sertifikaatit

Microsoft on tehnyt .netissään monta asiaa oikein, mutta jotkut tuntuvat edelleen aavistuksen hankalilta. Tähän kirjoitukseen innoitti tilanne, jossa haluat sallia itse allekirjoitetun sertifikaatin käytön omasta koodista avattavassa HTTPS-yhteydessä. Ohessa ratkaisu.

Itse tehdyt sertifikaatit eivät tietenkään pohjaudu perimmiltään mihinkään luotettavan tahon (kuten Verisignin) allekirjoittamaan sertifikaattiin, joten eihän moisiin passaa oletusarvoisesti luottaa: "Could not establish trust relationship with remote server." Toisaalta harvalla meistä on julkisesti luotettavia varmenteita kaikille testipalvelimillemme.

Vastaus on sinänsä helppo; ICertificatePolicy-rajapinnan kautta on vaivatonta määritellä sellainen politiikka, että mikä tahansa sertifikaatti kelpaa. Tämä ei välttämättä ole kovinkaan turvallista, mutta varsinkin testikäytössä funktionaalisuus yleensä ratkaisee. Seuraavalla pääsee vauhtiin:

using System.Net;
using System.Security.Cryptography.X509Certificates;

internal class TotaalinenLuottaja : ICertificatePolicy {

  public bool CheckValidationResult(
                  ServicePoint sp, 
                  X509Certificate certificate,
                  WebRequest request, int problem) {
    return true;
  }  
}

// ... ja toisaalla koodissa, ennen https-hakua ...

ServicePointManager.CertificatePolicy = new TotaalinenLuottaja();

HTTP-pakkaus on aliarvostettua

HTTP-protokolla tukee varsin helppoa ja järkevää tapaa pakata siirrettävää dataa siten, että serveri vetää lähtevän sivun zippiin ja selain purkaa sen. Oudointa on se, että selaimet tukevat tätä. Tai no okei, vielä oudompaa on se, että käyttö on silti niinkin harvinaista (ja työvälineet niinkin ankeita). Hyödyt ovat nimittäin aika huikeat: Html ja teksti yleensäkin on varsin hulppeaa pakkautumaan. Tässä pari pointteria asiaan liittyen.

Hyviä pakkausratkaisuja löytyy sekä IIS:lle että Apachelle. IIS:llä olen testaillut httpZipiä, mutta myös PipeSpeediä on kehuttu. IIS5:n sisäistä pakkausta ei ole kovin ruusuisesti arvosteltu, kutosessa on kuulemma otettu jo muutama askel eteenpäin. Apachella mod_gzip hallitsee.

Client-päässä selaimet hoitavat homman hyvin itsekin, ainakin kunhan pöydällä on riittävän uusi selain. IE 4+ hoitaa homman Windowsilla (Macilla täytyy mennä 5.x-sarjaan), Netscape 6+ (tai 4.06+, jos pari bugia ei kirpaise) ja Opera 5+ tukevat pakkausta (tai oikeastaan purkua) suoraan. Selaintukea voi testata Http-trace-sovelluksella, joka näyttää selaimen lähettämät otsakkeet. Jos "Accept_Encoding"-kohdassa on gzip tai deflate, pakkausta tuetaan.

Erillistä softaa tarvitaan asiakaspuolelle oikeastaan vain silloin, kun rakennellaan omia koneellisia hakusysteemeitä. Tämä problematiikka riippuukin sitten ihan ympäristöstä. Microsoftin .netillä malliratkaisut ovat yleensä aika SOAP-orientoituneita, mutta voi niitä käyttää muutenkin. Täytyy jonain päivänä tehdä oikeasti siisti ja dokumentoitu toteutus tuosta, mutta siihen asti tyydyn postaamaan nämä kaksi linkkiä: zhttp ja Retrieving Data from Web Services using Standard HTTP 1.1 Compression. Ja kiroamaan sitä, miten tuo pakkauksen tuki Http-haussa on jäänyt Microsoftilta niin kesken.