• Log på
  • Tilmeld dig
  • Kontakt os
PowerDMARC
  • Funktioner
    • PowerDMARC
    • Hosting af DKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • Tjenester
    • Installationstjenester
    • Administrerede tjenester
    • Supporttjenester
    • Servicefordele
  • Prissætning
  • Power Toolbox
  • Partnere
    • Forhandlerprogram
    • MSSP-program
    • Teknologipartnere
    • Branchepartnere
    • Find en partner
    • Bliv partner
  • Ressourcer
    • DMARC: Hvad er det, og hvordan fungerer det?
    • Dataark
    • Casestudier
    • DMARC i dit land
    • DMARC efter industri
    • Støtte
    • Blog
    • DMARC-uddannelse
  • Om
    • Vores virksomhed
    • Klienter
    • Kontakt os
    • Bestil en demo
    • Begivenheder
  • Menuen Menu

Hvad er SMTP TLS-rapportering?

Blogs
Hvad-er-SMTP-TLS-rapportering?

TLS Reporting er en omvendt feedback-mekanisme, der hjælper domæneejere med at finde problemer med e-maillevering med stor nøjagtighed. Den fungerer sammen med MTA-STS protokollen og giver sporingsdata om bouncede e-mails, der ikke blev leveret på grund af et mislykket TLS-håndtryk.

Hvad betyder TLS-rapportering?

TLS Reporting (TLS-RPT) er en standard til rapportering af problemer med e-maillevering, der opstår, når en e-mail ikke er krypteret med TLS. Den understøtter MTA-STS-protokollen, som bruges til at garantere, at alle e-mails, der sendes til dit domæne, bliver TLS-krypteret.

  • TLS-kryptering sikrer, at alle e-mails, der sendes til dig, bliver leveret sikkert. Men en angriber kan forsøge en SMTP-downgrade, en type angreb, hvor e-mailen sendes til dig uden at være krypteret, så de kan læse eller manipulere med indholdet. MTA-STS bekæmper dette ved at gøre det nødvendigt for alle e-mails at blive krypteret, før de sendes til dig. Hvis en angriber forsøger at udføre en SMTP-nedgradering, vil e-mailen slet ikke blive sendt.
  • TLS-RPT gør det muligt for dig, domæneejeren, at modtage rapporter om hver e-mail, der ikke bliver krypteret og ikke sendes til dig. Du kan derefter identificere kilden til problemet og løse dine leveringsproblemer.

Hvordan fungerer TLS-rapportering?

Hvordan fungerer TLS-rapportering?

TLS-rapportering (TLS-RPT) bruges til at understøtte MTA-STS-protokollen, som sikrer, at e-mails krypteres, før de leveres. Normalt forhandler din mailserver eller MTA (Mail Transfer Agent) med den modtagende server for at se, om den understøtter kommandoen STARTTLS. Hvis det gør det, bliver e-mailen krypteret med TLS og leveres til den modtagende MTA.

En hacker kan forsøge et SMTP-nedgraderingsangreb på dette tidspunkt, hvilket indebærer, at forhandlingen mellem afsendelses- og modtagelses-MTA'erne blokeres. Afsenderserveren mener, at modtageren ikke understøtter KOMMANDOEN STARTTLS og sender e-mailen uden TLS-kryptering, så hackeren kan se eller manipulere med mailens indhold.

Når du implementerer MTA-STS i dit domæne, gør det det obligatorisk for din afsenderserver at kryptere beskeder, før du sender dem. Hvis en angriber forsøger et SMTP-downgrade-angreb, vil e-mailen simpelthen ikke blive sendt. Dette sikrer TLS-kryptering på alle dine e-mails uden fejl.

TLS-rapportering (TLS-RPT) er en protokol, der giver dig som domæneejer besked, når e-mails, der sendes via dit domæne, har problemer med leveringen. Hvis en e-mail ikke kan sendes på grund af en SMTP-nedgradering eller et andet problem, vil du modtage en rapport i JSON-filformat, der indeholder detaljerne om den e-mail, der mislykkedes. Denne rapport indeholder ikke indholdet af e-mailen.

Hvorfor har du brug for SMTP TLS-rapportering?

Det er vigtigt for domæneejere at holde sig informeret om problemer med e-maillevering på grund af fejl i TLS-kryptering for e-mails sendt fra et MTA-STS-aktiveret domæne. TLS-rapportering gør det muligt ved at give disse oplysninger. 

At modtage feedback-rapporter

Hvis en besked ikke bliver sendt, hjælper TLS-rapportering dig med at få besked om det.

For at opnå total synlighed af e-mailkanaler

Få detaljeret indsigt i dit e-mailflow gennem TLS-rapportering

For at eliminere leveringsproblemer

TLS-rapportering hjælper dig med at identificere kilden til problemet og løse det uden forsinkelse.tls rapport

Trin til aktivering af TLS-rapportering 

Du kan aktivere TLS-rapportering for dit domæne ved at oprette en TXT-post for TLS-RPT og offentliggøre den på din DNS. Denne record skal udgives på subdomænet _smtp._tls.ditdomæne.com

Eksempel på TLS-RPT-post

v=TLSRPTv1; rua=mailto:[email protected];

Lad os se nærmere på komponenterne i den medfølgende TLS-rapporteringspost:

v=TLSRPTv1:

Dette tag angiver den version af TLS-RPT-protokollen, der bruges. I dette tilfælde, "TLSRPTv1" den første version af TLS-RPT-protokollen.

rua=mailto:[email protected]:

Dette tag angiver rapporterings-URI'en for de aggregerede rapporter (RUA'er). Det specificerer, hvor modtagerens mailserver skal sende aggregerede rapporter om TLS-fejl. rua står for "Reporting URI for Aggregated Reports".

Værdien "mailto:[email protected]" er en URI, der angiver en e-mailadresse ([email protected]) som de aggregerede rapporter skal sendes til via e-mail.

I praksis vil du erstatte "ditdomæne.com" med det faktiske domænenavn, hvor du ønsker at modtage disse rapporter.

Betydningen af hver komponent:

v=TLSRPTv1:

Dette angiver den version af TLS-RPT-protokollen, der bruges. Det er med til at sikre kompatibilitet mellem afsender og modtager af rapporterne.

rua=mailto:[email protected]:

Dette angiver destinationen for aggregerede rapporter om TLS-leveringsproblemer. Ved at angive en rapporterende e-mailadresse kan domæneejere modtage oplysninger om mislykkede eller problematiske TLS-forbindelser. Rapporterne er værdifulde til diagnosticering af potentielle sikkerheds- eller konfigurationsproblemer i forbindelse med e-mailkommunikation.

TLS-rapporteringsformat og eksempel på rapport

En JSON TLS-rapport følger et specifikt format, der er defineret af TLS-RPT-specifikationen (Transport Layer Security Reporting Policy). Dette format bruges til at formidle information om problemer med e-maillevering relateret til TLS-kryptering. Nedenfor er et eksempel på, hvordan en JSON TLS-rapport kan se ud:

Her er en oversigt over de vigtigste felter i denne JSON TLS-rapport:

TLS-rapporterings-format-og-rapporterings-eksempel

organisation: Den domæneorganisation, der ejer TLS-RPT-recorden.

e-mail: Den e-mailadresse, hvor aggregerede rapporter sendes til.

begin_date: Startdatoen for rapporteringsperioden.

slut_dato: Slutdatoen for rapporteringsperioden.

Politikker: Et array af politikobjekter, der beskriver de politikker, der er anvendt i rapporteringsperioden.

politik: Indeholder oplysninger om den anvendte politik.

policy_type: Angiver typen af politik (f.eks. "politik" for en TLS-politik).

policy_streng: Angiver den politikstreng, der er knyttet til politikken (f.eks. "reject" for en streng TLS-politik).

resumé: Indeholder sammenfattende oplysninger om de sessioner, der blev forsøgt.

total_successful_session_count: Det samlede antal succesfuldt etablerede TLS-sessioner.

total_failure_session_count: Det samlede antal TLS-sessionsfejl.

fejl_detaljer: Et array af objekter, der giver detaljer om specifikke fejl.

grund: En streng, der angiver årsagen til fejlen (f.eks. "certificate_expired").

tæller: Antallet af sessioner, der mislykkedes af en bestemt årsag.

Årsager til og typer af TLS-krypteringsfejl 

Problemer med certifikater:

  1. certifikat_udløbet: Certifikatet fra fjernserveren har overskredet sin udløbsdato, hvilket gør det upålideligt til kryptering.
  2. certifikat_ikke_gyldigt_endnu: Certifikatet fra fjernserveren er endnu ikke gyldigt, muligvis på grund af forkert servertid eller for tidlig brug af certifikatet.
  3. certifikat_tilbagekaldt: Certifikatet fra fjernserveren er blevet tilbagekaldt af certifikatmyndigheden på grund af sikkerhedsproblemer.
  4. untrusted_certificate: Den certifikatkæde, som fjernserveren præsenterer, har afsenderens mailserver eller klient ikke tillid til, hvilket indikerer en potentiel sikkerhedsrisiko.
  5. no_valid_signature: Certifikatet, der præsenteres af fjernserveren, er ikke korrekt signeret af en pålidelig certifikatmyndighed, hvilket giver anledning til bekymring om dets ægthed.
  6. ikke-understøttet_certifikat: Certifikatet fra fjernserveren bruger krypteringsalgoritmer eller nøglelængder, der ikke understøttes af afsenderens mailserver, hvilket forhindrer en sikker forbindelse.

Uoverensstemmelse mellem værtsnavn og identitet

  1. hostname_mismatch: Værtsnavnet, der er angivet i serverens certifikat, stemmer ikke overens med værtsnavnet på den server, som afsenderens mailserver forsøger at oprette forbindelse til, hvilket indikerer et muligt man-in-the-middle-angreb eller konfigurationsproblem.

Cipher Suite og krypteringskonfiguration

  1. usikker_ciffer_suite: Den cipher suite, der er forhandlet mellem afsenderens og modtagerens mailservere, anses for at være svag eller usikker, hvilket potentielt kan kompromittere kommunikationens fortrolighed og integritet.
  2. protocol_version_mismatch: Der er en uoverensstemmelse i de understøttede TLS-protokolversioner mellem afsenderens og modtagerens mailservere, hvilket forhindrer dem i at etablere en kompatibel krypteret forbindelse.
  3. no_shared_cipher_suite: Der er ingen fælles cipher suite tilgængelig, som både afsenderens og modtagerens mailservere kan bruge til kryptering, hvilket resulterer i en mislykket forbindelse.

Problemer med håndtryk og protokol

  1. handshake_failure: Der opstod et problem under den indledende TLS handshake-proces mellem afsenderens mailserver og modtagerens mailserver, hvilket forhindrede den sikre kanal i at blive etableret.
  2. uventet_besked: Afsenderens mailserver modtog en uventet eller ikke-understøttet besked under TLS-handshake-processen, hvilket indikerer et potentielt protokol- eller implementeringsmisforhold.

MTA-STS-politiske spørgsmål

  1. mta_sts_policy_not_found: Denne fejl opstår, når afsenderens mailserver ikke kan finde en MTA-STS-politik for modtagerens domæne.
  2. mta_sts_policy_invalid: Denne fejl opstår, når den MTA-STS-politik, der findes i DNS for modtagerens domæne, er ugyldig, indeholder fejl eller ikke overholder MTA-STS-specifikationen.
  3. mta_sts_policy_fetch_error: Denne fejl opstår, når afsenderens mailserver støder på en fejl, mens den forsøger at hente MTA-STS-politikken fra modtagerens domænes DNS-poster.
  4. mta_sts_connection_failure: Denne fejl opstår, når afsenderens mailserver forsøger at etablere en sikker forbindelse ved hjælp af MTA-STS, men fejler på grund af årsager som upålidelige certifikater, ikke-understøttede cipher suites eller andre TLS-problemer.
  5. mta_sts_invalid_hostname: Denne fejl opstår, når værtsnavnet på modtagerens mailserver, som angivet i MTA-STS-politikken, ikke stemmer overens med serverens faktiske værtsnavn.
  6. mta_sts_policy_upgrade: Denne fejl opstår, når afsenderens mailserver forsøger at opgradere forbindelsen til en sikker forbindelse ved hjælp af MTA-STS, men modtagerens server ikke understøtter opgraderingen.

Forenklet SMTP TLS-rapportering med PowerDMARC

Forenklet-SMTP-TLS-rapportering-med-PowerDMARC

PowerDMARCs SMTP TLS-rapporteringsoplevelse handler om at forbedre din sikkerhed og samtidig gøre dit liv lettere med en hosted service.

Oversatte TLS-rapporter

Komplekse JSON-rapporter til TLS-rapportering konverteres til forenklede oplysninger, som du kan skimme igennem på få sekunder eller læse i detaljer.

Automatisk registrering af problemer

PowerDMARC-platformen udpeger automatisk det problem, du står over for, så du kan løse det uden at spilde tid

tls rapport

  • Om
  • Seneste indlæg
Ahona Rudra
Manager for digital markedsføring og indholdsskribent hos PowerDMARC
Ahona arbejder som Digital Marketing and Content Writer Manager hos PowerDMARC. Hun er en passioneret forfatter, blogger og marketingspecialist inden for cybersikkerhed og informationsteknologi.
Nyeste indlæg af Ahona Rudra (se alle)
  • Metoder til at beskytte dig selv mod identitetstyveri - 29. september 2023
  • DNS's rolle i e-mail-sikkerhed - 29. september 2023
  • Den nye tids phishing-trusler og hvordan man planlægger forud - 29. september 2023
27. august 2020/af Ahona Rudra
Del denne post
  • Del på Facebook
  • Del på Twitter
  • Del på WhatsApp
  • Del på LinkedIn
  • Del efter mail

Beskyt din e-mail

Stop e-mail-spoofing, og forbedr e-mail-levering

15 dages gratis prøveperiode!


Kategorier

  • Blogs
  • Nyheder
  • Pressemeddelelser

Seneste Blogs

  • Metoder til at beskytte dig selv mod identitetstyveri
    Metoder til at beskytte dig selv mod identitetstyveri29. september, 2023 - 12:11 pm
  • DNS's rolle i e-mail-sikkerhed
    DNS's rolle i e-mail-sikkerhed29. september, 2023 - 12:08 pm
  • Den nye tids phishing-trusler og hvordan man planlægger forud
    Den nye tids phishing-trusler og hvordan man planlægger fremadrettet29. september 2023 - 12:06 pm
  • Sådan ser og analyserer du meddelelsesoverskrifter online
    Hvordan ser og analyserer man meddelelsesoverskrifter online?September 26, 2023 - 12:59 pm
logofod powerdmarc
SOC2 GDPR PowerDMARC GDPR-kompatibel Crown Commercial Service
global cyberalliance certificeret powerdmarc Csa

Viden

Hvad er e-mail-godkendelse?
Hvad er DMARC?
Hvad er DMARC-politik?
Hvad er SPF?
Hvad er DKIM?
Hvad er BIMI?
Hvad er MTA-STS?
Hvad er TLS-RPT?
Hvad er RUA?
Hvad er RUF?
AntiSpam mod DMARC
DMARC-justering
DMARC-overholdelse
Fuldbyrdelse af DMARC
BIMI Implementeringsvejledning
Permerror
MTA-STS implementeringsvejledning til TLS-RPT

Værktøjer

Gratis DMARC Record Generator
Gratis DMARC Record Checker
Gratis SPF Record Generator
Gratis opslag efter SPF-poster
Gratis DKIM Record Generator
Gratis opslag efter DKIM-poster
Gratis BIMI Record Generator
Gratis BIMI Record Opslag
Gratis opslag efter FCrDNS-poster
Gratis TLS-RPT Record Checker
Gratis MTA-STS Record Checker
Gratis TLS-RPT Record Generator

Produkt

Produkt rundvisning
Funktioner
PowerSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
API-dokumentation
Administrerede tjenester
Beskyttelse mod forfalskning af e-mail
Beskyttelse af mærker
Anti Phishing
DMARC til Office365
DMARC til Google Mail GSuite
DMARC til Zimbra
Gratis DMARC-uddannelse

Prøv os

Kontakt os
Gratis prøveperiode
Bestil demo
Partnerskab
Prisfastsættelse
FAQ
Support
Blog
Begivenheder
Anmodning om funktion
Logbog over ændringer
Systemstatus

  • English
  • Français
  • Nederlands
  • Deutsch
  • Русский
  • Polski
  • Español
  • Italiano
  • 日本語
  • 中文 (简体)
  • Português
  • Norsk
  • Svenska
  • 한국어
© PowerDMARC er et registreret varemærke.
  • Kvidre
  • Youtube
  • Linkedin
  • Facebook
  • Instagram
  • Kontakt os
  • Vilkår og betingelser
  • Politik om beskyttelse af personlige oplysninger
  • Cookie-politik
  • Sikkerhedspolitik
  • overholdelse
  • GDPR-meddelelse
  • Sitemap
Hvorfor Vendor Email Kompromis er så skræmmende (og hvad du kan gøre for at stoppe det)vec blogspf begrænsning blogHvorfor SPF ikke er god nok til at stoppe spoofing
Rul til toppen