Giving users what they want and expect, IMAP edition
Like many places, we have an IMAP server (currently we're using Dovecot). This IMAP server is part of our overall Unix authentication environment, so users log in to their IMAP mailboxes using their Unix login and password (well, their general login name and password, since it's also used for Samba access, authentication with several web servers, and so on). More specifically, users log in to our IMAP server using just their Unix login; they do not use '<user>@<our domain>', as apparently is common at many places.
Well, that's the theory. In practice we get a trickle of users who try to use '<user>@<our domain>' with our IMAP server and then plaintively report problems, because from Dovecot's perspective (or more exactly PAM's), there's no such login 'whoever@us'. We had another one recently, and when I saw the email my first reaction was to think that our support site needed to have a clear 'don't do it this way' note about '<user>@<our domain>', since it keeps coming up. Then I took a step back and reminded myself that users are right, and specifically that if users are doing something naturally and on their own, user education almost never works very well. If some number of users were going to keep putting in our domain on their IMAP login credentials, the best and most friendly thing to do would be to quietly accept it anyway, even if it's not technically correct.
(In a sense refusing '<login>@<our domain>' is robot logic. We know (or can know) what was intended and it's completely unambiguous, it's just that our software doesn't recognize it.)
As far as I can see Dovecot doesn't give you any straightforward
way to strip off a specific domain from the login name that users
give you. However it does appear to be able to strip all domain
names off the login name, so you'll accept '<valid login>@<any
random thing>', not just '<login>@<your domain>' (this is allegedly
auth_username_format to, eg
%Ln). In our environment it's
probably okay to be so broadly accepting, so I'm going to propose
this to my co-workers and then perhaps we'll deal with the whole
issue once and for all.
(We should still update our documentation to be explicit here, but once we accept everything that documentation is just a backup. It's not crucial that people actually read it and notice that bit; as long as they're close, their IMAP access will work.)