Beperk de instructies tot het ondertekenen van SpamTitan Gateway
TitanHQ publiceert een specifieke configuratie DKIM in de SpamTitan Gateway-procedure. Dit artikel volgt die productgrens. Er wordt niet van uitgegaan dat SpamTitan Cloud, Skellig, een uitsluitend inkomende implementatie of elke beheerde service-editie dezelfde controles biedt. Bevestig de geïnstalleerde versie, gelicentieerde mogelijkheden en daadwerkelijke uitgaande route voordat u een ondertekeningswijziging goedkeurt. Een domein dat wordt vermeld voor het ontvangen van e-mail is op zichzelf geen bewijs dat uitgaande berichten de gateway passeren of een handtekening van een klantdomein ontvangen.
De Gateway-procedure bevat zowel DKIM -ondertekeningsstappen als een afzonderlijke discussie over verouderde DomainKeys-beleidsrecords. Die mix is een belangrijke implementatiegrens. De moderne workflow voor handtekeningsleutels kan vanuit de bron worden verklaard, maar voor de oude beleidsstap is bevestiging van het huidige product vereist. Converteer niet stilletjes oude DomainKeys-terminologie naar een DMARC vereiste of bewering dat het publiceren van een o=-beleid moderne domeinbescherming tot stand brengt.
Identificeer de domeinrelay en het sleuteleigendom
De gedocumenteerde navigatie is Systeeminstellingen, Mail Relay, DKIM . Op de pagina worden domeinrelays vermeld. Bewerk het beoogde domein en open het tabblad DOMEINSLEUTEL. De procedure vraagt om een keuzeschakelaar naam die deze sleutel onderscheidt van andere domeinsleutels. Kies een label via het goedgekeurde naamgevingsproces van de organisatie en controleer het bestaande gebruik voordat u het publiceert. Een voorspelbaar label is geen geheim, maar het hergebruiken van een bezette selector kan een afhankelijkheid overschrijven die een andere afzender nog nodig heeft.
De bron beschrijft het genereren van een nieuw sleutelpaar en biedt ook een bestaand privé-sleutelveld. In deze handleiding wordt niet gevraagd, verzameld of aanbevolen om een privésleutel naar een ticket of gedeeld document te kopiëren. Het genereren of importeren van sleutels is een afzonderlijke geautoriseerde administratieve actie. De gids vermeldt 1024-bit en 2048-bits opties en beveelt de langere keuze aan. Bevestig de ondersteunde configuratie en huidige cryptografische vereisten voor het geïmplementeerde product; downgrade niet louter en alleen omdat een DNS editor op onhandige wijze een lange publieke waarde weergeeft.
Publiceer de gegenereerde openbare sleutel zonder het voorbeeld te kopiëren
Na Genereer verwijst de bron de beheerder naar het tabblad OPTIES en het DNS TXT materiaal. Publiceer de daadwerkelijke openbare sleutel op de naam die is gevormd uit de geselecteerde selector, _domainkey en het ondertekeningsdomein. De grote publieke sleutel die in de documentatie wordt afgedrukt, is een illustratie en geen herbruikbaar document. Leg de gekozen eigenaar en een gecontroleerde verwijzing naar de uitgegeven publieke waarde vast in het wijzigingsverzoek. Geen enkel privémateriaal hoort thuis in de publieke DNS .
TitanHQ bespreekt het verwijderen van externe opmaak van het gekopieerde beeldscherm. Interpreteer dit als het omgaan met de presentatie van de redacteur, en niet als het willekeurig bewerken van sleutelbytes. RFC 6376 , sectie 3.6.2.2 specificeert TXT bronrecords voor sleutelopslag. Een DNS tool kan meerdere tekenreeksen tussen aanhalingstekens binnen één tekenreeks weergeven TXT record; dat verschilt van meerdere concurrerende records of letterlijke aanhalingstekens die in de waarde zijn ingevoegd. Laat de DNS beheerder het daadwerkelijke logische record en de volledige naam van de eigenaar verifiëren in plaats van een screenshot van een invoervak als definitief bewijs te accepteren.
Houd het verouderde beleid en de testmodus gescheiden van DMARC
De providerprocedure beschrijft ook een TXT record op _domainkey gevolgd door het domein, met o=- of o=~ waarden, onder Beleidsrecords. Het noemt dit DomainKeys-beleid expliciet. Dit is niet de DMARC -beleidslocatie en is geen vervanging voor een openbare sleutel DKIM selector. Omdat de procedure deze historische elementen combineert, moet u bevestigen of die beleidsstap van toepassing is op de exacte huidige Gateway-versie voordat u deze toevoegt. Bewaar de onopgeloste vraag in het releaserecord in plaats van een moderne vereiste te bedenken.
De handleiding beschrijft afzonderlijk een DKIM -testvlag, t=y, in het sleutelrecord. Verwar dat niet met een instructie om een DMARC implementatie in de testmodus te zetten of met een bewijs dat ontvangers alle e-mail zullen accepteren. DKIM , DMARC en lokale ontvangerafhandeling hebben verschillende semantiek. RFC 9989 , sectie 4.4 verklaart de uitlijning vereist tussen een passerende authenticatie-identiteit en het auteurdomein. Een oude beleidsverklaring dat e-mail is ondertekend, bewijst niet dat een bepaalde handtekening valideert of op één lijn ligt.
Controleer dit voordat u de rotatie opzettelijk inschakelt en plant
De OPTIONS-workflow van TitanHQ gebruikt Verify om het DNS TXT record op te halen en te vergelijken met de geconfigureerde informatie van de gateway. Zodra de verificatie slaagt, activeert Enable DKIM ondertekening voor het domein. Behandel deze als afzonderlijke controlepunten. Een gepubliceerde sleutel bewijst niet dat ondertekening is ingeschakeld, terwijl een geselecteerde ondertekeningsoptie een ontbrekend of niet-overeenkomend openbaar record niet kan valideren. Bewaar het verificatieresultaat en de tijd ervan, zonder het te omschrijven als een ontvangeracceptatietest.
De documentatie beveelt periodieke sleutelrotatie aan. Een praktisch rotatieplan heeft meer nodig dan een kalenderinterval: identificeer actieve selectors, gegenereerde sleutels, berichten in de wachtrij, DNS caching, geautoriseerde operators en rollback-voorwaarden. Verwijder het vorige openbare record niet simpelweg omdat er een vervangende sleutel is gegenereerd. Bepaal welke overlap de werkelijke behoeften van het e-mailpad hebben, en bewaar het bewijsmateriaal dat die beslissing ondersteunt. Dit manuscript heeft de levensduur van wachtrijen niet gemeten of het overgangsgedrag van het geïnstalleerde product getest, dus die implementatiedetails blijven open.
Controleer het laatste uitgaande bericht in plaats van het filterlabel
Bij een afzonderlijk geautoriseerde acceptatieoefening moet onderscheid worden gemaakt tussen gatewaytransit, ondertekening, validatie en afstemming. Bekijk de velden d= en s= van de handtekening, het zichtbare auteursdomein en de authenticatieresultaten van de vertrouwde ontvanger. RFC 6376 , sectie 3.5 definieert de handtekeningvelden. Controleer berichtklassen die verschillende paden kunnen volgen, zoals gewone postbusmail, applicatiemeldingen en doorgestuurd verkeer. Het feit dat een inkomend bericht door SpamTitan werd gescand zegt niets over de manier waarop een uitgaand applicatiebericht werd ondertekend.
SPF is een aparte recensie. RFC 7208 , secties 2.4 en 4.6.4 beschrijf zijn MAIL VAN identiteits- en DNS-afhankelijke evaluatielimieten. Deze bron biedt geen universele uitgaande SPF opname voor elke SpamTitan-implementatie, dus hier is geen enkele uitgevonden. Verkrijg de feitelijk geautoriseerde verzendinfrastructuur en bekijk één volledig beleid voor die identiteit. Het succes van authenticatie blijft verschillend van de plaatsing in de inbox, de veiligheid van de inhoud of de goedkeuring van een betalingsverzoek door de ontvanger.
Fictieve diagnose en blanco acceptatiewerkblad
Een fictief ingenieursbureau, Alder Instruments, publiceert een nieuwe selectiesleutel, maar laat het ondertekenen uitgeschakeld terwijl er op een onderhoudsvenster wordt gewacht. De interne checklist markeert DKIM als voltooid omdat Verify is geslaagd. Uit een later onderzoek blijkt dat de checklist DNS overeenkomst en actieve ondertekening samenvoegde. De voorgestelde correctie is om de goedkeuring voor inschakeling, de waargenomen configuratiestatus en het toekomstige bewijs van de ontvanger te scheiden. Het is niet de bedoeling om de voorbeeldsleutel van de documentatie te publiceren of ter vervanging een verouderd beleidsrecord toe te voegen. Aan dit scenario ligt geen feitelijk systeem, bericht of DNS zoekopdracht ten grondslag.
- Gatewayproduct, versie, uitgaande route en domeinrelay: ______
- Eigenaar van selector en bestaande afhankelijkheden: ______
- Gegenereerde openbare eigenaar/waardereferentie en goedgekeurde DNS wijziging: ______
- Beslissing over bewaring van privésleutel, zonder geheim materiaal: ______
- Toepasselijkheidsbesluit van het verouderde DomainKeys-beleid: ______
- Resultaat verifiëren en vervolgens Goedkeuring/status inschakelen: ______
- Rotatie-overlapping, terugdraaien en behoud van vorige selector: ______
- Betrouwbare handtekening en uitlijning van ontvangen berichten: ______
- Resterende uitzonderingen, recensent en release-eigenaar: ______
Origineel implementatiebewijs, huidige toepasbaarheid van de bron, beoordeling van het menselijke onderwerp, acceptatie van de productieroute, visuele toegankelijkheid en vrijgave door de eigenaar blijven open. Er is geen sleutel gegenereerd, instelling gewijzigd, DNS record gepubliceerd of bericht verzonden. De bredere implementatievereiste van de catalogus kan niet als compleet worden aangemerkt op basis van deze documentaire workflow alleen.