Interessant dat Microsoft zich bemoeit met de interne bedrijfsvoering en risico-afweging van bedrijven.

Iemand een idee of dit ook geldt voor accounts gericht op particulieren, b.v. @hotmail.com en @outlook.com mailadressen?

Dit voelt een beetje als ABUS die ongevraagd langskomt om het nieuwste soort slot op je voordeur te zetten. Dit lijkt me iets waarvoor MS gewoon de verantwoordelijkheid bij de klant moet laten.

ja leuk he al je mail in control van MS. een hoop zal stuk gaan omdat MS een beperkte view heeft van mail en waar dat allemaal gebruikt wordt.

neem bijv de fixatie op SFP (via DMARC) dat forwarding breekt: http://www.open-spf.org/FAQ/Forwarding/

in een academische wereld waar mensen na 2 a 4j bij een andere universiteit werken, is forwarding essentieel! al die papers die published zijn met een mail adres die niet meer geforward kan worden... waanzin!

Wat goed dat een dienstenleverancier mee gaat met de tijd en dus nieuwe beveiligingsmiddelen uitrolt en oude uitfaseert!
Je moet maar durven! Maar zonder acties als deze blijven we met z'n allen veels te lang hangen op achterhaalde standaarden.
En daarbij, het is hun eigen toko.

Blijkkbaar kunnen klanten hun verantwoorelijkheid niet aan door op tijd hun voorbereidingen te treffen.
Een stok achter de deur op deze wijze lijkt me wel op zijn plaats dus.
Ook gezien de problemen met onveilighied etc op het net.
Goed gedaan van Microsoft!

ja heel fijn weer. ik heb nog op een systeem een fetchmail draaien die een specifiek account tbv een applicatie leeglepelt, maar fetchmail support geen oauth2 en dat schijnt dan in een versie 7 te zitten maar die is niet beschikbaar in de gebruikelijke distributies.
kun je weer source gaan downloaden en compileren, en het packaging gebeuren overriden... alsof in het algemeen de veiligheid van systemen daar zo veel beter van wordt!

en dit is maar een voorbeeld, er zijn vele applicaties die een mailbox uitlezen en die je niet zomaar even kunt aanpassen.
wellicht moeten we dan maar weer gaan klooien met onduidelijke "proxy" oplossingen zoals https://github.com/oauth2-proxy/oauth2-proxy

ze zouden op zijn minst een lijst van mailadressen en/of IP adressen moeten ondersteunen waar vanaf dit gewoon blijft werken.

Deze vergelijking slaat de plank mis. Je vergelijking zou geldig zijn als jouw slot in beheer is bij ABUS maar dat is niet het geval. De Mail en andere genoemde saas diensten/protocollen zijn in beheer bij MS en jij bent afnemer daarvan. Als de Mail etc bij jezelf in beheer zou zijn dan heb jij volledig zeggenschap erover.

MS heeft de verantwoordelijkheid om minimaal de basis inrichting van deze saas diensten op orde te hebben en dat veilig aan de afnemers aan te bieden.

Werd tijd.

Zo te zien hebben jullie niet in de gaten dat dit gaat over Exchange ONLINE.

Als het om offline Exchange installaties gaat zou het inderdaad vreemd zijn als Microsoft daar bepaald dat verouderde authenticatie methoden niet meer toegestaan zijn.

Maar voor een omgeving die bij hun draait is het niet vreemd dat zij verouderde / onveilige technieken uitfaseren.

Wist je dat nog niet? Microsoft rules! niet jij.

Er is helemaal niet zoiets als Basic Auth in POP3 en IMAPv4. Die kennen authenticatiemechanismen als PLAIN, LOGIN, CRAM-MD5.

Basic Auth is een authenticatiewijze in HTTP. De vergissing struikelde over de drempel en atomen zijn groen. Mist optrekken altijd een prima plan als je een eigen agenda er doorheen wilt drukken. Tsja. Laat me eens raden, het moet vervangen worden door een authenticatiedienst die heel toevallig een bepaalde partij centraler probeert te krijgen in een overkoepelende toegangslaag voor allerlei diensten in het algemeen, vermoedelijk ook van derde partijen?

Bedrijven met een Exchange mailserver en Linux werkplekken met een native mailclient zijn nu de sigaar.
Daarom als je naar een ander systeem overstapt, zorg dat je niet meer van Microsoft afhankelijk bent. Dus ook geen AD (kerberos hebben ze ook al een keer vernacheld) anders betaal je nog ms licenties voor elke linuxgebruiker/device.

Dit gaat over Exchange Online. Beter lezen!

Wat is dit nu weer voor dom gebash naar Microsoft? Dit is toch iets wat continue aan de gang is? Zelfde dat browsers alles via HTTPS afdwingen, of ongeldige certificaten niet meer accepteren. Hier is nu precies hetzelfde aan de hand, oude onveilige dingen worden uitgefaseerd (roepen ze al jaren) en niet meer toegestaan. Hulde. Niets mis mee. En als je toch dom bezig wil zijn biedt Microsoft nog weer een escape aan zodat je het toch lekker onveilig kan gebruiken. Heeft niets te maken met Microsoft die zich gaat bemoeien met bedrijfsvoering of zo. Wat een onzin.

Je zal straks zien dat iemand gehackt wordt via basic authentication...krijgt MS vast gewoon weer de schuld dat ze dat nog toestaan. Open Source is goed en Microsoft is slecht, het schopt ook zo lekker natuurlijk.

Wat een hoop onzin reacties hier weer. Oath2 bestaan al een tijdje en wordt niet alleen door MS gebruikt. Als een mailclient daar nu nog geen ondersteuning voor biedt, is het tijd om daar afscheid van te nemen.

Dit is gewoon een beveiligingsmaatregel die Microsoft neemt en alle klanten worden al jaren geïnformeerd. Als je nu je boel nog niet op orde bent, dan kan je beter het beheer aan een andere partij overlaten.

de heren hierboven die reageren in de trend van "update je mail client" hebben een hele nauwe scope over wat mail nu allemaal is en doet. het is niet slechts een kwestie van wat gebruikers die een andere mail client maar moeten gebruiken. er zijn heel veel processen die geautomatiseerd zijn die hier last van gaan krijgen. mail is core buisness en een gewilde kroonjuweel van een organisiatie en had NOOIT in een cloud bij een partij terrecht moeten komen!

Ik denk dat je niet helemaal begrijpt hoe de interne bedrijfsvoering van bedrijven hier bij betrokken is.
Veel bedrijven hebben hun "on-premise" Exchange omgeving verhuisd naar "online" (Office365, Outlook online).
Die gebruiken nog steeds Outlook en de Outlook webmail voor hun gebruikers, prima dat daar "modern authentication" in gebruikt moet worden.

Maar diezelfde bedrijven hebben ook APPLICATIES draaien die 1 mailboxje leeglezen en de mailtjes verwerken, bijvoorbeeld tickets aanmaken als je een mailtje stuurt naar een service account. DIE applicaties gebruiken gewoon POP3 of IMAP om de mailbox uit te lezen en die verbonden vroeger met de lokale Exchange server en nu met Exchange Online.
Dit soort applicaties wordt hierdoor getroffen en dat raakt de interne bedrijfsvoering van bedrijven.

Ik denk dat jij onder "een mailclient" alleen het programma verstaat wat je voor je neus hebt als je zit te e-mailen.
Echter, er zijn zoveel meer client programma's die mail lezen en/of sturen. Daar kun je niet allemaal afscheid van nemen, of het wordt weer een duur grapje.

ja we zijn er nog niet ...update via p2p.....ook zo lek als mandje....velen kunnen mee kijken

Ja vervelend al die zwaardere beveiligingen. Maar als je gehacked wordt dan raakt dat ook je bedrijfsvoering.

We maken deze onzin dagelijks mee met site contactforms koppelen met M365, Azure klanten.
Ik heb niks tegen betere beveiliging ik juig het toe maar het opzetten van MSGraph API en oauth2 bij Microsoft Azure is zo dom op gesteld dat je afvraagt of ze ooit zelf ermee werken.

Wat je wilt alles textbook en netjes scheiden qua tenant met betrouwbare certificaten? Ja sorry dat kan niet hoor daarvoor moet je eerst je applicatie (lees contactform) officieel laten registreren bij Microsoft en als je door review proces komt mag je het textbook afwikkelen.

Oh en vergeet niet om de twee jaar je secrets te vernieuwen want stel je voor dat iemand je secrets raadt dat kan natuurlijk niet.

Wat je wilt een alert bij verlopen van je keys? Oh nee daar hebben we niet aan gedacht dat moet jezelf maar in de gaten houden. Oh nee wacht je kunt natuurlijk altijd een API opzetten om dat op te halen waar je uiteraard wel weer een secret voor moet hebben met verloop datum en ohh....

Wat zeg je waarom we geen alert genereren bij token gebruik buiten registratie locatie om misbruik snel te achterhalen?
We zullen het meennemen als suggestie !


Maar je bent nu wel helemaal veilig natuurlijk.
https://www.crn.com/news/security/microsoft-azure-devops-targeted-by-hacker-group-reports
Ohh....


F it dan toch maar even een adres alias en simpele spf aanpassing this sht isnt worth our mental health.

Het door jou gelinkte artikel is van januari 2007! SPF stond toen in de kinderschoenen!
Forwarden gaat tegenwoordig prima zonder problemen te hoeven hebben met SPF!
Je moet er alleen een andere Envelope From voor gebruiken!
En als er DKIM op de Header From zit, zal DMARC ook nog kloppen!

Als jij je in de academische wereld betwijfel ik of je op de goede plaats zit.... verwijzen naar een artikel uit de oudheid (2007!) LOL.

euh wilt u even googlen naar SPF alignment?

https://community.spiceworks.com/topic/2344194-strict-spf-alignment-issue?source=recommended

asjeblieft een dingetje dat anno 2022 nog steeds speelt....

twijfel is gezond... stupiditeit niet. lees maar over 'spf alignment' en een wereld gaat voor u open...

https://support.dmarcdigests.com/article/1234-how-forwarding-can-break-dmarc

Ja maar daar gaat dit niet tegen helpen!
Men wil af van service accounts met wachtwoorden, maar daar voor in de plaats komen dan (statische) tickets.
Dat maakt voor de veiligheid verder niks uit.

Het is een goede ontwikkeling voor gebruik door menselijke gebruikers, maar voor applicaties die mail gebruiken zuigt het.

harige apenballen you might add! het gevolg zal zijn dat veel (web) appilcaties en mailing lists en uitbesteede (cloud) diensten die names jouw automatische mails doen niet meer werken => heel veel meer ellende voor die paar arme ITers die de fall over zich heen gaan krijgen. ik zou dit even goed onthouden want over een jaartje bij je burn-out, moet je maar even hier aan terug gaan denken aan dat grapje van MS.

Mag ik van Microsoft straks nog wel 1 laags WC papier gebruiken op kantoor? Die drielaags zijn wel een stuk veiliger. Dat geef ik toe. Maar als je eenlaags dubbelvouwt dan kom je al een heel eind. Ok, je moet even op het idee komen. Maar dat hadden ze in heel Seattle misschien nog even niet gedaan.

TL;DR DMARC controleert SPF of DKIM ... SPF checkt Envelope From (Return-Path), en moet voor DMARC inderdaad aligned zijn met Header From, maar als DKIM op de Header From wel klopt, speelt SPF sowieso geen rol meer.

Jij stuurt mail van <pietje.puk@example.NL> (Envelope en Header From) met kloppende SPF en DKIM, plus een DMARC policy, naar <info@example.COM>
De mailserver van example.COM forward naar example.NET.

Als mailserver van example.COM de Envelope From verandert naar bijvoorbeeld <bounce+pietje.puk=example.NL@example.COM>, dan zal de mail i.i.g. niet worden geweigerd op grond van de SPF voor example.NL.
De meeste servers die DMARC checken, zullen niet puur op een foute SPF weigeren, maar controleren of er een kloppende DKIM op de Header From (example.NL) zit en als dat zo is dan geeft DMARC een pass.
Als jouw mail geen geldige DKIM op de Header From (meer) heeft, dan geeft DMARC een fail en kan mail alsnog worden geweigerd - of in quarantaine worden gezet.

Als je dus DMARC wilt gebruiken op je domein dan is het verstandig om zowel SPF als DKIM te gebruiken!
Ook is het belangrijk dat de mailserver die forward geen DKIM getekende headers of de body veranderd, waardoor DKIM een fail zou opleveren!

Het voordeel van DMARC is de rapporten die je kunt krijgen en hierin zie ik regelmatig dat "mijn" - zakelijke - mail wordt geforward naar een gmail account, vaak met een kloppende SPF voor het domein waar de mail origineel naar toe werd gestuurd, waardoor weliswaar SPF voor "mijn" domein niet meer klopt, maar DKIM het wel houdt en daarmee ook DMARC een pass geeft.

Mail naar mijn Freedom en XS4all accounts wordt zonder DKIM/DMARC problemen naar mijn eigen mailservers geforward.

Er wordt hier en daar inderdaad een hoop aangerommeld.
Wat niet wegneemt dat het heel goed mogelijk is om tegenwoordig e-mail te forwarden zonder dat dit ten koste hoeft te gaan van eventuele SPF, DKIM en DMARC!
Als je dus een bedrijf, organisatie of universiteit bent waar veel mail wordt geforward en het belangrijk is dat klanten of ex-medewerkers die mail ook ontvangen, dan moet je wat meer aandacht schenken aan de gebruikte procedure.
Gebruik een Envelope From van jezelf, maar verander verder niks aan de (getekende) headers en de body!

google/DDG even op "Pigeonhole Sieve"

"TL;DR DMARC controleert SPF of DKIM ... "

het is iets subtieler allemaal denk ik...

https://datatracker.ietf.org/doc/html/rfc7489#section-6.3
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.2

vooral ook met die pct erbij.

Gaat MS binnenkort ook ipv4 uitzetten, komen we daar ook een keer vanaf.

ipv4 en ipv6 werken prima naast elkaar.
Daar gaat MS niet over. Als die het uitzetten werkt het nog net zo goed.

Dan controleert DMARC nog steeds SPF en/of DKIM

subtiel maar esentieel verschil vwb alignment... dus niet allemaal zo duidelijk en eenoudig...

anyway we dwalen af; want het neemt niet weg dat de topic over basic auth gaat en dat er plenty apps zijn in organisaties die dan 'belly-up' gaan.

Zou je me dan even willen uitleggen waarop DMARC dan wel zijn besluit op baseert als het niet op DKIM of SPF is?

Om vervolgens met deze verwerpelijke zooi te zijn opgescheept zeker.
https://reports.exodus-privacy.eu.org/en/reports/com.azure.authenticator/latest/

als SPF naar envelop kijkt alleen en DKIM naar de header "from" (de header is gesigneerd incl de 'form'), dan is DMARC alignement een issue voor forwarders aangezien afh van je DMARC policy de DMARC wel of niet passed, MAAR de daarop volgende spam filtering ook nog eens kan besluiten (onafh van DMARC dus) om een van de fails (DKIM of SPF en met forwarding zal er altijd eentje gaan falen) tot een drop / plaatsing in junk whatever tot gevolg gaat hebben.

Kortom, het is alles behalve triviaal en STERK afhankelijk van de ontvangende partij policies en instellingen of mail dan wel of niet door komt bij forwards.

Dan spreken we nog maar niet over de pct DMARC policy die dus de ene keer wel, de andere keer niet de mail aan checks laat gaan => heel lastig issues the debuggen en de vinger op de plek te leggen waar in het complexe systeem de dingen mis gaan.

Daartegenover staat dat forwards een veel gebruikte basis feature is die flink wat issues gaan opleveren als die niet meer goed werken. In de academische wereld, waar dus veel e-mail adressen op papers gepubliceert zijn en mensen vaak maar tijdelijk onderdeel van een organisatie zijn, wordt er ook veel gemailed tussen allerijl organisaties in andere wereld delen en daar heb je ook geen invloed op. De ellende is vaak vlugger en sneller te voelen dan in een eenvoudige MKB omgeving in een kikkerlandje als NL die alleen op de locale nederlandse markt operereert.

Anyhow, je snapt het nu , of je snapt het niet, maar het onderwep is basic auth en niet zo zeer DMARC/SPF/DKIM, maar de tegenwoordige mailfrutsraties komen tegelijk en worden door een enkele cloud partij (lees O365) geforceerd op plaatsen waar het wel degelijk problemen oplevert.

Bemoeien? Ze denken tenminste mee met hun klant. Niets mis mee lijkt mij

Dat doen browser boeren toch ook? Die bepalen ook de default policies van browsers waardoor van alles kan omvallen.
Op die manier tillen zij echter wel de security naar een hoger niveau en dwingen zij organisaties om mee te bewegen.

Ik vind het te prijzen dat Microsoft die verantwoordelijkheid neemt door klanten -die zelf niet bewust zijn beveiligingsrisico's- actief tegen zichzelf in bescherming te nemen.

Ik vind het ook een prima zet van Microsoft. En als je nog met (legacy) software zit wat geen modern authentication ondersteund, dan regel je maar een eigen mailserver. Dit gaat immers enkel om Exchange Online.

Draai het ook ff om. Waarom zou Microsoft tot in het einde der tijden iedereen z'n ouwe meuk moeten blijven ondersteunen? Wordt het sowieso niet veiliger op, de kosten gaan omhoog en het remt ook de vooruitgang.

Ook is het al jaren bekend dat dit er aan zat te komen. En het is ook al een keer uitgesteld. In 2018 werd voor het eerst door Microsoft aangekondigd dat ze Basic Authentication in 2020 zouden gaan uitfaseren. Dus iedereen, voor wie dit nu nog als een verrassing komt, heeft een beetje zitten slapen.

Je gebruikt dus een tool die niet (snel genoeg) is meegegaan met wat naar 'de stand der techniek' een addequate beveiliging is.

Ja maar, ja maar, er hangt bij de ingang een bordje 'verboden toegang voor onbevoegden', dus de beveiliging is al perfect geregeld.

Maar ze hebben in elk geval een goed argument naar het management waarom de upgrade nu eindelijk wel moet. MS zegt dat het moet en als je niet meedoet, gaat het stuk. Dat is voor het management vast overtuigend genoeg om iets van hun toekomstige bonus toch maar in de IT te investeren..

" dan regel je maar een eigen mailserver."

denk je nu werkelijk dat manglement dat net besloten heeft allez in ze clouds bij MS dmv O365 te doen (want glossy folder syndrome) DIE optie nog serieus bekijken? Pas als het kwaad is geschiedt; apps gaan stuk en ellende komt bloot, dan gaan ze eerst vergaderen en smoezen zoeken etc. en als het even kan het probleem toch eerder over de schutting bij de gebruikers te flikkeren.

in dit land hebben we vooral managers, geen leiders!

"Maar ze hebben in elk geval een goed argument naar het management waarom de upgrade nu eindelijk wel moet. MS zegt dat het moet en als je niet meedoet, gaat het stuk."

nee het is andersom, het is de geforceerde update die dingen stuk zal gaan maken. of en wanneer oauth beter is dan basic auth hangt sterk van de use case af; voor gebruikers en clients is oauth niet zo een issue, voor machines en alarmeringen die veelal scripts hebben die de automatisering doen, is het wel een probleem:

je hebt een wat oudere web site waar gebruikers een account aan kunnen maken en die moet daarom een mail versturen en om dat veilig te doen is er gebruik gemaakt van smtps (client-server-certificate checks) en basic auth (zodat je server side als het nodig is de zaak dicht te gooien door password te vervangen). dan besluit de grote organisatie alles van eigen exchange naar O365 te doen. nou ja prima, alles werkt nog en we gaan door, en dan nu ineens wordt basic auth afgedwongen uitgezet [en gaat men anaal op de DMARC]. op dat moment gaat de web site dus functioneel 'stuk'.

dat is een voorbeeld van een dingetje die ook zou kunnen gaan spelen bij enkele MKBers.

maargoed, we kennen de houding van de gemiddelde poster hier inmiddels wel; not my problem, it MUST be your fault.

als we aankondingen over 5 jaar de spanning op het net van 230V naar 120V te brengen, loopt iedereen dan achter en gebruiken die de verkeerde apparaten en stekkers of ben je van mening dat misschien die 5j niet realistisch is?

Misschien wel, maar nu moeten ze 2 authenticatie methoden blijven supporten. Straks maar 1.

Mijn vermoeden is dat het alleen een support vraagstuk is.