Exchange Online gaat e-mails van permanent kwetsbare Exchange-servers blokkeren
Exchange Online gaat e-mails van permanent kwetsbare Exchange-servers blokkeren, zo heeft Microsoft aangekondigd. Dit moet beheerders aansporen om naar een wel ondersteunde Exchange-versie te migreren. In eerste instantie wordt er begonnen met e-mails die vanaf mailservers met Exchange Server 2007 worden verstuurd, maar later gaat dit ook gelden voor Exchange 2010 en Exchange 2013. Microsoft wil naar eigen zeggen op deze manier het handhavingssysteem testen en aanpassen.
Zodra een permanent kwetsbare Exchange-server verbinding maakt met Exchange Online voor het afleveren van e-mails zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Beheerders krijgen dan dertig dagen de tijd om actie te ondernemen. Na deze periode zal Exchange Online beginnen met het "throttelen" van verbindingen afkomstig van de server en een SMTP 450 foutmelding geven. In eerste instantie zal het throttelen vijf minuten per uur zijn, maar dit zal met de tijd verder toenemen.
Als deze maatregel niet helpt zal Exchange Online beginnen met het blokkeren van verbindingen, en daarmee e-mails, afkomstig van de kwetsbare Exchange-server. Ook de periode dat Exchange Online verbindingen blokkeert vindt geleidelijk plaats, totdat het helemaal niet meer mogelijk is om vanaf de kwetsbare Exchange-server e-mails naar Exchange Online te sturen. Microsoft stelt dat het de maatregel niet invoert om klanten naar de cloud te krijgen, maar die te waarschuwen voor de risico's van het draaien van een niet meer ondersteunde Exchange-server.
Reacties (15)
De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Misschien dan adviseren om te stoppen met Exchange Online of iedereen dwingen niet meer met Microsoft producten te werken?
Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Door Anoniem om 16:34: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In het artikel staat dit stukje: zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Met andere woorden er zal nog wat andere communicatie plaats vinden tussen de Exchange server & Exchange Online dan alleen SMTP verkeer, want hoe duwen ze anders die melding daar naartoe? En die andere communicatie kan dan zaken zoals versienr. / patchniveau of dergelijke zaken bevatten.Door Anoniem om 16:34: Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in? Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Vermoedelijk heeft Microsoft de inschatting gemaakt dat ze een hoop meer gezeur gaan krijgen met zo'n ingebakken einddatum. Zie ook de opmerking van:Door Anoniem om 18:57: Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Door Anoniem:
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Als je je omgeving niet goed hebt ingericht dan maakt het niet uit met welke Exchange versie je werkt, de problemen komen dan vanzelf. Spam en phising staat helemaal los van welke Exchange server je gebruikt.Door Anoniem om 16:34: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In het artikel staat dit stukje: zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Met andere woorden er zal nog wat andere communicatie plaats vinden tussen de Exchange server & Exchange Online dan alleen SMTP verkeer, want hoe duwen ze anders die melding daar naartoe? En die andere communicatie kan dan zaken zoals versienr. / patchniveau of dergelijke zaken bevatten.Door Anoniem om 16:34: Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in? Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Vermoedelijk heeft Microsoft de inschatting gemaakt dat ze een hoop meer gezeur gaan krijgen met zo'n ingebakken einddatum. Zie ook de opmerking van:Door Anoniem om 18:57: Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Microsoft heeft maar 1 belang en dat is geld.
Door Anoniem: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Hoe ze dat doen is heel simpel. Exchange is namelijk gesloten software met een achterdeur. Zo kan Microsoft altijd bij jouw checken.In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Door Anoniem:
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Door Anoniem om 16:34: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In het artikel staat dit stukje: zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Met andere woorden er zal nog wat andere communicatie plaats vinden tussen de Exchange server & Exchange Online dan alleen SMTP verkeer, want hoe duwen ze anders die melding daar naartoe? En die andere communicatie kan dan zaken zoals versienr. / patchniveau of dergelijke zaken bevatten.Door Anoniem om 16:34: Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in? Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Vermoedelijk heeft Microsoft de inschatting gemaakt dat ze een hoop meer gezeur gaan krijgen met zo'n ingebakken einddatum. Zie ook de opmerking van:Door Anoniem om 18:57: Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Met andere woorden er zal nog wat andere communicatie plaats vinden tussen de Exchange server & Exchange Online dan alleen SMTP verkeer, want hoe duwen ze anders die melding daar naartoe? En die andere communicatie kan dan zaken zoals versienr. / patchniveau of dergelijke zaken bevatten.
Heb je ooit de header van een e-mail geanalyseerd ? Daarin staat alles wat nodig is om te bepalen waar een e-mail van afkomstig is en van welk onderliggend systeem tot de werkplek aan toe
Door Anoniem:
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
Microsoft mailservers zijn onbetrouwbaar. Je moet ook eerst een vage reputatie bij ze opbouwen. Het criterium vertellen ze je niet.Door Anoniem om 16:34: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In het artikel staat dit stukje: zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Met andere woorden er zal nog wat andere communicatie plaats vinden tussen de Exchange server & Exchange Online dan alleen SMTP verkeer, want hoe duwen ze anders die melding daar naartoe? En die andere communicatie kan dan zaken zoals versienr. / patchniveau of dergelijke zaken bevatten.Door Anoniem om 16:34: Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in? Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Vermoedelijk heeft Microsoft de inschatting gemaakt dat ze een hoop meer gezeur gaan krijgen met zo'n ingebakken einddatum. Zie ook de opmerking van:Door Anoniem om 18:57: Kan toch niet zo zijn dat Microsoft de wet gaat voorschrijven?
Dit heeft niks met een wet te maken. De ontvangende kant (in dit geval Microsoft) besluit wat ze wel of niet aan binnenkomend mailverkeer willen binnenlaten. Wanneer een kwetsbare server bereikbaar is op 't internet, dan is 't gewoon een kwestie van tijd voordat er misbruik van wordt gemaakt. En dan is 't weer een extra bron van spam/phishing mails of andere rommel.
25-03-2023, 18:39 door
Tintin and Milou
Door Anoniem:
En natuurlijk heb je hier ook enige goede betrouwbare bron van je claim?Door Anoniem: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Hoe ze dat doen is heel simpel. Exchange is namelijk gesloten software met een achterdeur. Zo kan Microsoft altijd bij jouw checken.In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
25-03-2023, 18:44 door
Tintin and Milou
Door Anoniem:
Microsoft mailservers zijn onbetrouwbaar. Je moet ook eerst een vage reputatie bij ze opbouwen. Het criterium vertellen ze je niet.
Om je beveiligingen openbaar te maken, is natuurlijk ook niet zo slim.Microsoft mailservers zijn onbetrouwbaar. Je moet ook eerst een vage reputatie bij ze opbouwen. Het criterium vertellen ze je niet.
Maar google heeft zelfde als bescherming.
Maar zijn zijn gewoon best practices bekend, maar voor goede SMTP afhandeling, hangt meer vanaf dan a een betrouwbaar IP.
https://docs.sendgrid.com/ui/sending-email/warming-up-an-ip-address
https://sendgrid.com/resource/email-guide-ip-warm-up/
https://www.linkedin.com/pulse/how-warm-up-smtp-server-ip-improve-reputation-hasan-aboul-hassan
Door Tintin and Milou:
Maar google heeft zelfde als bescherming.
Maar zijn zijn gewoon best practices bekend, maar voor goede SMTP afhandeling, hangt meer vanaf dan a een betrouwbaar IP.
https://docs.sendgrid.com/ui/sending-email/warming-up-an-ip-address
https://sendgrid.com/resource/email-guide-ip-warm-up/
https://www.linkedin.com/pulse/how-warm-up-smtp-server-ip-improve-reputation-hasan-aboul-hassan
Nee hoor als je Googleapps gebruikt met jouw domain kan je o.a. een ip nummer opgeven van je mailserver die vervolgens wordt gewhitelist.Door Anoniem:
Microsoft mailservers zijn onbetrouwbaar. Je moet ook eerst een vage reputatie bij ze opbouwen. Het criterium vertellen ze je niet.
Om je beveiligingen openbaar te maken, is natuurlijk ook niet zo slim.Microsoft mailservers zijn onbetrouwbaar. Je moet ook eerst een vage reputatie bij ze opbouwen. Het criterium vertellen ze je niet.
Maar google heeft zelfde als bescherming.
Maar zijn zijn gewoon best practices bekend, maar voor goede SMTP afhandeling, hangt meer vanaf dan a een betrouwbaar IP.
https://docs.sendgrid.com/ui/sending-email/warming-up-an-ip-address
https://sendgrid.com/resource/email-guide-ip-warm-up/
https://www.linkedin.com/pulse/how-warm-up-smtp-server-ip-improve-reputation-hasan-aboul-hassan
26-03-2023, 17:03 door
Hatsikidee
Door Anoniem: De vraag is natuurlijk: hoe doen ze dat? Een SMTP server die mail naar een andere server verstuurt identificeert zich in het algemeeen niet met een versienummer. Een ontvangende server doet dat soms wel, maar daar hebben ze het hier niet over.
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
In bepaalde gevallen kun je ook gokken wat er aan de andere kant voor software draait door te goochelen met bepaalde antwoorden, timing, etc. Maar dat lijkt me niet betrouwbaar genoeg voor deze toepassing.
Als ze vinden dat software een einddatum moet hebben, waarom bouwen ze die dan niet gewoon in?
Dat als de datum voorbij is, het ding gewoon niet meer werkt of bepaalde functies (zoals verzenden/ontvangen van mail) stoppen met werken?
Goed, alle aluhoedjes hebben hun zegje weer kunnen doen in dit topic, nu antwoord op je vraag. Zie deze post:
https://practical365.com/microsoft-block-old-exchange-servers/
Microsoft will introduce a change to the Exchange Online transport service to check the SMTP headers of inbound messages arriving in through inbound connectors configured with the ConnectorType set to be OnPremises. This limits the set of servers Microsoft will monitor and potentially block to those in hybrid organizations that handle email traffic to Exchange Online.
If a message comes from Exchange Server, the Exchange Online transport service checks the version number in the header to know what version the transmitting Exchange server runs.
Ik kan deze actie eigenlijk wel waarderen. Diverse mensen, zowel hier als op de gelinkte learn.microsoft blogpost gaan over hun giechel, want: ga je dan ook oude postfixes blokkeren??
Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Door Anoniem: Ik kan deze actie eigenlijk wel waarderen. Diverse mensen, zowel hier als op de gelinkte learn.microsoft blogpost gaan over hun giechel, want: ga je dan ook oude postfixes blokkeren??
Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Hilarisch MS en kwaliteits-eisen. Het grote probleem is dat MS bepaalt en niet de klant! Nu wordt haar ondeugdelijke software ook nog eens verhaalt op de klant. Pas dan de EULA aan!Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Door Anoniem: Ik kan deze actie eigenlijk wel waarderen. Diverse mensen, zowel hier als op de gelinkte learn.microsoft blogpost gaan over hun giechel, want: ga je dan ook oude postfixes blokkeren??
Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Mensen; lees eerst even heel bewust voor je in een spasme springt: Het gaat over Exchange Hybrid oplossingen, waarbij de klant met de ouwe exchange server dus ook meteen de zelfde is die de dienst Exchange Online afneemt. Dus nadrukkelijk niet om reguliere internet-MX resolve of dedicated mailroutes tussen verschillende partijen.
Juist omdat het gaat over een Hybride koppeling is het daarmee irrelevant om over Exim, Postfix of zelfs een Cisco ESA in de hele discussie te praten, want je kunt helemaal niet hybride koppelen met een ander product dan Exchange. SMTP en HTTPS communicatie stromen die voor een hybride koppeling nodig zijn dienen rechtstreeks (hooguit via een TCP-25+HTTPS loadbalancer op bijvoorbeeld een Netscaler of F5) uit te komen op de Exchange servers. SMTP StartTLS mag daarbij zelfs niet geoffload worden voor inspectie, anders heb je geen supported oplossing. En waarom zou Microsoft aan de door hun beloofde beschikbaarheid van dienstverlening niet randvoorwaarden mogen koppelen door kwaliteits eisen te stellen aan de on-premise component van de koppeling? Ik snap het best als je op gegeven moment zegt dat je niet langer bereid bent om ouwe grafzooi waar je al jaren geen product support meer voor afgeeft te ondersteunen binnen je overige producten...
Je heb trouwens ook geen probleem als je Office365 gebruikt en je hebt een hybride koppeling; dan krijg je daar ook gewoon een licentie voor een Exchange Management node bij, dus als je on-premise een bak hebt staan t.b.v. Exchange Attribute management (iets wat overigens niet meer noodzakelijk is!)
Als je nog een Exchange hebt staan waar daadwerkelijk maiboxen op hebt staan én dat is nog Exchange 2007, of Exchange 2010 (of for that matter Exchange 2013), dan moet je je gewoon gaan schamen! Dan heb je een technical debt waar de honden geen brood van lusten en dan vermoed ik dat er nog heel veel meer, hele ernstige dingen in je omgeving zijn. (mind you, Exchange 2007 draait niet op Windows 2012, en Exchange 2010 draait niet op Windows 2016 en vereist bovendien een windows 2012 AD controller. en beidde producten zijn al lang end of support). Voel die virtuele lineaal op je vingers dan maar!
Een Hybride koppeling bestaat trouwens uit meer dan alleen een SMTP connector: Via de OWA/ECP calls die vanuit de hybride koppeling gedaan worden, kan Exchange Online vast prima controleren op versie, het hoeft dus niet alleen SMTP header informatie te zijn waarop gecontroleerd wordt. Veel te veel focus op dat SMTP gedeelde, wat waarschijnlijk ook de clue is:
...
Want dat alles valt in het niets bij het gegeven dat het artikel op diverse plaatsen ruimte voor interpretatie geeft en andere blogs zelf ook de suggestie wekken dat dit mogelijk ook voor andere SMTP stromen gaat gelden (niet-hybride koppelingen).
As If!
Gegeven de gebruikelijke triggers voor mensen buiten het Microsoft ecosysteemm, die nu collectief beginnen te gillen, voelt het voor mij vooral als clickbait om een stukje bewustzijn over versie maintenance viral te laten gaan.
Kijk dan tot slot nog eens naar de datum waar op het artikel bij microsoft is uitgebracht (23-3) en vraag je eens af wat voor datum het een goeie week later is...
Al met al een prachtige prank, dicht genoeg bij het waarschijnlijke om niet meteen ongeloofwaardig te zijn en met een hele serieuze ondertoon: Daarom in zijn (naar mijn verwachting daadwerkelijke) bedoeling ijzer sterk! Fix your g'damn Lifecyle Management! , er liggen in de wereld nog veeeeeeeeeeeeel te veel Exchange servers onbeschermd aan het internet te bungelen die niet supported zijn!
Mensen; lees eerst even heel bewust voor je in een spasme springt:
Ik meen toch dat hierboven in het stuk niets genoemd wordt over enkel de hybride oplossingen, dus de berichtgeving geeft genoeg aanleiding om in de stress te schieten lijkt me.Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
