Reikwijdte en vereisten
Deze handleiding behandelt een beheerde Zimbra-samenwerking MTA, en niet een niet-gerelateerde gehoste mailbox met het merk Zimbra. Bevestig de geïnstalleerde versie, uitgaande relais en wie de MTA en DNS beheert voordat u de ondertekening wijzigt. De first-party wiki documenteert op domeinniveau DKIM, inclusief aliasdomeinen.
Configureer de gedocumenteerde route
- Stap 1. Inspecteer op de MTA de bestaande configuratie van het domein voordat u sleutels maakt. Diagnose-uitgang beveiligen:
zmdkimkeyutil -qkan de privésleutel vrijgeven. - Stap 2. Voor een domein zonder DKIM is het gedocumenteerde generatiecommando
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com, uitgevoerd in de juiste Zimbra-beheercontext. Vervang het voorbeelddomein door het goedgekeurde domein. - Stap 3. Publiceer alleen de gegenereerde openbare DNS record op de gegenereerde keuzeschakelaar onder
_domainkey. Controleer het TXT antwoord op gezaghebbende DNS . - Stap 4. Gebruik de juiste versie
opendkim-testsleutellocatie om het sleutelpaar te controleren en vervolgens een uitgaand bericht te testen. - Stap 5. Voor rotatie is de gedocumenteerde updateoptie
-u. Bewaar het vorige openbare record lang genoeg om eerder ondertekende berichten te kunnen verifiëren. Niet behandelen-r, waarmee ondertekeningsgegevens worden verwijderd, als een rotatieopdracht.
Productspecifieke risico's
Bereid een onderhoudsvenster voor, want sleutelgeneratie en DNS publicatie worden niet overal tegelijkertijd zichtbaar. Als een uitgaande relay een ondertekende tekst herschrijft, kan een lokaal geldige sleutel nog steeds een mislukte ontvangen handtekening opleveren. Plaats de test na het gehele uitgaande traject, inclusief disclaimers en security gateways. Voor een gehoste implementatie zonder MTA-toegang geeft u de hostingoperator de testvereisten in plaats van shell-opdrachten op een werkstation uit te voeren. Voeg nooit de uitvoer van sleutelquery's toe aan een supportticket zonder de geheimen te verwijderen.
Bewijs de route aan de ontvangende kant
Gebruik een goedgekeurde externe mailbox en sla het volledige onbewerkte bericht op met zijn tijdstempel en bericht-ID. In deze handleiding wordt geen live tenanttest geclaimd. Het volgende is een acceptatiewerkblad dat u tijdens de implementatie moet invullen, niet een record van waargenomen resultaten.
- Bewijsveld: zichtbaar vanaf; Wat te registreren: Werkelijk adres en domein; Acceptatievraag: Is dit de beoogde afzenderidentiteit?
- Bewijsveld: Envelop; Wat op te nemen: Return-Path en door de ontvanger gerapporteerd SPF domein; Acceptatievraag: Welk domein heeft SPF daadwerkelijk geauthenticeerd?
- Bewijsveld: SPF ; Wat te registreren: resultaat van vertrouwde ontvanger en geëvalueerde identiteit; Acceptatievraag: is het geslaagd en komt die identiteit overeen?
- Bewijsveld: DKIM ; Wat te registreren: elk d= domein, s= selector en ontvangerresultaat; Acceptatievraag: Komt ten minste één passerende handtekening overeen?
- Bewijsveld: DMARC; Wat vast te leggen: Resultaat ontvanger en geldend beleid; Acceptatievraag: Bestaat er een uitgelijnd passeerpad?
- Bewijsveld: Route; Wat te registreren: Product-, account- en berichttype; Acceptatievraag: Heeft de test gebruik gemaakt van het productiepad?
DMARC heeft ten minste één uitgelijnd, passerend SPF of DKIM pad nodig. Een passerende handtekening van een niet-gerelateerd servicedomein is niet voldoende. Streng uitlijning vereist exacte domeingelijkheid; ontspannen afstemming maakt gebruik van de toepasselijke relatie tussen organisatie en domein. Controleer de daadwerkelijke uitlijningsinstellingen van het domein voordat u succes verklaart. Een subdomein is geen automatische strikte match. SPF gebruikt de SMTP identiteit, niet de weergavenaam of Reply-To. Raadpleeg de uitlijning woordenlijst bij het vastleggen van de beslissing.
Gebruik Authentication-Results van het ontvangende systeem dat u vertrouwt, en niet van een header van een willekeurige afzender. Leg alle handtekeningen vast in plaats van te stoppen bij de eerste mislukking. Vergelijk voor doorgestuurde e-mail een directe test met een doorgestuurde kopie: doorsturen kan SPF evaluatie veranderen of de ondertekende inhoud wijzigen. Stel geen diagnose van deze effecten door het adres van de expediteur toe te voegen aan de autorisatie van uw provider.
Diagnose van fouten zonder de toegang te vergroten
Vergelijk eerst gezaghebbende DNS met de exact geconfigureerde recordnamen en controleer vervolgens de recursieve zichtbaarheid en servicevalidatie. Een verkeerde naam, afgekapte sleutel of conflicterend CNAME wordt niet opgelost door te wachten op caches. Houd slechts één SPF beleid aan bij een eigenaar en controleer de limiet van tien DNS-lookup-termen voor geëvalueerde include- en omleidingen voordat u een andere afzender samenvoegt. DKIM selectors behoren tot individuele ondertekeningsconfiguraties; overschrijf het record van een andere applicatie niet om een validatieresultaat af te dwingen.
Als de authenticatie slaagt maar de bezorging slecht is, controleer dan afzonderlijk de reactie van de ontvanger, de reputatie, de inhoud en de verzendrechten. DMARC pas belooft geen acceptatie of plaatsing in de inbox. Als geen van beide paden op één lijn ligt, stop dan de uitbreiding en corrigeer de feitelijke afzenderconfiguratie. Verzwak het DMARC beleid van het hele domein niet om één enkele productfout te verbergen.
Overdracht en herstel
Bewaar het goedgekeurde DNS verschil, de openbare opzoekresultaten, de servicestatus en het geredigeerde werkblad voor ontvangen berichten met een benoemde eigenaar. Houd inloggegevens en privésleutels buiten de tickets. Als dit mislukt, onderbreekt u de betrokken verzendtaak of gebruikt u een eerder geteste route onder controle van de service-eigenaar. Herstel alleen de gewijzigde records die bij deze integratie horen; bewaar openbare sleutels die nodig zijn voor berichten tijdens de vlucht. Test opnieuw na rollback, sleutelrotatie, domeinmigratie of een wijziging in de uitgaande relay. Sluit de wijziging alleen af als de producteigenaar en e-mailbeheerder de waargenomen identiteitsketen kunnen uitleggen.
Bevestig de providergrens
De wiki identificeert verschillende testtoollocaties voor ZCS 8.6 en eerder versus 8.7 en later, en zegt dat 8.7.x 2048-bits sleutels. Bevestig de geïnstalleerde versie in plaats van een oude voorbeeldsleutel te kopiëren. Voor een lange TXT waarde gebruikt u meerdere tekenreeksen binnen één bronrecord, en geen concurrerende records met een openbare sleutel. De wiki waarschuwt voor 8-bit conversie en mailinglijst/ PGP interacties; test die toepasselijke routes zonder terloops de codering te wijzigen of services opnieuw te starten. Intrekking met een lege p= maakt die sleutel ongeldig en is geen gewone overlaprotatie.
Werk een fictieve diagnostische casus uit
Alleen fictieve schriftelijke casus: ZM-01 gaat ervan uit dat het testen van de lokale sleutel slaagt voor shop.example , maar een downstream-gateway voegt een voettekst toe en het ontvangen bericht van help@shop.example rapporteert een body-hash-fout voor d=shop.example. SPF en andere handtekeningen zijn onbekend. De MTA- en gateway-eigenaren moeten de definitieve ondertekeningsvolgorde vaststellen en testen na alle wijzigingen; een lokale test spreekt de ontvangen fout niet tegen. Er wordt geen volledig DMARC -oordeel of gerepareerde levering beweerd. Voor dit geval is er geen tenant-, DNS , serveropdracht of bericht uitgevoerd.
Scheid een voorbijgaand bericht van de gereedheid voor handhaving
RFC 9989 Sectie 7.4 vereist een geldige DKIM voor een domein dat p=reject publiceert en waarschuwt voor de interoperabiliteit van indirecte e-mail. Eén enkel afgestemd SPF resultaat rechtvaardigt op zichzelf geen uitrol van het afwijzingsbeleid. Bekijk alle legitieme routes en beleidseigendom afzonderlijk van deze providerconfiguratie.