Bepaal waarvoor de remailer verantwoordelijk is
Een geverifieerde remailingservice ontvangt een bericht en verzendt nog een SMTP transactie. Die omschrijving omvat verschillende diensten: een adresdoorstuurserver, een discussielijst, een beveiligingsgateway of een applicatie die post herverdeelt. “Geauthenticeerd” is onvolledig tenzij het de identiteit, het mechanisme en de ontvangende hop noemt. Een service kan zijn eigen uitgaande verbinding authenticeren zonder de authenticatie van de oorspronkelijke auteur te behouden. De verantwoordelijkheidsgrens moet daarom de boodschap via de route volgen, in plaats van een productlabel te volgen.
Begin met een schriftelijk servicecontract voor de poststroom. Identificeer wie het originele bericht accepteert, de envelop wijzigt, de ondertekende inhoud wijzigt, bezorgingsfouten oplost en bewijs levert aan de uiteindelijke ontvanger. De onderstaande voorgestelde verantwoordelijkheidskaart is een planningshulpmiddel en geen observatie van een ingezette dienst. Elke operator moet zijn eigen wijzigingen kunnen uitleggen zonder controle te claimen over de filterbeslissing van een andere operator.
Scheid de drie identiteitsvragen
Het verbindende IP- en SMTP envelop afzender er toe doen SPF. Het ondertekeningsdomein en het beschermde berichtmateriaal zijn van belang DKIM. DMARC vraagt of een kwalificerende, geverifieerde identificatie overeenkomt met het auteurdomein uit het Van-veld van het bericht. Het succesvolle SPF resultaat van een remailer voor zijn eigen envelopdomein is niet automatisch een afgestemd resultaat voor een niet-gerelateerde originele auteur. Dit zijn afzonderlijke vragen, zelfs als een gebruikersinterface één geruststellend ‘geauthenticeerd’ label weergeeft. RFC 7208 , sectie 2.4 En RFC 9989 , sectie 4.4 de relevante grenzen definiëren.
Het herschrijven van enveloppen kan de expediteur verantwoordelijk maken voor een nieuw retourpad en SPF in staat stellen zijn uitgaande infrastructuur te beschrijven. Het herstelt op zichzelf niet de oorspronkelijke auteur uitlijning. Zo ook een vers DKIM -handtekening van de remailer bewijst iets over dat ondertekeningsdomein, niet noodzakelijkerwijs de oorspronkelijke auteur. Leg zowel oude als nieuwe identiteiten vast, zodat een latere analist kan zien welke relatie behouden is gebleven, vervangen of verloren is gegaan.
Eigen aanpassingen die een handtekening kunnen breken
Een service die een voettekst toevoegt, een ondertekend onderwerpveld wijzigt of beveiligde inhoud opnieuw codeert, moet de relevante DKIM handtekening begrijpen en canonicalisering. Sommige transformaties overleven de geselecteerde canonicalisering; anderen niet. Ga er niet van uit dat elke headerwijziging DKIM verbreekt, of dat “relaxte” canonicalisatie willekeurige bewerkingen toestaat. Bewaar een origineel exemplaar en vergelijk de feitelijk ondertekende headers en hoofdtekst bij het diagnosticeren van een fout. RFC 6376 , secties 3.4 en 5.4 leveren het mechanisme, en geen belofte over een bepaalde remailer.
De doorstuurrichtlijnen van Google bevelen aan om inhoud die onder DKIM valt te beschermen en stellen dat Gmail doorgestuurde berichten zelf evalueert. Dat is Gmail-specifiek operationeel advies, geen universele acceptatieovereenkomst. Een remailer blijft verantwoordelijk voor de wijzigingen die hij aanbrengt, inclusief een opzettelijke From-herschrijving die bij sommige lijstontwerpen wordt gebruikt. Een dergelijke herschrijving verandert de identiteit die aan de ontvangers wordt gepresenteerd en vereist een expliciete productbeslissing over antwoorden en attributie. Google-doorstuurrichtlijnen.
Behandel ARC als bewijs met een vertrouwensgrens
ARC kan de authenticatiebeoordeling van een tussenpersoon en een verifieerbare verwerkingsketen bevatten. De validatie ervan certificeert geen goedaardige inhoud en bevestigt niet dat elk verzegelingsdomein betrouwbaar is. De uiteindelijke ontvanger moet beslissen hoe hij die informatie, of helemaal niet, zal gebruiken. Bewaar de keten, de verzegelingsdomeinen, de evaluatie van de ontvanger en de lokale dispositie afzonderlijk. Een ARC -pas is geen vervanging voor een uitgelijnde DKIM -pas. RFC 8617 , secties 7 en 9.
Ook de standaardstatus heeft een datum nodig. Op 8 november 2026 blijft RFC 8617 experimenteel. De actieve draft-ietf-dmarc-arc-to-historic-01 stelt voor om het experiment te beëindigen en de RFC naar Historic te verplaatsen; het is een werk in uitvoering, geen doorgevoerde herclassificatie. Een servicebeoordeling zou dat voorstel moeten onthullen zonder de universele inzet ARC of de voltooide pensionering als feit te presenteren. Huidige conceptstatus.
Volg een fictief bericht door de grens
Beschouw een fictief bericht van notices@sender.example , dat via een alumni-forwarder naar een definitieve mailbox wordt gerouteerd. Stel dat de originele stream een uitgelijnde DKIM handtekening heeft. De forwarder wijzigt de envelopafzender naar zijn eigen domein, maar laat het beveiligde bericht ongewijzigd. De verwachte vraag bij de uiteindelijke ontvanger is of die originele handtekening nog steeds geldig is en op één lijn ligt. Het SPF resultaat van de nieuwe envelop beantwoordt een andere identiteitsvraag. Dit voorbeeld is een redeneeroefening; er is geen bericht, DNS antwoord of ontvangerresultaat verzameld.
Stel nu dat dezelfde service een disclaimer voor de inhoud toevoegt. De analist moet de met handtekeningen bedekte inhoud vóór en na die stap vergelijken. De eigen handtekening van een dienst of ARC zegel kan aanvullend bewijs opleveren, maar geen van beide mag stilzwijgend worden omschreven als herstel van de originele handtekening. Het corrigerende werk behoort in de eerste plaats toe aan de actor die de relevante transformatie heeft geïntroduceerd, terwijl de oorspronkelijke afzender nog steeds eigenaar is van zijn ondertekenconfiguratie en de ontvanger eigenaar is van zijn acceptatiebeleid.
Accepteer verantwoordelijkheid zonder levering te beloven
SMTP verantwoordelijkheid wordt overgedragen wanneer de ontvangende server een positief voltooiingsantwoord geeft na berichtgegevens. Die server is dan eigenaar van de levering of de juiste daaropvolgende foutafhandeling. Deze transportverantwoordelijkheid verschilt van een belofte van plaatsing in de inbox of voortgezette authenticatie bij elke latere hop. Een remailer moet wachtrij-ID's, tijdstempels en begrensde diagnostische records bewaren die voldoende zijn om die overdracht te verklaren. RFC 5321 , sectie 4.2.5.
RFC 9989 bespreekt expliciet de interoperabiliteit van indirecte stromen en waarschuwt ervoor domeinbeleid niet te behandelen als de enige input van de ontvanger. Controleer de deelname aan de lijst en het legitieme doorsturen bij het plannen van het afzenderbeleid, in plaats van te eisen dat een remailer het gedrag van elke ontvanger garandeert. RFC 9989 , sectie 7.4.
Bewijs is nog steeds vereist
Directe en indirecte leveringsmonsters met vergelijking van route, envelop, handtekeningen en vertrouwde resultaten. Deze vereiste blijft open. Verzamel geautoriseerde, gematchte monsters, markeer vertrouwde, door de ontvanger toegevoegde resultaten en vergelijk de hopidentiteiten en -wijzigingen. Documentair standaardonderzoek en de fictieve route leggen niet het gedrag van een daadwerkelijke remailingdienst vast.