It's simple really, and can affect both the appearance of security and actual security.
------------------------------------------------------------------------
Subject:
Re: [courier-users] RE: distinct namespace with userdb ? (Feature Request)
From:
Gordon Messmer <[EMAIL PROTECTED]>
Date:
Sun, 09 Nov 2003 09:56:02 -0800
To:
[EMAIL PROTECTED]
Jerome Bullert wrote:
The conflict is between the frontend and backend needs:
1. Courier and the auth systems need "[EMAIL PROTECTED]" to properly identify the account.
2. For both usability *and security*, the end user needs to be able to enter a username of "user" and still have the account identified correctly.
Elaborate, please. I don't see how users entering their username sans domain is a security feature.
Most mail users are not used to entering the fully qualified email address as the "username", when they've been taught that the "username" is that portion of the email address before the "@" sign, and the server name is that portion after the "@" sign. This is reinforced by support teams, sign-in instructions, and FAQs from AOL to Yahoo to Netscape Mail to workplace systems and so on. This is what users are taught.
(And they're certainly not familiar with the concept of multiple mail servers on the same system, all with overlapping usernames. It would probably just scare them if they did know.)
Therefore we have to expect, no matter what detailed instructions they receive, that many users, given the email address "[EMAIL PROTECTED]", are going to enter "john" as the username. Although this is *technically* a user error, it is *effectively* the same as telling the user to sign into "wrong-domain.com" as the user "john". The result is the same.
We've removed a layer of separation within the system, resulting in a lower level of security. This is not something that we would normally allow to happen.
Under this scenario, the best case is that "[EMAIL PROTECTED]" repeatedly enters a wrong password against the account of "[EMAIL PROTECTED]", possibly locking the latter user out of his account. When "[EMAIL PROTECTED]" finds that he has been locked out of his account because somebody has entered multiple wrong passwords (... that somebody "has been trying to break into my email"...), this results in a lower perceived level of security. Not to mention a poor experience for this locked out user and an increase in support time and costs getting both users back onto the right path.
We can tell ourselves that the chance of "[EMAIL PROTECTED]" successfully entering the password of "[EMAIL PROTECTED]" is remote, but it's probably not as remote as we'd like to think. In this scenario, since we know that both "right-domain.com" and "wrong-domain.com" are serviced by the same mail system:
-Odds that they service the same geographical area (or business type, or personal interest, etc) = High
-Odds that these users live in/are connected to the same area ( or business type, or personal interest, etc.) = High
As a result, the odds that these users could have the same password = Increased exponentially
-Whether it's the local high school, college, or pro football team, their favorite stock symbol, favorite porn star, etc.
(We all know how the average user excels at selecting secure passwords.)
Result = a lower level of security
What you're saying is that, even though I configure my email client to connect to "domain.com" (or "mail.domain.com"), the IMAP and POP servers don't know that *they are* "domain.com" (or "mail.domain.com"). Is this correct?The solution is in the middleware:
-The IMAP, POP, and Webmail servers could include functionality such that, if a user submits the username "user" to the server name "domain.com", the username is submitted to the authsystem, and subsequently Courier, as "[EMAIL PROTECTED]".
A fine idea, if Courier had any idea what domain those users were connecting to. None of the SMTP, POP, or IMAP protocols include a domain handshake.
As an example, SquirrelMail currently has at least one plugin available that will add this functionality, allowing the user to enter a username of "user", but submitting the username into the system as "[EMAIL PROTECTED]" based on the domain through which the user is accessing.
HTTP has a domain handshake. When you request a page, it usually looks something like:
GET /index.html HTTP/1.1 Host: www.example.com
That domain specification is available to php and CGI programs that run under the web server.
So, what do you say Sam? What would it take to add this functionality to the IMAP, POP, and SqWebMail servers?
SqWebMail could do it, but IMAP and POP would require a protocol re-write. Good luck.
My apologies if this is a stupid question. I'm not a mail expert (yet). But I am a Support expert that knows how users behave in the real world. And I know that a single "level of separation" can result in a major increase or decrease in both usability and support time/costs.
And I also know what it's like to answer the call from the user who unexpectedly saw the inside of another user's mailbox. It's not fun.
-- Jerome Bullert [EMAIL PROTECTED] -----------------------------
P.S.: Sorry for the extra post with the bad subject. My bad.
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
