Interessant Erik.


Toch een beetje vreemd. Als je een afzender als 'veilig' bestempelt, zou dat juist de security checks moeten activeren om te verifiëren dat dit ook de afzender is.

Dus meer buggy mail software dan een verkeerde configuratie door de gebruiker.

Met andere woorden, markeren als "veilige afzender" kan DMARC checks (en dus ook de onderliggende SPF en/of DKIM checks) elimineren, waardoor mails met gespoofde afzenders in inboxes kunnen belanden.

Dit is helaas een foute conclusie. De bron vermeld het verder wel duidelijk:
Microsoft tags this email as a phishing attempt (since it does not pass DMARC security checks), however, due to a misconfiguration in the client environment, the email was not blocked and appeared as legitimate in the executive’s email inbox.


De Office 365 omgeving (tenant) was verkeerd geconfigureerd. Waarschijnlijk heeft een systeembeheerder (in ieder geval iemand met admin rechten) de afzender in een algemene whitelist gezet of DMARC volledig uitgezet. Ik heb dit soort stomme fouten wel vaker gezien.

Daarnaast wordt hier verder op in gegaan:
It is important to note that this misconfiguration can be a result of guidance provided by DocuSign to eliminate false positive spam alerts. DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net and recommends marking them as safe sender. This can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this. While this article discusses spam filters, it can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this.

Anyway, menselijke configuratie fout dus. Als ze niet met hun poten aan het spamfilter hadden gezeten was deze mail gewoon als spam of phishing gemarkeerd gezet. De les van de dag is wederom: You pay peanuts, you get monkeys...

PS. Microsoft waarschuwt hier zelfs duidelijk voor op hun site. Je moet nooit whitelisten op email of IP adressen.

Inderdaad dat soort "advies" zie je wel vaker... het zou beter zijn om dat foute advies aan te pakken ipv de gevolgen
van het verkeerd navolgen proberen te bestrijden.
Ook is er natuurlijk sprake van een verwarrende terminologie. "safe sender", "whitelisten", dat zet mensen op het
verkeerde been.

Vreemd advies. Waarop zou je anders moeten whitelisten? Dat geeft eerder aan dat hun mailserver niet goed doordacht is. Als je op email adres whitelist mag dat nooit de check overslaan op legitimiteit van dat email adres. Dus spf, dkim, dmarc etc moet je nog steeds doen om te checken of het adres gespoofed is. Je kunt alleen de spam checks overslaan als het adres ge-whitelist is.

In aanvulling op wat Briolet schrijft (waarvoor dank):
Ik waardeer aanvullingen, correcties en zelfs kritiek - mits goed onderbouwd, maar jij bent aan het trollen en zwetst uit je nek.

Totale onzin. De lijst met "Safe Senders" wordt door gebruikers zelf beheerd.

Naar verluidt kan een beheerder middels een GPO het gebruik van "Safe Senders" in Outlook blokkeren (tenzij policies zijn uitgeschakeld omdat je niet een van de veel duurdere Office licenties gebruikt) en in de web client werken policies sowieso niet.

Als een gebruiker dse@docusign.net toevoeg aan "Safe Senders", verwacht die gebruiker niet dat voortaan ook e-mails met gespoofde afzender als "Safe" worden behandeld.

En beheerders, die weten wat DMARC e.d. is, verwachten niet dat de uitkomst van de DMARC-check vervolgens genegeerd wordt door Microsoft Exchange, en gebruikers daardoor mails met gespoofde afzenders in hun inbox krijgen.

Dit is gewoon een blunder van Microsoft.

Na googlen zag ik dat eerder anderen al op deze blunder hebben gewezen, zoals:
https://www.linkedin.com/pulse/safe-senders-list-loophole-through-your-exchange-security-r%C3%B8rvik

https://regarding365.com/email-overrides-are-not-best-practice-942a02ba8aec

Je maakt dezelfde stomme fout als Microsoft, namelijk spam en/of phishing op dezelfde hoop gooien als spoofing.

(Microsoft leert nooit, 17+ jaar geleden: https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden).

M.b.t. DMARC
DMARC (bouwend op SPF of DKIM) is géén antispammaatregel, maar antispoofing (niets belet hufters om vanaf een eigen afzenderdomein spam en/of phishingmails te verzenden met correcte SPF, DKIM en DMARC attributen).

Ik kan me tijdelijke uitzonderingssituaties voorstellen waarbij, als gevolg van configuratiefouten, de DMARC-check onbedoeld een negatieve uitkomst heeft, en je dergelijke mails niet wilt droppen - maar dan wel voorzien van toeters en bellen in de spambox of desnoods de inbox wilt plaatsen. Dit zou echter niets met "Safe Senders" te maken moeten hebben, want hier is niets Safe aan.

Eventueel kun je een negatieve DMARC-uitkomst gebruiken als één van de inputs van je spamfilter (positief zou ik negeren), om, als het tevens om spam lijkt te gaan, te besluiten alsnog te droppen of om aanvullende toeters en bellen aan de mail toe te voegen.

DMARC en dergelijke zijn al halve maatregelen, nl. omdat SMTP-from niet altijd getoond wordt, ontvangers er niet op letten en als ze dat wel doen, niet weten dat afzenderdomein X niet van de kennelijke afzender is.

Voor ontvangers die wel het afzenderdomein checken en weten (of uitzoeken) dat dit domein van de kennelijke afzendende partij is, is DMARC zeker zinvol, maar met dit soort idioterie van Microsoft kunnen we -wat mij betreft- stoppen met DMARC et al.

Helemaal niet "duidelijk": ik moest er flink naar zoeken, met als resultaat zeer veel pagina's die vooral beschrijven hoe handig "Safe Senders" is en het gebruik ervan aanmoedigen, zonder ook maar één waarschuwing daarbij.

De duidelijkste waarschuwingen vond ik (niet bovenaan) in https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/create-safe-sender-lists-in-office-365?view=o365-worldwide:
Hoezo zou een lezer plaats 2 van 4 in een lijstje met volgorde "most recommended to least recommended" als "not recommended" moeten beschouwen (zoals verderop blijkt)? Dit artikel spreekt zichzelf tegen.

Daaronder volgt een lichtblauwe "information box" met pas bij de derde bullet de volgende tekst:
Met andere woorden, we maken superhandige "Safe Sender Lists" maar tussen neus en lippen door zeggen we "Do Not Use" want we hebben een aanpak die anders is dan weldenkende mensen verwachten.

Pas een stuk verderop, direct onder het kopje "Use Outlook Safe Senders" (niet: "Do Not Use Outlook Safe Senders") staat een roze box met de tekst:

Maar het is natuurlijk een illusie dat eindgebruikers dit lezen, laat staan begrijpen dat in Microsoft's denkwereld "Safe Senders" gelijk staat aan "bypass DMARC" en dus "Allow Spoofing".

Misschien begrijp ik je hier verkeerd, maar DMARC gaat altijd over het header-from (RFC5322) adres, het adres dat in je mailprogramma wordt getoond en niet over het envelope-from (RFC5321) adres!

Als aanvulling hoe tegenstrijdig Microsoft's adviezen zijn, bijna onderin https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide staat een roze box met:
Go figure...

Sorry, ik had duidelijker kunnen zijn: met "SMTP-from" bedoel ik het feitelijke (door SMTP "begrepen") deel dat in principe tussen <> geschreven wordt.

Bij een afzender zoals:
toont een deel van de mail clients (MUA's), vooral mobiel, slechts:

in plaats van:

Nb. dat MUA's "" weggelaten vind ik geen probleem, maar ik wil wel dat tweede deel zien. Want als DMARC checkt (en Microsoft een negatief resultaat niet weggooit "want Safe Sender"), dan vindt die check -in dit geval- plaats op docusign.net.

Dan hoef ik "alleen nog maar" te weten dat het domein docusign.net van het bekende bedrijf DocuSign is (zo niet dan weet ik hoe ik dat op moet zoeken, wat helaas niet voor iedereen geldt).

Overigens zouden MUA's van mij een slotje mogen tonen als er betrouwbaar op DMARC gecheckt is en het resultaat positief is, maar erg lastig is dan wel dat je dan alle gebruikers moet uitleggen dat je daar bar weinig aan hebt bij bijvoorbeeld @gmail.com (alleen afzenderdomein wordt gecheckt) en dat er ook nog zoiets bestaat als BEC (Business Email Compromise) - dat niet alleen zakelijke gebruikers treft (nog even los van het feit of elke DocuSign medewerker te vertrouwen valt).

Het blijft tobben met de authenticiteit, betrouwbaarheid, vertrouwelijkheid en beschikbaarheid van e-mail, en Microsoft weet het ook nog eens onnodig ondoorzichtig te maken...

Als ik https://support.microsoft.com/en-us/office/add-recipients-of-my-email-messages-to-the-safe-senders-list-be1baea0-beab-4a30-b968-9004332336ce goed begrijp, is Microsoft nog stommer en nog tegenstrijdiger dan ik al dacht (verbeter me s.v.p. als het anders werkt dan ik opmaak uit die pagina, bevestigingen zijn ook welkom natuurlijk).

Daaruit:

Dus als je n.a.v. mijn post bovenaan deze pagina jouw lijst met "Safe Senders" hebt leeggemaakt, zul je ook de instructies onderaan die Microsoft-pagina moeten opvolgen om te voorkomen dat jouw contacten ook allemaal "Safe Senders" zijn en blijven. In plaats daarvan kun je natuurlijk ook al jouw contacten verwijderen (daarmee bedoel ik de contactgegevens die jij van hen hebt ;-)

Weer serieus: alle marketing-speak van Microsoft over hun omarming van "Zero Trust" is, tot nu toe, gebakken lucht gebleken. Het is m.i. de hoogste tijd dat dit soort "geen daden maar woorden"-producenten financieel aansprakelijk worden gesteld voor de vele "datalekken" (o.a. ransomware en uitlekken van vertrouwelijke gegevens) waar zij op z'n minst mede voor verantwoordelijk zijn.

Op zich is het koppelen met je adresboek een handige zet. Bij mij zet de mailserver junk direct in de junk folder. Mijn eigen mail client bekijkt vervolgens de inbox nog een keer en verplaatst alle mail met een afzender die niet in mijn adresboek staat, naar een postbus "onbekende afzenders". (Via een filterregel)

Gespoofde afzenders haalt de mailserver er dan al uit (Spambox of bouncen) en gelijkende afzenders worden ook uit de inbox geweerd. De inbox blijft zo betrouwbaar. En de onbekende afzenders worden extra gecontroleerd en indien goedgekeurd, aan mijn adresboek toegevoegd.

----
Het probleem van Microsoft lijkt te zijn dat de mailserver zowel spam als gespoofde mail in de spambox plaatst en hun mail cliënt bij whitelisted afzenders, deze mail weer naar de inbox verplaatst zonder in de header te kijken of deze mail vanwege spoofing in de spambox terecht gekomen was.

Gewoon een super stomme denkfout. In plaats van het plaatsen van waarschuwingen in hun handleidingen, hadden ze beter het probleem van hun mail cliënt kunnen oplossen. Want blijkbaar waren ze op de hoogte van dit probleem. Het bedrijf is te log en de schrijvers van handleidingen praten blijkbaar niet met de programmeurs als ze problemen zien.

Soms vragen bedrijven je in hun e-mail om hun the allowlisten. Dit is een van de redenen dat je dat niet moet doen.
Als een mail legitiem is en hij wordt toch tegengehouden dan is dat onderzoek waardig, dat moet je niet willen corrigeren met allowlists.

Hmm ja e.a. valt op Microsoft met spoofing zaken klopt eigenlijk wel.

Maar best veel echt grote partijen hun mail en hun mailsystemen en servers ook al hebben ze ( is vaak ook niet zo) dmarc, dkim en spf en eventueel meer) op orde zijn in basis nog steeds zeer veel voorkomende spam emailadresen en of erger zelfs zonder spoofing.

Ze houden hun eigen hok overduidelijk niet schoon! ( op zijn minst niet op tijd) zo ook hun cloud oplossingen bieden nog steeds heel veel scammers teveel ruimte.

Wat dan gek is als andere kleinere partijen wel alles, dmarc, dki, spf, dnssec ezn op orde hebben en ook de EU test en score betwrouwbare mail optimaal, blokken ze toch als smap of grey list enz. ( ip zelf clean en indien je de report functie gebruikt schrijven ze dat alles ok is , dat moet je dan nog 1 tot 2 keer doorlopen pas daarna krijg je manuele aandacht en kan je het oplossen.

Zoiets is natuurlijk "oneerlijke mededinging" en komt andersom niet voor.

Ook zonder dat je spamt en ip toch clean is en blijft moet dat alles soms vaker.

Ik wil dus aanhalen dat het gehele dmarc, dkim, spf enz door in ieder geval Microsoft op meerdere vlakken niet juist aangepakt is van twee kanten bekeken.

Waarbij jammer dat de grote partijen onderling grote "whitelisten" naja white in ieder geval mails vertrouwen en doorlaten waar niet uitmaakt of scam.
En anderen tevaak op "verborgen" listen of procedures aangwezen zijn om bij die partijen wel goed met hun mailserver systemen door te komen.
Maakt ook niet uit of je aangifte doet van deze praktijken AP en co lijken geen tijd te hebben , en de grotere hosters moeten dan ook vaak andere oplossingen voor mail aan hun klanten aanbieden, die treden niet op tegen microsoft want ze zijn ook partner!

Naja na onderzoek kan er dus wel degelijk een geldige reden zijn om dat toch te doen, bijvoorbeeld hen te helpen een goed mail reputatie op te bouwen indien werkelijk legitiem kan reeds een reden zijn.
Als ze via verschillende oplossingen via thuiswerken en dus mogelijk andere ip in client van providers gebruiken kunnen deze grey listed zijn en dus vertraging geven enz.
Of net een nieuwe IP die nog geen reputatie heeft en of voorheen block abuse list enz....

Wel dienen die partijen dan minstens spf, dmarc, en dkim op orde te hebben vind ik, en moet dit spf streng ingesteld zijn dat een fail daar ook echt een blok op gaat leveren, ( ook zou ik niet hele maildomain toelaten maar specifiek adres maar ok)

Maar is dat verstandig?

Als e-mails die echt afkomstig zijn van "piet@example.com", om welke reden dan ook, in jouw spambox belanden of worden geweigerd door jouw ontvangende mailserver, dan kun je dat e-mail adres "allowlisten". Probleem opgelost zou je zeggen. Totdat een aanvaller weet dat genoemd e-mailadres in jouw allowlist zit, want dan kan die aanvaller vanaf een willekeurige mailserver liegen dat hij of zij "piet@example.com" is. Tot zover "security by obscurity".

Anders wordt het als een bedrijf als Docusign aanraadt om "dse@docusign.net" te allowlisten, en mensen die dat doen niet weten dat ze daarmee de deur openzetten voor e-mails met vervalste afzender. Aanvallers kunnen gokken dat jij Docusign gebruikt of dat wellicht op internet vinden (bijv. omdat je er op een forum een vraag over gesteld hebt), en gokken dat jij "dse@docusign.net" in jouw allowlist hebt.

Als gebruiker weet je niet welk criterium doorslaggevend is: jouw "allowlist" of maatregelen "onder water" waaronder "hard fail" of "soft fail". En als je dat wel hebt uitgezocht kan het morgen weer anders zijn (bijv. omdat andere gebruikers een probleem hebben aangekaart).

Daar komt bij dat de meningen verdeeld zijn over wat de juiste instellingen zijn voor o.a. SPF en DMARC (bijvoorbeeld omdat indien een forwarder geen SRS heeft, mails met SPF "-all" niet aankomen). Zie bijvoorbeeld deze (m.i. tekenende) discussie: https://tweakers.net/nieuws/182316/e-mail-spoofing-was-mogelijk-bij-domein-testen-voor-toegang.html?showReaction=16117012#r_16117012.

SPF/DKIM/DMARC blijft half werk, gecompliceerd en foutgevoelig, nog los van dat veel ontvangers het echte afzenderadres niet checken (of niet eens te zien krijgen in hun mail client).

In mijn optiek zou je zo'n mail moeten kunnen whitelisten, maar blijkbaar zijn er mailclienten (Outlook?) die dan ook gespoofde mail weer doorlaten. Gespoofde mail zou ook met ge-whiteliste mail niet doorgelaten mogen worden.

Er zijn bedrijven die zelf mail spoofen, maar als die niet aankomt is het eerder zaak van de verzender dan van de ontvanger om hier wat aan te doen.

Als voorbeeld kwam ik gespoofde mail van de ziggo helpdesk tegen. Dit zal een externe helpdesk geweest zijn die hun eigen mailserver gebruikt om de mail namens Ziggo te versturen. Bij mij kwam die mail wel binnen omdat Ziggo hun dmarc indertijd nog op policy=none had staan. Het is niet aan mij om mijn beveiliging te verlagen om de mail binnen te krijgen, maar die helpdesk moet via de Ziggo mailserver gaan versturen, of Ziggo moet de externe mailserver opnemen in hun spf allow-lijst.

Ik moet toegeven dat dmarc voor een klein bedrijf als wij zijn, een stuk eenvoudiger te implementeren is dan bij een groot versplinterd bedrijf met vele mailservers en ingehuurde afdelingen.

Het is inderdaad wel heel krom dat er een koppeling is tussen "vertrouwde afzender" en "dan hoeven we DMARC niet te checken"! Dat zou eerder andersom moeten zijn: als je een adres op je lijst van vertrouwde afzenders zet dan word dit strenger gechecked dan wanneer dit niet het geval is.
Dan moet dit uiteraard wel een expliciet beheerde lijst zijn, niet "alle afzenders in je adresboek zijn vertrouwd".

Zoals meestal is het hele idee van "vertrouwd" niet als een simpele ja/nee vraag te beanwoorden. Vertrouwd voor WAT?

Voor het droppen, daar is de DMARC Policy van de afzender voor: p=none / p=quarantine / p=reject

Als iemand jouw afzender domein met adres@voorbeeldje.local gebruikt dan kun je met een DMARC Policy in je DNS record aangeven wat er met email die vanuit naam van @voorbeeldje.local wordt verstuurd moet gebeuren, als de DKIM/SPF check mislukt. (met p=none, dan gebeurd er dus verder niks met de email en kan deze worden afgeleverd)

Maar als je dan DMARC Policy p=reject hebt ingesteld, dan komt deze email niet aan.
(Als de ontvangende mail server DMARC checkt)

De manier hoe je omschrijft omzeilt DMARC helemaal niet. De safe sender list in de Outlook MUA zorgt er voor dat mail die eigenlijk in 'junk' afgeleverd wordt, nu in Inbox komt. Dat is wat anders.

Hoewel ik het er mee eens ben dat dat niet wenselijk is voor de gemiddelde gebruiker, omzeilt dit geen DMARC.

Het probleem is vooral dat Microsoft365 de DMARC-standaard niet volgt en p=reject negeert en de mail vrolijk bij de user aflevert. p=reject == p=quarantaine volgens MS, want anders mist de gebruiker misschien mail (false positives).

https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?redirectedfrom=MSDN&view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc

Grappige (nou ja...) is dan ook weer dat MS vervolgens hier ook vertelt hoe je de mail ipv in de junk gewoon in je inbox krijgt, maar goed.

Kortom, met DMARC/DKIM/SPF is helemaal niet zoveel mis als je stelt, maar men moet e-mail wel op de juiste manier implementeren en de standaarden volgen, anders werkt het inderdaad maar half.

Zie mijn antwoord hieronder.

Als de DMARC check wel wordt uitgevoerd maar met een fail niets wordt gedaan als de afzender in de allowlist staat, is dat effectief toch bypassen van DMARC?!

In de link die je gaf (hier clickable en iets korter: https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/use-dmarc-to-validate-email#how-microsoft-365-handles-inbound-email-that-fails-dmarc) staat klip en klaar (opmaak toegevoegd door mij):
Oftewel:
1) Fail wordt spoof
2) Afzender in allowlist: spoof wordt not spoof
Effectief: DMARC bypass

Ik herhaal, en dat vind ik nog meer na te lezen dat er kennelijk nog steeds legitieme mail op Microsoft's servers wordt afgeleverd met (onnodige) DMARC fail:
Ik mis steekhoudende argumenten in jouw post waarom dit niet zo zou zijn.

Aanvulling 12:35: de mogelijk grootste e-mail provider (vooral zakelijk), Microsoft, zegt hiermee tegen prutsers die SRS en dergelijke niet of niet goed implementeren, beloont hen in feite: "geeft niet, zeg gewoon tegen je gebruikers dat ze jou aan safe senders moeten toevoegen" - terwijl gebruikers er geen idee van hebben welke backdoor ze hiermee open zetten.

Daarmee ondermijnt Microsoft het hele systeem onder DMARC (nog los van dat veel ontvangers het echte afzenderadres niet checken - of niet eens te zien krijgen in hun mail client).

En daarom: SPF, DKIM en DMARC suck. Ontvangers en verzenders kunnen er niet op vertrouwen. Curiosity killed the cat, maar complexity kills the computer.

"1) Fail wordt spoof"
Fail wordt helemaal geen spoof. Fail blijft fail. Alleen de manier hoe de ontvanger (MS) hier mee omgaat is niet volgens de voorschriften. Dat dit effectief hetzelfde resultaat oplevert, betekent niet dat dat de schuld van DMARC is.

"Ik mis steekhoudende argumenten in jouw post waarom dit niet zo zou zijn."

Nou, die missen bij jou net zo goed waarom het wel zo zou zijn. DMARC doet toch prima zijn werk? Geeft namelijk een fail wanneer het adres gespooft is. Dat de ontvanger (dat is Microsoft in dit geval, niet de MUA/gebruiker,) er voor kiest om dat resultaat te negeren, is niet de schuld van DMARC. En dat is ook precies de reden dat je statement "en daarom: SPF, DKIM en DMARC suck" kant nog wel steekt met de redenering die je aanvoert. Microsoft is hier de schuldige, niet spf/dkim/dmarc.

Even de discussie nog vanuit een ander perspectief belichten. Ook hier werd gebruik gemaakt van een safelist voor mail (niet in M365 maar in een firewall onderdeel). Hierop stond ook een wetransfer mailadres. Wij hebben de proef op de som genomen en een spoof mail gestuurd vanuit dat mailadres met daarin ook een url via een shortener opgenomen. Het resultaat was dat deze netjes in de mailbox binnenkomt terwijl SPF, DKIM en DMARC failen.

De safelist zorgde er dus voor dat alle controles uitgeschakeld werden. Risico is dus dat wij daadwerkelijk een spoofmail krijgen met daarin een valse link waar een gebruiker op gaat klikken.

Ik denk dus dat een safelist, allowlist of whitelist alleen maar zorgen voor schijnveiligheid voor gebruikers. Je kunt geen mail volledige vertrouwen op basis van e-mailadres. Er zullen dus nog steeds aanvullende controles uitgevoerd moeten worden welke er vervolgens in resulteren dat de mail nog steeds als spam of quarantaine beoordeeld gaan worden.