Toegevoegde waarde van DMARC naast DKIM

25-01-2021, 14:24 door Anoniem

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.

25-01-2021, 14:29 door Anoniem

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

Je kunt ermee aangeven wat er met mail moet gebeuren die niet voldoet aan DMARC.
En je kunt rapporten vragen waardoor je een idee krijgt wat er allemaal uit jouw naam wordt verstuurd en wat ermee gebeurd.

https://dmarc.org/

25-01-2021, 15:14 door Anoniem

Door Anoniem:

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.

Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.

25-01-2021, 15:34 door Briolet

Het verschil is hemelsbreed.

Als je alle mail handmatig controleert via de header, dan is er geen toegevoegde waarde voor de ontvanger omdat die precies ziet wat ook DMARC zal zien. DMARC maakt het echter mogelijk om mail geautomatiseerd af te wijzen.

Echter, vergeet niet dat DMARC ook waardevolle informatie geeft aan de domeineigenaar. DIe kan via DMARC in de dagelijkse rapporten zien dat er mail met gespoofde afzender verstuurd wordt. Als dat veel is, kunnen ze actie ondernemen.
DKIM geeft helemaal geen terugkoppeling.

25-01-2021, 16:33 door Erik van Straten

Naast wat Briolet zegt: een DKIM signature zegt niets als deze door een server is gezet die het vertrouwen niet waard is.

Zoals zo vaak bij security: het probleem is dat veel mensen niks snappen van non-repudiation (it wasn't me). Het is fijn dat jij de authenticiteit van mails verzonden door jouw server kunt aantonen, maar dat heeft nauwelijks zin als je niet kunt aantonen dat een specifieke e-mail niet door jouw organisatie is verzonden.

Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.

Zie bijv. https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 waarin ik een DKIM-signed mail ontving van ashley.nivers@gmail.com die helemaal niet door een gmail.com server was verzonden.

Overigens ben ik na die bijdrage veel minder enthousiast geworden over SPF+DKIM+DMARC, omdat het voor DMARC goed genoeg is als ofwel SPF ofwel DKIM klopt - en belangrijker, omdat steeds meer mensen mailen op kleine devices waar je zelden nog de SMTP-afzender ziet en de meeste gebruikers er geen idee van hebben welke policies zendende servers gebruiken, hoe goed "hun" ontvangende mailserver daarop checkt en wat er met een mail gebeurt (spam folder, tagging) als er iets niet klopt. En bij gecompromitteerde afzender mail accounts (o.a. BEC) of slecht geconfigureerde/corrupte bulkmailers helpen deze maatregelen ook al geen zier (integendeel, ze suggereren onterecht authenticiteit).

25-01-2021, 17:06 door Anoniem

Door Anoniem:

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.

Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.

Beter lezen als je pedant wilt doen .

Ik schreef niet dat DKIM een technische link heeft met DMARC, maar dat mensen die zo ver zijn dat DKIM *implementeren* - wat de vragensteller claimt - echt al lang de relatie met DMARC zijn tegengekomen en daar niet naar hoeven vragen.

Dit is de zoveelste luie huiswerkstudent , en die ga ik niet helpen.

25-01-2021, 18:00 door Anoniem

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

Naast de reports, zoals anderen al schreven, lost DMARC vooral het probleem op waarbij een ontvangende mailserver geen actie heeft voor mails zonder DKIM signature. Een mailserver kan er bijvoorbeeld voor kiezen om mails zonder DKIM handtekening bij de spam te zetten, of zelfs in de inbox te zetten als de spam score niet te hoog is. Via DMARC kan je als organisatie zelf aangeven wat er moet gebeuren wanneer een signature mist: niets, quarantaine of reject.

26-01-2021, 10:48 door Anoniem

Door Erik van Straten:
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.

Het begint al met het foute beeld dat DMARC, DKIM en SPF iets zeggen over door welke ORGANISATIE een mail al of niet verzonden is. Nee! Het zegt iets over het afzender DOMEIN. En een domein correspondeert niet 1:1 met een organisatie.

26-01-2021, 13:37 door Briolet

Door Erik van Straten: Overigens ben ik na die bijdrage veel minder enthousiast geworden over SPF+DKIM+DMARC, omdat het voor DMARC goed genoeg is als ofwel SPF ofwel DKIM klopt - en belangrijker, omdat steeds meer mensen mailen op kleine devices waar je zelden nog de SMTP-afzender ziet …

Dat één van beiden genoeg is, is inderdaad een gemis. Veel mensen forwarden hun mail echter en dan op zo'n manier dat de SPF check op de afzendernaam niet meer klopt. Als ik een mailing verstuur zie ik dan ook een groot percentage SPF fouten. Ik kan me voorstellen dat deze fouten geaccepteerd worden als DKIM klopt.

Een DKIM ondertekening overleeft het forwarden altijd, mits de titel of inhoud niet aangepast wordt. Dat hadden ze altijd verplicht kunnen maken. Ik heb me verbaast bij de Duitse DHL en de Duitse Post. Beiden sturen ze de tracking code naar klanten via dezelfde mailserver. Op beide domeinen zat een DMARC beveiliging met 'reject' policy. Echter voegde deze mailserver geen DKIM ondertekening toe. Als je die mail op de verkeerde manier forwarde (met behoud van oude afzender), kwam hij nooit aan.

Probleem is dat de gewone gebruiker onbekend is met het fenomeen DKIM. GMail toonde een paar jaar geleden bij hun webmail wel de DKIM informatie via een pull-down menu vanaf de afzender naam. Dit hebben ze weer verwijderd. Ik gok omdat dit alleen verwarde vragen opriep bij gewone gebruikers.

Voor Thunderbird was er een plug-in die de DKIM informatie direct boven de mailinhoud plaatste. Maar sinds de strengere eisen aan plug-ins is er geen nieuwe versie meer van gemaakt.

Hoe mailservers omgaan met een foute DMARC weet ik niet. Onze mailserver doet ook echt een reject als dat de policy was. Ik zie ze dan nooit. Maar misschien dat sommige mailservers ze toch doorlaten en alleen in de spamfolder gooien. Dan haal je idd de hele beveiliging onderuit. (Wat nu ook als gebeurd bij SPF met een hard fail instelling. Die komt vaak toch aan bij veel mailservers.)

26-01-2021, 13:39 door Erik van Straten

Door Anoniem:

Door Erik van Straten:
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.

Het begint al met het foute beeld dat DMARC, DKIM en SPF iets zeggen over door welke ORGANISATIE een mail al of niet verzonden is. Nee! Het zegt iets over het afzender DOMEIN. En een domein correspondeert niet 1:1 met een organisatie.

Je hebt natuurlijk 100% gelijk, suf dat ik dat niet zo verwoord heb...

26-01-2021, 19:51 door Anoniem

Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?

KORT: DKIM en SPF kunnen DMARC / DMARC DNS entrys raadplegen om te zien of de ontvangen mail wel echt vanaf het orginele domein verstuurd is of dat een mail gespoofed is. Je verbeterd als het waren de DKIM en SPF functionaliteiten. Dit gaat geautomatiseerd en de gebruiker achter de mail server hoeft verder niets te doen (behalve beheer/servicedesk bellen bij onregelmatigheden).

LANG:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":

MailServer A (stelt DMARC en DMARC dns entry's in) -> stuurt mail -> Mail Server B onvangt mail (SPF + DKIM op server B controlleerd de DMARC/DMARC dns entrys en DNS public keys.) Aan de hand hiervan word de mail in quarantaine geplaatst of doorgestuurd naar de mailbox van de gebruiker. Zo voorkom je spoofing van mail. Alleen de geauthoriseerde mail door (dmarc) mail server A word als echt gezien door (spf+dkim) mailserver B.

Maar je stelt DMARC, SPF, DNS ook allemaal op je eigen server en dns in aangezien jij het volgende wilt:
- Je wilt kunnen aantonen dat de mail wel echt van jou komt (authorise mail).
- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).

- SPF;
SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).

- DKIM;
DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.

- DMARC;
DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.

- DANE;
DANE is een protocol wat je TLS certificaten laat binden aan DNS registraties. Dit gebeurd met DNSSEC. Het idee is (in dit geval) dat je hiermee STARTTLS kan forceren en handhaven.

- STARTTLS;
STARTTLS is een protocol dat er voor zorgt dat mail getransporteerd word over encrypted verbindingen "SSL/TLS verbindingen". Het heet STARTTLS omdat de TLS connectie eerst opgezet word voordat de mail verstuurd word, denk hierbij aan een HSTS achtige werking (lekker belangrijk). Het idee is dat je mail verstuurd over een beveiligde SSL/TLS verbinding net als met het HTTP over TLS/SSL (HTTPS) principe.

Nogmaals, verbeter me als ik foutjes maak, het word gewaardeerd ;)

- RAMLETHAL

27-01-2021, 11:57 door Anoniem

Door Anoniem:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":

Deze maatregelen hebben niets te maken met het "schoon houden van je server" (wat je er ook onder wilt verstaan).
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.

27-01-2021, 17:02 door Anoniem

Door Anoniem:

Door Anoniem:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":

Deze maatregelen hebben niets te maken met het "schoon houden van je server" (wat je er ook onder wilt verstaan).
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.

Dankje voor de verbetering!

29-01-2021, 16:10 door Erik van Straten

Door Anoniem: In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":

SPF helpt je server schoonhouden doordat het zogenaamde "Joe jobs" helpt voorkomen (https://en.wikipedia.org/wiki/Joe_job). SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver.

Stel jij bent eigenaar van example.com. Een cybercrimineel verstuurt bergen spam via in een botnet opgenomen PC's (met IP-adressen die afwijken van die van jouw mailserver) met envelope-from *@example.com. Ontvangende mailservers, die mail eerst accepteren en er daarna pas achterkomen dat een mail niet kan worden afgeleverd (bijv. mailbox vol) zullen de foutmelding dan naar jouw server "terug" sturen. Dit kan tot een soort DDoS leiden (voordat SPF bestond heb ik een mailservertje beheerd die soms meer dan 1 foutmelding per seconde ontving waarvan een deel in bestaande mailboxen terechtkwam).

Door Anoniem: - Je wilt kunnen aantonen dat de mail wel echt van jou komt (authorise mail).
- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).

Niet van jou of van de originele afzender, maar (zoals anoniem 26-01-2021, 10:48 terecht opmerkte) van het afzender-domein.

Door Anoniem: - SPF;
SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).

SPF was er veel eerder dan DMARC en werkt ook zonder. SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver. Daardoor werkt forwarding niet meer (tenzij de forwarding mailserver ten minste het domein in envelope-from wijzigt, maar om foutmeldingen te kunnen retourneren moet die mailserver dan "stateful" gaan werken, en niet elke mailadmin wordt daar blij van).

Door Anoniem: - DKIM;
DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.

DKIM is een protocol voor het digitaal ondertekenen van (een deel van) de onderdelen van een e-mail. Meestal doet de zendende mailserver dat. Probleem: het domein van de server die ondertekent mag afwijken van het domein in het From: veld dat een deel van de e-mail programma's laten zien, waardoor een DKIM signature door een server van een spammer kan zijn gezet, een niet vertrouwde partij dus. Een digitale handtekening zegt helemaal niets als je de zetter daarvan niet vertrouwt. Een ander probleem is dat sommige mailservers kleine wijzigingen in mails kunnen aanbrengen (onzichtbaar voor de ontvanger) die ertoe leiden dat de digitale handtekening niet meer klopt.

Door Anoniem: - DMARC;
DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.

Het primaire doel van DMARC is domain alignment. Bij een afdwingende instelling vereist DMARC dat ofwel het SPF domein (in envelope from) ofwel het domein van de DKIM-signerende server, of beide, overeenkomen met het domein in het vaak aan de gebruiker getoonde From veld.

Omdat SPF en/of DKIM "onderweg kapot kunnen gaan" vindt DMARC het nog acceptabel als één van die twee checks een negatief resultaat oplevert (als beide niet valideren heb je pech, tenzij het om spoofing gaat natuurlijk). Het nadeel hiervan is dat een spammer/spoofer maar één van beide (SPF of DKIM) hoeft te kunnen vervalsen.

Zie https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 voor uitgebreide info.

29-01-2021, 18:00 door Anoniem

Door Erik van Straten: