image

Microsoft wijst 365-beheerders op nieuwe anti-spamregels van Google

maandag 9 oktober 2023, 15:09 door Redactie, 12 reacties

Volgend jaar gaan er nieuwe regels gelden voor partijen die grote hoeveelheden e-mail naar Gmail-gebruikers sturen. Iets waar ook afnemers van Microsoft 365 rekening mee moeten houden, zo stelt Microsoft. Google gaat vanaf februari verplicht dat 'bulk senders' hun e-mail authenticeren door gebruik te maken van e-mailstandaarden SPF of DKIM.

"Wie e-mails via Microsoft 365 verstuurt kan tegen nieuwe problemen aanlopen bij het afleveren van e-mails bij populaire mailproviders. Google heeft bijvoorbeeld strengere beveiligingseisen gesteld aan het authenticeren van inkomende e-mailberichten, met name als die in grote hoeveelheden worden verstuurd", zo laat het Exchange Team in een blogposting weten.

Volgens Microsoft kunnen organisaties het afleveren van hun verstuurde e-mail verbeteren als er gebruik wordt gemaakt van standaarden als SPF, DKIM en DMARC. Dit moet ontvangers tegen malafide berichten beschermen en verkleint de kans dat een e-mail als spam wordt aangemerkt. "We raden onze klanten ten zeerste aan om deze methodes te gebruiken om de kans te vergroten dat e-mail door externe ontvangers wordt geaccepteerd."

Microsoft voegt toe dat het niets kan doen als een derde partij verzonden e-mails weigert. In dat geval is het aan systeembeheerders van de betreffende organisatie om aanpassingen door te voeren om de afzenderreputatie te verbeteren. Daarbij stelt het techbedrijf ook dat het versturen van bulkmail via Microsoft 365 'geen ondersteund gebruik' van de dienst is. Voor dergelijke mailings wordt aangeraden om de e-mails via de eigen on-premise mailservers of een bulkmailprovider te versturen.

Reacties (12)
09-10-2023, 15:26 door Anoniem
Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.
09-10-2023, 15:53 door Anoniem
Door Anoniem: Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.

Nou goed bericht toch? Microsoft laat klanten weten dat ze hun mail beveiliging op orde moeten brengen als ze nog geen SPF, DKIM of DMARC gebruiken. Dan wordt het tijd dat ze dat toch echt eens instellen. Het kan namelijk (behalve DANE omdat MS nog steeds geen DNSSEC kan...) ingesteld worden bij MS, de klant moet het alleen wel even doen.
09-10-2023, 17:42 door Anoniem
Door Anoniem: Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.
Klopt. Maar dat moet de eigenaar van het maildomain wel zelf doen.
Microsoft kan hier weinig mee, afgezien dit melden aan de beheerders, zodat die dit goed in de DNS kan zetten.
09-10-2023, 17:59 door Anoniem
Door Anoniem: Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.
Niet alle zaken zijn door Microsoft in te stellen. Ook kan mail keten kapot gaan als Microsoft dit ineens Instelt. Het feit dat je hier zo eenvoudig overdoet laat wel zien dat er wat kennis ontbreekt.
09-10-2023, 18:34 door Anoniem
Door Anoniem: Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.
Hoe moet iets standaard zijn als die standaard van beide partijen moet komen?
Microsoft kan namelijk niet in mijn DNS waar e.e.a. zoals SPF, DKIM, DMARC ook geregeld moet worden.
09-10-2023, 18:54 door Anoniem
Het zou aardig zijn ala microsoft ook de zaak eena op orde brengt... Hotmail & live zijn een zooitje.
10-10-2023, 07:58 door Anoniem
Kan iemnd mij uitleggen hoe ik een encrypted 7z/zip bestand (met een .txt erin) kan afleveren op een gmail email adres?
Of -überhaupt- een manier hoe ik een txt bestand kan afleveren zonder dat derde -waaronder google- de inhoud van het bestand kan achterhalen(/scannen op inhoud en geen gebruik te maken van filetransfersites?
10-10-2023, 10:28 door Anoniem
google gebruikt zelf niet eens spf (~all is een onzin instelling) .
10-10-2023, 10:30 door Anoniem
En het zijn helemaal geen bulk verzenders, ik verzend hier amper wat, en mijn klanten werden hiervan al de dupe vorig jaar.
10-10-2023, 11:20 door Anoniem
Door Anoniem:
Door Anoniem: Een beetje een omgekeerde wereld om met de vinger te wijzen naar partijen die mail wijzigen, omdat security measures niet ingesteld zijn. Deze zaken zouden eigenlijk gewoon de standaard moeten zijn.
Niet alle zaken zijn door Microsoft in te stellen. Ook kan mail keten kapot gaan als Microsoft dit ineens Instelt. Het feit dat je hier zo eenvoudig overdoet laat wel zien dat er wat kennis ontbreekt.
Waarschijnlijk is er wat meer aan de hand als MS zich druk maakt over de ander
10-10-2023, 11:24 door Anoniem
Door Anoniem: google gebruikt zelf niet eens spf (~all is een onzin instelling) .
Praat geen onzin aub. Zie https://support.google.com/a/answer/10684623?hl=nl
10-10-2023, 11:42 door Anoniem
DMARC maakt toch wel het een en ander stuk in de praktijk vwb forwarding. Het is beter op SPF of DKIM te testen van originele verstuurder; als die matched, dan is mail legitiem van de bron ongeacht de route die gevolgd is dmv forwards. Zo is de RFC [zie hieronder].

De DMARC alignment tests [bij O365] zijn echter een probleem:

Als je DKIM en SPF voor je domein opgezet hebt, maar geen DMARC, dan kun je mail nog steeds forwarden van everywhere via jouw domein en die mail wordt gewoon accept door O365. Test het maar! Stel je echter ook DMARC met bijv p=none in van je domein dat forward, dan worden de alignment tests bij O365 actief en worden je forwards niet meer doorgelaten.

Er wordt dus dan hard naar de DMARC van de envelope domein gekeken ook al is alles kosjer en had er beter naar DMARC van bron domein gekeken moeten worden. Volgens mijn interpretatie zou het ook zo moeten werken, maar toch gebeurt dat niet bij O365 [zie hieronder]. Gebeurde dat wel, dan werken legitieme forwards gewoon en met DKIM erbij wordt dan alles betrouwbaar.

Kortom DMARC is wat mij betreft niet goed doordacht en ook nog eens half baked bij O365 implementeert.

Er zijn namelijk heel veel legitieme redenen om forwards door te laten, zeker in het tijdperk waarbij mensen vaker van baan verwisselen en dus ook van organisatie etc. en sommige organisaties doe niet mee met de MS O365 cloud, maar zitten bij Google ofzo.


https://datatracker.ietf.org/doc/html/rfc7489:

" DMARC authenticates use of the RFC5322.From domain by requiring that
it match (be aligned with) an Authenticated Identifier. "

en dat is dus in de mail en niet de envelope die door een forward mechanisme een ander domein kan bevatten.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.