O365 SMTP AUTH megy/nem megy

Akkor az egyértelműen 2FA-s dolog, nem TLS-es hiány.

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...

Persze, hogy nem adatvédelem az ok, ők is tudják, hogy UPSek meg egy csomó kütyü pl nyomtató nem tud oAutholni, de a céges IT sarokkövei, csak már ebből is lehet pénzt csinálni.
 

Rájöttek, hogy hogyan lehet pénzt kérni a basic auth SMTPért: ott van a “high volume email” ami ingyenes a preview alatt, ami meglepő módon pont akkor ér véget mikor a basic auth ki lesz kapcsolva, de majd jó drágán abban is lehet küldni.

Vagy ott van az Azure communication services amiben nem csak darabszám de megabájt alapján is ki fogod fizetni a basic auth SMTPs emaileket. 
 

Mikor épp nem megy az smtp.office365.com-on a basic authos smtp akkor valamiért az exchange online powershell is le van pusztulva és az istennek se akar csatlakozni, amint meggyógyul az smtp akkor az exchange PS is csatlakozik, lehet véletlen de gyanús.

Off: Már bocs, de ha egy biztonságtechnikai cég nem tud megugorni egy IT biztonsági intézkedést, akkor _lehet_ hogy helyes, hogy sérülés éri az üzletét. Most ez attól teljesen független, hogy az MS hozzáállásával amúgy én sem értek egyet. Ma már szinte nincs is olyan, hogy az IT-nek nincs kihatása egy területre, de a biztonságtechnika különösen ilyen tud lenni. 

On: Ami a konkrét fenti hibát illeti, én kerülnék egyet, és javasolnám a cégeknek az Amazon SES-t. Fillérekbe kerül meglepően nagy mennyiségű levélforgalom is, és a SES korrektül kezel minden DKIM-mel kapcsolatos dolgot. Ha a domaint átmigrálják Route 53-ba (szintén fillérek), akkor még a DNS beállításokkal sem kell szopni, mert a DKIM-et a SES automatikusan bemigrálja a Route 53-as domainbe, az egyetlen, amit karban kell majd tartani az az SPF rekord (mert ha nem AWS-es levelezők, azt nyilván nem tudja megugorni az AWS). Tiszta, egyszerű, meglepően sok mindent támogat.