[imp] imp 2.3.x vs TWIG

[Anil Madhavapeddy]

Quoting andrew morgan <morgan@orst.edu>:

> Am I the lone voice of dissent on this issue?

Not at all!  Remember all this will be strictly optional.

> 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.

> I suppose you also tell your browser to save your password in forms?

No, because this breaks the premise that you enter a passphrase to unlock
your data.

> 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.

> 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.

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.

-- 
Anil Madhavapeddy, <anil@recoil.org>