In KDE4 times it was possible to access imap or pop3 servers using the imap or pop3 kioslave included in kdepimlibs repo. With the migration to kf5 the pop3 kioslave plugin has landed in the kdepim-runtime repo (https://cgit.kde.org/kdepim-runtime.git/tree/kioslave), but the imap kioslave plugin is unfortunately no longer available, but is needed to realize https://bugs.kde.org/show_bug.cgi?id=399094
Description
The IMAP slave has been removed intentionally during migration to KF5. Please use the KIMAP library to interact with IMAP servers.
And the mail:/ kio interface may be interesting for this task:
"You can then open «mail:/» in dolphin or whatever to browse your email
attachments."
for more details see: https://marc.info/?l=kde-pim&m=153772379115909&w=2
However, unlike the IMAP slave, the kiomail requires users to use Akonadi and have their email accounts configured there - at which point interfacing with Akonadi directly might more optimal :-)
What is the reason why the imap kioslave was removed? pop3 has similar functionalities and was not removed.
Because it was no longer needed (fully replaced by Akonadi and IMAP resource), it was duplicating a lots of code from KIMAP library and no-one was interested in porting it and maintaining it.
POP3 hasn't been removed because we don't have a replacement yet. While mapping IMAP onto an IO slave somewhat works, POP3 is mostly an abuse of the IO slave API and I hope to kill it as well at some point.
If you want the IMAP IO Slave, you are welcome to port it to KF5 and maintain it in KMyMoney, but we really don't have the time or manpower to maintain another IMAP implementation (one is causing us enough pain as it is).
At the cost of no longer available imap kio slave support
it was duplicating a lots of code from KIMAP library
then it looks to be the best to refactor the kimap kio plugin to use the KIMAP library and let the plugin only be a thin wrapper providing the kio slave protocol.
we really don't have the time or manpower to maintain another IMAP implementation (one is causing us enough pain as it is).
This I can understand and is an additional argument inside the imap kio plugin to use the KIMAP library
Any chance to make this a GSOC task ?
We don't really participate in GSOC/SOC/etc.. I don't want to speak for @mlaurent, but from my side, we simply don't have the time and manpower to manage it. And the topic of GSOC and similar projects never even came up on any PIM meeting.
If KMyMoney can coach a GSOC, we can for sure provide some guidance (on the technical level) to help with finishing the port, but I can say for sure that we are not willing to maintain the port.