Autentiser e-post sendt gjennom Zimbra: konfigurasjon og bekreftelse

Omfang og forutsetninger

Denne veiledningen dekker et administrert Zimbra-samarbeid MTA, ikke en urelatert vertspostkasse merket Zimbra. Bekreft den installerte versjonen, utgående reléer og hvem som kontrollerer MTA og DNS før du endrer signering. Førsteparts wiki-dokumenter på domenenivå DKIM, inkludert aliasdomener.

Konfigurer den dokumenterte ruten

• Trinn 1. På MTA, inspiser domenets eksisterende konfigurasjon før du oppretter nøkler. Beskytt diagnostisk utgang: zmdkimkeyutil -q kan avsløre den private nøkkelen.
• Trinn 2. For et domene uten DKIM er den dokumenterte genereringskommandoen /opt/zimbra/libexec/zmdkimkeyutil -a -d example.com, kjøres i riktig Zimbra-administrasjonskontekst. Erstatt eksempeldomenet med det godkjente domenet.
• Trinn 3. Publiser bare den genererte offentlige DNS posten på den genererte velger under _domainkey. Bekreft TXT svaret på autoritativ DNS .
• Trinn 4. Bruk den versjonen som passer opendkim-testnøkkel sted for å sjekke nøkkelparet, og test deretter en utgående melding.
• Trinn 5. For rotasjon er det dokumenterte oppdateringsalternativet -u. Behold den tidligere offentlige posten lenge nok til at tidligere signerte meldinger kan bekreftes. Ikke behandle -r, som fjerner signeringsdata, som en rotasjonskommando.

Produktspesifikke risikoer

Forbered et vedlikeholdsvindu fordi nøkkelgenerering og DNS publisering ikke blir synlig overalt samtidig. Hvis et utgående relé omskriver en signert kropp, kan en lokalt gyldig nøkkel fortsatt gi en mislykket mottatt signatur. Plasser testen etter hele utgående rute, inkludert ansvarsfraskrivelser og sikkerhetsgatewayer. For en vertsbasert distribusjon uten MTA-tilgang, gi vertsoperatøren testkravene i stedet for å prøve skallkommandoer på en arbeidsstasjon. Aldri fest nøkkelspørringsutdata til en støttebillett uten å fjerne hemmeligheter.

Bevis ruten i mottakerenden

Bruk en godkjent ekstern postboks og lagre hele råmeldingen med tidsstempel og meldingsidentifikator. Ingen levende leietakertest er hevdet i denne veiledningen. Følgende er et akseptregneark som skal fylles ut under implementering, ikke en rekord av observerte resultater.

• Bevisfelt: Synlig fra; Hva skal registreres: Faktisk adresse og domene; Akseptspørsmål: Er dette den tiltenkte avsenderidentiteten?
• Bevisfelt: Konvolutt; Hva skal registreres: Return-Path og mottakerrapportert SPF domene; Godkjenningsspørsmål: Hvilket domene autentiserte faktisk SPF ?
• Bevisfelt: SPF ; Hva skal registreres: Pålitelig mottakerresultat og evaluert identitet; Akseptspørsmål: Gikk det bestått, og stemmer den identiteten?
• Bevisfelt: DKIM ; Hva skal registreres: Hvert d= domene, s= velger og mottakerresultat; Godkjenningsspørsmål: Stemmer minst én bestått signatur?
• Bevisfelt: DMARC; Hva skal registreres: Mottakerresultat og gjeldende retningslinjer; Akseptspørsmål: Finnes det en justert forbikjøringsvei?
• Bevisfelt: Rute; Hva skal registreres: Produkt, konto og meldingstype; Akseptspørsmål: Brukte testen produksjonsbanen?

DMARC trenger minst én justert, bestått SPF eller DKIM bane. En bestått signatur fra et ikke-relatert tjenestedomene er ikke nok. Streng justering krever eksakt domenelikhet; avslappet justering bruker gjeldende organisasjon-domene-forhold. Sjekk domenets faktiske justeringsinnstillinger før du erklærer suksess. Et underdomene er ikke et automatisk strengt samsvar. SPF bruker SMTP identiteten, ikke visningsnavnet eller Reply-To. Rådfør deg med justering ordliste ved opptak av vedtaket.

Bruk Authentication-Results fra mottakssystemet du stoler på, ikke en header levert av en vilkårlig avsender. Fang alle signaturer i stedet for å stoppe ved den første feilen. For videresendt e-post, sammenligne en direkte test med en videresendt kopi: videresending kan endre SPF evaluering eller endre signert innhold. Ikke diagnostiser disse effektene ved å legge til speditørens adresse i leverandørautorisasjonen din.

Diagnostiser feil uten å utvide tilgangen

Sammenlign autoritativ DNS med de nøyaktige konfigurerte postnavnene først, og kontroller deretter rekursiv synlighet og tjenestevalidering. Feil navn, avkortet nøkkel eller motstridende CNAME er ikke fikset ved å vente på cacher. Behold bare én SPF policy hos en eier og sjekk grensen på ti DNS-oppslagstermer på tvers av evaluerte inkluderer og omdirigeringer før du slår sammen en annen avsender. DKIM velgere tilhører individuelle signeringskonfigurasjoner; ikke overskriv en annen applikasjons oppføring for å fremtvinge et valideringsresultat.

Hvis autentiseringen går gjennom, men leveringen er dårlig, inspiser mottakerens svar, omdømme, innhold og sendetillatelser separat. DMARC pass lover ikke aksept eller innboksplassering. Hvis ingen av banen stemmer overens, stopp utvidelsen og korriger den faktiske senderkonfigurasjonen. Ikke svekk hele domenets DMARC policy for å skjule en enkelt produktfeil.

Overlevering og gjenoppretting

Lagre den godkjente DNS forskjellen, offentlige oppslagsresultater, tjenestestatus og redigert arbeidsark for mottatt melding med en navngitt eier. Hold legitimasjon og private nøkler borte fra billetter. Ved feil, pause den berørte sendejobben eller bruk en tidligere testet rute under tjenesteeierens kontroll. Gjenopprett bare de endrede postene som tilhører denne integrasjonen; beholde offentlige nøkler som trengs for meldinger ombord. Test på nytt etter tilbakerulling, nøkkelrotasjon, domenemigrering eller endring i utgående relé. Lukk endringen bare når produktets eier og e-postadministrator kan forklare den observerte identitetskjeden.

Bekreft leverandørgrensen

Wikien identifiserer forskjellige testverktøyplasseringer for ZCS 8.6 og tidligere versus 8.7 og nyere, og sier at 8.7.x genererer 2048-bit nøkler. Bekreft den installerte versjonen i stedet for å kopiere en gammel prøvenøkkel. For en lang TXT verdi, bruk flere tegnstrenger i én ressurspost, ikke konkurrerende offentlige nøkkelposter. Wikien advarer om 8-bits konvertering og e-postliste/ PGP interaksjoner; teste de aktuelle rutene uten å tilfeldigvis endre koding eller starte tjenester på nytt. Tilbakekall med en tom p= ugyldiggjør den nøkkelen og er ikke vanlig overlappingsrotasjon.

Arbeid gjennom en fiktiv diagnostisk sak

Kun fiktiv skriftlig sak: ZM-01 forutsetter at lokal nøkkeltesting lykkes for shop.example , men en nedstrøms gateway legger til en bunntekst og den mottatte meldingen fra help@shop.example rapporterer en body-hash-feil for d=shop.example. SPF og andre signaturer er ukjente. MTA- og gateway-eierne må etablere den endelige signeringsordren og teste etter alle modifikasjoner; en lokal test motsier ikke den mottatte feilen. Ingen fullstendig DMARC dom eller reparert levering hevdes. Ingen leietaker, DNS , serverkommando eller melding ble utøvd for denne saken.

Skille en bestått melding fra håndhevingsberedskap

RFC 9989 Seksjon 7.4 krever gyldig DKIM for et domene som publiserer p=reject og advarer om interoperabilitet med indirekte e-post. Et enkelt justert SPF resultat rettferdiggjør ikke i seg selv en utrulling av avvisningspolicy. Gå gjennom alle legitime ruter og policyeierskap separat fra dette leverandøroppsettet.