I see… Yes, do add the warning. :)
Related to this, the email server from which I migrated these users allows logins using any email address associated (via alias) with an account as the username.
I only had to rename the accounts in the first place because SurgeMail doesn't support this, AFAICS.
From a user perspective, this feature is very helpful. Users change their preference, e. g., switching fromHIDDEN@xample.com to johnHIDDEN@ample.com as the company grows. Adding an alias is the straightforward way to deal with that.
It's natural for the user to believe that their preferred email address will log them into their account.
Do you think you could add this? When a user requests a login, SurgeMail could simply try all aliases in turn. (I understand from your explanation that your auth mechanism wouldn't allow directly associating multiple usernames/aliases with a single password.)
Am 22.09.2013 um 23:00 schrieb surgemail-support <surgemailHIDDEN@firstname.lastname@example.org>:
> Hi, yes it's expected behaviour as the authent protocol we use doesn't have a rename operation and by design doesn't have any way to access the password there is no easy way for it to move the password. I'm adding a clear warning so others won't be caught out by this.
> tellmail add_userHIDDEN@xample.com password
> and then added aliases "johnHIDDEN@ample.com" via the web interface.
> Afterwards we discovered that some users were using the long form to login, so we decided to rename their accounts. Many had already had several GB of email migrated into them by then.
> I renamed each account through the web interface by first deleting the alias "johnHIDDEN@ample.com", then renaming the account HIDDEN@xample.com" to "email@example.com" (and waiting until the web interface reported success - apparently it copies the entire user mailbox on the server in the process?), and then adding HIDDEN@xample.com" as an alias.
> It turns out that none of the renamed users could login (bad username or password). Fortunately, having just performed the migration via imapsync, I had a canonical list of passwords and was able to set them back to their expected values, but otherwise this could have been quite inconvenient.
> Only the renamed users were affected, as I verified with a script by checking all logins against the canonical list. Neither the old login HIDDEN@xample.com) nor the new one (firstname.lastname@example.org) was accepted.
> Is this expected behavior? At the very least I would expect a warning that I need to re-enter the password.
> This is with SurgeMail 6.5a-1 (Solaris x64). I have MD5 passwords enabled, is that relevant?