DMARC, en gratis teknologi til forebyggelse af phishing/ransomware og sikring af bedre email leverance
Email service provideren MailChimp har nu gjort det muligt for deres kunder at DKIM signe med en signatur fra kundens eget domæne, så er vi ved at være tæt på at MailChimp kan sende 100% DMARC compliant email, nu mangler kun en kundespecifik ReturnPath.
TDCs kunde emailserverplatform er tilsyneladende begyndt at afvise email fra domæner med en DMARC reject policy som fejler.
Det må siges at være godt nyt for TDC kunder som nu kan se frem til at modtage færre phishing emails.
Maillog fra en lille test jeg har udført:
relay=fpo.mail.dk[80.160.76.237]:25, delay=1.3, delays=0.02/0/1.1/0.25, dsn=5.7.1, status=bounced (host fpo.mail.dk[80.160.76.237] said: 550 5.7.1 msg rejected per DMARC policy for joke.dk
Så blev AOL også træt af email svindlere.
På deres blog har de skrevet lidt om sagen: AOL Postmaster blog
Yahoo har skrevet et par artikler om deres skift til DMARC reject policy.
Symantec har netop offentliggjort at deres Email Sescurity.cloud produkt får DMARC funktionalitet indbygget således brugerne beskyttes af dette.
Læs mere hos Symantec
Når du implementerer DMARC på din virksomheds domæner skal du huske eventuelle parkerede domæner du ejer.
Det kan f.eks. dreje sig om alternative udgaver af dit firmas domænenavn eller måske bare domæner du aldrig har fået taget rigtig i brug.
Du blev beskyttet imod webmisbrug af disse domæne dengang du registrerede dem, men hvis du vil sikre dig imod at de misbruges til phishing eller spam, skal du oprette en DMARC record med en reject policy på dem.
En DMARC record som nedenstående er alt hvad der skal til
_dmarc.firmanavn.dk IN TXT “v=DMARC1; p=reject;”
Vil du gøre lidt for de mailservere som endnu ikke understøtter DMARC kan du også oprette en SPF record
firmanavn.dk IN TXT “v=spf1 -all”
Google har netop offentliggjort nye/ændrede Bulk Sender Guidelines.
Det nye er at finde i afsnittet omkring authentication, Google anbefaler nu at man implementerer DMARC.
Så, hvor DMARC før udelukkende drejede sig om sikkerhed, så er det nu også et spørgsmål om hvor god man vil være til at ramme Indbakken hos Google.
Er Microsoft Sender ID dødt, halvlevende eller lever det i bedste velgående ? Det er faktisk ikke et helt nemt spørgsmål.
Lad os starte med lidt historie.
Sender ID og SPF er egentlig nogle eksperimenter som startede tilbage i April 2006, de er beskrevet i RFC 4406, RFC 4407 og RFC 4408.
Sender ID viste sig at være skruet lidt forkert sammen, så følger man standarden slavisk, og samtidig anvender 3. parts afsendere, kan det resultere i en del problemer.
Seks år efter Sender ID og SPF eksperimenterne startede, forsøgte man at komme frem til nogle konklusioner i RFC 6686, baseret på en masse indsamlede data.
Det er lidt svært at se nogle egentlig konklusioner, udover at mange anvender SPF og ikke så mange anvender Sender ID.
En egentlig konklusion skal man nok finde i RFC 4408bis, her kan man se at SPF er tæt på at blive en officiel Internet standard, et lignende dokument kan man ikke finde for Sender ID.
Så for at vende tilbage til det oprindelige spørgsmål om hvorvidt Sender ID er dødt, så må svaret blive: Måske ikke helt, men det for længst blevet overhalet af DMARC som kan alt Sender ID kan plus meget mere.
DK-Hostmaster afholdte 26 og 27 Februar et par DMARC Workshop dage. Tim Draegen var hentet til Danmark og underviste begge dage.
Vi kom hele vejen omkring SPF, DKIM og selve DMARC standarden.