Grålistning (e-post)
Grålistning är en metod för att skydda e-postanvändare mot skräppost . En e-postöverföringsagent (MTA) som använder grålistning kommer "tillfälligt att avvisa" alla e-postmeddelanden från en avsändare som den inte känner igen. Om e-posten är legitim kommer ursprungsservern att försöka igen efter en fördröjning, och om tillräckligt med tid har förflutit kommer e-postmeddelandet att accepteras.
Hur det fungerar
En server som använder grålistning avvisar tillfälligt e-post från okända eller misstänkta källor genom att skicka 4xx-svarskoder ("ring tillbaka senare"), enligt definitionen i Simple Mail Transfer Protocol (SMTP). Fullt kapabla SMTP-implementeringar förväntas upprätthålla köer för att försöka skicka meddelanden igen i sådana fall, och även om legitim post kan försenas, bör den ändå komma igenom.
Det tillfälliga avslaget kan utfärdas i olika skeden av SMTP-dialogen, vilket gör att en implementering kan lagra mer eller mindre data om det inkommande meddelandet. Avvägningen är mer arbete och bandbredd för mer exakt matchning av försök med originalmeddelanden. Att avvisa ett meddelande efter att dess innehåll har mottagits tillåter servern att lagra ett urval av rubriker och/eller en hash av meddelandetexten.
Förutom att vitlista bra avsändare kan en grålista ge undantag . Grålistning kan i allmänhet åsidosättas av en fullt validerad TLS-anslutning med ett matchande certifikat. Eftersom stora avsändare ofta har en pool av maskiner som kan skicka (och återsända) e-post, behandlas IP-adresser som har de mest signifikanta 24 bitarna (/24) som likvärdiga, eller i vissa fall används SPF-poster för att fastställa sändande pool. På liknande sätt använder vissa e-postsystem unika returvägar per meddelande, till exempel variabel envelope return path (VERP) för e-postlistor, Sender Rewriting Scheme för vidarebefordrad e-post, Bounce Address Tag Validation för backscatter-skydd, etc. Om en exakt matchning på avsändaradressen krävs, varje e-postmeddelande från sådana system kommer att försenas. Vissa grålistningssystem försöker undvika denna fördröjning genom att eliminera de variabla delarna av VERP genom att endast använda avsändardomänen och början av den lokala delen av avsändaradressen.
Grålistning är effektivt mot mass-e-postverktyg som används av spammare som inte ställer sig i kö och försöker igen postleverans som en vanlig posttransportagent normalt gör. Att försena leveransen ger också svarthålslistor i realtid och liknande listor tid att identifiera och flagga skräppostkällan. Det är därför mer sannolikt att dessa efterföljande försök upptäcks som skräppost av andra mekanismer än de var före grålistningsfördröjningen.
Fördelar
Den största fördelen ur användarens synvinkel är att grålistning inte kräver någon ytterligare användarkonfiguration. Om servern som använder grålistning är korrekt konfigurerad kommer slutanvändaren bara att märka en fördröjning på det första meddelandet från en given avsändare, så länge som den sändande e-postservern identifieras som tillhörande samma vitlistade grupp som tidigare meddelanden. Om e-post från samma avsändare upprepade gånger är grålistad kan det vara värt att kontakta e-postsystemets administratör med detaljerade rubriker för försenad e-post.
Ur en postadministratörs synvinkel är fördelen dubbel. Grålistning kräver minimal konfiguration för att komma igång med enstaka ändringar av lokala vitlistor. Den andra fördelen är att det är mycket billigt i systemresurser att avvisa e-post med ett tillfälligt 451-fel (faktisk felkod är implementeringsberoende). De flesta skräppostfiltreringsverktyg är mycket intensiva användare av CPU och minne. Genom att stoppa spam innan den når filtreringsprocesser används mycket färre systemresurser.
Nackdelar
Försenade leveransproblem
Den största nackdelen med grålistning är att för okända servrar, det förstör den nästan omedelbara karaktären hos e-post som användare har kommit att förvänta sig. E-post från okända servrar är vanligtvis försenade med cirka 15 minuter och kan försenas upp till några dagar för dåligt konfigurerade sändningssystem. Att förklara detta för användare som har vant sig vid omedelbar e-postleverans kommer förmodligen inte att övertyga dem om att en e-postserver som använder grålistning beter sig korrekt.
Detta kan vara ett särskilt problem med webbplatser som kräver att ett konto skapas och e-postadressen bekräftas innan de kan användas – eller när en användare av en e-postserver med grålista försöker återställa sina autentiseringsuppgifter på en webbplats som använder e-postbekräftelse av lösenordsåterställning. Om den sändande MTA för webbplatsen är dåligt konfigurerad, kan grålistning försena den första e-postlänken. I extrema fall kan leveransfördröjningen som utövas av grålistan överstiga utgångstiden för lösenordsåterställningstoken som levereras i e-post. I dessa fall kan manuellt ingripande krävas för att vitlista webbplatsens e-postserver så att e-postmeddelandet som innehåller återställningstoken kan användas innan det löper ut.
När en e-postserver är grålistad är tidslängden mellan den initiala fördröjningen och återsändningen variabel; grålistningsservern har ingen kontroll eller synlighet av fördröjningen. SMTP säger att försöksintervallet bör vara minst 30 minuter, medan uppgivandetiden måste vara minst 4–5 dagar; men de faktiska värdena varierar kraftigt mellan olika e-postserverprogram.
Moderna grålistningsapplikationer (som Postgrey för Unix-liknande operativsystem) vitlistar automatiskt avsändare som visar sig kunna återhämta sig från tillfälliga fel, oavsett avsändarens ansedda skräppost .
Implementering inkluderar vanligtvis också möjligheten att manuellt vitlista vissa e-postservrar.
En analys från 2007 av grålistning anser att det är totalt oönskat på grund av förseningen av post, och opålitligt eftersom, om grålistning blir utbredd, kan skräppostavsändare anpassa sina system för att komma runt det. Slutsatsen är att syftet med grålistning är att minska mängden skräppost som serverns spam-filtreringsprogram behöver för att analysera, resurskrävande och spara pengar på servrar, inte för att minska spam som når användarna. Slutsatsen: "[Greylisting] är väldigt, väldigt irriterande. Mycket mer irriterande än spam."
Andra problem
Den nuvarande SMTP-specifikationen (RFC 5321) anger tydligt att "SMTP-klienten behåller ansvaret för leveransen av det meddelandet" (avsnitt 4.2.5) och "e-post som inte kan överföras omedelbart MÅSTE ställas i kö och regelbundet testas av avsändaren." (avsnitt 4.5.4.1). De flesta MTA:er kommer därför att köa och försöka igen meddelanden, men ett litet antal gör det inte. Dessa hanteras vanligtvis av vitlistor eller undantagslistor.
Dessutom kanske legitim e-post inte levereras om försöket kommer från en annan IP-adress än det ursprungliga försöket. När källan till ett e-postmeddelande är en serverfarm eller går ut genom någon annan typ av relätjänst, är det troligt att en annan server än den ursprungliga kommer att göra nästa försök. För nätverksfeltolerans kan deras IP-adresser tillhöra helt orelaterade adressblock, och därmed trotsa den enkla tekniken att identifiera den mest betydande delen av adressen. Eftersom IP-adresserna kommer att vara olika, kommer mottagarens server att misslyckas med att upptäcka att en serie försök är relaterade, och vägra vart och ett av dem i sin tur. Detta kan fortsätta tills meddelandet åldras ur kön om antalet servrar är tillräckligt stort. Detta problem kan delvis kringgås genom att proaktivt identifiera sådana serverfarmar som undantag. På samma sätt måste undantag konfigureras för multihomed-värdar och värdar som använder DHCP . I extremfallet kan en avsändare (legitimt) använda en annan IPv6 -adress för varje utgående SMTP-anslutning.
En avsändarserver som utsätts för grålistning kan också återförsöka leverans till en annan mottagande e-postserver om den mottagande domänen har mer än en MX-post. Detta kan orsaka problem om alla sådana värdar inte implementerar samma grålistningspolicy och delar samma databas.
Se även
externa länkar
- Ett vitt papper med grålista av Evan Harris
- En grålistningsimplementering för netqmail
- Microsoft Exchange-grålistningsproblem - nyhetsgruppsartikel
- RFC 6647 från Internet Engineering Task Force, juni 2012: Standardiserar den aktuella tekniken