Thunderbird krijgt in juli ondersteuning voor Microsoft Exchange-protocol

Mozilla Thunderbird krijgt in juli native ondersteuning voor het e-mailprotocol van Microsoft Exchange. Later moet er ook ondersteuning voor de agenda en het adresboek bijkomen. Het is voor het eerst dat Mozilla een nieuw protocol aan zijn e-mailclient toevoegt.

Het team achter de opensourceclient voor e-mails schrijft dat het begonnen is met de integratie van Rust-componenten in de codebasis van Thunderbird. Momenteel bestaat de mailclient grotendeels uit oude C++-code, waardoor het volgens de ontwikkelaars niet mogelijk was om de Microsoft Exchange Web Services-api te integreren. Door de programmeertaal Rust te gebruiken moet dat wel kunnen.

Het is de bedoeling dat Exchange-ondersteuning in de volgende stabiele release van Thunderbird wordt toegevoegd. Die wordt naar verwachting in juli uitgebracht. Het team schrijft dat het een behoorlijke onderneming is om een nieuw protocol toe te voegen, waardoor er in eerste instantie alleen ondersteuning voor Exchange-e-mails wordt toegevoegd. Het is de bedoeling dat de agenda en het adresboek op een latere datum ook worden ondersteund.

Via een add-on van een derde partij was het wel al mogelijk om Exchange-accounts via Thunderbird te gebruiken, maar ondersteuning was nog niet native in de client ingebouwd. Overigens stopt Microsoft per 1 oktober 2026 met de Exchange Web Services-api voor Exchange Online en Office 365. Dat betekent dat de Exchange-ondersteuning in Thunderbird over twee jaar niet meer werkt voor Exchange-accounts die door Microsoft gehost worden, maar alleen nog voor Exchange-servers die organisaties zelf beheren. Het is niet duidelijk of het Thunderbird-team voor die tijd overstapt naar de Graph-api, waarmee dat wel moet kunnen.

Reacties (109)

[P-e-t-j-e]

Het kan niet native omdat het oude c++ code is maar via een plugin kan het het wel. Dan kunnen ze toch zelf een 'interne plugin' bouwen die de ondersteuning 'na tive' aanbiedt?

[R4gnax]

Dat het niet native zou kunnen is een foute aanname voortvloeiend uit de kromme formulering in het artikel hier op Tweakers. In het originele artikel staan zaken heel anders geformuleerd.

Men is gewoon begonnen met het omzetten van Thunderbird naar Rust, net zoals dat met Firefox gaande is, omwille van diverse criteria met stipt op #1 het argument memory safety. Niet onlogisch, gezien de aard van het product en hoe het data van derden, binnen lopend via het internet, af moet handelen.

Gaandeweg wilde men ook Microsoft Exchange gaan integreren, wat XML web services in zou houden. En hoewel dat wel kan door interop met C++ code te gaan doen, is dat heel lelijk en onveilig. (Als in: je verliest het memory safety criterium.)
Daarom is men gaan kijken hoe dit werkbaar te krijgen middels Rust, en dat ontwerp is nu dus grotendeels rond - waardoor we een projectie krijgen dat Exchange ondersteuning ergens in juli opgeleverd zou moeten kunnen worden.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:06]

[downtime]

Thx. Dat maakt het al een stuk duidelijker. Ik snapte ook al niet waarom C++ een bezwaar zou zijn.

[Pep7777]

Ik ook niet, als het in rust kan kan het ook in C++.
Maar ik snap helemaal dat als je al naar Rust aan het overstappen bent dat je de nieuwe stukken ook in Rust gaat doen.

[84hannes]

Doel je op deze tekst?

That means years of ad hoc changes without a larger architectural vision and a lot of decaying C++ code that was not using modern standards.

Furthermore, in the entire 20 year lifetime of the Thunderbird project, no one has added support for a new mail protocol before. As such, no one has updated the architecture as mail protocols change and adapt to modern usage patterns, and a great deal of institutional knowledge has been lost.

Ik vind dat @Kevinkrikhaar inderdaad wat vrijheid heeft genomen om dat te vertalen als

waardoor het volgens de ontwikkelaars niet mogelijk was om de Microsoft Exchange Web Services-api te integreren

Het is natuurlijk wel mogelijk. Het zou in COBOL waarschijnlijk nog mogelijk zijn, maar het zou geen pretje zijn om te doen.

[R4gnax]

Dat stukje omschrijft inderdaad de lead-up naar dit alles. Men wil nieuwe stukken van Thunderbird in Rust gaan pennen; simpelweg omdat het veiliger is en minder ruimte biedt aan gevaarlijke programmeerfouten - in de zin van bijv. buffer overflows die remote code execution toestaan.

Dat kun je met legio talen doen en bereiken, maar men wilde Rust gebruiken vanwege de gedeelde onderdelen tussen Thunderbird en Firefox, waar Firefox ook al op Rust leunt.

Hoofdstuk één in dit geheel was: hoe lijmen we dit aan elkaar vast op een zinnige manier; hoe krijgen we het nieuwe en het oude samen werkend; en hoe krijgen we het nieuwe überhaupt goed werkend binnen een bestaande C++ codebase waar weinig man nog echt wijs in is? En de gang van zaken daarvoor en daar naar toe leggen ze in de verdere tekst v/h originele artikel uit.

Het is dus alles behalve dat het onmogelijk zou zijn om het native te doen.
Sterker nog- dat zou wellicht zelfs makkelijker zijn. Maar aangezien het allemaal om nogal precaire code gaat waarbinnen het nieuwe brouwsel moet gaan draaien, waarbij er nog weinig kennis van zaken levend aanwezig is binnen de bestaande ontwikkelgroep, zou dat wel met een groot risico gepaard gaan als er bijv. geheugenfoutjes binnen sluipen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:06]

[Mitchelllll]

Zou iemand in het kort en liefst non tech jargon kunnen uitleggen waarom je een programma opnieuw in een andere programmeertaal zou willen schrijven? Waarom is dat?

[R4gnax]

In dit geval omdat Rust als programmeertaal op bepaalde fronten dusdanig anders in elkaar steekt t.o.v. C++ als programmeertaal, dat het eindproduct wat je er in optuigt, inherent veiliger in elkaar zal steken m.b.t. het voorkomen van bepaalde soorten programmeerfouten die anders tot exploiteerbare gaten in de software zouden kunnen leiden.

Dit heeft alles te maken met hoe Rust vis-a-vis C++ met zaken als geheugenallocatie omgaat. In C++ is dat veel handwerk en is het mogelijk om daar subtiele fouten in te maken waardoor je mogelijk in scenario's terecht kunt komen waar speciaal geprepareerde data verkeerd geinterpreteerd wordt en door dit soort allocatiefouten ergens terecht komt waar het niet hoort te zijn. Als een hacker dat goed uitmikt, kan daarmee het lopende programma dusdanig beinvloed worden dat er informatie waar geen toegang toe gegeven zou moeten worden, gelekt wordt; of in het ergste geval dat er extra instructies geinjecteerd kunnen worden die het programma uit gaat voeren. Dat is wat we, als het via data uit een ander systeem afkomstig gebeurt, een remote code execution gat noemen.

Iets wat je in een e-mail client noch web-browser wilt hebben, natuurlijk. Vandaar dan ook dat Mozilla delen van Firefox al langer bezig was om te pennen naar Rust. Het potentiële aanvalsoppervlak kleiner maken door de kans op dat soort fouten weg te nemen.

Dit beleid zetten ze nu eigenlijk met Thunderbird voort. Alleen is het hier niet bestaande code die omgebouwd wordt, maar een nieuw stuk code wat initieel in Rust gebouwd wordt. En omdat het het eerste stuk Rust is wat in Thunderbird's bestaande C++ code ingevouwen moet worden, is er wat extra hand- en spanwerk nodig geweest voor de opzet daarvan.

Die heuvel nemen, en dat hand- en spanwerk gedaan krijgen, is waar het Mozilla-artikel eigenlijk over gaat.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:06]

[Mitchelllll]

Thanks. Ik snap wat je bedoelt, maar om er echt een vinger op te krijgen moet je denk ik kunnen programmeren of hacken om.

[caipirinha]

In aan vulling wat R4gnax zegt, het is ook steeds moeilijker om goede onbetaalde C programmeurs te vinden. Mensen die zich in rust aan het bekwamen zijn zullen graag deelnemen aan de ontwikkeling van Thunderbird. Toen ik nog (heel lang geleden) programmeerde was dat in C en assembler, de meeste jonge collega's die bijvoorbeeld in python programmeren kijken me nu wazig aan als ik dat vertel

[Mitchelllll]

Python is veelgebruikt begreep ik. Is dat ook veiliger dan c++?

[R4gnax]

Ja. Python is een veel veiligere programmeertaal dan C++ omdat Python zich veel minder met lagere zaken zoals direct geheugenmanagement bezig houdt. Tegelijkertjid is daar ook een trade-off in: het is ook een veel langzamere taal. Dezelfde code in Python geschreven kan hele ordes trager zijn dan het equivalent in C of C++, juist vanwege alle extra abstractielagen.

Die trade-off zie je eigenlijk bijna altijd wel terug.

Rust is een beetje een uniek geval omdat het de snelheid van basaal C, wat echt heel erg 'close to the metal' is, benadert en tegelijkertijd wel bewust zo gemaakt is dat het op een aantal cruciale fronten veel, en veel veiliger is.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:06]

[Mitchelllll]

Bedankt voor de reactie!

[Sluuut]

het e-mailprotocol Microsoft Exchange

Welk protocol word hiermee bedoeld, Mapi over https, EWS?

[wildhagen]

EWS, staat toch letterlijk in de aankondiging van Thunderbird?

This article will go into technical detail on how we are implementing support for the Microsoft Exchange Web Services mail protocol, and some idea of where we’re going next with the knowledge gained from this adventure.

Exchange Web Services (EWS), an alternative to the MAPI protocol, is a documented SOAP-based protocol introduced with Exchange Server 2007.

Zie Wikipedia: Microsoft Exchange Server

[Robbierut4]

Goed nieuws. Die add-on heb ik gebruikt maar is een betaalde add-on. Dan doneer ik liever aan de ontwikkelaars van Thunderbird zelf.

Ook een mooi teken dat ze langzaam maar zeker doorgaan met het ontwikkelen van Thunderbird, want het heeft wel een tijdje op zijn gat gelegen. Nu nieuw design, grote nieuwe features, top.

[Qws]

Er is heel veel afkeer tegen de nieuwe Outlook programma voor Windows. het is niet zo vreemd dat Thunderbird groter wordt, Microsoft heeft haar mail programma compleet geruïneerd met "New Outlook", wat gewoon een opgevoerde website (Outlook.com) vermomd als een desktop applicatie is.

[Anoniem: 407645]

New Outlook doet wel meer dan dat.

https://proton.me/blog/ou...w-data-collection-service
https://www.xda-developer...ns-new-microsoft-outlook/

Mede hierdoor ben ik overgestapt naar Thunderbird, en op zich, nadat ik wat moest zoeken om bepaalde zaken naar mijn wens ingesteld te krijgen is het nu prima te doen. Voor mij is dit artikel goed nieuws maar denk dat de timing niet geheel willekeurig was.

Adresboek en agenda host ik zelf dmv Radicale, en werkt ook prima.

[Reactie gewijzigd door Anoniem: 407645 op 22 juli 2024 16:06]

[Terrestrial]

Gewoon de zakelijke outlook versie gebruiken uit het office pakket, dan heb je dat hele gezeik niet en die werkt out of the box al samen met outlook.com/hotmail.com

Ik vind het zo wazig dat ze die consumenten (de kinder versie) dan ook outlook gaan noemen. Had dat dan gewoon outlook expres laten heten of windows mail.

[Coffee]

Ik ben zelf sinds de invite-only Gmail bèta gebruiker van Gmail. Ben niet anders gewend dan een webversie gebruiken. Op werk gebruiken we Outlook. Zelfs met de keuze tussen oude Outlook desktop, de nieuwe Outlook, en Outlook Web, ligt bij mij altijd de voorkeur voor de web versie via de browser. Oprechte vraag, wat is er minder goed aan de nieuwe web-versie gebaseerde Outlook dan de vorige variant? Zelf vind ik m.n. de nieuwe zoekfunctie prettiger. Verder kan ik me niet zo goed voorstellen wat je mist, behalve wellicht exporteren van .PST’s?

[Qws]

Ik gebruik niet de desktop Outlook, maar de UWP Mail app van de Microsoft Store, en ook die wordt vervangen met de New Outlook.

Wat ik heel jammer vind, want de UWP Mail app start binnen 1 seconde op, gebruikt enkel 50mb ram en draait niet eens in de achtergrond. Apple's mail app start ook binnen 1 seconde op, ik vind het gewoon jammer dat de New Outlook, zo onnodig zwaar word en draait continue in de achtergrond.

[xFeverr]

Exact. Dit was de beste mailclient die Microsoft ooit heeft gemaakt. Belachelijk snel, werkte altijd, verder weinig poespas met agenda’s, RSS readers en office-integraties.

Maar helaas was het blijkbaar te mooi om waar te zijn en moest het dood. Heel erg zonde.

[bh808303]

De nieuwe Outlook heeft niets te maken met de oude Outlook, behalve de naam en dat ze allebei mail clients zijn. De nieuwe Outlook is gewoon de opvolger van Live mail. Alleen MS zou MS niet zijn als ze weer eens verwarring met de naamgeving zouden creëren.

Zoeken in een webclient van Outlook maakt gebruik van de server index en Outlook (Office suite) maakt gebruik van Windows search die vaak inconsistent is.

[jmvdkolk]

Volgens mij is er een verschil tussen zakelijk en privé gebruik, en dan ook nog tussen individuen. Voor mij mist de nieuwe Outlook een aantal functies (ten opzichte van de "echte" Outlook:
- Zoekfolders
- Offline mail
- Snelheid. Dit is mede afhankelijk van de internet snelheid op locatie.
- Macro's
- Minder overzichtelijke interface van nieuwe Outlook. Ik kan b.v. Resend Message niet vinden. In het algemeen zitten er minder opties in de knoppenbalk van de nieuwe Outlook, ook van functies die ik zo nu en dan gebruik
- Zoeken naar hoe de nieuwe Outlook werkt lukt maar nauwelijks. Alle pagina's online gaan over de "echte" Outlook

Bij mij op het werk zijn de meningen verdeeld. Sommigen zijn binnen een half uur terug bij de "echte" Outlook. Sommigen gaan nooit meer terug.

[evharten]

Met de webversie heb je geen ondersteuning voor shared-mailboxen, deze worden niet weergegeven, hopelijk gaat dat in de toekomst nog komen, maar vooralsnog is dit niet beschikbaar, en alleen te gebruiken in de outlook desktop client.

[Vinales]

Je kunt toch rechtsbovenaan een mailbox openen waar je toegang tot hebt. Wordt dan geopend in een nieuw venster.

[Amandess]

Wat ik persoonlijk dan weer mis in de Outlook web variant is een favorieten optie. In de desktop app heb ik de inboxen van alle shared e-mailboxen als favoriet gemarkeerd staan zodat ik als ik naar Outlook kijk in één oogopslag zie dat er nieuwe e-mail is.

Als ik dat via Outlook web moet doen, dan heb ik tig tabs open staan om elke mailbox afzonderlijk te kunnen monitoren. Ik wil geen desktop notificaties open hebben staan voor nieuwe e-mail want dat is een overkill aan notificaties die afleidend worden.

[RxTweak]

In het kader van efficiëntie compleet logisch. Waarom zou je alles dubbel ontwikkelen? En in de agile werkwijze, ook logisch dat je live gaat met een versie die nog niet volledig is.

[downtime]

Zover ik weet zegt niets binnen Agile dat je "live" moet gaan met incomplete versies. Want wat heeft de klant aan incomplete software? Voor Agile is het voldoende om elke sprint af te sluiten met werkende software die intern getest kan worden. Je gaat pas live als je een product hebt wat goed genoeg is om het aan klanten uit te leveren.

[84hannes]

Je gaat pas live als je een product hebt wat goed genoeg is om het aan klanten uit te leveren.

Deel van de Agile mindset is wel dat je snel feedback wilt, dus het delen van een programma dat bruikbaar, maar nog niet compleet is, lijkt me helemaal niet zo gek.

[wiseger]

Bij twee wekelijkse sprints valt er niet echt diepgaand te testen.

Dus komen issues naar boven terwijl je live bent, die je dan in de volgende sprint weer fixed.

[The Zep Man]

Dus komen issues naar boven terwijl je live bent, die je dan in de volgende sprint weer fixed.

Dat is de theorie. In de praktijk zitten sprints volgepropt en belandt wat niet voor het (beursgenoteerde) bedrijf maar wel voor de gebruiker belangrijk is onderaan de lijst, en wordt het daarmee steeds verder opgeschoven.

[acemoo]

Aan het einde van een sprint is de theorie dat je een potentially shippable product hebt. Dat betekent niet dat je iets in 2 weken live moet zetten.

[jmvdkolk]

Als je niet diepgaand kan testen binnen een twee wekelijkse sprint, dan is er iets niet goed geregeld. Zelfs binnen een sprint van een week kan er diepgaand getest worden, mits goed aangepakt. Als je uitgaat van handmatige testen, dan valt er natuurlijk pas wat te testen nadat de code af is, en is er weinig ruimte. Maar als je netjes automatische testen op alle niveau's opzet, dan zijn de diepgaande testen af en goed- of afgekeurd niet lang nadat development klaar is.

[wiseger]

Zo werkt het niet. Ik heb het niet over eenvoudige unit testjes om te zien of de boel breekt.

Tegenwoordig is alles aan elkaar geknoopt. Dat betekent dat je end-to-end testen moet opzetten met al je interface partners.

Dat betekent dat je dataset afgestemd moet worden met de data die je ontvangt tijdens het testen. Data die je verstuurd moet afgestemd worden met de ontvanger. Die zal ook moeten testen.

Dan heb je niet alleen je functionele testen maar ook je ook nog performance en security testen.

Dan zit het ook nog met verschillende dataset zoals bijvoorbeeld einde maand, einde kwartaal en einde jaar.

Goed testen kost je gewoon weken. En dat gaat niet bij Agile. Dus wordt dat niet gedaan.

[jmvdkolk]

Ik heb het ook niet over eenvoudige unit testjes. Ik heb het over systeem testen. Als jouw product onderdeel is van een groot ecosysteem, dan zal je APIs goed moeten afspreken en moeten testen dat de API nog zo werkt als voorheen. Kan je daarmee 100% garanderen dat alles goed is? Nee. Maar ook met jouw maandenlange test kan je dat niet.

Verschillende datasets kan voor einde maand, einde kwartaal en einde jaar kan je meenemen in de geautomatiseerde testen. Functionele, performance en security testen kan je ook automatiseren. Natuurlijk moeten er vervolgens alsnog acceptance testen overheen. Maar ook die moet je zoveel mogelijk proberen te automatiseren. Iedere vorm van test die gebaseerd is op handmatige acties wordt nl. zelden 2x hetzelfde uitgevoerd.

Bij Agile wordt heel anders over testen nagedacht. Als je dat vanaf het begin meeneemt in het ontwerp van de software en testen, dan kan je daar heel ver mee komen. Als je dat niet vanaf het begin meeneemt, dan is het heel lastig om agile te werken inclusief goede testen.

Ik werk in een mainframe omgeving waar traditioneel gedacht wordt en werd zoals jij aangeeft. Mijn product heeft dit weten te doorbreken. Met groot succes lukt het ons om vele malen per jaar een release te doen inclusief nieuwe features. Dit is in de mainframe wereld ongehoord.

[RxTweak]

Want wat heeft de klant aan incomplete software?

Nieuwe software versies kunnen tal van verbeteringen bieden zoals b.v. snellere laadtijden, een nieuwe user interface of door grote onderliggende upgrades aan de techniek. Juist door vroeg live te gaan in het ontwikkelproces en de gebruiker te betrekken in de nieuwe (onvolledige) versie, kun je het eindresultaat corrigeren nog voor de definitieve laatste versie. De gebruiker kan dan ook alvast snuffelen aan de verbeteringen. Dat het eindresultaat aan het begin niet in beton is gegoten, is een belangrijk kenmerk van Agile dus zodoende mijn opmerking.

Ontopic: ik zou deze mailclient graag een kans willen geven, maar helaas blokkeert mijn werkgever diverse applicaties zoals ook deze.

[Reactie gewijzigd door RxTweak op 22 juli 2024 16:06]

[lb2001]

Niet volledige versies live gooien is best een ergernis bij mij. Tenminste, software die duidelijk niet goed is getest.

Bedrijven gebruiken liever hun klanten als proefkonijn, zonder dat ze zijn ingeschreven voor een beta-programma, wat ik dus jammer vind. Zo krijg je van die half stabiele software voorgeschoteld.

Een voorbeeld daarvan is Discord. Heeft niks met Microsoft te maken, maar op het moment dat er iets nieuws wordt bedacht is het weer iets waar niemand wat aan heeft, of er is een vage bug bijgekomen. En dat duurt meestal minstens een half jaar voordat het wordt opgelost. Dat soort zaken.

Test je product goed voordat je het de deur uit duwt. Daar hebben gebruikers veel meer aan, ook al duurt het dan net wat langer voordat een nieuwe update beschikbaar komt.

[jimshatt]

Ik ben ook niet overgestapt omdat je als je je Gmail account wil kunnen gebruiken in "New Outlook", je mail gesynchroniseerd wordt naar een Microsoft server in plaats van alleen lokaal in de applicatie. Het is überhaupt niet nodig om Gmail te synchroniseren, want IMAP, maar het is iets vlotter om een lokale kopie te hebben. Maar nu is het dus een lokale kopie van een cloud kopie van een IMAP dienst.

Privacy-wise ook niet erg handig, en wellicht een extra attack surface voor hackers.

Maar misschien dat ik nu Thunderbird voor alles kan gebruiken, maar ik denk dat mijn werkgever het alsnog niet toelaat.

[DvanRaai89]

Het is überhaupt niet nodig om Gmail te synchroniseren, want IMAP, maar het is iets vlotter om een lokale kopie te hebben

Maar neemt dat ook ruimte in bij je Microsoft account / in de OneDrive? Of heb je daar überhaupt geen account voor nodig? Microsoft is dat wel aan banden aan het leggen met Windows 10&11.

[Reactie gewijzigd door DvanRaai89 op 22 juli 2024 16:06]

[jimshatt]

Goede vraag. Geen idee.

[Buntuhein]

Dramatisch inderdaad. Maar dat is de kant waar het allemaal naartoe gaat met heel Office en ook Windows. Alles als een service, alles online, geen controle meer voor de eindgebruikers.

[Tranquility]

Precies. Ook al heb je een legale betaalde versie van Office Professional Plus 2021, de New Outlook wordt alleen advertentievrij als de Office 365 hebt, dus met abonnement. Ze willen gewoon permanent geld van je hebben. Op dit moment kan ik de gedwongen overstap van de Windows Mail app naar de New Outlook nog steeds iedere keer terugdraaien, maar er komt binnenkort een moment dat dit niet meer mogelijk is.

De "klassieke" Outlook, die in mijn Office pakket zit, gebruiken is geen optie omdat synchronisatie met Google agenda niet werkt. In de New Outlook werkt dit gek genoeg wel, maar zit je dus met ads opgescheept. Als terugdraaien niet meer mogelijk is ga ik naar Thunderbird. Hopelijk komt er nog een registry hack o.i.d. die voorkomt dat de Windows Mail app steeds automatisch vervangen wordt door die New Outlook.

[spokje]

Ik dacht dat het aan mij lag. Kon gelukkig nog terug naar de oude, maar wat dramatisch indd.

[Tranquility]

Dat kan nu nog, maar voor hoe lang?

[SVMartin]

Ik gebruik al jaren alleen de webinterface. Ooit omdat dat de enige oplossing was op Linux, maar inmiddels bevalt deze uitstekend.

[johnbetonschaar]

Microsoft heeft haar mail programma compleet geruïneerd met "New Outlook", wat gewoon een opgevoerde website (Outlook.com) vermomd als een desktop applicatie is.

Blijf bijzonder hoe voorkeuren kunnen verschillen, want ik vind zelf de 'New Outlook' (of de web UI dus) echt veel beter dan de windows client, wat ik persoonlijk een van de slechtste mail user interfaces ooit is.

Er zullen vast 1001 functies in de native Outlook client zitten die niet in de web UI beschikbaar zijn, maar die gebruik ik allemaal niet blijkbaar, want ik krijg alles gewoon prima gedaan in de simpelere user interface, die veel overzichtelijker en consistenter is. Dus wat mij betreft is het een verbetering

[michelr]

Outlook != New Outlook

[Scriptkid]

Dat is het hele idee achter de 1 unified client

mobile, desktop, windows, apple, android, linux

allemaal 1 de zelfde client look en feel met zo veel mogelijk backend renderd om het simple te houden.

[TechSupreme]

De ene Outlook is de andere niet en Microsoft heeft dat best vaak. De ene OneNote is de andere niet, de ene Skype is de andere niet, de ene OneDrive is de andere niet.

En dat is best verwarrend.

Waar jij het over hebt is het voormalige Windows Mail wat omgedoopt is naar Outlook for Desktop, wat nu dus New Outlook mag heten. Deze Outlook versie heeft beperkte ondersteuning voor Exchange functionaliteit. Weet het niet zeker maar dacht dat het alleen maar werk met Exchange Online (dus niet on-premise)

Daarnaast heb je: Outlook 365, Outlook (de originele outlook) en Outlook for Business.

Alleen die laatste heeft volledige ondersteuning voor Exchange.

En dan heb ik het niet eens gehad over de Mobile apps, want dat is al helemaal een drama.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 16:06]

[smoking2000]

Die add-on heb ik gebruikt maar is een betaalde add-on.

De Tbsync & Provider for Exchange ActiveSync add-ons zijn gratis.

[himlims_]

In praktijk sterk afhankelijk van de instellingen van de Exchange server. Hierdoor niet altijd even succesvol kunnen gebruiken

[Frame164]

Als je netjes bent doneer je iets aan de maker, dus echt gratis is het niet.

[Desiler]

Dat maakt het alsnog gratis als een donatie niet verplicht is?

[Robbierut4]

[...]


De Tbsync & Provider for Exchange ActiveSync add-ons zijn gratis.

Dank. Ik was erg vroeg met de switch naar 115 en toen waren deze volgens mij nog niet beschikbaar. Maar eens tijd maken om door alle add-ons te scrollen om te kijken wat sindsdien is toegevoegd wat handig is

[Kriekel]

Waarom gaan ze voor een protocol dat over twee jaar al verouderd is?

[Cambionn]

Dat is enkel door Microsoft gehoste Exchange. Er zijn ook veel bedrijven die zelf een Exchange server hosten, en dat blijft ook na die 2 jaar. Saarvoor is het erg fijn dat dit erin komt.

[Llopigat]

Er zijn ook veel bedrijven die zelf een Exchange server hosten, en dat blijft ook na die 2 jaar.

Nou, steeds minder hoor! Bijna iedereen gooit ze er nu uit.

Het is namelijk steeds lastiger om zelf een mailserver te draaien. Als je niet al te groot bent dan wordt je mail continu geweigerd (juist door microsoft nota bene).

[Reactie gewijzigd door Llopigat op 22 juli 2024 16:06]

[aikebah]

Hangt wel een beetje af van welke microsoft je bedoeld. MS 365 totaal geen issue om spullen heen te sturen, enkel Hotmail/live/outlook.com is drama (met 'nee hoor er is niks wat bezorging in de weg staat in onze systemen' ondanks een harde SMTP reject in het ticket).

MS 365 is dan weer drama om te gebruiken (ander domein draait daar) als je ook extern toegankelijke distributielijsten hebt die ook weer deels naar extern door moeten. Reken dan maar op regelmatige hold-off met vaker wel dan niet een Non-delivery-report na 24 uur voor alle gmail leden op zo'n distributielijst.

Zo wordt je gewoon gedwongen om hele lijsten mailadressen met nog meer diensten te delen als je gmail wilt bereiken, omdat je een buiten MS365 gehoste oplossing moet gaan gebruiken om zulke distributielijsten te hosten. Vanaf MS365 is het een SRS-forward van de originele mail, ondertekent met de DKIM van de 'tenant domein' (xxx.onmicrosoft.com) ipv DKIM van het distributielijst domein.

[Llopigat]

Hangt wel een beetje af van welke microsoft je bedoeld. MS 365 totaal geen issue om spullen heen te sturen, enkel Hotmail/live/outlook.com is drama (met 'nee hoor er is niks wat bezorging in de weg staat in onze systemen' ondanks een harde SMTP reject in het ticket).

Klopt ja, dat had ik ook gemerkt toen ik zelf nog een mailserver had. Het probleem was alleen met de consumentenhosting van MS, niet de zakelijke.

Het probleem is dat ze 'reputatie' gebruiken. Als je ze weinig mail van je krijgen, bouw je niet genoeg 'reputatie' op. Dat ze het hele protocol hierbij negeren boeit ze niet. Je kan je met een ticket laten unblocken maar na 2 maanden zit de block er weer op.

En ja bulk uitgaand via MS365 is echt shit. Wij gebruiken zelfs een externe dienst om de interne medewerkers te mailen.

[powerboat]

Als je het helemaal platslaat, is een eigen mailserver hosten is niet moeilijk.
Je moet je enkel aan bepaalde spelregels houden.

Overigens kun je het op verschillende manieren inrichten zodat je server niet in gevaar komt.

[Llopigat]

Nouja het hosten niet. Het geaccepteerd worden door met name Microsoft's consumenten domeinen wel. Dat is echt hondsmoeilijk als je weinig mail stuurt. Want juist dan vertrouwen ze je niet.

Ik had daar elke 2 maanden problemen mee en ik had alles goed ingericht en ik stond op geen enkele blocklist.

[powerboat]

Zelf weinig issues mee gehad, ik stuur ook niet zoveel.

[Llopigat]

Nee maar het is juist als je weinig stuurt naar die domeinen. Dan bouw je geen 'reputatie' op. Microsoft heeft een heel stom systeem daarvoor.

Bijna elke mail provider blockt je gewoon als je daadwerkelijk spam stuurt (terecht), maar MS (op consumer domeinen, niet M365) blockt je als je niks stuurt

[Reactie gewijzigd door Llopigat op 22 juli 2024 16:06]

[powerboat]

Oh wat bijzonder.

[jmvdkolk]

Mijn ervaring is dat zelf mail hosten prima gaat, ook met sturen naar Microsoft. Ik weet niet of het eraan ligt dat ik SPF heb ingesteld, of aan iets anders. Maar al mijn e-mails naar Microsoft gehoste mail domeinen komen aan.

[jimshatt]

Minder en minder bedrijven hosten zelf. Cost of operation is veel hoger. Maar er zullen er vast nog wel wat zijn, zelfs over 2 jaar.

[Frame164]

En zo gek is het niet. Email is gewoon een dienst zoals telefonie. En die koop je ook in. Hoogstens zijn er nog wat bedrijven met een in-house PABX maar dat kan je vergelijken met de IT infrastructuur binnen een bedrijf. De services worden ingekocht.

[Blokker_1999]

Alleen blijft de vraag of Exchange vNext nog EWS zal ondersteunen natuurlijk. Temeer daar dit verdwijnt in de Online variant en ik het vreemd zou vinden dat MS het dan wel blijft ondersteunen in on-prem terwijl Outlook zelf er geen gebruik van maakt, die gebruikt MAPI.

[michelr]

Die communicatie was duidelijk: EXO Graph, on-prem EWS.

[Kriekel]

Maar praat die geen Graph-api?

[michelr]

On-prem praat geen Graph; dat was een tijdje wel zo (subset), waardoor ook bepaalde requests tegen M365 naar on-prem werden geproxied (indien nodig), maar dat is er ondertussen uitgehaald.

[Jazco2nd]

Begrijp ik het dan verkeerd?
Kunnen ze niet beter direct voor Graph-api ondersteuning gaan om zowel MS gehoste als zelf gehoste exchange te ondersteunen?

[YoMarK]

Exchange on-prem blijft voorlopig nog wel even, en je hebt ook nog zoiets als https://z-push.org/ .
Dat gebruik ik zelf binnen Kopano.

[Anoniem: 1883242]

Mail is in principe sowieso verouderd als je echt wil moderniseren of iets beters wil.
Gewoon er in gesleten...

[Reactie gewijzigd door Anoniem: 1883242 op 22 juli 2024 16:06]

[Llopigat]

Daar ben ik het wel mee eens. Het is zo kapot tegenwoordig dat het niet veel meer is dan een veredelde notificatiedienst ("Kom je bericht op onze portal checken").

Want je kan er niet zeker van zijn dat een bericht van de afzender komt, dat de inhoud niet onderschept is.. Er zijn allemaal workarounds maar die zijn ook niet dekkend.

[The Zep Man]

Want je kan er niet zeker van zijn dat een bericht van de afzender komt, dat de inhoud niet onderschept is.. Er zijn allemaal workarounds maar die zijn ook niet dekkend.

S/MIME en GnuPG zijn geen workarounds, maar lossen dit precies op. Ze zorgen er zelfs voor dat een gecompromitteerde mailserver geen probleem meer is. Verder wordt S/MIME direct door elk beetje mailpakket ondersteund.

Dat de overheid niet standaard gebruik maakt van S/MIME om eigen berichten te ondertekenen is kwalijk. Verder zou S/MIME-ondersteuning bij bedrijven afgedwongen kunnen worden.

Dat je niet je GnuPG public key op een met DigiD beveiligde site kan uploaden om je overheidscommunicatie veilig en ondertekend in je inbox te ontvangen is knullig. Zo'n systeem kan prima naast het huidige systeem leven.

"Maar hoeveel mensen maken daar dan gebruik van?"

Geen idee, want het bestaat niet. Als er een goed aanbod was, werd de vraag wellicht vanzelf groter.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:06]

[Llopigat]

Het zijn wel workarounds want de identiteit is ook daar niet gegarandeerd. GPG is te ingewikkeld met zijn keysigning parties. S/MIME is administratief weer te lastig en te weinig ondersteund.

Een verplichting zou het wel mainstream kunnen maken ja maar ik zie het zo gauw niet gebeuren.

[The Zep Man]

Het zijn wel workarounds want de identiteit is ook daar niet gegarandeerd.

Noem eens iets dat de identiteit wel "garandeert".

GPG is te ingewikkeld met zijn keysigning parties. S/MIME is administratief weer te lastig en te weinig ondersteund.

Alle noemenswaardige mail clients en web-interfaces ondersteunen S/MIME. Administratief is dat niet lastig voor organisaties. Met een hoge IT-volwassenheid is dat allemaal te automatiseren.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:06]

[telenut]

Maar bedrijven willen de inhoud van de mails scannen en laten dit dus niet toe...

[The Zep Man]

Bedrijven kunnen managed client-side scanning toepassen. Verder is er minder reden voor scanning als zakelijk enkel beveiligde mail wordt gebruikt en niet-ondertekende stilletjes naar /dev/null wordt doorverwezen.

[aikebah]

De keysigning parties zijn alleen relevant voor gebruik van web-of-trust gebaseerd vertrouwen. Voor point-to-point is het voldoende om een keer langs vertrouwde weg de public key te ontvangen danwel langs niet vertrouwde weg met een vertrouwde controle achteraf.

[Llopigat]

Ja maar dat is een behoorlijk gedoe met administratie, hoe je elke key van iedereen hebt geverifieerd.

En hoeveel mensen gaan dat in de praktijk doen? Zie ook bijvoorbeeld het vergelijken van de signature in WhatsApp of Signal. Wie doet dat nou echt? En de keyservers gebruikt niemand meer want die zijn een broeinest voor spammers.

Het is gewoon teveel wrijving voor de mainstream gebruiker en met alleen de cryptonerds kom je er niet.

PS: Ik gebruik GnuPG enorm veel maar voor email nu juist niet vanwege dit soort problemen.

[Reactie gewijzigd door Llopigat op 22 juli 2024 16:06]

[The Zep Man]

Ja maar dat is een behoorlijk gedoe met administratie, hoe je elke key van iedereen hebt geverifieerd.

Daar doe ik juist een voorstel voor. Voor communicatie met de overheid kan dat gevalideerd worden m.b.v. DigiD.

En hoeveel mensen gaan dat in de praktijk doen?

Die vraag heb ik al beantwoord.

[jmvdkolk]

Ik ben benieuwd wat voor alternatieven er zijn om te moderniseren.

[Anoniem: 1883242]

"IM" services kunnen identiteit en uitwisseling technisch vervullen.
Voor identiteit op zich zijn er een plethora aan mogelijkheden, van "blockchain", eigen sleutels tot issued ID's.

Hoe dat kwa UX het mooist of kwa identiteit zo persoonlijk, of kwa security zo veilig mogelijk moet en kan kun je lang en breed over lullen.
Ook over wie deze aspecten bij elkaar brengt of kan brengen.
Je voorkomen en 'proofs' kan op vele manieren bevestigd worden.

Email is geen van het bovenstaande echt maar wel zo gebruikt/misbruikt, gehuld in een waas van nut/belangrijk, gemak of veilig maar eigenlijk gewoon niet, met oubollige antieke flaws, zoals spoofing en spam.

Bovendien zijn het technisch/praktisch oerlelijke, trage, inefficiënte protocollen van smtp, pop3 t/m imap. Geen wonder dat er nog weinigen echt aan werken, laat staan ze in twijfel trekken en vervangen. Er in gesleten.

[Reactie gewijzigd door Anoniem: 1883242 op 22 juli 2024 16:06]

[jmvdkolk]

Er zijn natuurlijk een heleboel nieuwe technologieën om beter om te gaan met identiteit en security. Maar ik ben mij niet bewust van een oplossing die algemeen bruikbaar is ter vervanging van e-mail. Het is heel makkelijk om te zeggen dat we van e-mail af willen als we willen moderniseren of iets beter willen. Wat voor oplossing zie jij voor je die e-mail zou kunnen vervangen als we ons best zouden doen?

[Anoniem: 1883242]

Ik ken geen bestaande applicatie die alle punten aftikt en tot doel heeft om mail te vervangen, maar het kán prima.

Vreemde vraag ook, gezien het punt. De oplossingen zijn er maar de (specifieke) toepassing niet.

Of bedoel je technisch, kwa design? Inhoudelijk?
Heb een aantal aspecten en voorbeelden benoemd die je op verschillende manieren kunt uitvoeren en toepassen.
Geen behoefte aan een debat voor het één of ander en specifiek, mist volledig het punt.

[Reactie gewijzigd door Anoniem: 1883242 op 22 juli 2024 16:06]

[jmvdkolk]

Jij zegt:

Mail is in principe sowieso verouderd als je echt wil moderniseren of iets beters wil.
Gewoon er in gesleten...

Dat impliceert voor mij dat jij een idee wat je kan gebruiken om te moderniseren of als je iets beters wilt. Mijn vraag is: waar denk jij aan.

[Anoniem: 1883242]

Heb al enkele voorbeelden gegeven van de aspecten die relevant zijn.

Je kunt denken aan een authenticatiesysteem die gelinked is aan unieke sleutels die ofwel zelf gemanaged en erkend kunnen worden, al dan niet met whitelists en verifieerbaar om spam te voorkomen.

Je kunt een mechanisme bedenken om white list registratie "opt in" te maken, wanneer je van een service gebruiktmaakt, cq
registreerd, en er dus vanuit gaan waar een berocht (spam?) vandaankomt. En verantwoordelijk houden.

In plaats van tekst gebaseerde trage/brakke protocollen, en gare oplossingen die leunen op oa. DNS, kun je gebruik maken van volledig andere en modellen zoals "IM netwerken".

Of het nou een klein tekstberichtje is of een stuk HTML of andere markup maakt niet uit.

etc.

Nogmaals, ik heb geen trek in voluit te moeten schrijven wat elke 2-bit dev en zeker seasoned dev of sys/net ops snapt.

Al helemaal geen gemiemel en debate uitlokken over of het "pgp" of "welke blockchain", "hoe het communicatie protocol er moet uitzien" of "de netwerk topologie", welke patterns/modellen, etc. etc.

Lang en breed, onnodig, iedereen met een beetje verstand in tech weet wat ik bedoel en wat er beschikbaar is. Als niet, pech, ik ga dit reageersysteem niet proberen te gebruiken of misbruiken om uren en dagen op een smartphoneschermpje te tikken om te herkauwen en voor te kauwen.

Misschien als er specifieke vragen zijn maar heb een gloedhekel aan open vragen en "doe ff alles, u know ff alles uitleggen, in het groot, niks specifiek maar elk aspect ff concreet".

[Reactie gewijzigd door Anoniem: 1883242 op 22 juli 2024 16:06]

[jmvdkolk]

Never mind. JIj praat in oplossingen die nog gemaakt moeten worden, en vanuit de technologie. Ik wacht rustig tot iemand een oplossing kan bieden die niet nog gemaakt moet worden.

[Anoniem: 1883242]

Daar komt het op neer. De oplossingen en kennis zijn er, het is de wil en durf om toe te passen en samen te brengen, aan te bieden en te concurreren.
Er is zoveel beters mogelijk...
Juist omdat veel fundamentele zaken in opspraak zijn is het eigenlijk de ideale tijd om alternatieven te bedenken en aan te bieden, al is er op dit moment veel onzeker.

Privacy en/of inzichtelijkheid als de wet hierom vraagt, data ownership, anonimiteit of juist identiteit, etc. Technisch kan het op zoveel manieren gedaan worden.

Het is meer de vraag wat we nodig hebben en wie je wilt (be)dienen.

[Cambionn]

Mooi! Op dit moment kan het wel via omwegen, maar het loopt toch niet altijd zo soepel als je zal willen. Native ondersteuning is zeker welkom!

[Martinspire]

Wauw, dat heeft lang geduurd. Snap sowieso de ontwikkeling niet helemaal van deze mailclient. Het loopt gewoon enorm achter op alternatieven en weet ook niet echt vooruit te komen. De grafische overhaul was veelbelovend, maar viel achteraf gezien ook erg tegen. Momenteel nog gebruiker van Mailbird, maar die begint iets te duur te worden dat ik toch wel weer rond aan het kijken ben naar wat anders, maar er is gewoon te weinig met een fatsoenlijke gezamenlijke inbox, fatsoenlijke navigatie, fatsoenlijk spamfilter, mogelijkheid tot eigen accounts als ook die van de grote providers en dus inclusief exchange, plus fatsoenlijke performance en betrouwbare notificaties. Zeker voor Windows vind ik het aanbod tegenwoordig erg tegenvallen en Outlook zelf vind ik ook helemaal niks. Belabberde UI en heel traag.

[michelr]

Een "Exchange protocol" bestaat niet. "We are working on expanding protocol support for EWS (via ews and the internal ews_xpcom crate) and hooking it into the Thunderbird UI." Da's mooi, maar EWS is geen lange termijn strategie voor M365 mail client, dus richt zich op de on-prem customer base. En dat daar IMAP straks uit kan is winst.

[Reactie gewijzigd door michelr op 22 juli 2024 16:06]

[Kargin]

Mooie en betere client dan Outlook. Enige wat ik heb gemist was de exchange integratie.
Ik ben een paar maanden geleden overgestapt naar Betterbird (betterbird.eu). Ik vind dit minder buggy en iets uitgebreider.

[m-vw]

Ooit begonnen met de hele Netscape Navigator suite, daarna overgestapt naar Thunderbird en Firefox.

Maar nu al een paar jaar Office 365 met outlook. Ik begon mij steeds meer te ergeren aan Thunderbird. Wellicht ligt het aan mij maar bijvoorbeeld de zoekfunctie deed nooit wat het moest doen. Berichten waarvan ik 100% zeker wist dat ze bestonden werden nooit gevonden.

[19RAW68]

Sinds kort ook over op Outlook, gebruikte Thunderbird vooral omdat ik de mail lokaal op de NAS had staan. Echter, betrouwbaarheid werd steeds slechter, vaak vastlopers, je kon de mail maar op één device tegelijk openen, interface werd erg rommelig. En we zijn nu zo gewend aan cloudopslag dat dit ook geen issue meer is.

[cane]