Börja med den utvärderade identiteten
Uttalandet "vi publicerade -all , så mottagare måste avvisa identitetsstöld" kombinerar tre olika beslut. En domän publicerar en auktoriseringspolicy, en utvärderare erhåller en SPF resultat för en anslutande adress och identitet, och en mottagare bestämmer vad som ska göras med meddelandet. Att hålla dessa beslut åtskilda gör felsökningen mer exakt och förhindrar att en konfigurationsändring blir ett säkerhetslöfte som inte stöds.
SPF utvärderar HELO identitet eller den MAIL FRÅN identitet, inte bara adressen som visas i meddelandets Från-fält. Anteckna anslutningsadress, identitetstyp, utvärderad domän och tid innan du tolkar någon policy. Ett resultat för en leverantörs kuvertdomän beskriver inte automatiskt den synliga varumärkesdomänen. För en noll omvänd sökväg måste identitetshanteringen också fångas i stället för att gissas från en skärmdump. RFC 7208 , avsnitt 2.3 och 2.4
Vad all-mekanismen faktiskt gör
Alla mekanismer matchar alltid. Med minuskvalet misslyckas en nådd -all avkastning. Det uttalandet är exakt men villkorat: en tidigare matchningsmekanism kan avsluta utvärderingen först, och ett fel kan avbryta utvärderingen innan terminalmekanismen nås. Att kalla terminaltoken för en "hård avvisande switch" döljer båda villkoren. Dess betydelse är ett auktoriseringspåstående, inte ett kommando som körs i varje mottagares e-postsystem.
Mekanismer bearbetas i den angivna ordningen. En tillåten adress kan matcha en tidigare ip4- eller ip6-mekanism och producera pass utan att nå -all . En inkluderar kan också matcha. Omvänt kan en ogiltig policy eller uttömd utvärderingsbudget producera permerror istället för misslyckandet någon förväntade sig av att läsa den sista token. Postens sista tecken kan inte ersätta en faktisk utvärderingsväg. RFC 7208 , avsnitt 4.6, 5.1 och 8
Separera underordnade resultat från överordnade resultat
En inkludering är en rekursiv kontroll vars resultat mappas till den överordnade mekanismen. Det är inte text som klistrats in i föräldrapolicyn. Ett barnpass gör att inkluderingen matchar; ett barn misslyckas, softfail eller neutral gör att det inte matchar. Föräldern fortsätter sedan till nästa tillämpliga mekanism. Ett barn temperror eller permerror fortplantas som ett fel, medan ett barn none behandlas som permerror för include.
Detta har betydelse när en leverantör avslutar sin egen policy med -all . En avsändare som inte är auktoriserad av den leverantören sviker inte automatiskt hela kundens policy. En annan auktoriserad tjänst kan dyka upp senare i föräldraposten. Spara det underordnade resultatet och föräldrafortsättningen separat i diagnostikbladet. Annars kan en legitim multitjänstdesign felaktigt beskrivas som motsägelsefull eller trasig. RFC 7208 , avsnitt 5.2
Mottagarpolicy är ett annat bevislager
RFC 7208 beskriver misslyckande som ett uttryckligt uttalande om att klienten inte är behörig att använda domänen i den givna identiteten. Dess resultathanteringsvägledning överlåter dispositionen till mottagarens policy. En mottagare kan avvisa under SMTP , acceptera och markera, eller använda resultatet tillsammans med annan information. Den exakta åtgärden kan inte bevisas enbart av offentlig DNS . En godkännanderapport visar inte att den publicerade mekanismen ignorerades; det kan återspegla den utvärderade identiteten, en tidigare matchning eller mottagarens valda behandling.
Förvandla inte denna distinktion till råd att försvaga SPF urskillningslöst. En korrekt policy är fortfarande viktig. Inventera först legitima rutter, inklusive vidarebefordran och sändning från tredje part, särskilj sedan en auktoriseringsfelmatchning från den hantering som valts av en viss mottagare. Påståenden om DMARC behöver dessutom sin egen identitetsanpassning och policybevis. SPF fel i sig är inte en fullständig DMARC diagnos. RFC 7208 , avsnitt 8.4 och 10
Acceptans arbetsblad för en föreslagen granskning
Skapa en rad per auktoriserat meddelandeexempel, inte en rad per skärmdump. Fånga ruttens ägare, anslutningsadress, HELO namn, kuvertavsändare, utvärderad domän, exakt TXT post set, hämtningstid, parserversion och slutligt SPF resultat. Bifoga den ordnade mekanismvägen och förklara varför utvärderingen avbröts. Behåll mottagarens Authentication-Results förtroendegräns och härkomst separat från alla opålitliga rubriker som tillhandahålls av en avsändare.
Lägg till en andra del för disposition: SMTP svar om tillgängligt, mottagande system, tidsstämpel, kö- eller händelseidentifierare och om bevisen visar acceptans, avslag, karantän eller bara en ansökans status. Redigera onödiga mottagare och meddelandeinnehåll. En "levererad" status från en sändande applikation upprättar inte automatiskt placering i inkorgen. Markera otillgängliga fält som otillgängliga istället för att fylla i dem utifrån förväntningar.
Granskningen godkänner endast påståendet som faktiskt bevisats. En fullständig policyspårning kan stödja en SPF slutsats medan mottagarhanteringen förblir olöst. Ett SMTP avslag kan fastställa en viss transaktions resultat utan att bevisa att alla mottagare beter sig likadant. Registrera dessa två godkännandebeslut oberoende av varandra och behåll en ägare för saknade bevis.
Fiktiv diagnos: två tjänster och en terminal misslyckas
Tänk på en fiktiv organisation med en överordnad policy som kontrollerar en nyhetsbrevsleverantör, sedan en transaktionsleverantör och sedan -all . Ingen DNS efterfrågades och inget meddelande skickades för detta exempel. Nyhetsbrevet underordnade returer misslyckas för en transaktionsadress. Det korrekta nästa steget är att återuppta föräldern, inte förklara ett slutligt misslyckande. Om transaktionen inkluderar returer passerar, den ordinarie positiva inkluderar matchningar och moderreturerna passerar.
Föreställ dig nu en annan adress som inte matchar någon av leverantörerna. Om inget tidigare fel inträffar, når utvärderingen -all och returer misslyckas. Huruvida en viss mottagare avvisar det meddelandet är en separat observation. Ett stödmeddelande som säger att "leverantörens -all blockerade oss" skulle vara för tidigt i det första fallet och ofullständigt i det andra. Den användbara korrigeringen är att märka det underordnade resultatet, det överordnade resultatet och mottagaråtgärden separat.
Ett tredje hypotetiskt fall har ett tillfälligt DNS fel vid utvärdering av den första leverantören. Policyn kan inte diagnostiseras genom att hoppa direkt till final -all . Bevara felsökvägen och undvik att ändra posten bara för att tvinga fram en föredragen tolkning. Dessa exempel illustrerar endast resonemang; de är inte mottagna meddelandebevis eller testade resultat.
Publicering och operativa håller
Detta manuskript fastställer inte beteendet hos någon verklig avsändare eller mottagare. Innan du publicerar en driftdiagnos ska du skaffa de katalogkrävda resultatspecifika exemplen och deras DNS eller meddelandebevis genom ett auktoriserat arbetsflöde. En kvalificerad granskare bör inspektera hela vägen och bekräfta att mottagarbeviset tillhör samma transaktions- och tidsfönster.
Håll ändringar åtskilda från diagnos. Att ta bort en legitim tjänst, ändra kvalificeringar eller lägga till bred auktorisering kan påverka riktig post och kräver en egen granskning. Utkastets ursprungliga bevis, mänskliga expertis, källans tillämplighet, produktionsväg, visuella tillgänglighet och ägarens utsläppsportar förblir öppna. Ett fiktivt exempel är inte en ersättning för dessa portar, även när dess logik följer standarden.