Gör ombordstigningen till ett bevisspår, inte en rekordgenerator
En godkänd företagstjänst är inte automatiskt en godkänd domänkonfiguration. Ett team kan ha tillstånd att använda en e-postplattform medan de fortfarande behöver beslut om vilken hyresgäst, avsändaridentitet, DNS ändringar och destinationer för datadelning som är lämpliga. En agent kan organisera det arbetet, avslöja saknade förutsättningar och utarbeta ett exakt förändringsförslag. Det bör inte förvandla ett bekant leverantörsnamn till tillstånd att modifiera produktionen.
Detta är ett föreslaget arbetsflöde. Den hävdar inte att EmailAuth för närvarande implementerar tjänsteupptäckt, godkännandetillämpning, leverantörsanslutningar eller automatiserad verifiering. Dessa funktioner kräver aktuella produktbevis. Inget tjänstekonto, DNS zon, meddelandeström eller godkännandekontroll inspekterades eller ändrades för den här artikeln.
Identifiera företagstjänsten och dess ansvariga ägare
Börja med affärssyftet, ansvarigt team, godkänt leverantörskonto och avsedda meddelandekategorier. Registrera domänen eller underdomänen tjänsten kan använda, förväntad mottagarpopulation och den person som kan godkänna den omfattningen. En leverantörs infrastruktur kan delas av många kunder; en IP eller ett värdnamn som syns i en rapport är ett led att undersöka, inte ett bevis på att denna organisation auktoriserat avsändaren.
En agent kan jämföra en godkänd inventering med tillgängliga observationer och märka en eventuell matchning. Ägaren måste lösa oklarheter om den faktiska tjänsteinstansen. Håll bevis för matchen åtskilda från en självförtroendepoäng. RFC 9990 samlade rapporter tillhandahålla användbar autentisering och källinformation, men deras innehåll kan vara falskt och upprättar inte självständigt en kommersiell relation. RFC 9990 , avsnitt 3.1 och 8.2.
Sätt ihop förutsättningar utan att utöka åtkomsten
Samla in leverantörens nuvarande konfigurationsinstruktioner som stöds för den tjänsteinstansen, organisationens avsändarkrav och relevant befintlig konfiguration. Identifiera vilka delar som kan läsas under befintlig behörighet och vilka som kräver administratör. Att förbereda en inventering kräver inte att man samlar in lösenord eller privata nycklar i en agents konversation eller rapport.
Den föreslagna tillträdesgränsen bör tillåta agenten att endast inspektera den godkända hyresgästen och de resurser som behövs för uppgiften. En integration med breda skrivbehörigheter görs inte skrivskyddad bara för att uppmaningen ber om analys. OWASP:s vägledning för överdriven byrå rekommenderar att man begränsar både verktygsfunktioner och nedströmsbehörigheter. Verifiera den faktiska tillämpningen innan du använder en koppling i produktionen. OWASP Överdriven byrå.
Förhandsgranska identiteter och förändringar tillsammans
Förslaget ska koppla ihop den synliga författaredomänen, SPF identitet, DKIM signering av domän och leverantörskonto. Ett genererat TXT värde är bara en del av den relationen. DMARC utvärderar kvalificerade autentiserade identifierare och inriktning med Författardomänen; en leverantörs orelaterade standardsignatur justeras inte automatiskt. RFC 9989 , avsnitt 4.4.
Visa de exakta föreslagna ägarnamnen, posttyperna och värdena tillsammans med det observerade aktuella tillståndet. Förklara om en ändring lägger till en post med snäv omfattning, ändrar en befintlig avsändarbehörighet eller delegerar kontroll genom ett leverantörshanterat namn. Byt inte tyst ut en hel SPF rekord, bredda en domändelegering eller ta bort en annan avsändares väljare för att få en ny tjänst att passa. Varje verksamhet behöver en ansvarig godkännare och ett återvinningsbeslut.
Håll rapporteringssamtycke åtskilt från teknisk routing
Om onboarding föreslår en extern aggregatrapportdestination, identifiera vem som skulle ta emot rapporterna och varför. RFC 9990 definierar en DNS-baserad kontroll av externa rapporteringsarrangemang. Den tekniska bekräftelsen fastställer destinationens villighet att ta emot rapporter enligt protokollet; det ersätter inte organisationens godkännande att dela sina rapporteringsdata med den processorn. RFC 9990 , avsnitt 4.
Samma skillnad gäller för leverantörsåtkomst. En agent bör beskriva ett nödvändigt administrativt tillstånd innan någon beviljar det. Ett godkännande för att förbereda dokumentation tillåter inte beständig kontoåtkomst, skapande av autentiseringsuppgifter eller förändringar av flera hyresgäster. Om det stödda arbetsflödet behöver mer behörighet än vad agenten har, förblir förberedelsen användbar medan exekveringssteget förblir tilldelat den auktoriserade administratören.
Bind godkännande till själva förslaget
Ett användbart godkännande identifierar tjänsteinstansen, hyresgästen, domänen, exakta ändringar och relevant ögonblicksbild av aktuellt tillstånd. Om dessa fakta ändras innan verkställandet, returnera den berörda ändringen för granskning istället för att behandla ett gammalt godkännande som en allmän licens. Utförandemekanismen bör verifiera den godkännande aktörens auktoritet och den begärda omfattningen oberoende av modellens förklaring. OWASP auktorisation fuskblad.
Överväg en fiktiv kvittotjänst med notices.example . Dess företagsägare godkänner kundkvitton, medan DNS administratören granskar en föreslagen leverantörsspecifik väljare. Det godkännandet skulle inte omfatta att lägga till ytterligare en hyresgäst, omdirigera rapporter till en byrå eller ändra den överordnade domänens DMARC policy. Det här exemplet innehåller inga faktiska leverantörsvärden och visar inte att en godkännandekontroll finns eller fungerar.
Verifiera ett riktigt meddelande innan överlämnandet
Det planerade acceptanstestet bör använda en auktoriserad mottagare och ett meddelande från den faktiska tjänsten, inte bara en DNS checkare. Fånga avsändarens identiteter, vald signatur, betrodda mottagare-tillagda autentiseringsresultat och observerad leveransdisposition. Autentiseringsbevis måste tolkas inom mottagarens förtroendegräns, snarare än tas från någon fördelaktig rubrik som tillhandahålls med meddelandet. RFC 8601 , avsnitt 7.
En slutlig SMTP acceptans är en transportöverlämning, inte bevis på placering av inkorgen eller framgångsrik affärsbearbetning. Håll dessa resultat åtskilda. Överlämning bör identifiera konfigurationsägare, bevarade bevis, ändringsberoenden, övervakningsansvar och den godkända återställningsvägen. Ett olöst anpassningsresultat är en blockerare för det angivna acceptanskriteriet, inte en anledning att deklarera slutförande eftersom DNS värdet sparades. RFC 5321 , avsnitt 4.2.5.
Driftsättningsbevis krävs fortfarande
Kör en godkänd tjänst genom förutsättningskontroller, förhandsgranskning av ändringar, verifiering och överlämning. Detta exakta krav förblir öppet. Arbetsflödet och kartan är dokumentär förberedelse. Verklig tjänstidentitet, aktuell leverantörs tillämplighet, godkännandetillämpning, verkställd ändring, resultat av verkliga meddelanden och överlämnandebevis måste samlas in innan man hävdar att onboarding har visats.