Version: (using KDE KDE 3.2.1) Installed from: RedHat RPMs OS: Linux Again, it would be nice to have MirKrostuff Exchange support directly built-in kmail. I don't really like MS products but we use it in our enterprise. I know there is Ximian Evolution with the exchange connector wich support exchange web access... but it ain't free.
On Sunday 28 March 2004 18:46, Vincent Fortier wrote: >Again, it would be nice to have MirKrostuff Exchange support directly > built-in kmail. I don't really like MS products but we use it in our > enterprise. I know there is Ximian Evolution with the exchange connector > wich support exchange web access... but it ain't free. Please use the IMAP port on your exchange server. If you refer to contacts and calendar, this is being worked on and not part of kmail. Plus the Evolution solution will only work if webaccess is enabled by your administrator. Cheers, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6-cvs (GNU/Linux) iD8DBQFAZwoQu1Wkf8kBwz4RAhdOAJ9XqRh/599p5kFm84IWZmReZ0ORDACdG8HR 5GNiRc/PuoNOB9ktdhfa2GI= =VBxx -----END PGP SIGNATURE-----
The exchange plugin is now GPL software. You can download it at http://ftp.ximian.com/pub/source/evolution/ximian-connector-1.4.7.tar.gz Is it possible to integrate it into kontact?
*** Bug 81423 has been marked as a duplicate of this bug. ***
Now that the situation has changed (Connector now GPL), please reopen this wish.
Company migrated to Exchange 2003. Deactivated IMAP port. Now using Evolution 2.0 from Fedora Core 3 (I cheated and upgraded on my FC2 system). Evolution works great for Sending and Receiving these emails. Please reconsider/reopen this wish.
University migrated to Exchange. Deactivated IMAP port. I'm wondering whether there's a theme here. Please reopen - it has 100 votes and AFAIK it is not 'fixed' yet. Thanks.
Bug is still valid for KMail.
This won't be ready in time for 3.4. We will approach it along with access to other storage methods later.
Add one more voice to the chorus. I'm currently using Evolution in GTK-Qt with Baghira. It's very unstable, but it handles Exchange mail and calendars quite well. I would prefer KMail though, given that it's more stable under Baghira.
I hope this can be addressed soon. Webdav access to exchange servers is becoming more common and is normally the only access permitted from outside the firewall. The integration in Evolution seems to work quite well but I would prefer to have access from kmail, along with all my other mail accounts.
I'm adding some votes to this bug. Most companies these days do not enable outside IMAP access to their Exchange servers (including mine). WebDAV is becoming more & more widely used since it is one less port to open up on the firewall.
Exchange 2003 uses also some RPC over HTTPS component to serve mails. Outlook 2003 does support remote mailbox with this feature. It may be propriotary protocol and therefore not possible to intergrate into KMail, but Exchange does support RPC over HTTPS with NTLM/basic authentication. I propose this kind of interface as Exchange 2003 Web Access deployments have .net login lately and even Evolution does not support it.
Why is this problem marked as resolved? It is cleary not resolved. Kmail can not access Exchange via http https web like Evolution can. Thats what everyone wants. Please at least open this bug. It is not resolved and would be great if kmail could support exchange like Evolution can.
Now that Microsoft specs are "opening" and since the code is available elsewhere (evolution) since 4 years I sincerely think this bug should be reopened. This is by far my greatest whish for KDE, being more "connected" with what we are stuck with in many offices.
Agreed. We are forced to use Exchange now and overseas only open OWA and exchange port and hence I needed to migrate from kmail to evolution. So unfortunate.
I am force to use exchange and had to move away from Kmail.. please support it so we can all move back onto Kmail.
*** This bug has been confirmed by popular vote. ***
I'd like to second Divan Santana and others above. I was also forced to ditch KMail in favior of Evolution due to my company's Exchange server.
Good news kind of: http://www.kdedevelopers.org/node/3581 It looks like mailody and therefore kmail has got support for MS Exchange using native protocols via Akonadi using http://www.openchange.org/ project. Check out the link - hopefully in the near future Kontact/Kmail will support MS Exchange fully and also be fully ported to the Windows platform. :D
> It looks like mailody and therefore kmail has got support for MS Exchange using native protocols via Akonadi using http://www.openchange.org/ project. That is not entirely correct. Akonadi has support for MS Exchange via the openchange resource, yes. But KMail is not ported to Akonadi yet, that will take some time still. Mailody already uses Akonadi, though.
Note that the openchange solution is unlikely to work from outside the firewall -- certainly my company does not permit Outlook access to Exchange from outside the firewall. And the same issue seems to be referenced in comment 11. In these cases, Webdav support is required as that is what is normally enabled externally (in the form of Outlook Web Access). This also has the advantage that Webdav is an open standard (although I am sure Microsoft use their own extensions of it!).
*** Bug 60120 has been marked as a duplicate of this bug. ***
(In reply to comment #0) Version: (using KDE KDE 3.5.1 level A) Installed from: Suse SLED10 OS: Linux I would like IMAP support for Exchange 2007 to support the calendar of exchange. I saw also some authentification bugproblem appearing. Normal Imap on Oracle OCS (mailserver)is functioning. And with exchange strange effects appear in the local inbox (not imap) It was duplicating multiple times the folders present. I had to kill Kmail. Certain things appear to work with IMAP (ORACLE for example) but exchange is still a problem (?)
Since 20 June 2003 (see https://bugs.kde.org/show_bug.cgi?id=60120) no way to connect to exchange server using MAPI native exchange 5.5 protocol......... Any chance to see this appens before 100% of exchange users drop kmail to the benefit of evolution (or outlook)? I'd be glad to test. I'm part of users that works in a company that is running exchange servers with webdav and imap deactivated.
MAPI for Exchange 2007 is fully documented here: http://msdn.microsoft.com/en-us/library/cc678348.aspx
There is a free (GPL) Exchange to POP/IMAP/LDAP/CalDAV/SMTP gateway called DavMail: <http://davmail.sourceforge.net/> It supports Exchange 2000, 2003, and 2007. This should be useful for (a) KMail developers who may wish to appropriate DavMail's GPL code for connecting to Exchange, and (b) users of KMail (and other mail clients) who want a workaround for lack of Exchange support.
MAPI is not the only way to access Exchange 2007. Outlook in Office 2007 has an "Outlook Anywhere" feature, that uses the Exchange 2007 OWA web services API. http://msdn.microsoft.com/en-us/library/bb408417%28EXCHG.80%29.aspx (Most likely, davmail uses this API, however it would be much better to have native support in kde-pim) AFAIK, this is the way Apple provides Exchange 2007 support in Mac OS 10.6? and the iPhone. In most cases, it allows users Exchange access both in and out of the office, where MAPI support will typically only provide in-office access.
While davmail does work to a degree: 1)kmail via davmail doesn't manage to retrieve the full message list from my Exchange Inbox (other folders with fewer mails succeed) 2)kde 4.3.x doesn't have any CalDAV support, so still no calendar support
Not sure what the status is about the Akonadi agent for this. Reassigning to KMail2 in the meantime, can reporters check KMail 2 and amend this report? Thanks in advance
all FYI, the calendar is working for me via davmail as per email thread below(be sure to see last email in thread) http://kde.markmail.org/message/2cqxr6ivugk4sxfu
thanks, closing as fixed
Thanks for adding the improvement!
Ok, I give up on kmail as it's clear that kmail will NEVER EVER have support for exchange MAPI protocol. Bug https://bugs.kde.org/show_bug.cgi?id=60120 which was about having native MAPI support was marked as duplicate of this bug which has nothing to do with this bug which is about having exchange access via webdav. As my company (an certainly many other) are disabling webdav AND imap access for whatever reasons (mainly stability and security) I'm still stuck with a virtual machine running windows and outlook...for ever.... In the hope, here is a reminder for MAPI documentation: > MAPI for Exchange 2007 is fully documented here: > http://msdn.microsoft.com/en-us/library/cc678348.aspx Regards.
Olivier, I am sorry you feel that way. It would be better to open a new specific bug report for MAPI and for KMail2. This bug was against KMail1 which is not supported anymore. With this triaging effort, I hope to address only valid bugs and to port them to the attention of the developers. Bug reports with more than 30 comments are not helpful anymore. So I encourage you strongly to open a specific report for the remaining non working part of MAPI, instead of reopening this one which is too confusing.
(In reply to comment #34) > Bug reports with more than 30 comments are not helpful anymore. Attitude and comments like this helped me to stop reporting anything to bugs.kde.org years ago.
Juha, I am sorry. I am only a bug triager and I did as good as I could. Reopening this bug report then, with my apologies.
Juha please further note that I explained my actions and thus triggered some reactions. Do you think this bug report is readable and understandable from a devel point of view? You think so, I don't. I am waiting for a summary from you of what is needed against KMail2 state so I can open a new clear bug report from fresh, thanks in advance. Again apologies, there are hundreds of reports not triagged and we got through them to see those which were still valid for KMail2 as Kmail1 is discontinued.
As bug initiator, I will re-explain: Built-in exchange support means: - Most probably using native communication protocol (no imap or whatever) - kmail2 was not existing at the time but it does also affect it indeed - that would also mean the other components would also follow: address book + calendar + etc to be able to communicate with exchange server using native communication protocol Is that sufficient?
New wishlist opened here with a vote counter reset to ZERO. https://bugs.kde.org/show_bug.cgi?id=287984
BTW, this bug was also here: https://bugs.kde.org/show_bug.cgi?id=227672 (only regarding mail) IMHO, close as duplicate of the one I've openned above as the one I've openned also include support for contacts and calendars.
+1: this is duplicate of #227672 (which is more correctly linked to Akonadi instead of Kmail). I also wanted to note that a quick search showed that combined, duplicates regarding exchange/mapi support possibly via an openchange akonadi ressource (#78629, #287984, #60120, #227672) add up to 1081 (431 + 100 + 285 + 265) votes. How long would it take to write a bridge between libmapi and akonadi? I code in C++ but am not familiar with akonadi codebase or mapi protocol. Can any dev estimate how hard/long it would be?
Bump for 2013 with linkage to https://bugs.kde.org/show_bug.cgi?id=227672 ;)
Believe it or not, today marks the 10th anniversary of this bug entry! Happy birthday!
That's a reason to have some beer, isn't it?
I changed to Evolution because of this. My company doesn't allow IMAP on Exchange (which seems to be the default policy in a lot of companies) so I am either forced to use the OWA web interface or use Davmail. Both solutions aren't really options anymore for me because I prefer native applications to web frontends and Davmail has performance problems with rather big mail inboxes. Evolutions seems to have a very good EWS plugin (the official Exchange XML Api) and supports the calendar, mail and address book out of the box. I would really be happy to see the same support in Kontact/KMail/Akonadi whatever.
Seriously, I do not know whether it is in relation with this, but... When I was using the KDE 4.14 software the IMAP support still worked with the Office365 servers and with the Plasma 5.2 the IMAP connection started to give some problems with Office365 and with 5.4 it seems to stop working (well, sometimes it tries to work, presenting inside kmail 14 copies of the same message when a new one arrives and not presenting the headers of previously existing mails). I would not surprise myself if it were a problem with the Microsoft IMAP implementation.
(In reply to André Stein from comment #45) > I changed to Evolution because of this. My company doesn't allow IMAP on > Exchange (which seems to be the default policy in a lot of companies) so I > am either forced to use the OWA web interface or use Davmail. Both solutions > aren't really options anymore for me because I prefer native applications to > web frontends and Davmail has performance problems with rather big mail > inboxes. Evolutions seems to have a very good EWS plugin (the official > Exchange XML Api) and supports the calendar, mail and address book out of > the box. I would really be happy to see the same support in > Kontact/KMail/Akonadi whatever. Same for me, I can't understand wy this feature is ignored since at least 11 years! The wheel is reinvented daily (dnf replaces yum, wayland replaces X, dolphin replaces konqueror, dracut replaces initramfs, systemd replaces init, ....) but nothing about a major component in enterprise IT: native exchange support with calendar sharing, malbox sharing, ... Please stop reinventing the wheel and work on this major feature. I'm open source developer (OSCAR CLuster, and a few other related projects), and I know it's free time development and thus it comes when it's ready, but please, don't discourage development by saying this is not needed or that there are alternatives (wich is flase in this cas as imap is often blocked and has no mailbox sharing feature at least). For now I'm forced to use outlook web access and it's poor. My next computed will be a MAC so I'll have a unix like OS with Outlook support........
Almost 6 months ago I have started the effort to bring native Exchange support to Akonadi using the Exchange Web Services (EWS) protocol, which has become the primary standard used to communicate with Exchange (Microsoft Outlook uses it by default). Today I have published an initial release with full e-mail support and partial support for other items. If you're interested in doing some testing please check the project website on GitHub: https://github.com/KrissN/akonadi-ews
I will gladly do as soon as there is a PPA or (other relatively simple mean for trying it) and provide feedbacks!
(In reply to Vincent Fortier from comment #49) > I will gladly do as soon as there is a PPA or (other relatively simple mean > for trying it) and provide feedbacks! I've prepared a package for Ubuntu 16.04: https://github.com/KrissN/akonadi-ews/releases/tag/v0.8.0
I gave it a try. I had not played with KDE since around a year so I had to play a little with my installation in order to get things working as is seems there is a bug blocking plasma to startup properly with 16.04. For other who might be interested (not entirely related to this thread...): sudo add-apt-repository -y ppa:kubuntu-ppa/staging-misc sudo apt-get update sudo apt-get -y install plasma-desktop kde-l10n-fr Then getting your package installed: wget https://github.com/KrissN/akonadi-ews/releases/download/v0.8.0/akonadi-ews_0.8.0-1_amd64.deb sudo dpkg -i akonadi-ews_0.8.0-1_amd64.deb sudo apt-get install -f Then finally kontact ready: sudo apt-get update sudo apt-get -y install kontact kleopatra Once all set I was able to login into KDE/plasma and launch kontact and get things going. Now, the real thing! A few comments: - The domain box should be optional and thus perhaps a click on/off be appropriate - I think same should be true for the username: in my case there are no username except my email user... again, by default it may be more appropriate to auto-fill that box with the name section of the email address with a on/off to edit manually? - server auto-discovery failed to work... In my case I use an internal auto-discovery URL that I have to specify manually. My understanding of the interface is that it tries to auto-discover "online" but I cannot assign an auto-discovery URL manually? End-result: sadly as-is I wasn't able to get access to my inbox through EWS. Lastly, hopefully at some point full support for calendar along with contacts & task will be made available! Thnx for finally trying to close this gap within the KDE suite, it is really much appreciated and I look forward at trying later versions!
(In reply to Vincent Fortier from comment #51) > Now, the real thing! A few comments: > - The domain box should be optional and thus perhaps a click on/off be > appropriate I agree that some sites do not require it, but nevertheless I think that hiding it behind some checkbox would be more confusing. > - I think same should be true for the username: in my case there are no > username except my email user... again, by default it may be more > appropriate to auto-fill that box with the name section of the email address > with a on/off to edit manually? Similar as above. > - server auto-discovery failed to work... In my case I use an internal > auto-discovery URL that I have to specify manually. My understanding of the > interface is that it tries to auto-discover "online" but I cannot assign an > auto-discovery URL manually? Server autodiscovery relies on resolving an address based on your e-mail domain. Sometimes this won't as the autodiscovery service is not available (this is the case with my corporate account). In such case you can uncheck the "Server Autodiscovery" checkbox and enter the EWS URL manually. It should be something like: https://yourdomain.com/EWS/Exchange.asmx
(In reply to Krzysztof Nowicki from comment #52) > (In reply to Vincent Fortier from comment #51) > > Now, the real thing! A few comments: > > - The domain box should be optional and thus perhaps a click on/off be > > appropriate > I agree that some sites do not require it, but nevertheless I think that > hiding it behind some checkbox would be more confusing. Agreed. Perhaps adding a "(optionnal)" tool-tip message? > > - I think same should be true for the username: in my case there are no > > username except my email user... again, by default it may be more > > appropriate to auto-fill that box with the name section of the email address > > with a on/off to edit manually? > Similar as above. Same is true, a tooltip or auto-complete with what you username maybe based on your email would be nice. > > - server auto-discovery failed to work... In my case I use an internal > > auto-discovery URL that I have to specify manually. My understanding of the > > interface is that it tries to auto-discover "online" but I cannot assign an > > auto-discovery URL manually? > Server autodiscovery relies on resolving an address based on your e-mail > domain. Sometimes this won't as the autodiscovery service is not available > (this is the case with my corporate account). In such case you can uncheck > the "Server Autodiscovery" checkbox and enter the EWS URL manually. It > should be something like: https://yourdomain.com/EWS/Exchange.asmx Under evolution I manually entered my "autodiscover" URL then hit get URL and it fills up the URL OAB field automatically. In this case I manually entered the EWS URL and hit Try connect.. Which i found simpler to evolution as the user don't really care about the underlying UUID type OAB URL. Although a connection successful may be appropriate? It ended up not adding any folder within kmail for the new account (maybie a bug related to kmail and totally unrelated to your new feature, will further investigate?). Although from the subscription tab I can select my various folders and as well, it says "ready" under it in the reception tab. It's sad that it blocks over tiny details as I'd rather provide you with comments on the real stuff :) I'll reinitiate my kmail config as it may have older configs stuck? and give it another try.
(In reply to Vincent Fortier from comment #53) > In this case I manually entered the EWS URL and hit Try connect.. Which i > found simpler to evolution as the user don't really care about the > underlying UUID type OAB URL. Although a connection successful may be > appropriate? It ended up not adding any folder within kmail for the new > account (maybie a bug related to kmail and totally unrelated to your new > feature, will further investigate?). Although from the subscription tab I > can select my various folders and as well, it says "ready" under it in the > reception tab. Can you try to click "Check Mail" in KMail? This should force a full sync and should populate your folder tree.
Tried it, would have been to simple :) I removed/recreated the kmail config and also tried the following https://docs.kde.org/trunk5/en/kdepim/kmail/clean-start-after-a-failed-migration.html Also tried streaming notifications vs pool every x.y mins. Still no folders and no luck sadly. Starting kmail from a console gets the following output: $ kmail "KMail Kernel ETM" () "" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_Rt0qZi" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_6rPTQz" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_G17QQ6" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_BzULk8" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_dMPgUN" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_VBMxvj" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_ZB5RQu" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" "/subscriber/kmail2_17230_4JGo60" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" this does not work on a KActionCollection containing actions! done Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" org.kde.akonadi.ETM: GEN true false false org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" "/subscriber/kmail2_17230_NLIKyV" connectToServer "/tmp/akonadi-fortierv.BQzl2m/akonadiserver.socket" Could not resolve property : linearGradient4538 Could not resolve property : linearGradient4588 Could not resolve property : linearGradient4554 Could not resolve property : linearGradient4572 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4538 Could not resolve property : linearGradient4588 Could not resolve property : linearGradient4554 Could not resolve property : linearGradient4572 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4538 Could not resolve property : linearGradient4588 Could not resolve property : linearGradient4554 Could not resolve property : linearGradient4572 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Could not resolve property : linearGradient4532 Could not resolve property : linearGradient4582 Could not resolve property : linearGradient4566 Could not resolve property : linearGradient4548 Connected to "Akonadi" , using protocol version 52 Server says: "Not Really IMAP server" Read defaultResourceId "akonadi_maildir_resource_0" from config. Found resource "akonadi_maildir_resource_0" org.kde.akonadi.ETM: Subtree: 9 QSet(10, 11, 9, 14, 15, 12, 13) org.kde.akonadi.ETM: collection: "Dossiers locaux" org.kde.akonadi.ETM: Fetch job took 218 msec org.kde.akonadi.ETM: was collection fetch job: collections: 7 org.kde.akonadi.ETM: first fetched collection: "Dossiers locaux" Fetched 7 collections. org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: Fetch job took 244 msec org.kde.akonadi.ETM: was collection fetch job: collections: 2 org.kde.akonadi.ETM: first fetched collection: "Search" Fetched root collection 9 and 7 local folders (total 7 collections). resourceId "akonadi_maildir_resource_0" All done! Comitting. Emitting changed for "akonadi_maildir_resource_0" Emitting defaultFoldersChanged. org.kde.akonadi.ETM: Fetch job took 89 msec org.kde.akonadi.ETM: was item fetch job: items: 0 org.kde.akonadi.ETM: Fetch job took 17 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0 org.kde.akonadi.ETM: Fetch job took 258 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0 org.kde.akonadi.ETM: Fetch job took 258 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0 org.kde.akonadi.ETM: Fetch job took 256 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0
Do you have a GitHub account? I can raise this as a bug and we'll continue over there rather than trashing this bug report with irrelevant comments.
I see this bug has just been marked as RESOLVED/FIXED. Could someone point me to the commit where the feature has been added?
(In reply to Tristan Miller from comment #57) > I see this bug has just been marked as RESOLVED/FIXED. Could someone point > me to the commit where the feature has been added? https://cgit.kde.org/kdepim-runtime.git/commit/resources/ews?id=fa7c27c9cf8e30699fb6070f6445496016bb1990