Het beveiligen van e-mail met standaarden als dane en dmarc steeds populairder

Het simple mail transfer protocol, of smtp, geschreven in 1982, vormt de basis van e-mail zoals we het vandaag de dag gebruiken. En het is zo lek als een mandje. Niet alleen cybercriminelen weten dat, ook beheerders van domeinen erkennen het en passen steeds vaker moderne(re), aanvullende e-mailstandaarden toe. In cijfers van SIDN, die onder meer het .nl-domein beheert en zich richt op een beter, veiliger internet, is dit goed terug te zien.

Zoals met wel meer standaarden uit de begindagen van internet is de beveiliging van smtp minimaal. Mails gaan over het netwerk in cleartextformaat, waardoor iemand anders dan de ontvanger ze heel eenvoudig kan meelezen. En nog erger: er is geen validatie op afzender en inhoud.

Elmer Lastdrager, die vorig jaar promoveerde op het onderwerp phishing aan de Universiteit Twente en werkt als research engineer bij SIDN Labs, bevestigt het probleem. “Ontvangers van e-mail weten vaak niet zeker wie de afzender is, zeker als het verzendende of ontvangende domein geen andere standaarden dan het klassieke smtp toepast.” Phishers maken gebruik van deze kwetsbaarheid door nepmails te sturen die vaak nauwelijks te onderscheiden zijn van authentieke mails, gestuurd door banken, verzekeraars of andere organisaties. “De meeste mensen controleren de verborgen headers van hun e-mails niet, want dat is een vrij technisch verhaal. En als phishers ook nog eens een gevoel van urgentie inbouwen, waar mensen gevoelig voor zijn, worden ze al snel onvoorzichtig.”

Moderne standaarden vaker aangezet

Op stats.sidnlabs.nl publiceert SIDN actuele statistieken over het gebruik van de .nl-zone, waaronder e-mail. Uit de recentste cijfers wordt duidelijk dat moderne standaarden, met name spf, inmiddels een belangrijke positie hebben ingenomen. “Zeker het aanzetten van standaarden als dane en dmarc door enkele grote internetproviders heeft bijgedragen aan een grotere veiligheid”, zegt Lastdrager. “Wij proberen dit ook te stimuleren, onder meer door een incentive-regeling voor providers in de vorm van kortingen op domeinregistraties.”

Al deze inspanningen ten spijt zijn lang niet alle e-mails - wereldwijd gaan er momenteel zo’n drie miljoen per seconde over internet - even veilig. “Vooral bedrijven die veel mail versturen, doen er dan ook goed aan eens te kijken naar de protocollen die zij hanteren, zoals dkim, dmarc, spf en starttls.” Met uitzondering van spf en in mindere mate dkim, zijn deze lang niet overal bekend.

Spf het populairst

De meest gebruikte aanvullende standaard op smtp is spf, of sender policy framework. Hoe het werkt: door het plaatsen van een spf-record in de dns, in een txt-record, bepaalt de beheerder welke systemen mail mogen versturen en hoe de ontvangende mailserver hiermee moet omgaan. De ontvangende mailserver kan dit controleren. Enkele voordelen zijn: minder ‘valse mails’, meer controle over mailstromen en een betere e-mailreputatie. Een klein aandachtspunt is dat het doorsturen van mails door de ontvanger problemen kan opleveren, maar dit is op te lossen door het inrichten van een ‘softfail’. Wie meer wil weten over hoe dit gaat, kan onder meer hier terecht voor een gedetailleerde uitleg.

Waar spf als het ware de envelop is om de e-mail, is dkim, of domain keys identified mail, de verzegeling daarvan. Het is een wat gecompliceerd protocol dat gebruikmaakt van encryptie. Het bevat zowel een private sleutel, waarover de verzendende mailserver beschikt, als een publieke sleutel, waarmee de headers en de zogenaamde body van de mail door de ontvangende mailserver kunnen worden gecontroleerd. Dkim is een jongere standaard dan spf en ook de wat hogere complexiteit en beheerlast is een reden dat deze nog wat minder wordt gebruikt.

Dmarc: het sausje over spf en dkim

Dan is er nog dmarc, of domain-based message authentication, reporting & conformance, dat als het ware een ‘sausje’ is over spf en dkim. Het plaatsen van een dmarc-record in de dns helpt de ontvangende mailserver te bepalen wat er met een mail moet gebeuren als spf- en dkim-gegevens niet kloppen. Voor de beheerder is deze standaard interessant, vanwege de mogelijkheid om feedbackrapporten te ontvangen, waardoor de alarmbellen sneller gaan rinkelen als er phishingmails of malware worden verstuurd namens het domein.

Een misvatting van veel beheerders is dat ze standaarden daadwerkelijk moeten afdwingen, waardoor ze de aanvankelijke beheerlast al snel te hoog schatten. Lastdrager: “Net als dkim kun je ook dmarc toepassen zonder direct iets af te dwingen. Dit maakt het mogelijk om mailstromen te monitoren en te zien hoe het protocol werkt, zonder het risico te lopen dat mails niet aankomen. En als je standaarden wilt gaan afdwingen, hoeft dit ook echt niet direct voor het volledige mailverkeer. Je kunt je ook eerst op tien procent van het totaal richten om het effect van de genomen maatregelen te controleren. Hierbij loop je geen al te grote risico’s als gevolg van bijvoorbeeld een onjuiste configuratie.”

Opportunistisch starttls biedt kansen

Weer een andere standaard is starttls. Dit is het bekende tls, of transport layer security, maar dan voor mails. Het is een wat opportunistisch protocol, waarbij de verzendende mailserver aangeeft deze te ondersteunen en de ontvangende mailserver dit kan bevestigen, waarna de mail wordt versleuteld. Hackers kunnen die versleuteling eruit halen door de bevestiging van de ontvangende kant te verstoren, waardoor het protocol niet in werking treedt en mails alsnog in cleartext worden verstuurd. Iets wat tegen is te gaan met aanvullende protocollen als dane, rfc7672 en mta/sts. Vooral dane is in opkomst, blijkt uit cijfers van SIDN. Tussen augustus 2018 en augustus 2019 verdubbelde het aantal domeinnamen waarbij dane is toegepast: van 205.000 naar bijna 383.000. Voor wie meer wil weten over dane, hield SIDN onlangs een praktisch webinar. Dit is hier te vinden.

Door standaarden aanvullend op smtp te gebruiken en in sommige gevallen aanvullend op aanvullende standaarden, zoals dane bij starttls, wordt e-mail daadwerkelijk veiliger, maar ook ingewikkelder voor de beheerder. “Iedere keer dat je de keys aanpast, zul je dat moeten aanpassen in de records van de aanvullende protocollen. Als je iets gaat afdwingen, moet het wel kloppen. Als je hele organisatie geen mail meer kan verzenden of ontvangen, levert dat schade op,” aldus Lastdrager. Toch kan geen bedrijf meer om moderne e-mailstandaarden heen. Klassieke e-mail met smtp is onveilig en standaarden als spf, dkim, dmarc en starttls met dane maken het e-mailverkeer veiliger. “Ze zijn effectief en wat ook meehelpt bij de bredere adoptie ervan, is dat veel organisaties, waaronder de overheid in het geval van dmarc, ze inmiddels ook verplicht hebben gesteld in hun eigen e-mailbeleid.”

Weten of een domeinnaam gebruikmaakt van de in dit artikel genoemde moderne e-mailstandaarden? Op de website https://internet.nl/ kun je dit testen.

Dit artikel is geen redactioneel artikel, maar een advertorial. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (50)

[freddieleeman]

Ik heb recentelijk een uitgebreid blog geschreven over MTA-STS wat, net als DANE, een manier is om te publiceren dat je mailserver encryptie ondersteunt en onbeveiligde verbindingen moeten worden vermeden. In tegenstelling tot DANE vereist MTA-STS geen DNSSEC: https://www.uriports.com/blog/mta-sts-explained/

Tevens is het raadzaam om naast DANE en MTA-STS ook TLS-RPT toe te passen. Met TLS-RPT kun je rapporten opvragen van verzendende mailservers zodat je kunt zien wanneer er problemen met je mailserver zijn. Bijvoorbeeld een verlopen of onjuist certificaat wat een indicatie kan zijn van een MiTM aanval. Meer hierover lees je in mijn blog hier: https://www.uriports.com/blog/email-security-explained/

Als het om privacy gaat is het natuurlijk het beste om mail te versleutelen dmv (Open)PGP, zodat de email niet alleen tijdens het transport maar ook op de server zelf en in je mailbox beveiligd is. Voor de mensen die reeds gebruik maken van PGP encryptie maar nog geen WKD hebben geconfigureerd heb ik tevens nog een interessant artikel geschreven: https://www.uriports.com/blog/setting-up-openpgp-web-key-directory/

Met WKD (Web Key Directory) kun je eenvoudig je publieke sleutel publiceren. Er zijn al diverse e-mail clients en services die WKD ondersteunen om sleutels automatisch op te zoeken zodra er een e-mailadres als ontvanger wordt ingevoerd. Je bent dan niet meer afhankelijk van publieke key servers.

[ANdrode]

Ik kende WKD niet en dacht 'oh daar komt een blockchain plug' - maar gelukkig is het echt implementeer are technologie.


DNSSEC begint steeds minder een beperking te worden. Meestal ga je uit van aanvallers buiten het eigen netwerk en draai je een eigen recursing resolver met DNSSEC support (want in tegenstelling tot in 2012 is die is nu standaard aanwezig).

[maxxware]

Met DANE en DMARC wordt alleen het email-transport beveiligd. Je email is dus encrypted TUSSEN de MTA's, maar niet OP de MTA's. De enige echt veilige email oplossing is GPG. Als we allemaal GPG gebruiken hebben we ingewikkelde oplossingen als DMARC, DANE, domainkeys, etc. helemaal niet nodig.

[eth0]

GPG prima voor end to end, maar GPG alleen is niet voldoende.

Zaken zoals DMARC en SPF en DKIM blijf je nodig houden om de bulk van SPAM tegen te gaan, daar doet GPG niets aan, want hoe wil je dan thrusted senders bij houden?

START TLS wil je ook nog steeds gebruiken, want de headers zijn niet encrypted tijdens transport. Dus als iemand een mail verstuurd welke GPG encrypted is kan nog steeds de headers mee lezen, dus denk aan zender, ontvanger, subject en zelf interne ip's van de verzender.

Ofwel we hebben al deze protocollen nodig boven op GPG.

[itlee]

Headers uitzetten kan op een beetje fatsoenlijke Hardware spamfilter al jaren. (lees ik pas t al jaren toe). dmarc/spf/dkim is prima, maar ik krijg tegenwoordig ook al spammails waarbij de spf verified is en dat het gewoon door je filter heen loopt omdat er vertrouwd uitzet.

Je ziet het vooral bij hackers die ook toegang hebben tot DNS van een domein zetten ze die records erin en niemand die het ziet/controleert. (98% van de domein eigenaren zegt het allemaal niks...)

Spam blijft een lastig fenomeen.

[mdavids]

ik krijg tegenwoordig ook al spammails waarbij de spf verified is

Dat komt misschien omdat SPF werkt op de 'envelope FROM' en niet op de FROM-header in de body van de mail. De eerste kan dan [e-mail] zijn (met geldige SPF), terwijl die laatste dan bijvoorbeeld [e-mail] is. Met DMARC erbij kun je dit tackelen. Dat zorgt namelijk voor 'identifier alignment', waardoor envelope en body FROM met elkaar overeen moeten komen.

[itlee]

Ok thnx, maar als je te hard op de dmarc settings gaat en dit in quarantaine zet gaat er een hoop mis. Heel veel beheerders en zeker internationaal hebben geen idee hoe ze dingen goed moeten instellen. Dus daarom zet je 't vaak maar minder strak. Tot alle overlast vandien.

[freddieleeman]

Je moet ook niet je anti-spam oplossing inrichten om mails met een DKIM of SPF 'pass' te vertrouwen. Daar zijn die technieken helemaal niet voor bedoelt. DKIM valideert dat de mail gedurende transport niet is aangepast, en SPF geeft alleen aan dat de bron waar de mail van afkomstig is wel of niet daarvoor gemachtigd is. Of de inhoud van die e-mail SPAM bevat is hierbij niet relevant. Standaard geeft bijvoorbeeld SpamAssassin geen positieve of negatieve score aan SPF/DKIM. Dat zou ik ook zeker niet adviseren.

[mdavids]

SPF geeft alleen aan dat de bron waar de mail van afkomstig is wel of niet daarvoor gemachtigd is.

Extreem nuttig dus.

[freddieleeman]

Zeker, want zo voorkom je dat anderen mail kunnen versturen namens jouw domein. Het is vooral ter voorkoming van phishing.

[Jace / TBL]

DKIM valideert dat de mail gedurende transport niet is aangepast,

En ook dat het is gesigned door iemand die de private key heeft die hoort bij de public key die in de DNS van het verzendende domein staat. Dat is vrij veelzeggend toch?

Natuurlijk kan de eigenaar van een domein zelf ook gewoon spam sturen, maar spammen onder naam van iemand anders (wat zeer veel gebeurt) filter je er zo wel uit.

[freddieleeman]

Zeker, het is er ook ter validatie. Maar spam wordt ook verzonden vanaf gehackte servers waar netjes SPF en DKIM is ingesteld. Ik zou geen spam-score toewijzen aan het hebben of ontbreken van een valide DKIM handtekening of SPF.

[Belsameth]

DMARC (en SPF/DKIM) zeggen niets over de inhoud van de mail en geven dus niet aan of iets al dan niet spam is. Het voorkomt domain spoofing. Lang voordat DMARC wat breder uitgerold was zag ik al zeer regelmatig spam welke perfect DMARC alligned was.

[eth0]

Ja klopt helemaal, ik schaarde domain spoofing, scammers etc... ook even voor het gemak onder SPAM/MEUK. maar je hebt gelijk.

[Belsameth]

Ik dook er even op in omdat het vaak als anti spam oplossing gepresenteerd word, vooral in de context dat DMARC aligned mail geen spam is. Een gevaarlijk idee

Wel is het natuurlijk te gebruiken om DMARC aligned mail van known domains niet te scannen (banken e.d.), maar dat is duidelijk een andere usecase.

[Reactie gewijzigd door Belsameth op 23 juli 2024 03:01]

[freddieleeman]

Dit is niet helemaal juist. Het email transport wordt beveiligd dmv STARTTLS. DANE en MTA-STS zijn mechanismen om publiekelijk te publiceren dat e-mail transport versleuteld moet gebeuren, en als dat niet mogelijk is er geen communicatie moet plaatsvinden. Dit is dus iets wat een verzendende mailserver wel moet ondersteunen. Niet ondersteunende mailservers zullen de mail, bij het ontbreken van STARTTLS gewoon onversleuteld doorsturen.

Met DMARC kun je een beleid publiceren wat er moet gebeuren met e-mail op het moment dat DKIM en SPF faalt maar heeft niets met het transport zelf te maken. Als een DKIM gesigneerd bericht wordt onderschept en doorgezonden zal alleen SPF falen en DMARC dus gewoon resulteren in een 'pass'.

Wat eth0 schrijft is tevens correct, PGP zonder STARTTLS blijven de headers gewoon zichtbaar.
Je e-mail op en top beveiligen? Ga voor STARTTLS, SPF, DKIM, DMARC, DANE, MTA-STS, STARTTLS Everywhere, TLS-RPT, OpenPGP en WKD. Kost je een dagje knutselen, maar dan heb je ook wat!

[Anoniem: 1248170]

wat gebruikt protonmail?

[eth0]

https://internet.nl/mail/protonmail.com/274330/

https://protonmail.com/security-details

[freddieleeman]

https://protonmail.com/blog/security-updates-2019/

MTA-STS, DANE en WKD (PGP)

[Eonfge]

Voor email is dat inderdaad de beste optie.

Het meest moderne protocol is echter Matrix. Dit is een gefederaliseerd, end-to-end encrypted, protocol voor berichten, audio en video. Elke organisatie kan zijn eigen server neer zetten, of je kunt het uitbesteden aan een derde partij.

Een partij die het al in gebruik is gaan nemen is bijvoorbeeld het Franse Ministerie van Defensie. Het is nog nieuw, dus er worden nog hier een daar wat patches uitgerold, maar in de toekomst is dit beveiligde, decentrale protocol mogelijk de vervanging voor email.

[Reactie gewijzigd door Eonfge op 23 juli 2024 03:01]

[ajolla]

Hoe komt het dan dat er niet voor GPG is gekozen?

[CAPSLOCK2000]

Met name voor e-mail is DANE erg belangrijker, belangrijker dan voor HTTP(s).

SMTP mist namelijk een aantal mogelijkheden die HTTP heeft. Het belangrijkste gebrek is een mens achter de knoppen om vragen aan te stellen als het niet duidelijk is. SMTP loopt typisch van server naar server en de computer moet zelf iets beslissen. Traditioneel is de keuze altijd geweest om mail altijd het voordeel van de twijfel te geven en door te sturen, of de verbinding nu veilig is of niet.

Omdat er geen mensen in de keten zitten en de mail toch wel aankomt is het vaak ook niet duidelijk dat er iets niet goed gaat. Als mailservers al een SSL-certificaat hebben dan is het vaak voor de verkeerde naam (www.voorbeeld.com ipv mail.example.com) of al jaren verlopen. Dat maakt het lastig om uit die spiraal te breken. Als je in je eentje je mailserver strenger maakt dan komt je mail niet aan en zijn je gebruikers & communicatiepartners ongelukkkig terwijl ze er zelf weinig aan kunnen veranderen.

Nog een mogelijkheid die mist is de "redirect". Met HTTP kun je iemand vrij eenvoudig doorsturen naar de HTTPS versie van je site zonder verdere interactie. SMTP heeft dat niet. Tot voorkort (MTA-STS) was er ook geen direct equivalent voor HSTS. Zelfs als je in het verleden een veilige verbinding hebt gehad kun je daar in de toekomst niet op vertrouwen.

Bij SMTP kun je op de gok proberen een beveiligde verbinding op te zetten, maar als dat niet lukt kun je niet anders dan terugvallen naar een onbeveiligde verbinding. Een aanvaller kan dus simpelweg beveiligde verbindingen blokkeren en zo een onbeveiligde verbinding forceren. Omdat DANE via DNS werkt weet je voor je de verbinding opzet al of je encryptie kan gebruiken of niet, en weigeren als het niet mogelijk is.

Een andere groot voordeel van DANE is dat je geen CA's meer nodig hebt om SSL-certificaten uit te geven. DANE werkt net zo goed met self-signed certificaten. Dat is mooi want het verkrijgen van een SSL-cert is vaak toch nog wel een hobbel, zelfs met de gratis certificaten van LetsEncrypt. LE is heel mooi, maar je hebt wel wat interactie nodig met de servers van LE. Die moet je wel kunnen bereiken. Je hebt dus een min-of-meer permanente open internetverbinding nodig, en de LE organisatie moet niet failliet gaan of gehacked worden ofzo.

Voor een typische webserver is dat geen probleem. Die kan vrijelijk via HTTPS communiceren met de hele wereld en als er toch iets mis gaat dan hebben de gebruikers dat snel genoeg door.

Bij e-mail-servers ligt dat wat moeilijker omdat ze vaak verder zijn afgeschermd in het netwerk en geen interactieve gebruikers hebben. DANE maakt het veel makkelijker om zo'n server een self-signed certificaat te geven zonder een hele CA op te hoeven tuigen. (Het verlangt wel wat meer van je DNS infrastructuur).

[DennisBaaten]

Op de GitHub pagina van internet.nl vindt je how-to's voor het implementeren van veilige e-mailstandaarden zoals DANE en DMARC. Ook is er recent door SIDN een webinar gegeven over de implementatie van DANE.

[Yagermeister]

Wellicht is het een idee dat men hier een artikel van maakt hoe je het ook kan instellen op de diverse mail servers. Dan heeft dit artikel tenminste een beetje nut.

[eth0]

De implantatie verschilt per mailserver, en natuurlijk of je self hosted hebt of in de cloud. En als je het in de cloud draait ben je overgeleverd aan wat deze provider ondersteunt of juist niet ondersteunt.

Je kan hier testen

https://internet.nl/mail/.../274319/#control-panel-12

Maar niet alleen diet domain waar jij mail opdraait moet goed zijn, ook de verzender, het is wel een beetje alles of niets.

Als je wilt weten hoe je STARTTLS icm Postfix kan opzetten, daar heb ik al eens een uitgebreide post over geschreven.

https://kruyt.org/postfix-and-tls-encryption/

[Reactie gewijzigd door eth0 op 23 juli 2024 03:01]

[Anoniem: 111246]

Als tweaker kun je dit prima googlen en tutorials lezen over hoe zoiets basaals as SPF in te stellen is.
En als je dan toch bezig bent, kun je DKIM en daarmee ook DMARC ook wel vinden.

Mocht je gebruik maken van O365 of Gsuite, dan zijn er zelfs daar tutorials te vinden over hoe je het instelt.
Voor je eigen mailserver zal je iets meer onderzoek moeten doen, maar dit is niet nieuw. Het bestaat al jaren en ik begrijp dan ook niet dat er nog organisaties zijn die dit niet gebruik maken.

Ik zie inmiddels (op mijn O365) steeds vaker mails in de spam terecht komen, check je vervolgens de hostheaders, dan kom je er al gauw achter dat de verzendende partij geen gebruik maakt van SPF/DKIM, etc.
Veel al ontwetendheid. Het wordt tijd dat dit verplicht wordt en niet meer optioneel.

[Yagermeister]

Heb je helemaal gelijk bij echter is het ook zo dat als men een advertorial kan plaatsen kan men ook meteen een uitleg geven over hoe je het doet instellen. Dat scheelt dan ineens zoekwerk en heeft het hele artikel tenminste ook nog een beetje nut.

Nu is het een beetje een leuk artikel waar je niks mee kan als je niet verder zoekt.

[cat_byte]

Wellicht is het een idee dat men hier een artikel van maakt hoe je het ook kan instellen op de diverse mail servers...

Ik zou als eindgebruiker ook willen weten hoe je kunt checken of je hosting /email provider deze zaken implementeert.

[Airw0lf]

Voor degene die dit willen (gaan) doen:
Er is eigenlijk niks te koop; alleen iets om in te stellen => dit regel je met instellingen in je DNS - niet met instellingen in een mailserver.

Als aanvulling:
Testen kan (bijvoorbeeld) met https://www.appmaildev.com/en/dkim

[Reactie gewijzigd door Airw0lf op 23 juli 2024 03:01]

[mdavids]

dit regel je met instellingen in je DNS - niet met instellingen in een mailserver.

Dat is niet helemaal waar. DKIM-handtekeningen bijvoorbeeld, die moet de verzendende mailserver zetten. De ontvangende server kan die dan weer controleren m.b.v. het DKIM-record uit DNS (wat in feite een publieke sleutel is).

En mailservers die mail ontvangen, moeten daarnaast ook nog DMARC- en SPF-records uit DNS ophalen en daar slimme dingen mee doen. Bijvoorbeeld DMARC-reports uit kunnen sturen, of een DMARC-policy toepassen.

Kortom, wie dit in zijn geheel wil doen, moet naast DNS ook wat zaken op de mailserver instellen.

En ook voor DANE+STARTTLS moeten zaken worden ingesteld op de mailserver.

Maar inderdaad, door alleen al SPF- en DMARC-records in DNS te publiceren, wat relatief simpel is, kun je al een hele goede, eerste stap zetten.

[Adm.Spock]

T.net scoort 67% voor de website en 50% voor de mail...... WAUW... voor een techsite is dat natuurlijk een grote teleurstelling....

[LeonM]

Ja, ik heb mij hier al vaker over verbaasd.

Tweakers.net heeft SPF ingesteld met een '?all' (neutral) SPF mechanism. Met een neutraal advies dient de ontvanger geen score te hangen aan de SPF uitkomst, wat er effectief op neer komt dat SPF is uitgeschakeld voor hun domein. Bovendien gebruikt tweakers helemaal geen DMARC.

Wegens het gebrek aan SPF en DMARC heeft een ontvanger dus niks om op te baseren of een afzender legitiem is. Dat betekend dat iedereen een email kan sturen met een @tweakers.net afzender adres, en dat deze email zeer waarschijnlijk gewoon aankomt bij de ontvanger.

Zie: https://www.mailhardener.com/tools/spf-validator?domain=tweakers.net

[Kees]

Dat is gewoon een stuk techdebt. We geven alle moderators een @tweakers.net adres, maar willen niet dat alle moderators een mailbox bij ons op de servers hebben om daarvandaan te moeten mailen. We stellen dus een forward in naar zijn prive mailadres.

Maar omdat die moderators die mail wel moeten kunnen gebruiken zonder via onze servers te mailen is het niet mogelijk om dmarc/spf volledig sluitend op te zetten.

Daarnaast kloppen een aantal van die tests niet, zo beweren ze dat we geen htst gebruiken terwijl die toch echt wel gezet word, en ze roepen dat we geen redirects doen naar https, terwijl dat gewoon wel gebeurd.

[Reactie gewijzigd door Kees op 23 juli 2024 03:01]

[mdavids]

Daarnaast kloppen een aantal van die tests niet, zo beweren ze dat we geen htst gebruiken terwijl die toch echt wel gezet word, en ze roepen dat we geen redirects doen naar https, terwijl dat gewoon wel gebeurd.

We zien dat Tweakers vrij snel een HTTP 429 (Too many requests) stuurt. En bij die response ontbreekt de HSTS-header. Het zou zomaar kunnen dat de test van https://internet.nl/ zich daarom vergist, want die stuurt toch wel een klein aantal requests achter elkaar (onder andere om te kunnen nagaan of de content over IPv4 gelijk is aan die over IPv6, maar ook om de TLS-settings te verifiëren).

[Reactie gewijzigd door mdavids op 23 juli 2024 03:01]

[Kees]

Ah inderdaad, dat zou inderdaad de fout kunnen zijn, die limiting treed vrij snel op voor een 'robot'. Ik zal daar ook even htst headers toevoegen.

[mdavids]

Ah inderdaad, dat zou inderdaad de fout kunnen zijn, die limiting treed vrij snel op voor een 'robot'. Ik zal daar ook even htst headers toevoegen.

Heeft meteen effect:

https://internet.nl/site/.../637800/#control-panel-10

[freddieleeman]

Waarom moeten moderators mail kunnen gebruiken zonder via jullie server te mailen? Je kunt het gebruik van een beveiligde verbinding via jullie SMTP server toch verplicht stellen? Dan is DKIM en SPF geen probleem meer. En het doorsturen van inkomende email is ook geen probleem als je Sender Rewriting Scheme (SRS) toepast. Dan breekt SPF niet en kan de doorgezonden mail alsnog van een DKIM handtekening worden voorzien.

[Stromboli]

Ik gebruik al sinds jaar en dag SPF op al mijn domeinen (ook DKIM trouwens) maar ik ervaar met SPF al sinds dag 1 een probleem dat ik nooit heb kunnen tackelen.

Het gaat om mail forwarden, wat veel gebeurt door mensen met een eigen domein (dus adres@eigendomein) en wat dan geforward wordt naar een algemene mailbox ergens anders.

Ik zet op mijn domein (zeg stromboli.com) een SPF record met de servers waar ik vandaan mail. Een klant heeft een adres zoals [e-mail], dat is een forward adres die alles redirect naar [e-mail]. Echter als een mail van mij dan binnenkomt bij Pietje's gmail, is voor gmail niet mijn oorspronkelijke mailserver de verzendende server, maar Pietje's eigendomein.com die hem heeft geforward. Dat is het IP wat in de header staat als hij bij Gmail aankomt.

En het SPF record op mijn stromboli.com bevat uiteraard geen entry voor Pietje's eigendomein.com, dus de SPF check faalt en Gmail denkt dat het spam is.

Zie ik nu iets over het hoofd of is hier niks tegen te doen? (behalve alles markeren als toegestane sender maar dat doet het hele idee van SPF teniet)

[Reactie gewijzigd door Stromboli op 23 juli 2024 03:01]

[freddieleeman]

Niet iets waar jij iets aan kan doen, maar wat hosting providers moeten aanpassen die mail doorsturen:

https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

[Belsameth]

Dit is de reden dat een heleboel mailbox providers SPF negeren, anders dan als een factor in DMARC. SPF is veel te kwetsbaar en word daar bovenop ook nog eens erg vaak verkeerd geimplementeerd.

[lasharor]

Op mijn eigen domein heb ik vrij recent ook DMARC aangezet. Ik had te maken met mensen die mijn email adres gebruikten om te spammen waardoor ik nogal wat mailtjes terug kreeg van "slachtoffers".

Na het aanpassen van mijn DNS records is het vrij snel afgelopen met al die spam. Dus heb hier wel positieve ervaringen mee.

[Warbringer]

Voor mensen die dit interessant vinden kan ik de volgende presentatie op Black Hat 2019 aanraden. Het is een werk tussen de Belastingdienst en een collega van me die op basis van Splunk en SPF, DKIM, DMARC en DNS data phishing campagnes inzichtelijk weten te maken. Naar aanleiding van dit verhaal hebben organisaties zoals ICANN en RIPE gevraagd om deze presentatie intern te komen geven. Stuur me maar een DM als je meer wilt weten.