Ta kontroll över din spam med procmail - del 2 Mail-/spamboxhantering. Kurt Magnusson

Ta kontroll över din spam med procmail - del 2 Mail-/spamboxhantering Kurt Magnusson I första texten visade jag hur jag lagt upp mitt procmailrc-skript. Det nämndes då att extrabrevlådorna för spam och backup som ingår i "konceptet", behöver cirkuleras för att inte fylla upp ISP:ns diskarna med gammal spam. I denna text kommer vi att gå igenom en enkel metod för att göra denna cirkulering. Det betyder att vi kommer att se på hur man skriver några enkla kommandofiler, snarare än att arbeta med procmail. Problemet löses enklast genom att låta en kommandofil byta namn på en serie brevlådor, genom att döpa om dem i tur och ordning från äldsta till nyaste. Man kopierar den yngre över den föregående, äldre versionen. När grunden är gjort är det bara att bestämma hur många generationer av brevlådan man vill spara och hur ofta man vill göra cirkuleringen, varje natt eller en gång per vecka eller mer. - Kommandofiler eller shellscripts Eftersom vi här ger oss in på ett för många ovant område, Unix/Linux kommandofiler eller shellscripts, kan en enkel genomgång av sådana skript vara på sin plats. Shellscripts egentligen textfiler som innehåller sekvenser av Unix-kommandon som Unixskalet (eller shellet) så kan köra i tur och ordning. Många har säkert under DOS- och Win3.11/95-tiden laborerat med Autoexec.bat och andra bat-filer. Shellscripts är inget annat än en kraftfullare variant av dessa gamla bat-filerna. En hel del Unix-användare har gått över till Perl för skript, något som de flesta dataintresserade hört talas om. Själv håller jag fast vid skripten, då de är snabba att utveckla, man slipper tänka på att definitera och öppna/stänga filer och variabler. De är faktiskt perfekta för jobb, som det vi står inför. Jag rekommenderar att börja med att läsa någon enkel Unix-introduktion, så man vet vilka grundläggande Unix-kommandon som finns. För den som vill veta mer är det bara att söka, det finns t o m kompletta böcker på nätet. Det viktigaste är att komma ihåg att även om de ser otroligt kryptiska ut, så är Unix kommandonamn mycket systematiska och logiska i sin namngivning. Skaparna använde sig av minnesstödteknik, mnemnonics, för att korta ner namnen. Motsvarigheten till windows "dir"-kommando i Unix, "ls", står helt enkelt för "list", "cp" för "copy", "mv" för "move" osv. Om man läser ut namnen, när man läser förkortningen, blir de lika förståliga som de gamla Dos-kommandona. Shellskript är alltså rena textfiler som kan skrivas med de flesta Unix/Linux-editorer. Enklast väljer man den editor man behärskar. Jag gissar att de flesta, speciellt de med liten Unix-erfarenhet, föredrar "pico", iom dess likhet med DOS editorn "Edit". Annars finns emacs och för de verkliga självplågarna, vi. Det viktiga är att först öva med editorn, att skriva enkla texter, klippa och klistra text mellan olika rader osv. Man får då en känsla för hur editorn fungerar och på så sätt minskar man risken för de editeringsfel som annars kan uppstå. När jag på 80- och början av 90-talet arbetade som IT-lärare, så det första jag gjorde, var att låta mina elever lägga hela 2-3 dagar på att lära sig editorn de skulle använda. Jag råder alla med liten Unixvana att göra det samma. Börja med att göra enkla skripts, t.ex. ett som gör långa "dir"-listor likt Dos:s "dir". === filen "tst" === ls -la $* ==== slut fil ==== Vi har nu ett enkelt skript, men den är inte riktigt i körbart skick. För att provköra filen använder vi kommandoraden "sh tst /usr/local/bin". Som synes listar vårt skript innehållet i kataloget "/usr/local/bin" i ett format som är rätt likt DOS "dir"-kommando. Ta kontroll över din spam med procmail del 2 Sida 1 Lars Magnusson - Får ej användas utan att källan anges

Som jag nämnde är "ls" Unix "dir"-kommando och genom att lägga till "-l" [för "long list"] talar vi om att vi vill ha utskriftversionen som ger all info om filerna, då "ls" enbart motsvarar "dir /w". Om vi åter jämför med DOS så får vi också förklaringen till "$*" i mitt exempel. "$1" är samma som Dos "%1", "$2" är "%2" etc. Därför står "$*" för alla argument som angivits på kommandoraden. Vi kan alltså ange flera katalog på kommandoraden om vi vill och de listas alla av "ls". Det finns ytteligare möjligheter med skript-argument, men de ligger utanför ramen för denna minikurs, så vi nöjer oss med ovanstående. Notera att jag döpte filen till "tst", inte "test". Man skall aldrig skall döpa en skriptfil till "test" i Unix ;-). Det är ett internt kommando i de flesta Unix-skal, så effekten kan bli rätt annorlunda och sällan den förväntade, när man provkör skriptet. Men varför skrev vi "sh tst"? Då filen "tst" ännu inte är markerad som körbar, måste därför skalet få instruktioner att köra filen. Genom att skriva "sh" först, förstår Unix att nästa fil, "tst" är ett skript. Någon som kommer ihåg "command /c test.bat"? Vi har också valt det ursprungliga Unix-skalet, Bourne Shell, "sh", men vad man använder är en smaksak. Det tekniskt bästa skalet idag är antagligen senaste versionen av KornShell, ksh93. Själv har jag kört ksh88 eller "ksh", sedan 1988, men på mina nuvarande maskiner är "bash" standard, då den bekvämt stödjer piltangenter för historik och rad-redigering i sin "emacs"-mode, samma som windows Dos-fönstren. Mina skript är dock oftast skrivna för "sh", standard-skalet, pga bättre flyttbarhet mellan olika Unix/Linux-dialekter. - Organisering av skripts Innan vi fortsätter, kan det vara på sin plats att nämna något om hantering av skript. Jag har själv valt att skapat ett eget bin-katalog för mina skript. Det finns flera "globala" katalog som "/bin", "/usr/bin" och "/usr/local/bin" som standard under Unix, men dessa är låsta för oss användare, så jag har ett eget i mitt hemkatalog. Där jag förvarar dels alla mina skript samt en del andra program, som editorn "microemacs". Hos min ISP heter kataloget heter "/home/mit-namn/bin". Det blir också enklare att managera skripten om man lägger dem på samma ställe. Jag har även lagt till kataloget till min PATH. Skriv "echo $PATH" för att se vad ni har, det samma idé som i Dos, men med ":" istället för ";" mellan de olika katalogen. Detta görs i min ".bashrc" startfil, som är en individuell autoexec.bat som initierar körmiljön för mitt skal. Det finns även andra startfiler som ".profile", ".kshrc", ".cshrc" m.fl., beroende på vilket skal man kör, men åter ligger det utanför vad vi gör här. De olika Unix-guiderna har oftast lite text om det. Observera att "." först i namnet gör filen "osynlig", man måste lista dem med "ls -a" eller "ls -la" för att se dem. Jag vill påminna om, att har man ett eget bin-katalog _skall_ det skyddas. Jag har stängt mitt för alla utom mig själv (och root, som når allt :-) och samma med själva skripten, jag återkommer till detta. Av samma skäl skall egna bin-kataloget stå sist i PATH-definitionen, så ingen kan smyga in någon elakhet i i mitt katalog, som kan ersätta "riktiga" Unix-kommandon. Det har hänt att hackers har lagt in skript med samma filnamn som viktiga systemkommandon, t.ex. ett ftp-skript som öppnar ftp-förbindelsen som om den vore vanliga ftp, men också mailar användar-id och lösenord till hackern. Ligger bin-kataloget sist, så väljs de riktiga kommandona före eventuella fejkade. - Filcirkulering Om vi så återgår till uppgiften, för att styra cirkuleringen hade jag valt att lägga på ett generationsnummer på de äldre filernas namn. "spam" är yngst och "spam.4" äldst. När så "spam.3" flyttas till "spam.4", så skrivs föregående "spam.4" alltid över och försvinner ur annalerna för alltid. Vi kan alltså klara det med ett enkelt move-kommando, "mv gamla_namnet nya_namnet.nummer". Starta editorn med ett lämpligt kommandonamn för skriptet, t.ex. "pico cirkulera" eller något annat som passar. Checka bara så skriptnamnet inte redan används av Unix. Fastnar ni pga detta, pröva med att skriva "q", "quit" eller "exit". Många interaktiva unix-kommando använder dessa ord för att avsluta. Ta kontroll över din spam med procmail del 2 Sida 2 Lars Magnusson - Får ej användas utan att källan anges

Låt oss de på ett basskript för cirkuleringen. När ni skrivit in det, spara skriptet och kör kommandot "chmod 700 cirkulera", så skriptet blir körbart. "chmod" eller change mode sätter rättigheter på filerna. "chmod" kan ges med både oktala värden som bokstäver för rättigheterna, men oktala värdet "700" är kombinationen som är lämpligast när ingen annan skall köra skriptet och är den jag använder på alla mina skript, liksom för själva bin-kataloget. ==== Cirkulera ====!/bin/sh * cirkulera Cirkulera brevlådor i katalogen /home/mitt-namn/mail ($HOME/mail) * cd $HOME/mail cd $HOME/tst /bin/mv f spam.3 spam.4 > /dev/null 2>&1 /bin/mv f spam.2 spam.3 > /dev/null 2>&1 /bin/mv f spam.1 spam.2 > /dev/null 2>&1 /bin/mv f spam spam.1 > /dev/null 2>&1 /bin/mv f mail.bup.3 mail.bup.4 > /dev/null 2>&1 /bin/mv f mail.bup.2 mail.bup.3 > /dev/null 2>&1 /bin/mv f mail.bup.1 mail.bup.2 > /dev/null 2>&1 /bin/mv f mail.bup mail.bup.1 > /dev/null 2>&1 ==================== För att förklara utseendet på skriptet, "!/bin/sh" överst talar om för mitt bash-skal med vilket Unix-skal skriptet skall köras. Vi väljer enklast tänkbara, Bourne, "/bin/sh". ""-raderna nedanför är rader med kommentarer, likt DOS "Rem"-rader. Sedan har jag som en ful vana att aldrig lita på var jag är i burken, så jag gör en förflyttning. Jag gör en "change directory" ("cd") till mitt mail-katalog med "cd $HOME/mail", där "$HOME" är mitt Unix-konto:s loginkatalog. Denna variabel sätts, när vi loggar in. Då detta är ett batchskript behöver jag heller inte bekymra mig om att kunna hoppa tillbaka till utgångspunkten. Processen dör så fort skriptet är färdigt. "/bin/mv" gör att "move"-kommandot "mv" inte använder sig av eventuella hängsle-livrem -alias i startfilen, att kommandot i vår ".kshrc", ".bashrc" eller ".cshrc"-fil angivits med ett alias med hängsel-livremflaggan "-i", som 'alias mv="mv i ". För er som sällan kör Unix, "-i" ihop med kommandona "mv" och "rm", frågar alltid användaren om denne verkligen skall skriva över/ta bort den existerande filen och väntar på ett "y" eller "n" innan det fortsätter. Men i ett skript som skall köra automatiskt vi vill undvika att fastna på sådana skydd mot mänskliga tabbar. Och "-f" står för force, "gör verkligen det här". Om ni sedan undrar över varför jag har "> /dev/null" sist på raderna, så sänds ev. skärmmeddelande från "move"-kommandot till stora soptunnan "/dev/null" (DOS " > NUL:"). Så långt tror jag de flesta känner igen sig, men "2>&1" betyder att även ev. felmeddelande går samma väg. Att jag gör så, är att de första fyra gångerna man kör skriptet eller om man tar bort någon av de 4 filerna, så kommer "mv" att skrika att den saknar filer. Då detta inte gör något, skickar jag ev felmeddelande permanent på soptippen. Det finns även andra möjligheter, men just nu lär vi oss krypa. Men varför behöver felmeddelande en eget "instruktion", "2>&1"? I Unix så sänds normala meddelande/utskrifter från program till skärmen via en "kanal" och Ta kontroll över din spam med procmail del 2 Sida 3 Lars Magnusson - Får ej användas utan att källan anges

felmeddelande via en annan. Vanliga meddelande går på "kanal 1", medan felmeddelande går på "kanal 2". Båda hamnar normalt på skärmen, men man kan skicka dem åt olika håll med redirection om så behövs. Kanal 1 pekas ut med ">" och ett filnamn och kanal 2 med "2>" + filnamn2. "2>&1" betyder alltså "kör ut kanal 2 på kanal 1", vilken vi redan skickat till den bottenlösa imaginära filen /dev/null. "2>&1" skall också alltid stå efter anvisningen för kanal 1. Sedan en varning! När ni vill testa skriptet, gör det inte med existerande spam och backup-filer, byt till ett testkatalog och skapa testfiler i testkataloget, t.ex. med "echo '' > spam.1". Därför finns en utkommenterad cd $HOME/tst innan jag kör, genom att flytta till mail-kataloget och att ha ett tst-katalog, med kopior av mailfilerna eller tomma dummy-filer, kan man tryggt testa. Efter 4 körningar har alla filerna flyttats runt och skrivits över, de tidigare generationerna har försvunnit. Provkör vi med orginalen, har dessa nu försvunnit för all framtid. Därav test-kataloget tst, som jag testar i. Behövs fler provkörningar, får vi köra "echo > filnamn " en gång till och skapa 4 nya testfiler. Sker det ofta, varför inte göra ett eget skript för att generera filerna ;-). - Tidsstyrning När vi så har ett fungerande skript skall det ju köras regelbundet. Detta kan vi göra med tidsstyrningskommandot "cron". Checka dock först vilken editor cron startar med genom att ge kommandot "echo $EDITOR" och se vad som är definierat. Oftast är det "vi" och det vill nog de flesta ändra på. Orsaken är att vi inte vill fastna i en oförståbar editor, som vi, när vi skapar tidstyrningen och får cron-kommandon att haverera för oss. Åter föreslår jag Pico för den ovane. Gör 'grep "EDITOR".profile.bashrc' med vidare och se var det står, "EDITOR=någonting". Om inget står där eller om det är fel editor, vill vi nog redigera startfilen och skriva in den editor vi vill ha. Det är viktigt att det efter "EDITOR=/usr/local/bin/pico" står "export EDITOR" (om det är här pico finns). Oftast finns en eller två långa exportrader i slutet av startfilens definitioner. Aktivera ändringen genom kommandot "../.profile" eller "../.bashrc", vilket betyder att "kör startfilen från nuvarande kommandolinje". Ändringarna slår igenom utan att vi behöver logga ur och in igen. Notera, "cron" kör oftast med en enklare $PATH än våra interaktiva skal, så ibland hittar den inte kommandon som inte finns i /bin och /usr/bin-katalogen, det är därför en god ide att ange fullständig path. Nu kan vi redigera vår "cron"-fil. Starta med "crontab -e" och lägga in tidsstyrningen på den första tomma linjen. Vi väljer att köra 30 minuter över 4 varje morgon, så vi inte stör övriga användare : 30 4 * * * /bin/sh /home/mxxxx/bin/cirkulera När vi sparar och går ur editorn, aktiveras tidsstyrningen. Crontab kör normalt med 24- timmarsklocka och de två första positionerna är minut och timma. De nästa två är dag i månaden (1-31) och månad (1-12), samt sista anger dag i veckan (0-6 med söndag = 0). "*" betecknar "varje dag". Om något går fel, får vi ett brev från cron, som mer eller mindre tydligt talar om vårt misstag. Om vi bara vill köra en gång i veckan, t.ex. måndag morgon, så skriver vi: 30 4 * * 1 /bin/sh /home/mxxxx/bin/cirkulera Själv har jag en del annat som skall göras och kör dagligen. Då "cron" tidigare var spärrat hos min ISP, så kör jag med något som heter "at" istället. "at" är egentligen för att köra enstaka jobb, så jag fick lära den att starta om sig själv. För att slippa ändra i själva körschemat har jag en batchkontrollskript, "autorun", som styr allt: ==== Autorun =====!/bin/sh ********** autorun Ta kontroll över din spam med procmail del 2 Sida 4 Lars Magnusson - Får ej användas utan att källan anges

För dagliga körningar kl 0430 kör vi skript vi har i vårt lokala bin-katalog ********** WTMP=$HOME/tmp DATUM="`date \"+%d%m%y\"`" RECV=xx.yy@jobbet Work Dir Hämta dag E-postadress för status $HOME/bin/cirkulera Kör cirkulering $HOME/bin/statistik $DATUM Gör statistik Mail s Mail-statistik, $DATUM $RECV < $WTMP/stat.$DATUM min lösning med att starta autorun at -s -f $BINDIR/autorun 4.30am tomorrow > /dev/null 2>&1 ================== Man kan naturligtvis göra autorun hur komplext som helst, detta exempel är förenklat. Själv har jag bl.a. en del analysfunktioner för de spam som Spamassassin, grålistning samt min.procmailrc släpper igenom. Vidare hämtar autorun e-post från andra konton jag med tiden har satt upp av någon anledning, rena specialbrevlådor. Jag har även en funktion som mailar en statuslogg från körningen av autorun till min huvudbrevlåda, dels för att ha check på att skriptet faktiskt kör, dels då jag vill se vilka nya brev eller falska positiva som dykt upp sedan gårdagen. Då behöver jag inte logga in och checka spambrevlådan för false positives varje dag, listan hjälper mig att identifiera ev. brev som kommit fel. Kommandot "Mail -H -f mail/spam.1 > statfil.mail" i skriptet "statistik" hjälper mig att göra en lista av de "spam" som kommit förbi spärrarna dagen innan. Jag använder gårdagens fil, för om jag listar dagens fil kan jag komma att missa sådant som inte kommit in när jag gör listan. Nedan har vi en statusfil från i våras. Där kan man notera att antalet nya mail och spam inte stämmer, jag har alltså fått en del "korrekta brev", men de syns först i nästa dags logg, som "New Mails". ===== Autorun logg ===== Yesterdays number of mails: 47 Following autorun jobs done (060209): New mails (15:13:37) : 1 isoc-members-annou [ISOC-members-announce] I 2 mailman-bounces@is isoc.se mailing list memb 3 SourceForge.net Te SOURCEFORGE.NET UPDATE - 4 =?UTF-8?Q?M=C3=A5n [medlemmar] Ny listserver 5 news-bounces@wysiw WYSIWYG NEWS, 3 February, *********** Total mails yesterday: 1 silicon Announceme Registration deadline app 2 darrell burth Fw: This fave outlet has 3 ³²¼ Ä\ [ABC-SPAMTAGGED] ======== 4 Young Oakley [ABC-SPAMTAGGED] Adult Mo 5 Katie Holmes [ABC-SPAMTAGGED] YOU WON.. 43 Oscar Crocker Under the Radar Equity fo 44 Josiah R. Goldstei OTC Platinum Report 45 Justin Barnett Look at the Chart on This Ta kontroll över din spam med procmail del 2 Sida 5 Lars Magnusson - Får ej användas utan att källan anges

46 Kurt J. Farmer Rising Star Stocks 47 Odell Castle SuperNova Stocks *********** Update: No update job 060209 Spam filter (15:13:37) : 1 comovs [ABC-SPAMTAGGED] ÈÈÑÀå½Ä 2 migsjälv@isp.se [ABC-SPAMTAGGED] PartyPok 3 Reginald Gipson [ABC-SPAMTAGGED] Best Pha 4 Brandon [ABC-SPAMTAGGED] Cheap Dr.. 37 Oscar Crocker Under the Radar Equity fo 38 Josiah R. Goldstei OTC Platinum Report 39 Justin Barnett Look at the Chart on This 40 Kurt J. Farmer Rising Star Stocks 41 Odell Castle SuperNova Stocks *********** Newspam filter : 15:13:37 : Ingen NewSpam! Runned jobs: : mlget Lock files blocking in /home/mig-själv/mail: 15:13:37 : Inga lock-filer! Mailjobs: Runned mailget job 060209 (15:13:37) : fetchmail: No mail for xxxxxx at pop.home.se fetchmail: No mail for xxxxxx@spray.se at lmpop.vip.spray.net ====== ***** End autorun ******** Den som undrar över "fetchmail", det är ett program för att hämta e-post från andra e-postkonton (pop eller imap-protokoll), för att sen sända dem till mitt huvud-kontot eller något annat konto. Korrigering av förra texten Efter att jag skrev förra texten, testade jag ett par udda problem med svenskspråkig e-post som givit mig viss huvudbry en längre tid. När jag testade, fann jag en sak som jag missat. I min rc-fil har jag regel med ett antal nyckelord för aktiespam. Denna regel innehåller ordet "stock". Naturligtvis fick den även träff på alla brev som innehöll ordet Stockholm. Men hur kunna behålla "stock", men släppa igenom "Stockholm". Det fanns dock en enkel lösning, som jag beskriver i detalj i den tredje text om karantänen, en "ifelse"-lösning. Men här är dock en snabb rättning. === Stockholms regeln === :0 B: *$.*stock { Ta kontroll över din spam med procmail del 2 Sida 6 Lars Magnusson - Får ej användas utan att källan anges

:0 B *$.*Stockholm { } } :0 E *$.*(stock invest...) $SPAM ========================= Regeln fångar alla ord med "stock" i sig och gör en if-else test. Om det står "Stockholm" så görs inget, annars om stock, invest mv. så läggs den i spamlådan (eller /dev/null). Om man får brev av samma typ, som triggar en fel spamregel, kan man behöva gör flera liknande regler. Sammanfattning Jag har nu kört antispam-funktioner i åtta år, varav tre år med min egen lösning och fyra år med min ISP:s, Spamassassin, grålistning och procmail, och min slutledning är att spam kan övervinnas. Stängde jag av procmail, skulle jag åter få ca 15-20 spam om dagen. Verktyg som Spamassassin och grålistning har gett en klar minskning av spam generellt sett, men den finns där fortfarande. Vanliga spamfilter är fortsatt inte perfekta, så vi måste för en överskådlig framtid fortfarande ha dessa extra antispamfunktioner. Om våra IT leverantörer tog större ansvar och hjälpte oss med liknande filtrering, så skulle kostnaden för spammarna öka så pass att deras kunder inte längre skulle finna spam ekonomiskt som marknadsföringsmetod. För det är dit vi måste komma, enda sättet att stoppa spam är att öka kostnaden. Beträffande funktionalitet var Earnest när jag lade ner utvecklingen på väg att bli en riktigt bra antispamfunktion. Men nu kör jag med min ISP:s standard och procmail, tillsammans är resultatet ändå så bra att jag är helt nöjd. Jag vet numer varför vissa riktiga brev hamnar som spam eller false positives och jag kan enkelt kontrollera spam-eländet. När mina matchningar blir sämre får jag ibland lägga till nya nyckelord från spammen i procmail-filen, oftast nya sätt att stava Viagra, pills m.fl. Men om man får in 2-3 spam i veckan av ca 15-20 totalt om dan och bommar på ett korrekt brev i veckan, så får man idag vara nöjd. Ta kontroll över din spam med procmail del 2 Sida 7 Lars Magnusson - Får ej användas utan att källan anges