Grålistning (engelska: greylisting) är en metod för att bekämpa skräppost som bygger på att avsändande e-postprogram eller -server till fullo stöder omsändningar, vilket de flesta skräppostskickande bottar och datorvirus inte klarar av.

Grundförutsättning redigera

Hur ett e-postmeddelande förs över från en dator till nästa på vägen mellan sändare och mottagare finns specificerat i ett standarddokument som heter RFC 5321 (äldre motsvarande standarder är RFC 821 och RFC 2821). Där står det bland annat hur en e-postserver eller e-postprogram ska bära sig åt om meddelandet inte kan levereras omedelbart (stycke 4.5.4.1). Den ska vänta och försöka igen senare.

Att hålla meddelanden i kö och vänta på att de ska gå att skicka på nytt är acceptabelt för persondatorer som bara hanterar ett fåtal brev åt gången eller för dedicerade servrar som ägnar hela sin kapacitet åt att hantera e-post. Det är däremot mycket svårare för bottar och virus som måste klara sig på minimala resurser för att kunna arbeta oupptäckta.

Princip redigera

Så här fungerar grålistning. Det som dator1 skickar till dator2 står med grön text. Det som dator2 skickar till dator1 står med röd text. Observera att alla svar inleds med en statuskod på tre siffror (konversationen här är inte helt i enlighet med standarden, men liknar en faktisk konversation).

  1. Dator1 kontaktar dator2 och presenterar sig i syfte att överbringa ett epost-meddelande.
    HELO dator1
  2. Dator2 svarar med att kort presentera vad den kan och hur den accepterar epost-meddelanden.
    250-dator2
    250-8BITMIME
    250-PIPELINING
    250 SIZE 41943040
  3. Dator1 börjar med att skriva vilken avsändare brevet kommer ifrån.
    MAIL FROM: <emma@example.com>
    250 Ok
  4. Eftersom dator2 tyckte att avsändaren var acceptabel så kan dator1 gå vidare med att skriva mottagarens adress.
    RCPT TO: <pelle@example.org>
  5. Nu vet dator2 både avsändarens och mottagarens adresser (trots att den inte har fått själva brevet än). Det är nu grålistningen kommer in. Om dator2 inte känner till att emma@example.com har skickat epost till pelle@example.org från dator1 förut så bryter den konversationen här och ber dator1 att komma tillbaka senare.
    450 Recipient address rejected: Temporary failure
  6. Men dator2 glömmer inte bort att dator1 har ett brev att skicka, utan lagrar avsändar- och mottagar-adress eventuellt tillsammans med IP-adressen för dator1 och tidpunkt i en databas. Nästa gång dator1 försöker leverera samma brev igen kommer den att känna igen brevet och släppa igenom det (under förutsättning att dator1 har väntat "lagom" länge först).

Allt det här är något som avhandlas mellan dator1 och dator2 helt utan mänsklig inblandning.

Fördelar redigera

De flesta bottar och datorvirus ger upp när de får ett 450 Temporary failure tillbaka. Det lönar sig mer att gå vidare i listan med adresser och skicka skräppost till nästa mottagare än att ödsla resurser på någon som kanske har en övergiven överfull postlåda. För välunderhållna e-postsystem med välskriven programvara är det däremot självklart att lägga brevet på kö och försöka leverera det igen inom rimlig tid.

Nackdelar redigera

Fördröjning redigera

Att ett brev fördröjs är helt enligt reglerna i RFC 5321, trots det så förväntar sig de flesta användare att epost levereras omedelbart.

Mobila enheter redigera

Om en bärbar dator eller en mobiltelefon blir tvungen att hålla ett brev i kö kan det hända att den blir avstängd, förlorar nätkontakten eller byter IP-adress innan den har lyckats leverera brevet. Det kan då dröja länge innan den får någon chans att försöka leverera brevet igen.

Om enheten har möjlighet att kännas igen av en "egen" server kan meddelandet skickas via denna, som inte har några problem med att köa meddelandet. Det finns olika mekanismer genom vilka en enhet med tillfällig främmande IP-adress kan autentisera sig för servern, som då inte behöver grålista e-post från enheten. Ingen av dessa mekanismer stöds dock direkt av all e-postprogramvara.

Omsändning från annan dator redigera

Riktigt stora epost-leverantörer som Gmail och Hotmail kan ha flera hundra servrar i ett datorkluster för att hantera epost. Det är därför inte säkert att nästa försök att leverera brevet kommer från samma dator som det första försöket.

Utebliven omsändning redigera

Tyvärr så finns det fortfarande epost-system och -program som är så dåligt skrivna och/eller dåligt konfigurerade att de inte klarar att lägga meddelanden på kö eller inte klarar av att sända om de meddelanden som ligger i kö.