GNOME Bugzilla – Bug 303346
imap adds wrong server name to login
Last modified: 2005-05-16 14:09:44 UTC
Distribution/Version: gentoo My login on that server is ooblick@mydomain.com (example domain - not real). However the imap server is hosted at imap.mydomain.com. In the "Receiving mail" setup box for that connection I have "host: imap.mydomain.com:993" (it is ssl) and "username: ooblick". Evolution then asks for the password for ooblick@imap.mydomain.com which fails as my username is ooblick@mydomain.com. So I changed the username to "ooblick@mydomain.com". Evolution now asks for the password for "ooblick@mydomain.com@imap.mydomain.com" which is even worse. Expected Behaviour: Evolution should not automatically add the "Host:" name from the imap setup the login. It should be up to me to have to add a domain if it is needed.
you're confused. you said yourself that your username is ooblick. your email address is ooblick@mydomain.com. the password dialog is not using your email address, it is using your username at (@) the host imap.mydomain.com there is no bug here.
That is plainly wrong. The user name should be what I enter, and not what what Evolution makes up for me. In this case Evolution is creating a username which doesn't work, and doesn't even make sense. You've given me no solution or work around to my problem, so this remains a bug.
In my mind the solution to this would be for the password dialog to ask for just the User field, and not try to append the hostname.
Adding keyword
evolution is not making up any user names. think of the prompt as saying the following (which it has already been changed to btw a month ago in CVS): Please enter your password for the user <username> on the host <hostname>: the only difference betwen the new prompt and the old prompt is that the old prompt had @ instead of " on the host " so, you see, the old prompt is just: Please enter your password for the user <username>@<hostname>: the username that it sends to the server to authenticate is just <username>, it doesn't do the @<hostname> concatenation when sending the user/pass to the server. it never did. there is no bug here.