Självständigt arbete på grundnivå

Självständigt arbete på grundnivå Independent degree project - first cycle Datateknik Användning av greylisting för spamfiltrering för myndigheter Pontus Eliasson

Mittuniversitetet Avdelningen för informationssystem och teknologi (IST) Författare: Pontus Eliasson, poel1600@student.miun.se Examinator: Lennart Franked, lennart.franked(at)miun.se Handledare: Magnus Eriksson Utbildningsprogram: Nätverksdrift, 120hp Kurs: DT140G Datateknik B, Självständigt arbete, 15hp Huvudområde: Datateknik Termin, år: VT, 2018 2

Sammanfattning Undersöker användbarheten av greylisting för att filtrera skräppost ur en myndighets perspektiv som har juridiska krav på sig att vara kontaktbara via epost och då har begränsningar i hur inkomna epost får filtreras. Genom att sätta upp en simulerad miljö så testas ett antal olika program för massutskick av epost och greylisting visar sig vara mycket effektivt när det kommer till att filtrera bort epost som skickas från klienter som inte till fullo stödjer SMTP s funktion för omsändningar enligt RFC. Greylisting har dock en inbyggd nackdel i sättet som skräposten filtreras och det är att samtlig epost från tidigare ej sedda avsändare kommer att fördröjas, i mina försök och med mina inställningar av Postgrey blev det en genomsnittlig fördröjning på ca 17min. Nyckelord: Grålistning, Greylisting, SMTP, Spam, Postgrey 3

Abstract Investigates the usability of greylisting as a means of filtering spam emails in the perspective of a (swedish) government agency that has got legal obligations to be reachable by email and thus are limited in the ways incoming emails may be filtered. By setting up a virtual environment a few softwares for sending bulk mail are tested and greylisting shows to be a very effective when it comes to filter emails that are sent from clients that does not fully support the SMTP s functions for retransmission listed in the RFC. Greylisting has got an built in disadvantage in the way that email are filtered and that is that all emails from senders that has not been seen before will be delayed, in my tests and with my settings of Postgrey I got an average delay of approximately 17min. Keywords: Greylisting, SMTP, Spam, Postgrey 4

Innehåll Sammanfattning 3 Abstract 4 1 Introduktion 6 1.1 Bakgrund och problemmotivering.................. 6 1.2 Avgränsningar............................ 6 1.3 Konkreta och verifierbara mål.................... 7 1.4 Övergripande syfte.......................... 7 2 Teori 8 2.1 SMTP övergripande design..................... 8 2.1.1 Överföring av meddelande.................. 8 2.2 Grålistning.............................. 11 2.2.1 Olika typer av grålistning som beskrivs i RFC 6647:... 12 2.3 Postgrey................................ 13 2.4 Text mining spam detektion..................... 14 3 Metod 14 3.1 Bulk-mail mjukvaror......................... 16 4 Resultat 17 4.1 Referenstest och fördröjning..................... 17 4.2 Resultat av test av spammjukvara................. 17 4.3 Bulk Mailer Pro........................... 17 4.4 Send Blaster 4............................ 18 4.5 Atomic Mail Sender......................... 19 5 Analys 22 6 Slutsats 23 7 Bilagor 24 5

1 Introduktion 1.1 Bakgrund och problemmotivering Statskontorets rapport om Myndigheternas spamhantering en vägledning kring rättsliga frågor [1] från 2005 visar på de svårigheter som finns när en myndighets skyldighet att vara kontaktbar skall vägas mot myndighetens säkerhetsarbete så som att kunna filtrera skadlig kod och använda olika typer av filter för skäppost. En av möjligheterna som rapporten kommer fram till är möjligheten att inte acceptera epost som bryter mot SMTP-protokollet genom att använda förfalskade adresser [1, p.23-25]. Med anledning av det resonemanget så är det intressant att undersöka användbarheten av greylisting då greylisting lutar sig mot samma princip i och med att greylisting beroende på inställningar och implementation skickar felkoder till nya avsändare att tjänsten för tillfället inte är tillgänglig. Följer avsändaren SMTP-protokollet så kommer avsändaren att skicka om mailet senare och då kommer mailet att släppas igenom [2, 1.1]. Bakgrunden till att undersöka användbarheten samt eventuella för och nackdelar med greylisting som metod för att filtrera bort skräppost för myndigheter är kravet som myndigheter har på sig att tillhandahålla service enligt förvaltningslag (1986:223) 5. Dessa serviceskyldigheter innehåller ett krav på myndigheter om att det skall vara möjligt för en enskild att kontakta en myndighet via epost och kunna få svar på samma sätt [3, 5]. Detta kravet gör det både juridiskt och etiskt svårt att använda andra väldigt strikta former av filtrering som t.ex blacklisting då det teoretiskt sett skulle kunna innebära att legitima email från enskilda filtreras bort. I ett papper från 2016 publicerad av IEEE (som bland annat undersöker greylisting) så påvisas det att greylisting fortsatt är en effektiv metod när det kommer till att blockera spam. Greylisting lyckades effektivt blockera spam från botnäten Cutwail och Darkmailer som då stod för 43% av alla spammail i världen [4, 1.1]. 1.2 Avgränsningar Arbetet avgränsas till att enbart undersöka greylisting som ensamt skydd mot skräppost. Greylisting kommer då inte att testas tillsammans med andra metoder för att motverka skräppost som Statskontoret i sin rapport [1] anser att myndigheter kan använda sig av. Testerna kommer i sin helhet att genomföras i virtuella miljöer och uteslutande med programvara som är gratis eller har en obetydlig kostnad. Kommer enbart att undersöka greylist i förhållande till SMTP RFC 5321. Enbart mjukvaror som har inbyggt stöd för SMTP direkt i mjukvaran kommer att testas. Externa SMTP servrar för relay kommer ej att användas som relay eller testas vilket innebär att eposten kommer att skickas direkt från spam- 6

mjukvaran istället för att gå via en extern SMTP server vars uppdrag är att vidarebefodra eposten. 1.3 Konkreta och verifierbara mål Undersökninge har som mål att undersöka ifall greylisting fortfarande är en effektiv metod för att filtera skräppost som skickas från mjukvaror som är speciellt framtagna för att skicka stora mängder med epost (Bulk Mailers). Även de nackdelar som greylisting innebär främst kopplat till fördröjning av legitima epost skall undersökas. 1.4 Övergripande syfte Syftet är att undersöka användbarheten av greylisting när det kommer till att reducera mängden skräppost som kommer fram till en myndighets funktionsbrevlåda samt undersöka de för och nackdelar som finns med att använda greylisting för att filtrera skräppost sett ur en myndighets perspektiv. 7

2 Teori 2.1 SMTP övergripande design SMTP - Simple Mail Transfer Protocol är ett protokoll vars mål är att överföra epost med hög tillförlitlighet och effektivitet [5, p.4]. SMTP är ett protokoll som är oberoende av vilket underliggande transportprotokoll som används så länge som det är tillförlitligt (connection oriented). Det vanligaste är dock TCP och det är även det protokollet som används som exempel i RFC 5321 [5, p.4]. Figur 1: Övergripande SMTP design från RFC 5321 [5, p.6] När en SMTP klient ska skicka ett meddelande så etableras en tvåvägsanslutning mellan en SMTP client och en SMTP server. Klientens skyldigheter är att överföra meddelanden eller att rapportera dess misslyckande att göra det [5, p.6]. Ett krav för att en SMTP implementering ska anses som fullt kapabel är bland annat att den stödjer alla köfunktioner och funktioner för att sända om meddelanden som inte överfördes [5, p.6]. Figur 1 visar övergripande hur förhållandet mellan SMTP klient och SMTP server fungerar. En SMTP server kan agera både som slutgiltlig destination för ett meddelande eller som en vidarebefodrare av ett meddelande. I de fallen som en SMTP server agerar som vidarebefodrare så övertar SMTP servern ansvaret för att tillse att meddelandet levereras korrekt, alternativt att rapportera misslyckandet att leverera meddelandet [5, p.7]. 2.1.1 Överföring av meddelande En SMTP session initieras av klienten som upprättar en anslutning mot servern och servern svarar med ett öppningsmeddelande med kod 220 som informerar klienten att servern är redo. SMTP tillåter att servrar kan konfigureras att dela ut mjukvaruinformation samt versionsinformation efter detta öppningsmeddelande men det är inget krav då det kan finnas säkerhetsanledningar till att inte göra så [5, p.17]. Protokollet ger även möjlighet för en SMTP server att neka en an- 8

slutning efter att t.ex en TCP anslutning har upprättats genom att sända ett meddelande med kod 554 istället för 220 [5, p.17]. När SMTP servern har accepterat en sessionen genom att skicka 220 koden till klienten efter att anslutningen upprättades så skickar klienten EHLO kommandot, som visar klientens identitet samt att klienten kan hantera vissa tillägg till SMTP och begär då att servern ska informera vilka tillägg till SMTP som servern stödjer [5, p.17]. Skulle klienten inte stödja tilläggen till SMTP så skickar klienten HELO kommandot istället för EHLO och då kommer inte SMTP servern att svara med vilka tillägg som den stödjer [5, p.17]. SMTP servern svarar på klientens EHLO med en koden 250 som innebär Requested mail action okay, completed samt en lista på vilka tillägg som servern stödjer. Kod 250 är en återkommande kod som används av SMTP servern som positiv feedback. Första tvåan i koden representerar att det är ett positivt svar om att den begärda åtgärden har utförts samt att en ny begäran kan göras av servern. Siffra nummer två som i det här fallet är en femma betyder att koden indikerar statusen hos mottagande mailsystem [5, p.47-48] vilket kan ses i figur 2. Den tredje siffran i dessa koder som används av SMTP visar mer specifikt på betydelsen av siffra två i koden. 9

Figur 2: Visar hur koderna som används i SMTP är uppbyggda. Från RFC 5321 [5, p.47-48] 10

Överföring av själva meddelandet startar med att klienten skickar MAIL kommandot med avsändarens identitet. Detta meddelande får enbart skickas när det inte pågår någon överföring av ett meddelande (mail) [5, p.18]. MAIL FROM: <reverse-path > [SP <mail-parameters >] <CRLF > Kommandot informerar servern om att överföringen av ett nytt meddelande påbörjas och att servern ska nollställa alla buffrar, tabeller samt all data kopplad till förgående meddelande. Fältet <reverse-path > innehåller avsändarens brevlåda som kan användas för att rapportera fel i överföringen av meddelandet och <mail-parameters > delen finns till för möjligheten att kunna förhandla fram tillägg till SMTP med servern [5, p.18]. Väljer servern att acceptera meddelandet så svarar servern med 250 koden. Om servern inte accepterar att ta i mot meddelandet så måste servern svara avsändaren om felet är permanent eller tillfälligt. Ett permanent fel definieras som ett fel som kommer att inträffa om klienten försöker att skicka samma meddelande igen medans ett temporärt fel definieras som ett fel som kan kommas att accepteras om klienten försöker skicka samma meddelande igen senare. Förutsatt att klienten får tillbaka kod 250 efter att klienten skickat MAIL kommandot med avsändarens adress så skickar klienten nu RCPT kommandot innehållandes mottagarens adress enligt följande [5, p.18]: RCPT TO: <forward-path >[ SP <rcpt-parameters >] <CRLF > RCPT kan upprepas flera gånger utan begränsning för att t.ex kunna skicka samma meddelande till flera personer. Även i det här fallet så måste servern svara med kod 250 förutsatt att det inte uppkommit några problem och servern istället ska svara med kod 4xx eller 5xx. Nästa steg är att klienten skickar: DATA <CRLF >kommandot vilket påbörjar överförandet av själva meddelandet till servern förutsatt att servern accepterar att ta i mot meddelandet genom att skicka 354 koden till klienten. Klienten (eller en servern som agerar klient vid överförande av ett meddelande) indikerar att meddelandet är slut med en linje med enbart en. (punkt), servern svarar på slutet av meddelandet med kod 250. [5, p.19] Har klienten inga fler meddelanden att överföra så skickar klienten QUIT kommandot till servern som svarar med kod 221 och stänger ner förbindelsen. [5, p.87] 2.2 Grålistning Grunden till grålistningens funktion är att stora delar av alla spammail skickas med mjukvara speciellt utvecklat för just den uppgiften (även kallat spamware) som inte till fullt stödjer SMTP protokollet, speciellt att spammjukvaran inte stödjer omsändningar av meddelanden när SMTP klienten fått ett temporärt felmeddelande [2, p.3]. Istället för att försöka igen senare så hoppar spammjukvaran över den adressen och fortsätter med nästa adress i listan. Orsaken till detta är att dessa spammjukvaror är utvecklade i syfte att skicka stora mängder mail på kort tid och har inget behov av tillförlitlighet. Eftersom många av dessa mjukvaror inte stödjer omsändningar så kan det utnyttjas vilket grålistning gör genom att skicka felmeddelanden med 4xx kod till hittills okända avsändare [2, 11

p.2] vilket informerar en tidigare okänd SMTP klienten att meddelandet inte kan överföras just nu men att det finns en möjlighet att meddelandet går att överföra senare. För att bestämma om grålistning ska genomföras eller ej så kontrolleras ett eller ett eller flera attribut hos SMTP klienten, om grålistning ska genomföras så sker det under någon fas av SMTP sessionen där meddelandet ska överföras. [2, p.3] 2.2.1 Olika typer av grålistning som beskrivs i RFC 6647: Connection-level greylisting Genomförs genom att SMTP servern väljer om servern accepterar TCP anslutningen från en SMTP klient eller ej. Den enda informationen som finns tillgängligt för SMTP servern är SMTP klientens IP vilket även skulle kunna innebära ett hostname (värdnamn). I connection-level greylisting så ansvarar greylistingsmjukvaran för att hålla ett register med IP adresser och/eller hostname tillhörande SMTP klienter som grålistningsmjukvaran har sett. Registret kommer då att innehålla alla kända avsändare. Vissa implementationer tillåter att registret över kända SMTP klienter gallras efter en viss bestämd tidsperiod, vilket innebär att listan över redan sedda avsändare rensas efter en viss bestämd tidsperiod och dessa avsändare skulle då bli greylistade på nytt. Skulle en SMTP klients IP och/eller host name inte finnas i registret (alternativt inte funnits i registret tillräckligt länge) så kommer SMTP servern att skicka ett felmeddelande med kod 421 samt stänga ner anslutningen alternativt att svara med andra 4yz SMTP koder på samtliga kommande SMTP kommandon från klienten under sessionen. [2, p.3-4] SMTP koden 421 innebär <domain > Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) [5, p.50] vilket är en generellt felmeddelande som kan skickas som svar på alla kommandon om tjänsten måste avslutas. Eftersom 4yz koden innebär att felet bara är tillfälligt och att meddelandet kan accepteras utan ändringar ifall avsändaren väljer att skicka meddelandet igen vid ett senare tillfälle [5, p.18], innebär det att en SMTP klient som följer SMTP standarden kommer att skicka om meddelandet efter en tidsperiod och finns då med i IP / hostname-registret och meddelandet kommer då att accepteras. Följer SMTP klienten inte standarden så som vissa mjukvaror skapade för att skicka spammail så kommer meddelandet aldrig skickas om [2, p.2]. SMTP HELO/EHLO Greylisting kommer att acceptera TCP anslutningen från SMTP klienten men kommer att svara på samtliga kommandon från klienten med 4yz felkoder tills att anslutningen avslutas så vidare inte SMTP klientens fullständiga domännamn (FQDN) alternativt IP samt vissa HELO/EHLO parametrar kopplat till SMTP klientens FQDN finns i registret sen tidigare [2, p.4]. 12

SMTP MAIL Greylisting använder sig av return email adress som skickas som första steg i MAIL kommandot under överförandet av ett meddelande [5, p.18] MAIL FROM: <reverse-path> [SP <mail-parameters >] <CRLF >. Har inte både avsändarens returadress (reverse-path) setts tidigare i kombination med en SMTP klients IP/adress så kommer SMTP servern att svara med 4yz felkoder under resten av sessionen [2, p.4]. SMTP RCPT Greylisting använder informationen från kommandot: RCPT TO: <forward-path>[ SP <rcpt-parameters >] <CRLF >där forwardpath är mottagaren av meddelandet. SMTP RCPT Greylisting kontrollerar ifall mottagaren har setts innan i kombination med någon följande parametrar: SMTP klientens IP/FQDN (Fully Qualified Host Name, vilket är ett fullt specifierad domännamn alternativt en numeriskt IP adress till en host ), avsändarens returadress (reverse-path) alternativt de andra adressaterna i meddelandet. Finns inte kombinationen av mottagare och vald parameter i registret sen tidigare så kommer 4yz SMTP koder att skickas på alla framtida kommandon från klienten [2, p.4-5]. SMTP DATA Greylisting är en greylisting som genomförs under SMTP s DATA del vilket är överföringen av det faktiska meddelandet. Antingen så kan greylistingen utföras när klienten skickar DATA kommandot alternativt när klienten skickar en punkt (.) som visar på att meddelandet är slut. DATA greylisting kan filtrera på en kombination av en mängd olika parametrar, bland annat returadress och mottagare men även i kombination med information från DATA delen så som innehållet i meddelandet eller headern [2, p.5-6]. 2.3 Postgrey Postgrey är en policy server för Postfix som implementerar greylisting, Postgrey kontrollerar ifall IP, avsändare och mottagare har setts innan i den kombinationen. Har kombinationen inte setts tidigare så skickas ett temporärt fel och som default så måste det gå minst 5 min innan en omsändning av mailet kommer att accepteras. [6]. Postgrey har även som standard att om den grålistar ett mail så kommer Postgrey att svara med (Greylisted + help url) [7]. 13

2.4 Text mining spam detektion Utöver greylisting så finns det även andra metoder för att filtrera spam, ett av dessa är Text mining (Data mining) vilket är en metod för att genom algoritmer bedöma om ett epost är spam eller inte. Dessa metoder är dock inte helt felfria, i en rapport från 2016 där tre olika former av text mining användes för att detektera epost så var mellan 4% och 16,5% av algoritmens resultat felaktigt (Spam släpptes igenom alternaivt att legitim epost nekades) [8]. 3 Metod Metoden som kommer att användas är att tre stycken virtuella maskiner körs, två av de virtuella maskinerna kommer att köra Ubuntu och kommer att vara konfigurerade att köra Postfix. En av maskinerna som kör Ubuntu kommer även att agera DNS server för det virtuella nätverket. Den tredje maskinen kommer att köra Windows 10 och är den maskinen som kommer att ansvara för köra mjukvaran som ska skicka ut spammailen till de två Ubuntu maskinerna som kör Postfix, en förklaring till hur de virtuella maskinerna är uppsatta kan ses i figur 3. Samtliga virtuella maskiner körs på den fysiska maskinen nedan: Fysisk Maskin OS Windows 10 Pro - Version 1803 CPU Intel Core i7-6700k @ 4.00GHz RAM 16 GB Mjukvara för att köra virtuella maskiner Oracle Virtualbox v.5.2.12 14

Figur 3: Visar de virtuella maskinerna med tillhörande version En av Ubuntu maskinerna kommer att agera referens och den andra maskinen kommer i ett senare testskede att konfigureras med Postgrey daemon som sköter greylistingen. Det enda som skiljer referenssmaskinen mot maskinen som ska konfigureras med Greyfix är att referensmaskinen även agerar DNS server för nätverket. SMTP Referens SMTP Greylisting Postfix version 3.3.0 3.3.0 Tilldelat RAM 2048MB 2048MB Tilldelade CPU-Kärnor 2 2 Konfigurerad mailserver mail.ref.exjobb.se mail.greylist.exjobb.se Greylisting paket - Postgrey v1.36 För att säkerställa att de båda Postfix konfigurationerna på de två Ubuntu maskinerna är fullt fungerande innan ytterligare konfiguration görs med greylisting samt att DNSen är rätt konfigurerad så görs tester från Windows 10 maskinen där mailservern på de två maskinerna pingas (test för att undersöka 15

om det finns fungerande förbindelse) samt ett testmail skickas från bulkmailmjukvaran bulkmail [9] till maskinerna konfigurerade med Postgrey. Mailen ska levereras till båda SMTP servrarna innan greylisting konfigureras på maskinen som ska köra greylisting. Därefter konfigureras Postgrey v1.36 på maskinen som ska köra Greylisting, Postgrey konfigureras att neka epost från tidigare ej sedda tupels (IP, mottagare och avsändare) i 600 sekunder innan eposten accepteras och släpps igenom. Efter att Postgrey v1.36 är konfigurerat och körs på maskinen som ska greylista så kommer mail skickas från SMTP Referens servern till greylisting servern för att säkerställa att eposten kommer fram när eposten skickas från en klient som till fullo stödjer SMTP. När greylisting är konfigurerat så ska effekten av greylisting testas med hjälp av olika mjukvaror för massutskick av epost (bulk email software). En textfil med en mailadress till referensimplementationen av SMTP (Postfix) samt en mailadress till maskinen som kör Postgrey skapas och kommer att användas av samtliga mjukvaror. Mjukvarorna kommer att skicka eposten från olika avsändare så att varje tuple av (IP, avsändare och mottagare) är unik för varje mjukvara. 3.1 Bulk-mail mjukvaror Följande mjukvaror för att skicka massmail kommer att testas. Samtliga mjukvaror kommer att testa med den inbyggda implementationen av SMTP som följer med mjukvaran, inga externa SMTP servrar kommer att testas. Mjukvara Version Hemsida Bulk Mailer Pro 8.4.4682.17304 http://bulkmailerpro.com/ Send Blaster 4 4.1.10 http://www.sendblaster.com/sv Atomic Mail Sender 9.41.0.434 https://www.atompark.com/bulk-email-sender/ 16

4 Resultat 4.1 Referenstest och fördröjning Tre epost skickades från refernsmaskinen till maskinen som kör Postgrey genom att via konsolen från referensmaskinen telneta mot port 25 localhost (Vilket innebär att man ansluter sig till den lokala SMTP servern på referensmaskinen) och skicka mail till greylist@greylist.exjobb.se. Det skickas totalt 3 stycken epost från olika avsändare och med minst 60 min mellanrum. Tabell 1: Fördröjning av leverans Mail skickades Mail mottogs Fördröjning av leverans 11.02 11:20 18 min 13:14 13:31 17 min 13:33 13:51 18 min Vilket ger en genomsnittlig fördröjning av 17.66 min. 4.2 Resultat av test av spammjukvara Tabell 2: Greylisting filtrering Mjukvara SMTP-Referens SMTP-Greylist Bulk Mailer Pro Mottaget Ej mottaget Send Blaster 4 Mottaget Ej mottaget Atomic Mail Sender Mottaget Ej mottaget 4.3 Bulk Mailer Pro Med mjukvaran Bulk Mailer Pro så kommer mailet fram till referensimplementationen av SMTP men den blir greylistad av implementationen som kör Postgrey. Bulk Mailer Pro identifierar dock att den har blivit greylistad. Inga försök till omsändningar görs. Figur 4 visar programets felmeddelande som visar att programet har identifierat att mottagaren kör greylisting och att epostet ej kunnat levereras. 17

Figur 4: Bulk Mailer Pro - Identifierar att den har blivit greylistad 4.4 Send Blaster 4 Med mjukvaran Send Blaster 4 så kommer mailet fram till referensimplementationen av SMTP, men den blir greylistad av implementationen som kör Postgrey. I figur 5 så visas att Send Blaster 4 inte identifierar att den har blivit greylistad utan enbart att mailet inte kan levereras. Inställningarna som använts visas även i figur 6. 18

Figur 5: Send Blaster 4 - Indentifierar ej att den har blivit greylistad 4.5 Atomic Mail Sender Med mjukvaran Atomic Mail Sender så kommer mailet fram till referensimplementationen av SMTP men den blir greylistad av implementationen som kör Postgrey. Atomic Mail Sender identifierar inte att den har blivit greylistad utan enbart att mailet inte kan levereras vilket visas i figur 7. Det går dock att se att mottagaren kör greylisting men enbart genom att kontrollera loggen samt att Postgrey som standard skickar ut felmeddelandet som kan ses i figur 8. 19

Figur 6: Atomic Mail Sender - Mailet greylistas, mjukvaran identifierar inte att den har blivit greylistad. 20

Figur 7: Endast genom kontroll av loggen så framgår det att mailet har blivit greylistat och då enbart för att Postgrey är konfigurerat att skicka det meddelandet innan den skickar 4xy felkoden 21

5 Analys Ingen av bulk mail mjukvarorna som jag har testat lyckades leverera email till SMTP implementationen som var konfigurerar med Postgrey. Greylisting fungerade utmärkt när det kom till att blockera email skickade från dessa mjukvaror och enbart en av mjukvarorna lyckades identifiera att den hade blivit greylistad. Trots att greylisting var väldigt effektivt när det kom till att blockera spam från dessa mjukvaror så finns det även en inbyggd nackdel i metoden då även legitima email blir fördröjda att komma fram. Samtliga bulk mail mjukvarorna var konfigurerade att använda mjukvarans inbyggda implementation av SMTP. Det är väldigt troligt att resultatet hade blivit ett annat ifall en extern SMTP server hade använts för relay. Referensimplementationen av Postfix klarade utan problem av att leverera epost till servern som körde Postgrey med en fördröjning i snitt på 17.66 min. Fördröjningen på leveransen av eposten kommer skilja sig beroende på hur lång tid Postgrey är satt att greylista en avsändare, i mitt fall så valde jag 600 sekunder (10 min). 22

6 Slutsats Greylisting är en effektiv metod när det kommer till att filtera bort epost från avsändare som inte till fullo följer SMTP implementationen enligt RFC. En nackdel är att alla nya avsändare kommer att uppleva en fördröjning när det kommer till leveransen av deras epost. För en myndighet så är greylisting klart mer användningsbart än för privata företag då dessa har en betydligt större möjlighet att kunna filtera bort skräppost än vad myndigheter har på grund av jurdiska krav på att vara kontaktbara. Det finns alternativ till greylisting och då främst olika former av text mining som kan vara ett alternativ då dessa är mycket effektiva på att identifiera spam. Dock så har källan jag använt mig av visat på att det finns en risk för att legitim epost kan klassificeras som spam och då fastna i skräpposten, detta innebär ett problem för myndigheter som riskerar att inte tillhandahålla kravet på kontaktbarhet som finns i förvaltningslag (1986:223) 5, om inte myndigheten väljer att manuellt granska skräpposten i jakt på legitima epost som har sorterats fel av algoritmen. För eventuell framtida tester så hade det varit intressant att se hur resultaten hade blivit ifall en extern SMTP server hade använts istället för mjukvarornas inbyggda SMTP lösningar. Referenser [1] Statskontoret, Myndigheternas spamhantering en vägledning kring rättsliga frågor, 2005. [Online]. Available: https://goo.gl/uuaeb2 [2] Internet Engineering Task Force (IETF), Email greylisting: An applicability statement for smtp, 2012. [Online]. Available: https://tools.ietf.org/html/rfc6647 [3] Svensk författningssamling 1986:223, Förvaltningslag (1986:223), 1986. [Online]. Available: https://lagen.nu/1986:223 [4] Fabio Pagani ; Matteo De Astis ; Mariano Graziano ; Andrea Lanzi ; Davide Balzarotti, Measuring the role of greylisting and nolisting in fighting spam, 2016. [Online]. Available: https://ieeexplore.ieee.org/document/7579772/ [5] Network Working Group, Simple mail transfer protocol - rfc5321, 2008. [Online]. Available: https://tools.ietf.org/html/rfc5321 [6] D. Schweikert, Postgrey - postfix greylisting policy server. [Online]. Available: https://postgrey.schweikert.ch/ [7], postgrey(8) - linux man page. [Online]. Available: https://linux.die.net/man/8/postgrey 23

[8] Zahra Khan ; Usman Qamar, Text mining approach to detect spam in emails, 2016. [Online]. Available: https://goo.gl/rgcglm [9] Bulk Mailer, Bulkmailer. [Online]. Available: http://bulkmailerpro.com/ 7 Bilagor Figur 8: Mailservern på de två Ubuntu maskinerna konfigurerade med Postfix pingas från Windows 10 maskinen för att säkerställa att DNSen är rätt konfigurerad. 24

Figur 9: Kontroll att mjukvaran kan leverera epost till båda maskinerna som kör Postfix innan konfiguration av Greylisting - Båda mailen levereras korrekt. 25

Figur 10: Bind inställningar. Figur 11: Bind inställningar. 26

Figur 12: Bind inställningar. 27

Figur 13: Inställningar Postfix för referensmaskinen 28

Figur 14: Inställningar Postfix för greylistingsmaskinen 29

Figur 15: Postgrey inställningar. 30