Ett meddelande kan använda en välbekant Från-adress medan du skickar svar någon annanstans. Den skillnaden kan vara legitim, till exempel en biljetttjänst, eller så kan den omdirigera en känslig konversation. Undersök de faktiska fälten och den mottagande förtroendegränsen innan du kallar missmatchningen för en attack eller behandla autentisering som ett godkännande av svarsdestinationen.
Förstå fältets roll
RFC 5322 beskriver Reply-To som den eller de brevlådor som författaren föreslår att svar ska skickas till. I sin frånvaro går svaren normalt till brevlådan Från. Detta är en instruktion i meddelandeformat, skild från SMTP kuvertleverans och skild från ett mänskligt godkännandebeslut. Klienter och arbetsflödesverktyg kan tillämpa sitt eget svarsbeteende, så inspektera den faktiska mottagaren innan du skickar ett känsligt svar. RFC 5322 avsnitt 3.6.2.
DMARC använder författarens domän, inte fältet Svara till, för sin identitetsrelation. Ett pass bekräftar därför inte att en annan Svara-till-domän tillhör samma organisation. En giltig DKIM signatur kan täcka Reply-To när det fältet ingår i signaturens undertecknade rubriklista, men integriteten för ett värde är inte tillåten att använda det för konfidentiell korrespondens. DMARC och DKIM.
Anteckna originalet istället för en skärmdump
Behåll råmeddelandebytes. Skapa en separat anteckning som visar From, Reply-To, Return-Path, DKIM d= and h= values, and the receiving system that produced Authentication-Results. Markera Från och Svara-Till som avsändare tillhandahållna fält, DKIM -signaturen som ett påstående som kräver verifiering och autentiseringsresultat som betrodda först när deras ursprung har fastställts. RFC 8601.
Anta inte att en kopierad Authentication-Results är äkta. På samma sätt bevisar inte ett Return-Path i en godtyckligt sparad textfil oberoende SMTP kuvertet. Korrelera med auktoriserade mottagningsloggar där det behövs.
Jämför tre scenarier med skrivhuvud
Antag synlig från billing@supplier.example.test i varje fall. Kuvertidentitet, DKIM d= och h= värden, faktiska signaturer och betrodda mottagarresultat tillhandahålls inte. Ett kopierat godkänt påstående kan inte fylla dessa luckor.
- Oväntad väg: Reply-To case@support.example.test ; inget arbetsflödesgodkännande tillhandahålls. Flagga den olika exakta domänen för granskning, håll känsliga svar och fråga tjänsteägaren via en känd kanal.
- Samma domän rutt: Svara-till help@supplier.example.test . En regel för exakt domänfelmatchning skulle inte flagga den, men detta är inte ett bevis på att brevlådan eller begärd information är auktoriserad.
- Omfattat undantag: Reply-To case@tickets.example.test ; anta att en fiktiv inventering endast tillåter denna tjänst för rutinmässiga supportbiljetter. Behandla det som förväntat för det ändamålet, inte tillstånd till betalningsändringar eller konfidentiella dokument.
Dessa exempel är skrivna värden och beslut, inte en inkluderad .eml-fil, parserkörning eller verkligt autentiseringsresultat. Ingen DKIM signatur är tillverkad. Den föreslagna tjänsteägaren verifierar både mottagarens och tillåten information innan ett verkligt svar; e-postutredaren erhåller separat originalbytes och betrodda autentiseringsbevis.
Verifiera svarsdestinationen mot arbetsflödet
Fråga tjänsteägaren om den externa destinationen förväntas för denna meddelandetyp och om den är lämplig för den föreslagna informationen. En supportbrevlåda kan legitimt skilja sig från en faktureringsavsändare, men ändå vara olämplig för betalningsinstruktioner eller känsliga bilagor. Godkännandet bör matcha syftet, inte bara domänens existens.
För oväntade förfrågningar, kontakta den förmodade avsändaren via en känd oberoende kanal. Testa inte en tvivelaktig destination genom att e-posta konfidentiellt material. Om en klient automatiskt fyllde i Reply-To, avbryt utkastet tills destinationen har verifierats.
Stäng frågan på fältnivå
Anteckna huruvida oöverensstämmelsen var förväntad, obehörig eller olöst, och vilka bevis som stöder detta fynd. Behåll autentiseringsresultat som en separat observation. Detta bevarar en användbar distinktion: ett meddelande kan vara intakt och domänautentiserat medan dess föreslagna svarsväg är olämplig för affärsåtgärden.