Igen, arra gondoltam. Sajnos vannak az M365-ben olyan elvárások, amiket a tenant meg kell, hogy ugorjon. Ráadásul ezek köre szépen bővül, ahogy sikerül egyre többeket behúzni a szolgáltatásban (a nem-M365 levelezés rendszeres szabotálásával pl.). Ilyen elvárás a fix IP bizonyos dolgokhoz.
Mi úgy oldjuk ezt meg, hogy az adott ügyfélnek csinálunk egy al-tartományt, a saját hosting szolgáltatásunkban teszünk rá levelezést és azon keresztül küldenek az olyan végpontok, amik az M365 jelenlegi feltételeinek nem felelnek meg. Pl. nincs fix IP, pl. tartományon kívülre is akar küldeni de nem tud OAuth2-t, pl. nem támogat TLS1.2-t, stb.
Bevallom, engem bosszant, hogy egyre több dologról kell lemondani vagy pénzköltéssel "feljavítani", hogy működjön az egyébként nem kifejezetten olcsó M365-tel. Abba pedig nagyon sok KKV csak a levelezés miatt megy be (a többi szolgáltatásról sokszor nem is tudnak, sokan később sem veszik azokat igénybe), mert rendszeresen belefutnak abba, hogy az aktuális e-mail hosting-tól az M365-ben lévő címzettjük nem kapja meg a levelet (az MS által elkövetett nem véletlen, rendszeres szabotázsok miatt). Aztán mikor trükkökkel beszippantják az ügyfelet, akkor lehet ráerőltetni újabbnál újabb hülyeségeket a biztonságra hivatkozva.
Mondjuk engem érdekelne, hogy miért nem biztonságos egy random 32 karakteres lejszó egy titkosított TLS csatornán átküldve... De ugyan ez a user a böngészőjébe elmentett sütivel mindenféle hitelesítés nélkül szerencsétlenkedhet az M365-ben akár hetekig újrahitelesítés nélkül. Ahogyan az előző (költői) kérdésemnél is, hogy ugyan ez a hitelesítési módszer miért lesz mégis megfelelő, ha egy másik, külön fizetős szolgáltatásban veszi igénybe ugyan ez az ügyfél, ugyan azon a rendszeren...