Avsändarpolicyram

Sender Policy Framework ( SPF ) är en e-postautentiseringsmetod utformad för att upptäcka förfalskade avsändaradresser under leveransen av e-postmeddelandet. Enbart SPF är dock begränsad till att upptäcka ett förfalskat avsändaranspråk i e-postkuvertet, som används när posten studsas. Endast i kombination med DMARC kan den användas för att upptäcka förfalskning av den synliga avsändaren i e-postmeddelanden ( e-postspoofing ), en teknik som ofta används vid nätfiske och e-postspam .

SPF tillåter den mottagande e-postservern att under e-postleverans kontrollera att ett e-postmeddelande som påstår sig komma från en specifik domän skickas av en IP-adress som godkänts av den domänens administratörer. Listan över auktoriserade sändningsvärdar och IP-adresser för en domän publiceras i DNS- posterna för den domänen.

Sender Policy Framework definieras i RFC 7208 daterad april 2014 som en "föreslagen standard".

Historia

Det första offentliga omnämnandet av konceptet var år 2000 men gick mestadels obemärkt förbi. Inget nämnde konceptet igen förrän ett första försök med en SPF-liknande specifikation publicerades 2002 på IETF: s "namedroppers" e-postlista av Dana Valerie Reese, som inte var medveten om 2000 års omnämnande av idén. Redan nästa dag Paul Vixie upp sin egen SPF-liknande specifikation på samma lista. Dessa inlägg väckte stort intresse, ledde till bildandet av IETF Anti-Spam Research Group (ASRG) och deras e-postlista, där SPF-idén vidareutvecklades. Bland förslagen som lämnades in till ASRG var "Reverse MX " (RMX) av Hadmut Danisch och "Designated Mailer Protocol" (DMP) av Gordon Fecyk.

I juni 2003 slog Meng Weng Wong ihop RMX- och DMP-specifikationerna och bad om förslag från andra. Under de kommande sex månaderna gjordes ett stort antal förändringar och ett stort community hade börjat arbeta med SPF. Ursprungligen stod SPF för Sender Permitted From och kallades ibland också SMTP+SPF ; men dess namn ändrades till Sender Policy Framework i februari 2004.

I början av 2004 skapade IETF MARID- arbetsgruppen och försökte använda SPF och Microsofts CallerID-förslag som grund för det som nu är känt som Sender ID ; men detta kollapsade på grund av tekniska konflikter och licenskonflikter.

SPF-gemenskapen återgick till den ursprungliga "klassiska" versionen av SPF. I juli 2005 godkändes den här versionen av specifikationen av IESG som ett IETF- experiment , vilket uppmanade samhället att observera SPF under de två åren efter publiceringen. Den 28 april 2006 publicerades SPF RFC som experimentell RFC 4408.

I april 2014 publicerade IETF SPF i RFC 7208 som en "föreslagen standard".

Funktionsprinciper

Simple Mail Transfer Protocol tillåter vilken dator som helst att skicka e-post som påstår sig vara från valfri källadress. Detta utnyttjas av spammare och bedragare som ofta använder förfalskade e-postadresser , vilket gör det svårare att spåra ett meddelande tillbaka till dess källa och lätt för spammare att dölja sin identitet för att undvika ansvar. Det används också i nätfisketekniker , där användare kan luras att avslöja privat information som svar på ett e-postmeddelande som påstås skickas av en organisation som en bank.

SPF tillåter ägaren av en internetdomän att ange vilka datorer som är auktoriserade att skicka e-post med kuvert-från-adresser i den domänen, med hjälp av DNS-poster ( Domain Name System) . Mottagare som verifierar SPF-informationen i TXT-poster kan avvisa meddelanden från obehöriga källor innan de tar emot meddelandets brödtext. Funktionsprinciperna liknar alltså de för DNS-baserade svarthålslistor ( DNSBL ), förutom att SPF använder behörighetsdelegeringsschemat för domännamnssystemet. Nuvarande praxis kräver användning av TXT-poster, precis som tidiga implementeringar gjorde. Ett tag registrerades en ny posttyp (SPF, typ 99) och gjordes tillgänglig i vanliga DNS-program. Användning av TXT-poster för SPF var tänkt som en övergångsmekanism vid den tiden. Den experimentella RFC, RFC 4408, avsnitt 3.1.1, föreslog "ett SPF-kompatibelt domännamn BÖR ha SPF-poster av båda RR-typerna". Den föreslagna standarden, RFC 7208, säger att "användning av alternativa DNS RR-typer stöddes i SPF:s experimentella fas men har avbrutits".

Envelope-from-adressen sänds i början av SMTP-dialogrutan. Om servern avvisar domänen bör den obehöriga klienten få ett avvisningsmeddelande, och om den klienten var en relaying message transfer agent (MTA), kan ett avvisningsmeddelande till den ursprungliga kuvert-från-adressen genereras. Om servern accepterar domänen och därefter även accepterar mottagarna och meddelandets brödtext, bör den infoga ett retursökvägsfält i meddelandehuvudet för att spara kuvertet-från-adressen. Även om adressen i retursökvägen ofta matchar andra avsändaradresser i e-posthuvudet, såsom rubriken- från , är detta inte nödvändigtvis fallet, och SPF förhindrar inte förfalskning av dessa andra adresser, såsom avsändarhuvudet .

Spammare kan skicka e-post med ett SPF PASS-resultat om de har ett konto på en domän med en avsändarpolicy, eller missbrukar ett inträngt system på denna domän. Men att göra det gör det lättare att spåra spammaren.

Den största fördelen med SPF är för ägarna av e-postadresser som är förfalskade i returvägen. De får ett stort antal oönskade felmeddelanden och andra autosvar. Om sådana mottagare använder SPF för att specificera sina legitima käll-IP-adresser och indikera FAIL-resultat för alla andra adresser, kan mottagare som kontrollerar SPF avvisa förfalskningar och på så sätt minska eller eliminera mängden backscatter .

SPF har potentiella fördelar utöver att hjälpa till att identifiera oönskad e-post. I synnerhet, om en avsändare tillhandahåller SPF-information, kan mottagare använda SPF PASS-resultat i kombination med en tillåtelselista för att identifiera kända pålitliga avsändare. Scenarier som komprometterade system och delade sändande e-postmeddelanden begränsar denna användning.

Skäl att genomföra

Om en domän publicerar en SPF-post är det mindre sannolikt att spammare och nätfiskare förfalskar e-postmeddelanden som låtsas vara från den domänen, eftersom de förfalskade e-postmeddelandena är mer benägna att fångas i spamfilter som kontrollerar SPF-posten. Därför är en SPF-skyddad domän mindre attraktiv för spammare och nätfiskare. Eftersom en SPF-skyddad domän är mindre attraktiv som en falsk adress, är det mindre sannolikt att den förnekas av skräppostfilter och så i slutändan är det mer sannolikt att den legitima e-posten från domänen kommer igenom.

FAIL och vidarebefordran

SPF bryter vanlig vidarebefordran av meddelanden . När en domän publicerar en SPF FAIL-policy kan legitima meddelanden som skickas till mottagare som vidarebefordrar sin e-post till tredje part avvisas och/eller studsas om allt av följande inträffar:

Speditören skriver inte om returvägen , till skillnad från e-postlistor.
Nästa hopp tillåter inte speditören.
Denna hop kontrollerar SPF.

Detta är en nödvändig och uppenbar egenskap hos SPF – kontroller bakom "gränsen" MTA ( MX ) på mottagaren kan inte fungera direkt.

Utgivare av SPF FAIL-policyer måste acceptera risken för att deras legitima e-postmeddelanden avvisas eller studsas. De bör testa (t.ex. med en SOFTFAIL-policy) tills de är nöjda med resultaten. Se nedan för en lista över alternativ till vanlig vidarebefordran av meddelanden.

HELO tester

För en tom retursökväg som används i felmeddelanden och andra autosvar är en SPF-kontroll av HELO -identiteten obligatorisk.

Med en falsk HELO-identitet skulle resultatet NONE inte hjälpa, men för giltiga värdnamn skyddar SPF också HELO-identiteten. Denna SPF-funktion stöddes alltid som ett alternativ för mottagare, och senare SPF-utkast inklusive den slutliga specifikationen rekommenderar att alltid kontrollera HELO.

Detta gör det möjligt för mottagare att godkänna e-postmeddelanden baserat på ett HELO PASS, eller att avvisa alla e-postmeddelanden efter ett HELO FAIL. Den kan också användas i ryktesystem (alla tillåta eller neka lista är ett enkelt fall av ett ryktesystem).

Genomförande

Efterlevnad av SPF består av tre löst relaterade uppgifter:

Publicera en policy : Domäner och värdar identifierar de maskiner som är behöriga att skicka e-post för deras räkning. De gör detta genom att lägga till ytterligare poster till sin befintliga DNS-information: varje domännamn eller värd som har en A-post eller MX-post bör ha en SPF-post som anger policyn om den används antingen i en e-postadress eller som HELO/EHLO-argument. Värdar som inte skickar e-post bör ha en SPF-post publicerad som indikerar sådan ("v=spf1 -all").
Kontrollera och använda SPF-information : Mottagare använder vanliga DNS-frågor, som vanligtvis cachelagras för att förbättra prestandan. Mottagarna tolkar sedan SPF-informationen som specificerad och agerar på resultatet.
Revidering av vidarebefordran av post : Vidarebefordran av vanlig post är inte tillåten av SPF. Alternativen är:
- Remailing (dvs. ersätta den ursprungliga avsändaren med en som tillhör den lokala domänen)
- Vägra (t.ex. svara på 551 Användaren är inte lokal; försök <[email protected]> )
- Tillåtelselista på målservern så att den inte vägrar ett vidarebefordrat meddelande
- Sender Rewriting Scheme , en mer komplicerad mekanism som hanterar routing av meddelanden om utebliven leverans till den ursprungliga avsändaren

Därför är nyckelfrågan i SPF specifikationen för den nya DNS-informationen som domäner och mottagare använder. Posterna nedan är i typisk DNS-syntax, till exempel:

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

"v=" definierar vilken version av SPF som används. Följande ord tillhandahåller mekanismer att använda för att avgöra om en domän är kvalificerad att skicka e-post. "ip4" och "a" anger vilka system som är tillåtna att skicka meddelanden för den givna domänen. "-all" i slutet anger att om de tidigare mekanismerna inte matchade, ska meddelandet avvisas.

Mekanismer

Åtta mekanismer definieras:

ALLT	Matchar alltid; används för ett standardresultat som `-all` för alla IP-adresser som inte matchas av tidigare mekanismer.
A	Om domännamnet har en adresspost (A eller AAAA) som kan lösas till avsändarens adress kommer den att matcha.
IP4	Om avsändaren är inom ett givet IPv4- adressintervall, matcha.
IP6	Om avsändaren är inom ett givet IPv6- adressintervall, matcha.
MX	Om domännamnet har en MX-post som löser sig till avsändarens adress kommer den att matcha (dvs. posten kommer från en av domänens inkommande e-postservrar).
PTR	Om domännamnet ( PTR-post ) för klientens adress finns i den givna domänen och det domännamnet löser sig till klientens adress ( vidarebekräftad omvänd DNS ), matcha. Denna mekanism avråds från och bör undvikas, om möjligt.
EXISTERAR	Om det givna domännamnet löser sig till någon adress, matcha (oavsett vilken adress det löser sig till). Detta används sällan. Tillsammans med SPF-makrospråket erbjuder det mer komplexa matchningar som DNSBL -frågor.
OMFATTA	Refererar till policyn för en annan domän. Om domänens policy går igenom, godkänns denna mekanism. Men om den inkluderade policyn misslyckas fortsätter behandlingen. För att helt delegera till en annan domäns policy omdirigeringstillägget användas.

Kval

Varje mekanism kan kombineras med en av fyra kvalificeringar :

+ för ett PASS-resultat. Detta kan utelämnas; t.ex. +mx är samma som mx .
? för ett NEUTRALT resultat tolkat som INGEN (ingen policy).
~ (tilde) för SOFTFAIL, ett felsökningshjälpmedel mellan NEUTRAL och FAIL. Vanligtvis accepteras meddelanden som returnerar en SOFTFAIL men taggas.
- (minus) för FAIL, posten ska avvisas (se nedan).

Modifierare

Modifierarna möjliggör framtida förlängningar av ramverket . Hittills har endast de två modifierarna som definierats i RFC 4408 blivit allmänt distribuerade:

exp=some.example.com ger namnet på en domän med en DNS TXT-post (tolkad med SPF:s makrospråk) för att få en förklaring till FAIL-resultat – vanligtvis en URL som läggs till i SMTP-felkoden. Denna funktion används sällan.
redirect=some.example.com kan användas istället för ALL- mekanismen för att länka till policyposten för en annan domän. Denna modifierare är lättare att förstå än den något liknande INCLUDE- mekanismen .

Felhantering

Så snart SPF-implementeringar upptäcker syntaxfel i en avsändarpolicy måste de avbryta utvärderingen med resultatet PERMERROR. Att hoppa över felaktiga mekanismer kan inte fungera som förväntat, därför kan inkludera:bad.example och redirect=bad.example också orsaka en PERMERROR.

En annan skyddsåtgärd är maximalt tio mekanismer som frågar efter DNS, dvs vilken mekanism som helst förutom IP4, IP6 och ALL. Implementeringar kan avbryta utvärderingen med resultatet TEMPERROR när det tar för lång tid eller en DNS-fråga tar slut eller så kan de fortsätta att låtsas som att frågan inte returnerade någon data — vilket kallas en "void lookup". De måste dock returnera PERMERROR om policyn direkt eller indirekt behöver mer än tio frågor om mekanismer . Dessutom bör de returnera PERMERROR så snart mer än två "void lookups" har påträffats. Eventuell omdirigering= räknas också mot dessa bearbetningsgränser .

En typisk SPF HELO-policy v=spf1 a mx ip4:192.0.2.0 -all kan köra fyra eller fler DNS-förfrågningar: (1) TXT-post (SPF-typen var föråldrad av RFC 7208), (2) A eller AAAA för mekanism a , (3) MX-post och (4+) A eller AAAA för varje MX-namn, för mekanism mx . Förutom den första, räknas alla dessa frågor mot gränsen på 10. Dessutom, om till exempel avsändaren har en IPv6-adress, medan dess namn och dess två MX-namn bara har IPv4-adresser, då utvärderingen av de två första mekanismerna resulterar redan i mer än två void-uppslagningar och därmed PERMERROR. Observera att mekanismerna ip4 , ip6 och alla behöver ingen DNS-sökning.

frågor

DNS SPF-poster

För att möjliggöra snabb testning och distribution kontrollerade initiala versioner av SPF efter dess inställning i DNS TXT-posten för den sändande domänen - även om denna post traditionellt var tänkt att vara fritext utan semantik. Även om IANA i juli 2005 tilldelade en specifik resurspost typ 99 till SPF var upptaget av aldrig högt, och att ha två mekanismer var förvirrande för användarna. 2014 avbröts användningen av denna post efter att SPFbis-arbetsgruppen kommit fram till att "...betydande migrering till SPF RR-typen inom överskådlig framtid var mycket osannolik och att den bästa lösningen för att lösa detta interoperabilitetsproblem var att släppa stödet för SPF RR typ."

Rubrikbegränsningar

Eftersom SPF i allt högre grad förhindrar spammare från att förfalska kuvert-från-adressen, har många flyttat till att endast förfalska adressen i fältet Från i e-posthuvudet, som faktiskt visas för mottagaren snarare än att endast behandlas av mottagarens meddelandeöverföringsagent (MTA ) . . SPF (eller DKIM ) kan dock användas tillsammans med DMARC , för att även kontrollera fältet Från i e-posthuvudet. Detta kallas 'identifier alignment'.

Anpassade proprietära implementeringar krävs för att skydda mot sådan förfalskning av visningsnamn och kan inte använda SPF.

Spridning

Anti-spam programvara som SpamAssassin version 3.0.0 och ASSP implementerar SPF. Många e-postöverföringsagenter (MTA) stöder SPF direkt som Courier , CommuniGate Pro, Wildcat , MDaemon och Microsoft Exchange , eller har patchar eller plugin-program tillgängliga som stöder SPF, inklusive Postfix , Sendmail , Exim , qmail och Qpsmtpd . Från och med 2017 publicerar mer än åtta miljoner domäner SPF FAIL -alla policyer. I en undersökning publicerad 2007 hade 5 % av .com- och .net -domänerna någon form av SPF-policy. Under 2009 rapporterade en kontinuerlig undersökning på Nokia Research att 51 % av de testade domänerna anger en SPF-policy. Dessa resultat kan inkludera triviala policyer som v=spf1 ?all . ^{[ behöver uppdateras ]}

I april 2007 publicerade BITS, en avdelning av Financial Services Roundtable, e-postsäkerhetsrekommendationer för sina medlemmar, inklusive SPF-distribution. År 2008 publicerade MAAWG (Messaging Anti-Abuse Working Group) en artikel om e-postautentisering som täcker SPF, Sender ID och DomainKeys Identified Mail (DKIM). I sina "Sender Best Communication Practices" sa MAAWG: "Åtminstone bör avsändare införliva SPF-poster för sina e-postdomäner". Under 2015 reviderade Messaging Anti-Abuse Working Group (MAAWG) ett dokument om e-postautentisering som täcker SPF, DomainKeys Identified Mail (DKIM) och DMARC (DMARC). I sin reviderade "Sender Best Communication Practices" sa MAAWG: "Autentisering stöder transparens genom att ytterligare identifiera avsändaren(arna) av ett meddelande, samtidigt som det bidrar till att minska eller eliminera falska och förfalskade adresser".

Se även

externa länkar

IETF RFC4408: Sender Policy Framework (SPF) för auktorisering av användning av domäner i e-post, version 1 EXPERIMENTAL ( 2006)
IETF RFC6652: Avsändarpolicyramverk (SPF) Autentiseringsfelrapportering med användning av missbruksrapporteringsformatet, FÖRESLAGEN STANDARD ( 2012)
IETF RFC7208: Sender Policy Framework (SPF) för auktorisering av användning av domäner i e-post, version 1, FÖRESLAGEN STANDARD ( 2014)
libspf2 – En öppen källkodsimplementering av SPF-protokollet ( 2010)
https://senderpolicyframework.com/ och https://www.spfwizard.net/ (verktyg för generering, validering och konfiguration av SPF-posten)