Min mailserver (del 5) - Min mailserver kan I stole på

I del 2 af mailserver-serien efterlod jeg et hængeparti som Baldur Norddahl med rette efterlyste.
Spam kan bekæmpes i to ender - ved afsendelse og/eller ved modtagelse.
Ud over de klassiske metoder med spam-filtrering, så er der et interessant trekløver
SPF, DKIM og DMARC jeg beskriver nedenfor.

SPF handler om at vi fra DNS for dmænet beskriver hvilke maskiner, der lovligt må sende emails for domænet.
Kommer en mail fra mit domæne "petertoft.dk" fra en kinesisk IP-adresse, så synes jeg man skal smide emailen væk.

DKIM strammer skruen lidt mere ved at alle emails, der sendes fra domænets mail-server får en digital signatur i mail-headeren.
Signaturen kan checkes ud fra informationer som gemmes i DNS for domænet. Passer eller mangler de digitale signaturer, så kan modtager smide mailen væk.

DMARC bygger ovenpå SPF og DKIM ved at man kan publicere råd om hvordan modtager af emails fra min domæne "petertoft.dk" skal behandles ud fra hvor langt man er med DKIM.

Et overblik kan findes på dette link

Tidligere i min mail-server serie har jeg skrevet om et fiktivt domæne. I denne artikel skifter jeg til et faktisk domæne "petertoft,dk" - mit domæne, der har styret DNS-mæssigt hos GratisDNS.dk

SPF

En stor del af problemet med email-spam er at som udgangspunkt, så kan alle lege "pto@petertoft.dk" som afsender.
Vi kan blokerere for at andre end mail-serveren for "petertoft.dk" domænet sender emails lovligt.

Ideen er at en modtager kan slå op i DNS for domænet og bede om min "Sender Policy Framework" (SPF)
og se hvilke afsender-maskiner er lovlige. Det er op til hver mail-server om det anvendes.

I DNS for domænet tilføjer jeg for domænet "petertoft.dk" et TXT felt:

HOST : petertoft.dk
VALUE : v=spf1 a mx ~all

Dvs. at det kun er MX (mail-servere) for domænet som kan få lov til at sende emails fra domænet.
"~all" betyder at emails, som kommer fra andet end "petertoft.dk" (vores mail-server - den der har MX-recorden i DNS) er nok spam.

Jeg kan stramme den ved at anvende "-all" fremfor "~all" - det er en anbefaling af, at man smider emails fra domænet "petertoft.dk" væk med mindre de kommer fra mail-serveren.

En fuld syntax kan læses her.

Bemærk at mit nye SPF felt også gør, at jeg ikke bare kan anvende Gmail eller andre web-services for domænet hvor jeg tidligere skødeløst ændrede identitet.
Det er netop den slags tricks jeg vil modvirke. There is no free lunch...

DKIM

Der er mange vejledninger på nettet om at få sat DKIM op og de fleste jeg har prøvet virker ikke længere på Debian Linux.
Jeg har dog fundet en glimrende vejledning til at sætte OpenDKIM op - og den er fin og det giver ingen mening at jeg "genskriver den" her.
Det er en lille software-server man installerer og starter op. Den kan bl.a. signere emails, der sendes ud fra maskinen.

Læs selv http://linuxaria.com/howto/using-opendkim-to-sign-postfix-mails-on-debian - og husk at "example.com" skal erstattes med dit eget domænenavn over alt i hans eksempel.

Dog skriver skribenten at man i DNS skal opsætte

HOST : mail._domainkey.example.com 
VALUE : v=DKIM1; h=rsa-sha256; k=rsa;p=enlangkodekommerhersomibaresletikkefaaratse

Jeg havde mere held med at udelade "h=rsa-sha256;" i min DNS-record (som også nævnt her) når jeg har testet mit setup (se nedenfor).

Dvs. jeg har for petertoft.dk

HOST : mail._domainkey.petertoft.dk
VALUE ; v=DKIM1; k=rsa;p=enlangkodekommerhersomibaresletikkefaaratse

DMARC

DMARC er en DNS-record man publicerer til andre mail-servere. Der er en fin beskrivelse f.eks. på dette link fra Google og en lille intro her

Jeg er selv lige gået i gang med DMARC, dvs. jeg skal til at stramme skruen som anbefalet af Google-linket.
Det som også er smart med DMARC er at man kan anmode modtager-mailservere om at sende rapporter tilbage om mails afsende kan valideres korrekt. Når alt er vel kan man stramme reglerne.
Har I kære læsere flere erfaringer med dette?

Check og samlet DNS opsætning af DKIM, SPF og DMARC

Jeg har haft stor glæde af at kunne teste SPF og meget andet på http://www.dnsinspect.com/ - se dette link for petertoft.dk

Og DKIM er nemt testet på http://www.brandonchecketts.com/emailtest.php

Til sammen har jeg pt. følgende DNS opsætning i TXT-felterne - billedet er fra gratisdns.dk (tak til Peter Larsen for en fantastisk (og gratis) service :-)

Illustration: Privatfoto

Næste afsnit kommer til at handle om SSL-sikret webmail, IMAPS og sikker SMTP.

Kommentarer er meget velkomne :-)

/pto

Kommentarer (43)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kim Østergaard

Kære Peter,
Hvor er det dejligt at du tager emnet med SPF og DKIM op. Vi kæmper en daglig kamp, for at forklare IT-chefer vigtigheden af det. Kun nogle få procent af vore kunder har rent faktisk en SPF record, når de tjekker ind som kunder.

Vi har skrevet en artikel på dansk om vigtigheden af SPF og DKIM:
http://mailplatform.dk/udvalgte-funktioner/sadan-anvendes-spf-og-dkim/

Kim

  • 0
  • 0
Arne Jørgensen

Jeg har også opsat SPF, DKIM og DMARC på mit maildomæne.

Eftersom alle tre elementer bruger DNS til at publicere data om hvordan mail fra dig skal behandles så kan du højne sikkerheden for at de publicerede informationer er korrekte ved at smide DNSSEC på dit domæne.

Modtager af mail kan dermed tillægge validiteten af mails fra dig endnu højere troværdighed hvis de verficerer at dine DNS-records ikke er blevet manipuleret.

Hvis man skriver til mailinglister skal man være lidt opmærksom med at stramme DMARC-skruen idet de fleste mailinglister manipulerer med indholdet af din mail (fx med unsubscribe info nederst i mailen) og dermed invaliderer din DKIM-signatur.

Jeg kan, ligesom Henrik, anbefale https://dmarcian.com til opsamling af DMARC-rapporter.

  • 1
  • 0
Jesper Knudsen

Vi har i ScanMailX været med til at udvikle og teste de første varianter af DMARC og har også support for dette i vores system. Som nævnt af Arne, så er det faktisk vores konklusion at DMARC ikke er super anvendeligt for domæner hvor post sender af "rigtige" mennesker. DMARC bruge idag af f.eks Facebook, men kun på deres facebookmail.com domæne som er robotter og ikke på deres medarbejders mail domæne.

En god måde at teste om du har sat SPF/DKIM/DMARC op på er at sende en mail til check-auth@verifier.port25.com eller checkmyauth@auth.returnpath.net - de sender så en rapport tilbage.

  • 0
  • 0
Jesper Knudsen

Jeg skulle have lavet en nyere check-up, kan nu også se at googles.com som er google staff domæne og gmail.com kører DMARC dog kun med p=none (blot data opsamling). Problematikken med mailing lister og dertilhørende forwards, hvor SPF bare alene ofte skaber problemer, forstærkes blot.

  • 0
  • 0
Henrik Schack

Problematikken med mailing lister og dertilhørende forwards, hvor SPF bare alene ofte skaber problemer, forstærkes blot.


Jamen det er da rigtigt gammel mailinglistesoftware kan give udfordringer i en overgangsperiode.
Sådan er det jo tit med nye sikkerhedstiltag, folk var også skide trætte af det da det blev lov man skulle have sikkerhedssele på i bilen, det var jo slet ikke til at komme hurtigt ind og ud af en bil. Idag kan de fleste godt se fornuften i en sikkerhedssele frem for at bruge forruden som udgang :-)

  • 0
  • 0
Henrik Schack

De reagerer tilsyneladende ikke på SPF.


Jeg tror ikke der er mange af de store mailudbydere som
konsekvent afviser email alene på baggrund af en SPF record som fejler.
Der eksisterer ganske enkelt for mange SPF records som er smidt på med en møgskovl.
Selv blandt helt store firmaer kan man se groteske fejl i SPF.

Et par eksempler:

En SPF record må ifølge RFC'en ikke "koste" mere end 10 DNS opslag at anvende.

nykredit.dk SPF recorden koster 162 opslag og indeholder iøvrigt også en tastefejl
https://dmarcian.com/spf-survey/nykredit.dk

Nets anvender 22 DNS opslag og har ikke helt styr på teknikken.
https://dmarcian.com/spf-survey/nets.eu

Hos Basisbank går det heller ikke for godt med SPF

https://dmarcian.com/spf-survey/basisbank.dk

  • 0
  • 0
Baldur Norddahl

DMARC har to funktioner. Den ene er at sende rapporter, som tidligere omtalt. Jeg bruger også dmarcian.com til dette.

Den anden funktion er ofte overset eller misforstået. DMARC "fikser" SPF og DKIM. De to er nemlig ikke så meget værd alene, som mange tror.

En mail har to afsender felter. Det ene kalder man "SMTP envelope MAIL FROM". Det er populært sagt adressen der er skrevet uden på konvolutten på brevet. Den anden er "FROM" headeren. Den sidste er hvad der faktisk vises til brugeren. Problemet er at SFP kun verificerer "SMTP envelope MAIL FROM".

Spammeren kan simpelthen skrive "spam@kina.com" i SMTP envelope MAIL FROM, et domæne uden SFP, så alt er fint. Og så kan han skrive "skat@skat.dk" i FROM feltet, som er det der vises til brugeren. Det er ligemeget at der er en SFP på skat.dk, da det aldrig tjekkes.

DMARC tilføjer et sæt regler for hvordan de to FROM felter skal relateres. Hvis der findes en DMARC for skat.dk, så vil modtager-mailsystemerne bruge denne DMARC information til at undersøge om det er ok, at en mail med skat.dk i FROM bruger kina.com som SMTP envelope.

For DKIM er der et tilsvarende problem. Ren DKIM indeholder ikke noget system, hvorved domæne ejeren kan angive at DKIM er et krav eller ej. Så spammeren kan simpelthen undlade at DKIM-signe spam mails. Eller han kan DKIM-signe mailen med et urelateret domæne. DKIM virker desuden ved at man angiver hvilke felter der er signede. Spammeren kan angive ekstra felter der ikke er signede, herunder et ekstra FROM felt, som han så snyder din mail klient til at vise.

Her tilføjer DMARC et system, hvorved modtageren kan undersøge i hvilke situationer, han kan forvente at en mail er korrekt DKIM-signet.

Og endelig så giver DMARC din mail to chancer for at "bestå". DMARC specificerer at det er nok at blot én af SPF eller DKIM tjekene er ok. Der findes tilfælde hvor SPF fejler (email forwarding) og hvor DKIM reder dagen. Omvendt er der nok ikke så mange tilfælde hvor DKIM fejler, medmindre du har en fejlopsætning - men da DKIM ikke er så udbredt som SPF, så er det en meget god ide med SPF som backup alligevel.

  • 1
  • 0
Baldur Norddahl

Hvordan skal man forholde sig til SPF, DKIM og DMARC på en mailserver som forwarder den post den modtager på sine domæner til trediepart (fx. gmail)?

Det afhænger af afsender-domænet på den mail der skal forwardes. Der er følgende muligheder:

Case 1: Ingen SPF, DKIM eller DMARC

Du forwarder bare mailen.

Case 2: SPF uden DKIM eller DMARC

Du kan bruge SRS: http://www.openspf.org/SRS

Case 3: DKIM med DMARC. Eller DKIM uden SPF

Du forwarder bare mailen.

Case 4: SPF og DKIM, uden DMARC

Fjern DKIM signaturen og brug SRS.

case 5: SPF med DMARC, uden DKIM

Mailen kan ikke forwardes, send den tilbage til afsender.

Jeg kender desværre ikke noget projekt der implementerer ovenstående regler.

  • 1
  • 0
Kim Østergaard

Helt enig, vi overvejer også at differentiere det i vores engine, og dermed målrette de forskellige ISP'er, men det er et stort arbejde hvor vi ikke vil forvente at se nogen forbedret leveringsevne.

Mange derude har desværre for svage DKIM krypteringer, her er der noget at hente ved at lægge den i 1024 eller højere.

  • 0
  • 0
Baldur Norddahl

Helt enig, vi overvejer også at differentiere det i vores engine, og dermed målrette de forskellige ISP'er, men det er et stort arbejde hvor vi ikke vil forvente at se nogen forbedret leveringsevne.

Det kunne jo være et krav fra en kunde, som har valgt at beskytte deres domæne med DMARC.

SPF kan kunden klare med en include, men DKIM er noget i må supportere for dem. Men jeg forstår ikke helt - tidligere i tråden sendte du et link der antyder i allerede har fuld support?

Hvis i allerede har DKIM, så er DMARC jo ikke andet end en DNS opdatering.

  • 0
  • 0
Jens Jönsson

"Jeg kan stramme den ved at anvende "-all" fremfor "~all" - det er en anbefaling af, at man smider emails fra domænet "petertoft.dk" væk med mindre de kommer fra mail-serveren."

Så gør dog det, hvad kan man bruge ~all til ?

"SoftFail - The SPF record has designated the host as NOT being allowed to send but is in transition - accept but mark "

Vil du eller vil du det måske ?

SPF er >ikke< bulletproof. De fleste SPAM filtre kigger på SPF og sender e-mail med ~all videre, endda uden nogen nævneværdig score. Med andre ord tæller ~all ikke og der bliver kigget på andre parametre, før det vurderes om e-mailen er SPAM.

Brug ~all til det formål det er lavet til, nemlig test....

  • 0
  • 0
Vijay Prasad

Hej Peter.

Spændende serie. Jeg står lige pt. med håret i postkassen og skal stå for bla. post-server til afdelingen på mit universitet med godt 50 ansatte og 1000 studerende (og, de vil af tåbelige årsager ikke bare vil bruge MS eller Google's gratis tilbud).

Hvad jeg godt kunne tænke mig videre i serien, er lidt om hvad man gør for ikke at miste mails (jeg har mange brugere, men, du har måske, ligesom jeg, mails fra tilbage i 90erne, som du gerne vil beholde) og generelt holde systemet "friskt" (der har være lidt i sysadmin delen, men mest fokus på opdateringer af pakker, tænker mere på hvad man kan gøre for at minimere nedetid).

Mvh,

PS: Linker gerne til vores setup når jeg engang har det implementeret, ud over post er det også hjemmesider og fildeling til studerende/ansatte -- det hele planlagt til at køre på 8-10 RaspPI'ere.

  • 0
  • 0
Henrik Schack

Er du sikker på, at I ikke sender mails fra andre mailservere, skal du klart bruge -all (altså hard fail).
Du skal IKKE have en anden host end selve domænet på din SPF. Der er ALENE din TXT value der skal være "v=

I forhold til DMARC er det uden betydning om man anvender -all ~all eller ?all
DMARC kræver en PASS for at være aligned, så det der betyder noget er at man får listet alle valide senders.

  • 0
  • 0
Peter Toft

Hvad jeg godt kunne tænke mig videre i serien, er lidt om hvad man gør for ikke at miste mails (jeg har mange brugere, men, du har måske, ligesom jeg, mails fra tilbage i 90erne, som du gerne vil beholde) og generelt holde systemet "friskt" (der har være lidt i sysadmin delen, men mest fokus på opdateringer af pakker, tænker mere på hvad man kan gøre for at minimere nedetid).

Og det skal køre på R-PI?? Det ville jeg ikke. Du får slet ikke den ydelse af f.eks. en IMAPS server, du gerne vil have på den platform.

Jeg vil i øvrigt foreslå at du laver backups enten via en Netapp filer (som kan det ud af boksen), eller en rsync (diff-backup) løsning. Det vigtige er at publicere til ledelsen og medarbejdere hvad du garanterer af backup-stategi. Hvor ofte og hvor langt tilbage du beholder, og hvor ofte laves off-site backup.

  • 0
  • 0
Baldur Norddahl

Er du sikker på, at I ikke sender mails fra andre mailservere, skal du klart bruge -all (altså hard fail).

Det vil være dumt, hvis du altså gerne vil kunne skrive til alle.

-all er inkompatibelt med email forwarding og det er altså ret brugt. Hvad fortæller du din direktør, når han pludselig ikke kan skrive til en vigtig kunde?

Med ~all er der en chance for at mailen havner i spam folderen, men det er trods alt noget folk kan forholde sig til.

BOFH http://da.wikipedia.org/wiki/Bastard_Operator_From_Hell holdninger er ikke konstruktive.

  • 0
  • 0
Jens Jönsson

Legacy modtagere der kun har SPF support bør ikke smide mails væk på baggrund af et system der ikke fungere 100%. Derfor ~all til legacy modtagerne.

Jeg er så glad for at du siger "bør ikke smide mails væk".

Jeg vil da gerne smide mails væk, hvis jeg tror de er SPAM. Det er vel sådan SPAM filtre virker ?
Konfigurerer man SPF, så må man i min optik også teste om det virker og ikke køre med noget "halvkonfigureret". Hvad er ideen i det ? Man må konfigurere så der såvidt muligt fungere så tæt på de 100%.

Jeg er enig i at SPF ikke er guds gave til at bekæmpe SPAM og det kan også godt omgås, men det er en del af en større løsning. Det er forholdsvist nem at konfigurere (ingen har sagt at e-mail er nemt), og resultatet er forholdsvist stort i fht. indsatsen (For afsenderen, færre afviste e-mails, det er min erfaring)
Men det bliver jo faktisk ikke nemt at forholde sig til, hvis alle bare bruger "~all".

Det er muligt at jeg har misforstået noget, men er du så ikke rar at prøve at forklare nærmere ?

  • 0
  • 0
Michael Rasmussen

~all er i min optik, kun noget man anvender, såfremt man ikke er helt sikker på sit eget setup, og har intet med legacy at gøre. Hvad andre gør har man ingen inflydelse på alligevel, så såfremt man er sikker på sit eget setup, kan man roligt anvende -all. Hvis man ved, og er interesseret i, at al mail fra ens domæne kun skal afsendes fra servere nævnt i sin SPF, har jeg svært ved at se, hvorfor man skal annoncere for omverdenen: Mail fra mit domæne kommer kun fra foo eller bar, men modtager i mail fra andre, er det kun måske, det ikke kommer fra mig!

  • 0
  • 0
Micki Pedersen

Hej Michael,

Sådan som jeg forstår det Baldur tidligere i tråden har nævnt, så er der den ulempe at SPF tagget -all blockerer mailforwarders.
Så det er kun bullet proof hvis man altid ved at der i den anden ende af de adresser man skriver til ikke er en maildistributionsliste/mailforward. Og det kan man vel aldrig være?

Så er der noget der hedder SRS, men så vidt jeg kan læse der, er man afhængig af at modtagerens mailforwarder understøtter det, og så er man jo lige vidt.

Derfor bør DKIM signeringen + DMARC være den primære mekanisme i at begrænse misbrug fra sit maildomain.

Jeg er lidt i tvivl om man bør droppe SPF helt eller ej. Hvad er fordelen, når man bliver nødt til at ty til ~all. Bliver den gradueret på en fornuftig måde i SPAM-filtreringen (fx ved at mails fra mailforwarders bliver greylisted/delay'ed), der så retfærdiggør at vi skal stadig skal bruge den, på trods af at vi bruger ~all og ikke -all?

  • 0
  • 0
Baldur Norddahl

Jeg vil da gerne smide mails væk, hvis jeg tror de er SPAM. Det er vel sådan SPAM filtre virker ?
Konfigurerer man SPF, så må man i min optik også teste om det virker og ikke køre med noget "halvkonfigureret". Hvad er ideen i det ? Man må konfigurere så der såvidt muligt fungere så tæt på de 100%.

Det er ikke DIT setup der er problemet. Det er modtagerens setup. Og det har du ingen kontrol over.

De mailsystemer jeg beskæftiger mig med har to niveauer af spam filtrering. Det meste spam bliver sendt til en spam folder. Kun det spam som systemet med garanti ved er spam bliver automatisk slettet eller nægtet modtaget. Gmail er et eksempel som fungerer sådan.

-all betyder slet.
~all betyder sæt mailen i karantæne = send mailen til spam folderen.

Normalt læser brugeren ikke spam folderen, men hvis man står og venter på en vigtig mail, så er det et godt sted lige at tjekke.

Det er muligt at der er systemer der helt ser bort fra ~all men det er stadig bedre end -all som er known broken.

Igen igen, hvis modtageren har valgt at videresende post til en email adresse til en anden, så fejler SPF. Det er ret almindeligt at folk har mange email adresser men ønsker at læse det hele ét sted. Så de bruger email forwarding til at sende videre til én adresse. Det resulterer i at din email ikke ankommer direkte fra din SMTP server men i stedet fra den SMTP server som står for at videresende - bam SPF tjek fejlet. Du argumenterer for hardfail, hvilket betyder at mailen ikke kommer frem. Du siger at det ikke er en fejl i din ende, afsenderen er en af dine ikke teknisk kyndige brugere, modtageren er hellere ikke teknisk kyndig og har iøvrigt ingen indflydelse på opsætningen. Det er en BOFH holdning. Dine brugere kan ikke sende mails til ønskede modtagere og det ER dit problem.

Dertil kommer at SPF ikke i sig selv beskytter imod spam. Uden DMARC er konceptet simpelthen ikke noget særligt værd. Det forhindrer ikke at spammeren bruger dit domæne i From: feltet, så hvad er pointen? Du pisser på brugerne uden noget gain.

Hvis derimod modtageren har DMARC support, så har 1) ~all/-all ingen betydning, 2) systemet begynder pludselig at give mening, nu er der beskyttelse imod at spammeren forfalsker From:, og 3) vi har DKIM til at løse forward problemet.

  • 2
  • 0
Baldur Norddahl

Jeg er lidt i tvivl om man bør droppe SPF helt eller ej. Hvad er fordelen, når man bliver nødt til at ty til ~all. Bliver den gradueret på en fornuftig måde i SPAM-filtreringen (fx ved at mails fra mailforwarders bliver greylisted/delay'ed), der så retfærdiggør at vi skal stadig skal bruge den, på trods af at vi bruger ~all og ikke -all?

Hvis modtageren har DMARC support, så er der ingen forskel på ~all og -all. DMARC har et nyt sæt regler der har højere prioritet end SPF.

Hvis modtageren ikke har DMARC så kan ~all muligvis antyde at der kan være tale om spam. Måske bedre end ingenting.

Og sidst så tæller ~all som PASS i DMARC hvis nu du har lavet fejl i din DKIM-opsætning. Så det er en ekstra chance i tilfælde af fejl i dit setup. Virker naturligvis kun hvis modtageren ikke bruger email forward.

  • 1
  • 0
Baldur Norddahl

Mail fra mit domæne kommer kun fra foo eller bar, men modtager i mail fra andre, er det kun måske, det ikke kommer fra mig!

Fordi det er fakta et kun er måske, at det ikke kommer fra dig. SMTP har lige fra fødslen haft mulighed for at sende mails videre. Det forsøgte SPF at ændre, men de fik aldrig brugerne med på ideen. Email forward er ligeså populært som det altid har været.

Så er der dem der siger at brugerne må lære at bruge POP3/IMAP til at flytte post fra en email konto til en anden, men det er bare 100 gange sværere at sætte op og ikke altid muligt.

Du har netop ingen kontrol over hvad andre gør. Derfor kan du ikke forlange at de skal droppe email forward.

  • 0
  • 0
Micki Pedersen

Hej Baldur,

Tak for uddybelsen og præcisionen. (SPF med -all er selvfølgelig no-go.)

Mit dilemma består i om jeg jeg/man bør droppe SPF helt - for ikke medvirke til at mine mails til modtagere med mailforwarders ender i spam for de modtagere der understøtter SPF men ikke DKIM og DMARC - det vil jeg nemlig nødig!

Ulempen er selvfølgelig at jeg så risikerer at der kommer for meget spam ud fra mit domain, fordi jeg ikke tilgodeser de mailservere som understøtter SPF men ikke DKIM og DMARC.

For at kunne afgøre mit dilemma bør jeg nok sætte mig lidt bedre i hvordan spamfiltre vurderer på baggrund af SPF (hvor meget "vægt" / points har det at SPF fejler) og lidt til hvilke mailservere der understøtter hhv SPF men ikke DKIM og DMARC. Findes der mon en liste med de info på de største mailudbydere?

Jeg er på nippet til at mene at jeg slet ikke bør have SPF, velvidende at det gør at modtagere (mailservere) der ikke kigger på min DKIM og DKIM så vil modtage noget mere spam end ellers fra mit domain. Hvad er dine tanker om det?

  • 0
  • 0
Povl H. Pedersen

-all er det eneste rigtige. Hvis man laver forwards, så må man whiteliste de afsender der fejler et SPF check.

Et af de store problemer lige nu er, at Microsoft kæmper en hård kamp for teknisk at smadre SPF totalt. Hvis man rykker mail til skyen (Office365) og inkluderer Microsofts SPF record i sin egen, så har man brugt 8 ud af de 2 DNS resolutions man må have i en SPF. Første level har de 4 og næste level inkluderes 3 mere + den enes for at inkludere MS. Så 7 + den ene for at inkludere MSFT. Så er der kun plads til 2 ekstra a, mx eller lign inden man rammer limit og alt vil fejle. Men det undrer ingen, Microsoft har aldrig været glade for Internet, og er vel stadig pigesure over at NetBoy (NetBEUI) ikke blev standarden.

Problemet med for lange SPF records efter skift til Office365 er observeret i flere tilfælde. For det er normalt for en virksomhed at have flere a: records, eller mx record, eller inkludere SPF fra en reklamespreder.

Som jeg ser det, så er man, såfremt man bruger Microsoft næsten nødt til at sætte noget DNS op til at svare på "exists" forespørgsler a'la RBL blacklists. Undrer mig at Microsoft ikke har gjort det endnu, fremfor deres killer SPF. Det vil være en stor dag når de begynder at tænke sig om.

Man kan så regne på om RBL style exists giver flere eller færre opslag. Men det kan begrænses til max 2 per mail. 1 for SPF recorden, og en for IP adressen.

  • 0
  • 0
Henrik Christian Grove

-all er det eneste rigtige. Hvis man laver forwards, så må man whiteliste de afsender der fejler et SPF check.

Så du mener at alle der abonnerer på en af de port-lister jeg kan finde på at skrive til skal white-liste mig? (post-liste-serveren videresender jo.) Det skalerer exceptionelt dårligt.

  • 0
  • 0
Jeppe Bundsgaard

Hej Peter
Dette er godt nok en gammel diskussionstråd - men måske overvåger du den stadig? Jeg har fulgt din DKIM-vejledning og det virkede! Vores mail er nu ikke længere spam hos Google. Tak!

Jeg har flere domæner på samme server som sender mail, og det er jo ikke noget problem fra DKIMs synspunkt. Men på GratisDNS får jeg et problem som jeg ikke kan finde en løsning på - måske du eller andre der lytter med har en ide. Problemet er at jeg har en domænetemplate, og i opsætningen af den, kan jeg ikke oprette txt-records til de enkelte domæner.

Det vil sige at jeg lige nu sender følgende:
mail._domainkey.domæne.template
v=DKIM1; h=rsa-sha256; k=rsa; s=email; p=MIGfMA0GCSq...

På mit hoveddomæne bundsgaard.net fungerer det fint, for det er den dertil hørende nøgle jeg udsender. Men alle de andre domæner sender jo også denne nøgle, og så er det jo ikke så smart.

Så vidt jeg kan gennemskue, kan jeg ikke lave den samme nøgle for alle domæner, fordi der i nøglen er oplysning om domænenavnet...

Har du en ide?
Eller kender du eller I andre et forum hvor jeg kan stille spørgsmål om mailopsætning og dns?

  • 0
  • 0
Log ind eller Opret konto for at kommentere