[imp] imp 2.3.x vs TWIG

[andrew morgan]

On Sun, 28 Jan 2001, Anil Madhavapeddy wrote:

> > I don't want IMP to store passwords in a database permanently.  I realize
> > they are stored right now in the database temporarily while the user is
> > logged in, but it seems like a bad security decision to keep the password
> > in the database permanently (between logins).  Even if the password is
> > encrypted/encoded/hashed, it would be possible to recover the plaintext
> > password.
>
> Well, this depends on what kind of crypto strength you use, but it will
> be near-impossible to brute-force the attacks unless you also give them
> the decoding key, which shouldn't be stored in the database.

But the information has to be stored in an accessible manner so that it
can be used between sessions.  Even right now, IMP has to be storing your
IMAP password in the database in a recoverable fashion so that it can send
it everytime you load a new page.  It would have to do the same for the
new "horde" password which is used to decrypt the multiple passwords.
Ugh, I guess this new scheme is no more secure or insecure than the
current scheme, so I'll stop complaining.

> > I don't want to sound like the sky is falling, but I get worried when an
> > intermediate system wants to save my password.  Is it that hard for me to
> > type it in every time?
>
> The idea is that you only have one password, and that this password 'unlocks'
> your other passwords, such as IMAP server login, LDAP login, Calendar login,
> and so on.  The same trust principle is applied in public-key infrastructure
> or SSL, when you trust the root Certificate Authorities in your browser.

I understand that.  We are moving towards a single username and password
for central IS services at OSU, but this is occuring in the back-end
services themselves.

> > On a somewhat related note, I don't understand why you would want to make
> > several email accounts appear as one inbox.  If you really want them all
> > to be the same final destination, why not set each one to forward the mail
> > to a single account?  And if they are separate accounts, such as one for
> > business and one for personal, wouldn't you want those accounts to appear
> > separately in webmail?  I wouldn't want them mixed together in a single
> > inbox where the two purposes could be confused.
>
> This is admittedly a power-user feature, but not the prime purpose of the
> proxy.  The proxy's purpose, first and foremost, is to maintain a persistent
> IMAP connection, to get over the performance problems that webmail clients
> have.  It could also be useful in load-balancing large IMAP cluster farms.

How do you know when the connection should be closed?

> As for the feature itself - multiple IMAP accounts can't be forwarded to a
> single account, without losing the ability to access them separately (there's
> no two-way synchronisation of flags that I know of, although I'd love to hear
> of one).  The rewriting would be to be rewrite the folders to something
> like INBOX.Work.SubFolders and INBOX.Personal.SubFolders, for example.
>
> The mails would never mix in a single folder.  This particular is still
> somewhat unclear in my mind.  I'm just playing with it to see if it's viable;
> I might try to hack up a prototype using p5-Net::IMAP.

It seems to me that it would be better to copy the way other email clients
handle multiple accounts, such as Mozilla:

Work Account
 +--- INBOX
 +--- Sent-Mail
Home Account
 +--- INBOX
 +--- Sent-Mail

etc...

This would be simpler for the users because they are already familiar with
this style.  Also, it seems to me that this functionality should be in the
client, not the proxy.

	Andy