Ja, dat was ik, maar iets minder ongenuanceerd. Zet SPF op ~ (oftewel softfail) en DKIM op verplicht. SPF was ziek, is ziek en zal ziek blijven... We lopen regelmatig aan tegen bedrijven die SPF op fail hebben staan en kunnen dan niet forwarden. Nee, we gaan niet onze software minder scherp instellen.

SPF op softfail heeft het voordeel dat spamfilters alsnog getriggerd kunnen worden (het telt mee in de uiteindelijke score).

DKIM geeft uiteindelijk 100% zekerheid want is een goede cryptografische handtekening.

Vergeet niet ook DMARC in te richten!

Technisch werkt het dus goed. Immers die host mag ook niet de email versturen namens dat domain en een forward valt daar ook onder. Dit is juist wat SPF aangeeft. Welke hosts Email mogen verzenden namens het domain.
Is SPF ideaal, nee absoluut niet.

SPF op softfail heeft het voordeel dat spamfilters alsnog getriggerd kunnen worden (het telt mee in de uiteindelijke score).
DKIM geeft volgens mij alleen maar aan dat deze email verzonden was door een gecontroleerd systeem. Het zegt niet iets over mogelijke andere hosts die ook namens het domain E-mail kunnen/mogen verzenden.

In de mail bovenaan https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 zie je waarom uitsluitend SPF plus DKIM niet verhindert dat kwaadwillenden mail sturen met jouw domeinnaam in het From veld (in het voorbeeld is dat gmail.com, maar dat had natuurlijk ook jouw domein kunnen zijn).

Met DMARC kun je dat afdekken.

Er resteert dan nog wel een (vaak groot) ander probleem: kwaadwillenden kunnen onbeperkt experimenteren met domeinnamen die lijken op jouw domein (zie bijv. [1]).

[1] https://www.security.nl/posting/478698/Oplichters+gebruiken+domeinen+met+nl-prefix+voor+ceo-fraude

Softfail SPF > DKIM > DMARC.

Google is vaak helder of dit soort technieken: https://support.google.com/a/answer/2466580?hl=nl.

De implementatie in bijvoorbeeld PHP of .NET is ook vrij simpel als je de achterliggende gedachte maar snapt;
Enkele voorbeeld bronnen;
PHP: https://github.com/PHPMailer/PHPMailer/blob/master/test/phpmailerTest.php#L1251
.NET: https://github.com/dmcgiv/DKIM.Net

Succes!

Ja, dat is logisch: blijkbaar handelt google de mail voor dat bedrijf af, en google doet wel degelijk aan SPF, DKIM en DMARC. :) Inrichten dus is het devies. Zo moeilijk is het niet.

@Rolfeo: met DKIM/DMARC kun je wel degelijk de verzender beschermen: je bent immers de enige met de geheime handtekening? Het is een Public/Private key systeem waarbij de public key in DNS staat. Daarmee kun je dus de verzender uniek en veilig identificeren (wel van keys uit gaan die lang genoeg zijn zoals google al eens heeft ondervonden...).

Je hebt feitelijk SPF niet nodig (wel inrichten en op softfail zetten) mits je DKIM en DMARC gebruikt.

Correct.

Dat is onjuist.

SPF is het enige protocol van de drie waarmee wordt vastgelegd welke mailserver(s) (d.w.z. de IP-adressen ervan) namens jouw domein e-mail mogen zenden.

Uit de PDF v1.0 te vinden via [1]:
[1] https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html

Gebruik geen SPF, DKIM of DMARC, je roept er alleen maar problemen mee op die geen enkel doel dienen. Als ze al een doel dienen, is het niet in het voordeel van jouw organisatie, maar dat van anderen. En dan nog is het enorm beperkt. Want wie gaat jouw domein gebruiken om een ander mail te sturen? Dat gebeurt voor 99% van de domeinen zelden of nooit en zeker niet bij ontvangers die ooit iets met je te maken (willen) hebben.

Uitzonderingen daargelaten (zoals banken of gemeenten). Denk na en volg niet zo maar de kudde. Spring niet in de sloot omdat anderen dat doen.

Gebruik in plaats daarvan authenticatie signing met certificaten of GPG met trustrelaties. Dat is echte afzenderauthenticatie.

Als je ook DMARC instelt, hoeft maar een van SPF/DKIM correct te zijn. De ander mag falen. IK zie in mijn DMARC rapportages regelmatig dat SPF faalt vanwege forwarding, maar die mail komt gewoon aan omdat DKIM klopt. Forwarding gaat natuurlijk wel mis als de ontvanger geen DMARC maar wel SPF controleert.

Forwarding is een slechte methode omdat dit binnenkomende mail oncontroleerbaar maakt. Beter is het niet te forwarden, maar als ontvanger de mail via POP3 op te halen.

Doordat DKIM de authenticiteit van het bericht bewijst is het een prima methode om samen met DKIM eenduidig de verzendende mailserver als legitiem te kunnen betitelen. Je leest de factsheet niet goed (genoeg). Er staat niet dat je SPF nodig hebt, enkel dat DMARC nodig is. SPF is niet nodig. We doen niet anders, en zijn best een hele grote, en heel veel gephishte partij. :)

De factssheet is niet duidelijk genoeg. Ik zal daar eens een boompje met ze over opzetten.

Het doel van SPF+DKIM+DMARC is niet het verhinderen dat jouw mail aankomt (hoewel het al snel een ongewenste bijwerking kan zijn), maar het verhinderden dat derden namens jou (althans, namens jouw domein) kunnen mailen.

Met welk doel pas jij dan überaupt nog DKIM en DMARC toe?

Nee, dat doet een DKIM header niet:
- zo'n header bewijst slechts dat het bericht en (door de verzender!) gekozen headers niet zijn gewijzigd sinds ondertekening door die verzender;
- zo'n header bewijst niet dat de verzender geautoriseerd is om dat namens het domain in het From veld te doen. In plaats daarvan staat in de DKIM header zelf waar het certificaat voor het controleren van de handtekening vandaan gehaald moet worden; het is dus een koud kunstje om die naar een DNS record van de aanvaller te laten wijzen;
- zo'n DKIM header kan bovendien door een MTA (mailserver) onderweg worden verwijderd en desgewenst kan er een totaal andere aan worden toegevoegd (na wijziging van elke informatie naar keuze).

De klassieke fout die hier gemaakt wordt is ervan uitgaan dat als iets digitaal gesigneerd is, het wel goed zit - waarbij vergeten wordt betrouwbaar vast te stellen wie gesigneerd heeft.

In regel 04) in [1] zie je dat een mail zogenaamd van een gmail.com afzender digitaal is ondertekend door ip8.rp01.net - dat zegt natuurlijk geen ruk.

Nee, want het enige dat jouw DMARC record doet is eisen dat er een DKIM header in de mail zit, niet wie die DKIM header heeft toegevoegd (en de handtekening heeft gezet), noch wat daar in moet staan!

Als gmail.com geen SPF maar wel DKIM en DMARC zou vereisen, had de aanvaller in [1] zonder DMARC warrning spam kunnen versturen (bijv. vanaf zombie PC's).

Je denkt te weinig vanuit het perspectief van de aanvaller! Het is een kwestie van tijd voordat aanvallers dit doorhebben voor jouw domain...

Het lukte mij niet NCSC ervan te overtuigen een update uit te brengen omdat er een fout in staat, wil je ze daar even aan herinneren? Tnx!
Bij een kringeltje is dat soft fail, de beschrijving suggereert hard fail (dan had er een minnetje moeten staan).

[1] https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29

Ik wil alle lezers mijn excuses maken, want ik denk dat ik een verkeerde aanname heb gedaan.


Mijn aanname dat DMARC niet checkt "wie die DKIM header heeft toegevoegd (en de handtekening heeft gezet)" is onjuist, want uit [1] maak ik op dat de domainname achter "From:" moet overeenkomen met de domainname achter "d=" in de DKIM header (in de default "relaxed mode" mag er ook een subdomain achter "From:" staan. Voorbeeld: een e-mail adres achter "From:" dat eindigt op @test.example.com matcht op "d=example.com" uit de DKIM header).

Dit suggereert dat het voldoende is om slechts DKIM en DMARC te gebruiken, dus zonder SPF; ik vermoed echter dat het slecht idee is om geen SPF te gebruiken. Voordat ik dat schrijf waarom, wil ik dat dubbel-checken - maar ik heb zo een afspraak, dus dat komt later.

Nogmaals mijn excuses!

[1] https://tools.ietf.org/html/rfc7489#section-3.1.1

Dank voor je excuses Erik! Ik meen echt dat ik een en ander goed heb begrepen (en het werkt ook echt!). :)

SPF op softfail werkt echt perfect. Helaas doen de grote providers Ziggo en KPN nog niet mee (dom, want het scheelt ze heel veel spam). We zijn druk aan het lobbyen om ze wel mee te krijgen.

DMARC werkt. We zien het in de cijfers... :)

Tussen 13:00 en 15:00 heb ik vanmiddag 4 spams ontvangen met respectievelijk:
From: "Intrum support" <REDACTED#1_AT_imagique.nl>
From: "Intrum support" <REDACTED#2_AT_jeetjes.nl>
From: "Intrum Support" <REDACTED#3_AT_ajaxchubbvarel.nl>
From: "Intrum support" <REDACTED#4_AT_accessis.nl>

Als genoemde domeinen SPF, DKIM en DMARC hadden gebruikt, waren deze spams (met een idioot lange link eindigend op Factuur.scr, malware dus) tegengehouden door alle ontvangende mailservers die genoemde protocollen ondersteunen (het slechts gebruiken van SPF had overigens al volstaan, omdat de spammers in bovengenoemde spams hetzelfde afzenderadres achter From: als achter Return-Path hebben opgenomen - maar dat is eerder uitzondering dan regel).

Omdat de meeste e-mail ontvangers niet snappen dat afzenderadressen eenvoudig vervalst kunnen worden (en deze mythe door veel vertrouwde organisaties in stand gehouden wordt) zullen ontvangers van dit soort spams denken dat de getoonde afzenderadressen de daadwerkelijke afzenders zijn - terwijl deze spams vanaf zombie-PC's zijn verzonden (resp. 117.211.134.134, 14.182.146.220, 186.233.176.35 en 45.243.46.253) en genoemde domeinen daar niets mee te maken hebben.

Of de spammers in dit geval volledige bestaande afzenderadressen hebben gebruikt (dus niet random_naam@domein), weet ik niet. Zo ja dan is het gevolg daarvan meestal dat de schijnbare afzenders veel rommel en verwensingen naar hun hoofd geslingerd krijgen, en wellicht daarop weer menen te moeten reageren (met escalatie en verder onbegrip als gevolg).

Door bij het zenden van e-mail SPF, DKIM en DMARC toe te passen, kun je, in veel gevallen, imagoschade (en frustraties van medewerkers indien volledige afzenderadressen zijn misbruikt) helpen voorkomen.

Ongeacht of je dat doet is het zeer verstandig om bij ontvangst op die protocollen te checken. Naast dat je de werkelijke afzenders daamee een dienst verleent, beperk je ook de hoeveelheid spam (inclusief phishing en ransomware mails) in inboxes van je medewerkers. Zaligmakend is dit overigens niet zoals ik eerder al aangaf.

Ik ben dan niet van Straaten, maar wel een Erik. Ja, SPF/DKIM/DMARC is de enige manier die spam en ook phishing (veel algemener dus) tegengaat mits goed ingericht, en mits de ontvanger het goed ondersteund. Zoals al eerder vermeld werkt het prima. Tevens wordt de deliverability van legitieme mail verhoogd (je bewijst immers te zijn wie je zegt te zijn).

KPN, Ziggo, leest u mee? Gaat u het eindelijk ondersteunen? Het scheelt u namelijk geld. Veel geld. Uw mailservers krijgen minder mail te verwerken omdat het aan de buitenkant wordt geblokkeerd. Kans op fout positief en fout negatief is zo goed als 0 (tenzij de verzender dom doet, en dan is het eigen schuld, dikke bult).

O, ik ben degene die al eerder poste:

25-07-2016, 08:27
25-07-2016, 11:30
26-07-2016, 09:45

"implementeren" heeft twee betekenissen hier.

Door als ISP te *controleren* op SPF/DMARC/DKIM kun je een zeker percentage spam redelijk vroeg in de mailafhandeling tegenhouden.
Mogelijk zelfs dat KPN of Ziggo dat al doen - je moet daarvoor klant zijn om te zien of ze dat doen .(aan je mail)
Waarom je trouwens denkt dat dat "veel geld" scheelt zie ik niet zo erg . Heb je een echte business case ?
Of denk je alleen dat "technisch mooi" ook meteen "veel geld" betekent ?

Als ISP zelf SPF record publiceren, en headers met DMARC signen helpt de ISP _niet_ tegen inkomende spam .
Het helpt alleen *andere* ISPs die SPF/DMARC/DKIM checks doen om mail gespoofed met afzender vanuit de publicerende ISP tegen te houden.
Dat is wat KPN / Ziggo nog niet doen. - (dat is wel van buiten te zien, aan de ontbrekende DNS records ).

Overigens kan het een eindgebruiker echt niet schelen dat het de "de schuld" is van "de afzender" vanwege SPF/DKIM/DMARC/RDNS of nog meer rare technische termen , de eingebruiker wil alleen maar dat mail "het gewoon doet" .
En die heeft (terecht) niet zo veel boodschap een technerds die zeggen "eigen domme schuld"

@anoniem 28-7-2016 14:32 Erik hier:

Implementeren als in controleren. Toevoegen voor verzenden zou leuk zijn, maar biedt inderdaad weinig toegevoegde waarde voor KPN en Ziggo zelf. Als KPN en Ziggo het gebruiken voor controleren van binnenkomende mail dan heeft dat 2 grote voordelen:

- bescherming van de klant voor phishing mail van banken, verzekeringsorganisataties, maar ook webwinkels en dergelijke voor phishing op domeinnaam van de betreffende organisatie.
- Derhalve goed voor de reputatie van de ISP (vergelijk XS4ALL in dit opzicht die dit al heel lang doen).
- reductie in inkomende spammail, resulterend in uitgestelde of verminderde investeringen in ontvangende mail clusters, het mailvolume neemt significant af. Dus minder hardware, en dus minder beherende capaciteit nodig.

Dit is een hele simpele business case die niets met 'mooi' te maken heeft, en als jij het belang er niet van ziet is dat jouw probleem.

Bij een ISP waar ik gewerkt heb konden we 'het' ineens af met een cluster van 4 machines in plaats van 20 machines die scanden, en konden we ineens de database cluster weer gebruiken waar die in eerste instantie voor was aangeschaft: database dingen doen in plaats van spammailtjes ontvangen. 90% minder spam op die cluster was redelijk significant. Al een jaar of 10 geleden overigens, toen DMARC nog niet bestond en toen bleek dat SPF een prutsoplossing was. DKIM stond in de kinderschoenen.

Een eindgebruiker heeft wel degelijk een mening over binnenkomende spam en zeker over phishing: 'daar moet de ISP mij tegen beschermen'. Als de ISP dat inderdaad kan dan is dat win-win-win (klant, isp en legitieme verzender).

Ik geloof toch niet dat ik DMARC helemaal snap, eerder schreef ik (daarbij mijn excuses makend):
Echter ik ontvang e-mails met daarin twee DKIM headers, met twee verschillende "d=" domeinen, en toch worden die goedgekeurd!

Ik licht mijn vraag toe aan de hand van een analyse van zo'n e-mail, naar verluidt afkomstig van Ziggo - in relatie tot een opmerking van een Anomien eerder in deze thread.

Ziggo zelf weet ik niet, maar alle (vermoedelijk legitieme) mailings van Ziggo die ik ontvang, worden verzonden via mail servers van brightbase.net die kennelijk van dezelfde eigenaar zijn als het domein mailplus.nl (zie ook [5] voor een voorbeeld van wat ik bedoel).

Voorbeeld van een e-mail met 2 DKIM headers
Sinds 13 juli 2015 (ruim 1 jaar geleden dus) heeft mailplus.nl haar zaken zo te zien redelijk voor elkaar, want steevast zie ik sindsdien in door mailplus.nl namens Ziggo verzonden mails de volgende header (toegevoegd door mijn ISP Xs4all.nl):
waarbij ik de @ achter ziggo.contact door een . heb vervangen (en, voor de duidelijkheid, relevante entries op 1 regel gezet).

Ik schreef dat "mailplus.nl haar zaken zo te zien redelijk voor elkaar" heeft, want uit de Xs4all header kun je afleiden dat er sprake is van zowel SPF, DKIM als DMARC. Sterker, er lijkt zelfs sprake van twee DKIM headers; daarover later meer.

Een @ vervangen door een punt heb ik ook gedaan in de From: header die ik hieronder toon:
Met andere woorden, als een mail client het gehele afzender adres laat zien, zullen de meeste ontvangers daaruit afleiden dat iemand bij ziggo.nl de echte afzender moet zijn. Maar is dat ook zo, of gaat het om een phishing mail?

DMARC check
Uitgevoerd in een CMD prompt venster (waarbij ik 212.54.32.26 als IP-adres voor de nameserver gebruik, omdat die authoritative is voor ziggo.nl DNS lookups):
(ook hierin de @ achter qjm2foqd vervangen door een punt). Opvallend:
1) p (policy)=none; zie [1] voor een gedetailleerde uitleg. Duidelijk is dat er geen maatgerelen van de ontvangende mailserver worden verwacht als er iets niet klopt;
2) Ziggo heeft het bedrijf dmarcian ingehuurd voor analyse van hoe met "haar" afzender e-mail adressen wordt omgesprongen (legitieme vs. vervalste e-mails waarbij het From: veld eindigt op "@ziggo.nl>").

SPF
Het Return-Path luidt:
waarbij X1 t/m X4 getallen of alfanumerieke identifiers zijn, en ik de @ voor mpbounces vervangen heb door een punt.

Eveneens uitgevoerd in een CMD prompt venster:
Het minnetje voor "all" geeft aan dat het hier niet om een advies, maar om een regel gaat: indien een e-mail met Return-Path eindigend op @mpbounces.ziggo.nl wordt aangeboden vanaf een IP-adres dat niet in de toegestane lijst voorkomt, moet de e-mail worden geweigerd. Zaak (voor de ontvangende mailserver, wat wij hier handmatig nabootsen) is dus te bepalen wat wel toegestane IP-adressen zijn.

Aangezien er naast een "include" niets staat over IP-adressen van mailservers die namens mpbounces.ziggo.nl e-mail mogen verzenden, hoeven we uitsluitend naar de "include" directive te kijken. En die geeft aan dat we het SPF record van mailplus.nl mee moeten nemen, dus ook dat vragen we op (46.31.48.17 is een authoritative DNS server voor mailplus.nl):
Zoals je ziet zijn er twee verschillende "text" records, wij zijn natuurlijk alleen geïnteresseerd in degene die begint met "spf1". Uit de tekst daarachter kun je direct afleiden dat e-mails aan ontvangende mailservers mogen worden aangeboden als het IP-adres van de aanbiedende server een IP-adres heeft in de reeks van 46.31.48.0 t/m 46.31.55.255.

Zo te zien ontvangt Xs4all de meeste Ziggo mails voor mij van de server dmta9.brightbase.net met IP-adres 46.31.53.9, dus dat is legitiem.

DKIM
In de e-mails zie ik twee DKIM headers. Uit de laatste "Ziggo" e-mail die ik ontving (Subject: Je nieuwe factuur van Ziggo, Date: Tue, 26 Jul 2016 18:04:31 +0200 (CEST)):
(In de eerste header heb ik achter i=ziggo.contact de @ vervangen door een punt, en ik heb een lege regel tussen beide DKIM headers tussengevoegd, in de e-mail zelf stonden deze strak achter elkaar).

De eerste DKIM header is, gok ik, door Ziggo zelf toegevoegd, waarna de e-mail door Mailplus is geforward, waarbij Mailplus kennelijk de tweede DKIM header heeft toegevoegd.

Check of de DKIM public keys bestaan
We zoeken de in DNS gepubliceerde public keys op (hoe je dat doet heb ik beschreven in [2]):
en

Handmatig controleren van DKIM signatures is iets dat ik nog nooit heb geprobeerd, want dat is vermoedelijk lastig (je moet op de juiste manier en in de juiste volgorde de gespecificeerde velden en de message body achter elkaar zetten, en daar de gespecificeerde hash (sha256 in dit geval) over uitrekenen. Die berekende hash moet hetzelfde zijn als de door de verzender met zijn private key versleutelde hash, die je met de public key uit het bijbehorende DNS record kunt decrypten).

DKIM Verifier voor Thunderbird
Daar bestaan tools voor, o.a. voor Thunderbird (die ik gebruik voor privé mail), met dank aan Anoniem in [3]; zie [4].

Ik heb 3 Thunderbird screenshots gemaakt van de laatste e-mail die ik van Ziggo ontving, zie [5] (Thunderbird v45.2.0, DKIM Verifier v1.5.1 met default settings). Van boven naar onder:
1) De e-mail zoals ontvangen;
2) De e-mail waarin ik de DKIM header van Ziggo.nl heb verwijderd;
3) De e-mail waarin ik beide DKIM headers heb verwijderd.

In de middelste screenshot zie je dat de DKIM verifier vermeldt: Valid (signed by mailplus.nl) echter met een geel driehoekje erachter. Als ik daar de muispijl boven laat hangen, verschrijnt een klein popup boxje met de tekst "From is not in the signing domain". M.a.w. woorden: het is een geldige handtekening, echter gezet door iemand die helemaal niets met de afzender te maken hoeft te hebben!

Ik heb nog meer geëxperimenteerd, maar deze post is alweer veel te lang geworden. Overigens vind ik ondertussen het hele DKIM+DMARC verhaal zodanig complex worden met alle mogelijke variaties van parameters en dubbele headers zoals hierboven getoond, dat ik mij afvraag of het realistisch is om ervan uit te gaan dat alle ontvangende mailservers e.e.a. correct zullen implementeren en dit niet tot heel veel fouten gaat leiden (zowel onterecht geweigede of als spam getagde legitieme mails, en doorgelaten nepmails).


VRAAG
Wat is nou precies het criterium van DMARC? Hoe kan het dat er 2 DKIM headers zijn, waarvan eentje met d=mailplus.nl terwijl From: eindigt op ziggo.nl, en Xs4all beide DKIM headers goedkeurt? Of zou Xs4all die laatste DKIM header hebben afgekeurd indien de DMARC policy "reject" of "quarantine" was geweest, en zo ja, zou daarmee de hele mail geweigerd of als spam getagged zijn?


[1] https://dmarc.org/wiki/FAQ#Does_DMARC_.E2.80.9Cp.3Dnone.E2.80.9D_affect_the_way_my_emails_get_delivered.3F

[2] https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29

[3] https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29#posting464032

[4] https://addons.mozilla.org/en-US/thunderbird/addon/dkim-verifier/

[5] https://imgur.com/a/WQGMA

Edit 21:41: typos gecorrigeerd en teksten iets verduidelijkt

https://wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/

Een mail mag gewoon meerdere DKIM headers hebben. DMARC eist alleen dat er een SPF òf een DKIM header is die het zichtbare afzenderadres goedkeurt. DMARC trekt zich dus niets aan van andere DKIM headers, maar zoekt alleen die, die het afzenderadres bevat.

Als ik in mijn mailserver log kijk, vind ik voor de ziggo mail:

Dus de DKIM module checkt alle DKIM headers en de DMARC module kijkt alleen naar de correctheid van SPF voor ziggo.nl en of er een DKIM header op naam van ziggo.nl is. Als één van beiden correct is, geeft DMARC een pass.

-----

Voor Ziggo is het wel lastig om een DMARC policy op te zetten die verder gaat dan 'p=none'. Dit omdat er ook veel reguliere consumenten een ziiggo.nl adres hebben. Hun mail moet dan ook DKIM gesigneerd worden en ze zullen dan altijd de SMTP server van ziggo moeten gebruiken om hun mail te versturen. Ik denk dat de helpdesk het druk krijgt als ziggo zijn DMARC policy op quarantaine zet. (-:

@Briolet: dank voor jouw reactie! Die klinkt aannemelijk, maar zorgelijk vind ik dat fraudeurs, door (veel) meer dan 1 zinvolle DKIM header in e-mails op te nemen, mogelijk ontvangende mailservers in verwarring kunnen brengen en in elk geval kostbare resources laten verspillen.

Om die reden vind ik een (kennelijk niet bestaande) eis dat een e-mail (eventueel alleen indien toegepast in combinatie met DMARC) hooguit 1 DKIM header zou mogen hebben, veel meer voor de hand liggen. Immers, meer dan 1 DKIM signature draagt helemaal niets bij.

De combinatie vn SPF, DKIM en DMARC is het mooiste.
Mensen due hun mail forwarden kunnen het beste SRS gebruiken zodat het afzender adres herschreven word.
Vervolgens is het SPF probleem ver weg.

https://blog.networking4all.com/2016/06/e-mail-beveiliging-spf-dkim-en-dmarc/

Het is geen kwestie van zien, een simpel statement zonder onderbouwing (hoeveel het kost om te implementeren, en hoeveel je waarop gaat besparen) kun je geen business case noemen.
De mensen die _dat_ niet zien hebben gewoonlijk het probleem dat "er niet naar ze geluisterd wordt" .

De hoeveel je gaat besparen hangt af van het percentage spam wat je op basis van SPF/DKIM (al) kunt rejecten/of spam-taggen, en of je misschien veel moeite deed om een vergelijkbaar filterresultaat met minder efficiente content checks te bereiken.
De implementatie kosten (bij schaal grote ISP) zitten in het (regressie)testen, logging inrichten/bereikbaar maken, en eventueel support proces aanpassen.


Ah kijk, toch wat cijfers, dat maakt het beter . Is die 90% overigens een hard cijfer, over je geheugen van 10 jaar ?
Ik moet zeggen dat ik geen andere cijfers heb, maar ik ben wel verbaasd dat 90% van de spam dan via SPF/proto-DKIM detecteerbare afzenders zou komen . Het is wel de orde reductie in server capaciteit (80%), en ik kan me wel voorstellen dat het verschil tussen een lichte check en een zwaardere analyse in die orde van grootte zit .


Je schreef over "fout negatief, fout positief - behalve als de verzender dom doet, jammer dan" . Fout positief (mail van tante Truus met de baby fototjes komt niet aan omdat de ISP van tante truus een moeilijk technisch woord fout heeft staan" is waar de eindgebruiker niet zoveel boodschap aan heeft dat het de schuld is van rdns/spf/dmarc/dkim records .

Dat is onjuist.

Uitleg hoe SRS werkt

Mailserver A ---> Mailserver B ---> Mailserver C

Stel:
- Voor A is een dwingend SPF record gepubliceerd;
- B doet niets met SPF en heeft ook geen SRS geïmplementeerd;
- C checkt binnenkomende mail op SPF;
- Een gebruiker van B laat zijn mail automatisch doorsturen naar C;
- Een gebruiker op A stuurt een mail naar de gebruiker op B die zijn mail naar C laat doorsturen.

Dat gaat dus fout, want C zal, aan de hand van het SPF record van A, vaststellen dat B niet geautoriseerd is om e-mails te verzenden met een Return-path verwijzend naar A (C zal dergelijke mails weigeren, waarna B ze hoort terug te sturen naar A).

De "oplossing" is dat de beheerder van B, ook als hij niets met SPF te maken wil hebben, een complexe oplossing genaamd SRS moet implementeren om zijn gebruikers e-mail te kunnen laten forwarden.

De truc daarbij is dat SRS het afzenderadres in Return-path wijzigt in een soort tijdelijk account op B, dat eventuele NDR's (Non-Delivery Reports) maar ook "ontvangst"- en "geopend" meldingen kan aannemen (van C) en doorsturen naar de oorspronkelijke afzender op A. Nb. door SRS wordt het From veld natuurlijk niet herschreven.

Waarom SPF in combinatie met DMARC nog desastreuzer is voor forwarding

1) Als je SPF afdwingt (met -all) en combineert met DMARC waarin je eveneens SPF afdwingt (met aspf=s), kan er door niemand geforward worden - ongeacht of SRS wordt gebruikt.
Immers, met SRS wijzigt het Return-path, dat daarna niet meer zal overeenkomen met het afzenderdomein in From, waardoor DMARC alarm zal slaan; zonder SRS rewrite zal SPF alarm slaan omdat de mail op C vanaf een ongeautoriseerd IP-adres wordt aangeboden.

2) Als je SPF met DMARC combineert en niet afdwingt, bestaat de kans dat middels SRS geforwarde mail door de ontvangende server als spam wordt getagged; immers het domein in Return-path komt (door de SRS rewrite) niet meer overeen met From.
Geforwarde mail die niet door SRS is aangepast kan in deze configuratie ook als spam getagged worden, namelijk omdat SPF niet meer klopt: de mail is verzonden vanaf een niet geautoriseerd IP-adres.

Nu zou je kunnen zeggen: dan moet je SPF + DMARC maar in "relaxed" mode toepassen en niet gebruiken om op spam te checken. Maar waarom zou je SPF en DMARC dan überhaupt nog inzetten?

Om misverstanden te voorkomen: SRS is niet iets dat je als eindgebruiker zelf kunt inzetten, dat zal de beheerder van de mailserver(s) (ook alle backup Mail eXchangers indien daar DNS MX records voor bestaan) voor het domein uit jouw e-mail adres moeten inrichten - als jij wilt dat mail voor jou wordt doorgestuurd (voor zover dat überhaupt nog werkt).

Lastig daarbij is dat, als die beheerder op zijn mailservers niets met SPF te maken wil hebben, hij (om forwarding in een deel van de gevallen mogelijk te maken) toch SRS zal moeten configureren op zijn mailserver(s).

Gezien het feit dat steeds meer zendende mailservers SPF met DMARC combineren, kan ik me voorstellen dat beheerders steeds minder zin hebben om tijd te verspillen aan SRS.

Conclusie
Forwarding is dood. Deal with it.

En gebruik SPF en DMARC in strict mode, dan heb je zo min mogelijk last van "backscatter" (NDR's) als gevolg van spammers die jouw afzenderdomein spoofen in Return-path en spam sturen naar niet (meer) bestaande accounts, of accounts met volle mailboxen etc.

Erik,

Erik weer hier: Forwarding? geen problemen mee als ~ wordt gebruikt voor SPF (en strict voor DKIM). Forwarding is dermate groot dat je dat niet kunt en mag negeren. SPF is dood. Deal with it. SPF heeft geen toegevoegde waarde ten opzichte van DKIM.

Ten aanzien van je eerdere vraag over 2 headers: de tweede header tekent de eerste (recursie) dus dat levert geen problemen op.

anoniem 31/7 22:11: Die 90% was hard. KPN en Ziggo zouden best in staat moeten worden geacht om hun eigen business case te schrijven. Als ik het kan, als xs4all het kan, als google het kan, als yahoo het kan, dan kan een kleine club als KPN of Ziggo het ook. Zo groot zijn die nu ook weer niet (maar hebben heel, heel veel last van incoming spam/phishing). In Nederland wel ja, maar niet vergeleken met de grootte van google...

Ik ben de MailPlus deliverability persoon (verantwoordelijk voor die mail eerder). De reden van de tweede DKIM signature is dat wij op die basis feedback krijgen van diverse providers zoals Yahoo over reputatie, spam-metrieken, klachten en dergelijke.

Verder adviseren we tegenwoordig vaak ~all in het SPF record dat bij DMARC gaat. Maar dat is aan de klant om daar een keuze in te maken.

We hebben ook cijfers over de problemen/bounces bij forwarden. Dat is eigenlijk verwaarloosbaar klein. Als klanten geen DMARC gebruiken dan hebben we een -all policy en daar komen nauwelijks bounces op binnen (1% van de 0.3% bounces). Dat is vaak op te lossen door de laatste partij de mail op te laten halen bij de eerste (ipv forwarding). Bij Gmail/Hotmail kan je dat bijv. instellen.

Verder vind ik het eigenlijk te gek voor woorden dat alle ISPs in NL nog steeds geen checks doen op DMARC. De enige reden is omdat het geen business value heeft ("ze worden nog niet aan de schandpaal genageld"). Begrijpelijk maar niet goed. Maar hetzelfde geldt voor de hosters. Bij erg veel hosting partijen kan je de emails nog niet met DKIM ondertekenen.

Overigens is DMARC, of in ieder geval DKIM/SPF authenticatie in lijn met het domein, steeds actueler. Zowel Hotmail als Gmail gaan zonder 'bewijs dat iets geen phishing is' steeds een hogere spamscore geven. Voor IPv6 is het al een voorwaarde bij hen. En als je Office365 hebt dan moeten externe partijen al authenticatie regelen om weer terug naar het eigen domein te kunnen mailen. Ook staat het in de NCSC richtlijnen dat organisaties DMARC horen te gebruiken om phishing tegen te gaan.

SRS kan ik niet adviseren. De meeste SRS implementaties zijn 'flawed' (want ze maken het local part van het return path langer).

Dank voor jouw antwoord, maar ik ben het niet met je eens.

Los van DKIM, met de huidge DMARC spec heb je 2 mogelijkheden als je ook SPF records publiceert:
1) aspf=r (relaxed) of niets specificeren - "r" is de default
2) aspf=s (strict)

Waarom je 1) zou willen gebruiken, ontgaat me (tenzij je wilt dat via SRS herschreven geforwarde mail potentieel als spam wordt gezien). Als je 2) gebruikt, zal geforwarde en middels SRS aangepaste mail als gevolg van DMARC sowieso horen te worden geweigerd.

Als we de betrouwbaarheid van SMTP mail niet vergroten, zal SMTP, zodra er een WhatsApp equivalent verschijnt dat geen telefoonnummer nodig heeft, ten dode opgeschreven zijn. Inclusief forwarding (overigens per definitie een security risico). Wat wil je?

Je hebt zeker nog nooit een Joe-job meegemaakt?

SPF is nooit geschikt geweest als anti-spoofing (From veld) en/of anti-spam maatregel. Wat ik erover vind op Internet, is dat DMARC is begonnen met aansluiten op SPF (en dat dus toch als anti-spoofing maatregel in te zetten) omdat DKIM op dat moment nog nauwelijks gebruikt werd; dat punt zijn we hopelijk voorbij.

Waar SPF wel prima geschikt voor is, is om backscatter spam tegen te houden (maar daar heb je de combinatie met DMARC geheel niet voor nodig).

Voorbeeld, ik ontving gisteravond 6 verschillende ING phishingmails met in Return-Path de volgende domeinen:
- adelbert.nl (zendende en spoofende zombie PC = adsl-135.176.58.161.tellas.gr)
- de-it-krachten.nl (zendende en spoofende zombie PC = cpc84888-dund14-2-0-cust213.16-4.cable.virginm.net)
- variodrive.nl (zendende en spoofende zombie PC = 117.194.195.107, dat is in India)
- bouquetnet.nl (zendende en spoofende zombie PC = 95.187.108.219, dat is in Saudi Arabië)
- felixvanderputtenverf.nl (zendende en spoofende zombie PC = 201-62-89-83.life.com.br)
- ch-bourgoin.fr (zendende en spoofende zombie PC = 93.157.144.65, dat is in Rusland)

De reden dat de spammers deze domains misbruiken is dat ze (A) bestaan en (B) geen SPF records hebben gepubliceerd. Als mijn account niet had bestaan of als mijn mailbox vol was geweest en als mijn provider XS4all eerst e-mail aan zou nemen en pas daarna zou checken of de mail kan worden afgeleverd (zoals veel andere grote providers wel doen), had elk van de bovengenoemde domains een NDR ontvangen - spam door spam.

Zo lang er voldoende domains zijn die geen SPF records publiceren, zullen spammers die misbruiken.
Zodra die schaars worden, zijn domains met ~ SPF records aan de beurt...

Overigens zagen de usernames bij genoemde domeinen er realistisch uit, dus je hebt ook nog kans dat backscatter daadwerkelijk in inboxes belandt. Om dat soort leed te voorkomen is SPF juist uiterst zinvol!

Hoe meer ik erover nadenk, hoe stompzinniger de combinatie van SPF en DMARC is. Alleen kent DMARC helaas geen optie om SPF geheel te negeren. En dat leidt dan weer tot het advies van Mailplus (Anoniem om 11:21 hierboven) om geen SRS meer te gebruiken, waar anderen nog roepen dat je dat juist wel moet doen als je wilt forwarden.
Het ontbreekt er nog maar aan dat mailservers, waarvan de beheerders niets in SPF zien maar wel willen forwarden, afhankelijk van of de zendende server SPF en/of DMARC toepast, en met welke instellingen, per mail moeten uitzoeken of ze wel of geen SRS moeten toepassen om te kunnen forwarden...

Sorry maar dat is onjuist, de DKIM headers zijn geheel losstaand.

Hartstikke bedankt voor jouw reactie!

Ah, daarom dus!

Doordat er allerlei verschillende keuzes worden gemaakt, ontstaat wel een onvoorspelbaar landschap - met alle potentiële problemen van dien.

Thanks!

In tegenstelling tot DKIM [1] is DMARC nog geen internet standaard [2]. Bovendien constateer ik (zie mijn vorige bijdrage hierboven) dat je DMARC niet kunt loskoppelen van SPF. Hoe zinvol ik DMARC ook vind, het is nog erg onvolwassen.

Ik zie veel bulk mails met een DKIM header gezet door een ander domain dan de afzender in From. Als dan ook het Return-Path herschreven is, begrijp ik dat men nog geen DMARC inzet.

Dat is wel jammer, want dat is al een tijd een standaard.

Hmm, "richtlijnen", uit [1]: Ook in de PDF is sprake van adviseren.

Helaas draagt zo'n advies bij aan de chaos op Internet. Het is nu totaal niet duidelijk wie wat implementeert, en morgen kan weer alles anders zijn.

[1] https://tools.ietf.org/html/rfc6376 (DKIM)
[2] https://tools.ietf.org/html/rfc7489 (DMARC)
[3] https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html

DMARC heeft er echter geen last van als de SPF bij geforwarde mail niet meer klopt. Zolang de DKIM header nog klopt, blijft de DMARC check geldig. Dus zo gezien kun je stellen dat SPF genegeerd wordt als je ook DKIM toepast.

Mijn ervaring met kleinschalige mailhoeveelheden naar klanten is dat 25% van de mail geforward wordt. (Dat zie ik in de DMARC reports waar zo'n 25% een SPF fail geeft). Forwarden is dus zo groot dat je dat inderdaad niet mag negeren.

Hier de MailPlusser weer.

Ik zou DMARC een standaard noemen. Mails worden daadwerkelijk gefilterd door een steeds groter aantal partijen. Het is de enige manier om goed te bewijzen dat een email van een vertrouwd systeem af komt / geen phishing is. Ze zijn nog bezig om forwarding beter te fixen met ARC (voor een cryptografische keten bij forwarders).

MailPlus kan SPF wel degelijk loshalen van DMARC. De authenticatie die DMARC nodig heeft komt niet in het vaarwater met het SPF record op het hoofddomein. Dat komt omdat ons From-domein en Envelope-Sender andere domeinen zijn (om de bounces correct te kunnen afhandelen). Alle ESPs doen dat.

Standaard staat op ons eigen Envelope-Sender-domein een "-all" (bounces.mailplus.nl). Als er DMARC is ingesteld dan heeft de domeineigenaar er al grip op en volstaat ~all. Een ontvangende mailserver is dus altijd in staat om een correcte beslissing te nemen.