PLEASE BE AWARE that this was done on a brand new install of Neon User with Kmail 5.10.1

ADDITION ADDITION ADDITION ADDITION

...... BECAUSE I DID NOT RECOGNIZE THE MEANING OF A TERM IN THE SETUP I COMPLETELY MISSED THAT THERE IS A BUTTON WHICH TAKES ONE TO AKONADAI SETUP AND THERE IS AN OPTION FOR MICROSOFT EXCHANGE ACCOUNTS....

THE BELOW WAS NOT NECESSSARY FOR ME TO DO WHEN I TRIED TO SETUP THE SAME ACCOUNT AGAIN.... I NOW HAVE TWO OF THE ACCOUNTS AND THAT IS OK...

IT IS VERY SIMPLE AND MERELY REQUIRES USUAL NAME PASSWORD EMAIL AND STUFF THERE IS, HOWEVER A "NEW THING" THAT HAS TO BE TICKED.

THE INSTRUCTIONS ARE in the link through the below thread at this forum.

viewtopic.php?f=215&t=157179&p=410945#p410945

IT MAY WORK with other versions and it may not.

FOR THE USUAL PEOPLE WHO COMPLAIN THAT THE OLD WOODSMOKER IS TOO WORDY...JUST GIVE US THE INFORMATION...

Microshaft has changed the paradigm...

a "simple put this in" will not work in all cases IN THE CLOUD...

. The USER must INTERACT with the institution to find out how the institution has "tweaked" their version of E-mail in the cloud for Outlook.

also...

There is a "GUI" thing which does not reflect how things have changed with what must be entered in certain "boxes".

SO,...this is a VERY long post...but at the end...for the user, at least this one, IT WORKS... and there are some suggestions to the devs about how to make WHAT ALREADY WORKS redone so that the USER UNDERSTANDS what NEEDS to be done.

BEGIN THE LONG POST:

Kmail and Outlook(tm) DYNAMIC how to simple steps.

How to get Kmail to work with "Microsoft Cloud" e-mail which is at an institution and the user is working from home using Kmail.

Using Neon User Edition, installed a few days before this post.

FIRST:

Kmail WILL DO IT...THE CODE inside Kmail will do it. !!! YAY!

HOWEVER THIS POST….is for BOTH THE USER AND the developers.

We are NO LONGER …in a situataion of….. DO THIS AND IT WILL WORK.

The problem with that approach, the original approach, was that it was a situation of…

MS “changing some small thing” and so what worked a few months ago does not later.

HOW MANY POSTS litter the net about “Kmail worked and then it stopped”. And that was because MS had changed some small thing, NOT because Kmail had somehow “stopped working”..

It is NOW…..

with “the Cloud”…. That MS has created a situation in which….

MS provides “the cover”

and the individual institution has “a SMALL amount of “leeway” “ in which to be “different” than other institutions to foil the MULTITUDE of hackers.

We all know, of course, that there are MANY “settings” in an e-mail client ….but just a FEW are actually important in that the “user” can “do this or that” and that the institution does “this or that” and the COMBINATION….. and PERMUTATIONS...(look it up ) of them make a “first line defense” against the hacker.

The writer will provide ONE SMALL example of this..

A few years ago, when the writer’s institution “ran it’s own e-mail system” the IMAP receiving address was written with the FIRST LETTER in capitals when the “standard method” was that the IMAP was done in all lower case.

But, now that the institution has moved the e-mail to “Outlook™ “ on the cloud the IMAP has a totally different “first word”.

When one sees the “first word” of THE WRITER’s institution one will say….WELL BIG WHOOP!! ANYBODY could do THAT! And yes….anybody could but….this is the first,….

SMALL ...step to creating a situation in which every institution has a UNIQUE set of parameters with which the evil hacker will have to deal..

So….. as to the DYNAMIC...some things need to be stated up front.

Kmail REALLY DOES WORK…. It has the code, but the USER will have to interact with the institution to get the “moving part” for that institution, and there may be SEVERAL moving parts.

Because Kmail really DOES work but there are several “moving parts” those moving parts can get in the way of the normal, home, user getting it to work.

HOWEVER we need to also visit about what the developers have done.

The developers have the GUTS of Kmail to where it WILL WORK……

But, the GUI , to this writer, has not been changed to reflect this new paradigm about security in e-mail.

Fundamentally the moving parts are,

A) a GUI which does not reflect “what MS cloud wants”
and
B) what the institution is USING in it’s particular e-mail operation and that then…

leads…..to the situation of…..

THERE ARE ONLY THREE PROBLEMS

I) one problem is the GUI for Kmail
II) a second problem is that MY INSTITUTION

AND PROBABLY YOUR….

MScloud outlook has changed the word …

IN THE RECEIVING TAB….. the word IMAP in the address….

to the word "whatever"

ALSO….ALSO another moving part…

III) the "safety first" lean of KDE creates a situation of the uninformed user NOT KNOWING ABOUT a preset and that the user has to ask the IT people at the institution about whether to "untick" the preset or to leave the preset "ticked".

a) one problem is the GUI for Kmail.

The situation is that:
a) the GUI for Kmail is the same GUI that was standard for years but does not have "words" that show the user what is actually needed to put into the box when dealing with THE NEW outlook situation.

b) The KDE presets of "signing keys" and "pass keys" being set as default CONFUSES the INexperienced user as to whether a sent e-mail is rejected for:

i) some incorrect setting in Kmail
ii) some unknown setting at the institution
iii) some interaction between an incorrect setting in Kmail and the unknown setting at the server.

KMAIL IS READY AND REARING TO GO...it really IS!

But , FOR THIS USER... it is recommended that THE DEVELOPERS OF the GUI terminology and the presets POSSIBLY should change words and notifications so that the user is aware of the DYNAMIC situation with outlook on the cloud.

HOW DO I KNOW THIS?

HOW did I come to these conclusions?

There are several REASONs why I PARTICULARLY was able to do this.

I AM NOT BRAGGING... but the situation really is a unique one that the "normal user" would not experience.

And because of that

A) this post is being done so that the READER will be aware of the NEW dynamic relationship between a WORKING Kmail and the “variability” of different institutions on the cloud

and

That I really AM recommending that several things be changed about the GUI of Kmail AND that there really DOES need to be "notified" about different settings.

It is my HONEST opinion that if these “COSMETIC” changes are made then EVERYBODY will be able to EASILY get Kmail to work with “outlook on the cloud”.

B) the first reason is that I have fiddled with this for YEARS, as many here might know...I am not bragging but...at a critical juncture I realized that:

a) ONE CRITICAL WORD AND BOX in the GUI for Kmail is not appropriate for the PRESENT situation with the MS cloud.

THE IT PERSON at the institution DID NOT KNOW THAT...and so could not give helpful directions.

b) the present KDE mandate of "security first and user second" automatically creates a situation in which the app will not work IF ONE DOES NOT KNOW...

JUST PARTICULARLY ...

WHAT... TO ASK... the institution's IT person.

And that is because..."many" institutions do NOT use the very strong security measures that Kmail provides and mandates.

I know there will be rants "WELL THEY SHOULD" but please let us get beyond that.

A VERY EXPERIENCED IT PROFESSIONAL in both the Windows(tm) world AND KDE world would probably know this but a user sitting at a home computer would not...

AND...the " local business or local college IT person” would not ...

IF THE IT PERSON did not use KDE. !!! !!! !!!

THEIR words talking on the phone are not necessarily OUR words!!

The NEW and WORKING...Kmail is constantly producing messages about passphrases and generated passphrases and if one does NOT KNOW AHEAD OF TIME...that

ALL OF IT WAS generated by Kmail AS A DEFAULT ...

and NOT BECAUSE THE outlook system was requesting it...

then the user is left in a never ending loop of "the filter did not accept..."

There are THREE OPTIONS, the user name, the e-mail and the "passphrase"

AND the concommitant QUESTION... ( is the passphrase the users PASSWORD for the institutional e-mail or the multi-letter / number combo that appears on the FIRST ATTEMPT AND IS GENERATED BY KMAIL ) ...

...and one better get it written down because it will NOT appear again.

And then one has...because there is NO option to "show" what one is typing the HAUNTING QUESTION .."did I mis-enter something"?

The second reason that I figured this out is...

B) because the college trusts me and WHEN I ASKED...they...

gave me the "hidden keys" which are actually "not hidden" but that Microsoft just does not want the stuff out in the wild so that people like Linux users can not be tied to the outlook site at an institution.

The only way that I got the "hidden keys" is because they gave me a link to a password protected site...in the cloud...which took...my normal institutional password! WHAT?

if one KNOWs the information is there then one can get AT the information but if one DOES NOT KNOW...then one is ...out of luck...it isn't spread around.

############

HOW TO SETUP Kmail WITH OUTLOOK --- a PARTICULAR.. instance.

This particular instance works. You should check your company / institution for details... but the situation is this.

The institution at which I work " does not use "IMAP" anymore". THEIR QUOTES...

They, INSTEAD... use the "Microsoft Cloud" which is basically MS Outlook(tm) and because of that...

the things that are typed into the IMAP box are NOT what is NORMALLY typed into the box,.

BECAUSE OF THAT...

There are several problems PRESENTLY in using Kmail which "might" be addressed

a) REWRITE ... Possibly...the "words on the interface" to where the user can be made aware that "this is what the word on Kmail means in terms of MS Cloud".

An example is that Kmail uses the word IMAP... and one assumes that one would use the classic things to type in the box...but one instead uses a term which involves the word "whatever" for the box "IMAP" in the incoming tab.

THE WORD IMAP is NOT USED!!!

But, THEN SURPRISINGLY...

Microsoft then does a turn around and goes back to

SMTP for sending !!

So in the sending tab one uses "SMTP.whatever.whatever.

So the suggestion is...that..., to that end possibly the GUI for Kmail could possibly replace the words for the IMAP sending box with the following: IMAP/outlook

Because entering the "whatever" address in the IMAP field does, indeed, work.

The "American" terminology is not congruent with European useages.

Such as, apparently, at least some institutional useages only have the word "server" for both outgoing and incoming but, in Kmail the the incoming server APPEARS to be looking for the word IMAP but will ALSO use "whatever".

BUT THE USER DOES NOT KNOW THAT if the user uses the "classic instructions".

And for the outgoing server; one would assume that one would use "whatever" but it instead uses "SMTP, whatever...yada"

HOWEVER, HOWEVER, …. IT IS THE PERSONAL OPINION… of this user that the institutions really can “change” some of the words in the address such as …

whatever.whatever,whatever,name of institution to ANOTHER first word….such as maybe…

whatever, whatever, etc.

THIS is what the institution under discussion PREVIOUSLY did, there was ONE letter changed in the addy…. Such as “Mail.mail.whatever” instead of “mail.mail.whatever”.

If the BELOW method does not work then ONE MUST CONTACT THE IT people…

BECAUSE….

Kmail DOES, INDEED, work.

AND WE HAVE MOVED BEYOND WHAT USED TO BE THAT EVIL MICROSHAFT WAS CHANGING THINGS…..NOW ….

THE CHANGES ARE AT THE INSTITUTIONAL LEVEL!!

this is a PARADIGM SHIFT WHICH HAS BEEN ENABLED by the massive amount of computing power available on the cloud.

B) This institution really is on the cutting edge of doing this MScloud stuff.. but it does NOT USE any kind of "passkey' the "passkey signing" setting in Kmail is preset to it being “ON” and the user is met with being presented a complex passkey which one must write down and enter but it is TOTALLY SUPERFLOUS to the actual institution.

AT LEAST FOR THIS INSTITUTION…..and I think a LOT of institutions.

This particular institution HAS passkeys but does not "use" them.

Kmail checked for passkeys and it DID INDEED FIND THEM...but again, the institution does not presently use them.

Kmail can do….A GOOD THING ...Kmail is READY…... ...WHEN the institution is "ready" to use them.

Kmail IS READY TO GO OUT OF THE BOX !! ...

but with the passkeyas….

The setting in Kmail is PRE-set to "on" so that

WHEN ONE TYPES AND SENDS AN E-mail…….

the institution server is "seeing" something coming in that is "encrypted" and rejects it with
"invalid d-bus reply from filter agent".
if it does not already use passkeys.

That kind of message is probably totally meaningless for many folks.

But, the VERY SIMPLE ... answer is simply to RESTART Akonadai.

AAAANNNNDDD JUST HOW MANY NEW OR EXPERIENCED USERS KNOW diddly about Akonadai?

AND...KDE does not want simple users to actually KNOW anything about using a terminal and definitely does not want users to know about "sudo".

However, the restart of Akonadai does not need sudo powers but STILL the terminal must be used!!

Kmail has the rest of it ready to go.

C) All of the "backend of" kmail works just fine, it will go to the institution and find the correct port and provide what kind of "login" is needed and it is presented.

D) So, to restate, GIVEN that the institution wants a person to use a client and will provide the particulars of what is needed then the user can simply enter the required information in fields that are now NOT LABLED using terms that apply to a "cloud" situation that uses Outlook.

The SAME would probably apply for some other type of groupware server which is proprietary.

In other words Tina or whatever would have their own "tina.tina . whatever."

Because of this...

IT IS SUGGESTED... that the user should be informed during setup that the institution should be contacted as to whether some kind of "passphrase"(this is more of a European useage than U.S. ) ) . and encryption is needed.

That is because Kmail's default is THAT IT IS REQUIRED ... and settings are preset that way.

In this particular case the writer did not know that in THE ABSOLUTE CUTTING EDGE NEON version of Kmail …..

there were settings that had to be TURNED OFF because the institution did not inform the user because the user DID NOT KNOW TO ASK.

NOTE THAT…..the writer did not know to ask and the institution did not know to tell the writer to turn such settings off….

IN OTHER WORDS……

“the world” has “moved beyond”…..”static do this and do that” and it will work…. It is now a DYNAMIC between the user and the institutions particular settings which have to be set within Kmail.

And, when they are set….it works!!
However, when the user ASKED then the IT person said..."oh yeah" turn that stuff off".

Now, part of this is "KDE erring on the side of safety” and that is fine!!

But the user, should, in this writers opinion, be INFORMED AT THE BEGINNING that the setting needs to be checked with the institution.

Otherwise...KDE erring on the side of safety is a BIG WASTE OF TIME for the UNinformed user...

Kmail WORKS ...it is just that the user NEEDS TO KNOW some really basic settings and what they will do as a default.

E) POSSIBLY...there could be an automagic situation to where Akonadai is reset when the d-bus message appears... or not, the code may be too complex or just not work...without competing with another part of the code...dunno...

or the user could be informed to use the command:
"Akonadai dictyl" restart

The writer will provide the complete output of terminal for the command in this writers situation:

Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QStr ing,QString,QString)
akonadi.collectionattributetable OK
akonadi.collectionmimetyperelation OK
akonadi.collectionpimitemrelation OK
akonadi.collectiontable OK
akonadi.flagtable OK
akonadi.mimetypetable OK
akonadi.parttable OK
akonadi.parttypetable OK
akonadi.pimitemflagrelation OK
akonadi.pimitemtable OK
akonadi.pimitemtagrelation OK
akonadi.relationtable OK
akonadi.relationtypetable OK
akonadi.resourcetable OK
akonadi.schemaversiontable OK
akonadi.tagattributetable OK
akonadi.tagremoteidresourcerelationtable OK
akonadi.tagtable OK
akonadi.tagtypetable OK
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QStr ing,QString,QString)
org.kde.pim.akonadiserver: "Cannot connect to agent instance with identifier 'akonadi_maildir_resource_0', error message: ''"
QDBusConnection: name 'org.freedesktop.Akonadi.Control' had owner '' but we thought it was ':1.214'

woodsmoke:~$ Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication.

+ + + + +

FOR SETUP...

here are the specific entries for various fields in Kmail which worked for this user:

RECEIVING

Account name the name of the institution such as "nameofinstitution.edu"
IMAP server: whatever.whatever.com
User name: users normal e-mail address
Password: the users password for the institution

Advanced: enable server side subscriptions

"Connections settings"... click the button: Autodetect and it will autodect the encryption, port and authentication.

SENDING

outgoing mail server:

smtp.office365.com
server requires authentication ticked
login is normal e-mail
password is normal password

Store SMTP password is ticked.

Advanced

use the Autodetection button and everything will be provided and NO CHANGES are needed.

SMTP setting --- neither box is ticked.

+ + + + + +

OF COURSE...the particular institution might use other than "login" and again, Kmail "should" find that. if it doesn't work then the user will have to contact the IT people.

So, for this user that is how it worked and it worked immediately.

+ + + + + +

The big picture here for this writer to transmit to the developers is:

For someone that needs to interact with a MS cloud outlook system there MIGHT BE...

a) a READ ME that first explains the above points

b) a change in the GUI ...for the receiving part of the GUI... the word "IMAP" might possibly be changed to IMAP/outlook or some such

Of course if a person is using NOT outlook but a proprietary business thing then the user should be made aware that "another" address than "whatever.whatever whatever" would be needed.

But, the LARGER point here is that the label "IMAP" and the box:

will accept something OTHER than IMAP but the USER does NOT KNOW that...

Possibly there could be a popup balloon with larger context.

And then IF THE ABOVE DOES NOT WORK...

The user should contact the institution to get the particular items to enter into the fields

But, the big picture is

Receiving...
The IMAP field will take an IMAP address AND the whatever address! YAY!!

so the entry should be something like "whatever,whatever, yada yada"

OR IT CAN BE

IMAP,institution name, yada...

AND

Sending..

in sending the input information STILL begins.. with the original "SMTP...whatever".

SO TO REPEAT ...Kmail DOES WORK IT DOES WORK!! YAY!

Signing keys and security.

The KDE posture is "safety first and user next" according to some developers, but for "most" people...

... this writer does not think that the average KDE users will be EXPERTS in all this...

... and, that some kind of notification should be made that the user should ask the IT people if a signing key is needed!!!

and if it is not then the user can safely tick the setting to off in the settings AND

... when the user is writing an e-mail the "lock" should APPEAR TO BE UNLOCKED otherwise one will get the d-bus message.

If the lock is not "opened" then the user should OPEN the lock to see if the e-mail will send.

If, of course, it does not work; then one is back at the beginning of this and should communicate with the institution.

And if the d-bus message appears then Akonadai MUST be restarted.

HOWEVER, HOWEVER, HOWEVER... AND HERE IS WHERE KMAIL HAS EVERYTHING CORRECT...

WHEN IT IS ONCE RESTARTED IT DOES NOT APPEAR TO HAVE AGAIN TO BE RESTARTED !!! V


I do not know if it would be possible for Kmail to be made "smart enough"... that it would pop a message that "Kmail is going to shut down and restart Akonadai and then restart" if the dbus message is received.

or...

possibly a warning label can be placed somewhere that if the dbus message appears then the user should restart Akonadai.

BUT...the user is THEN...going to have to KNOW HOW TO USE A TERMINAL...which right now appears to be verboten for KDE.

So...

Here is a serious question.

Would it be possible to have TWO(2) interfaces / GUIs?

One a "first time user" interface which has "irritating extra information or popups" and then when the user is experienced can "tick a button" to change to a "less verbose" interface which would be like the present one?

The “new” ‘first” would include the IMAP button, information about checking for whether passphrases are necessary and also how to use a terminal to restart Akonadai.

HOWEVER...KUDOS TO THE DEVELOPERS!!! Because….finally….. Kmail works with the new MS cloud outlook !!

woodthanksthedevssmoke