On Thu, August 17, 2006 09:29, Lars Kneschke wrote: > [EMAIL PROTECTED] schrieb: >>> Yes. That's my main concern. >>> >> >>It's not all that different to imapd having access to the whole db. >>Unless you have seperate DB's per user you can't have that layer. >>At some point you have to trust something ;-> > > A webbased application has stored the database connection string in > cleartext somewhere on the webserver. If you hack the webserver and get > the > sql connection setting you have access to the whole (imap)database. That's > really bad. > > If you access the imap server over the imap protocol, you need to have a > username/password. And if you get this somehow, you can still access only > one imap box(ignoring acl).
But if you hack the imap server, you again have the username/password for the dbmail database, so same situation. I'd think in general it's usually easier to get through web applications than something like an imap daemon, due to the track record of "web apps" in general and the relatively low level of tech knowledge required vs. exploiting buffer overflows in a compiled daemon, but both would have to be coded well to prevent these issues. > That's the main difference and my main concern. I'd be interested in what you come up with for a solution here. I've put just a little thought to this same scenario in the past, and came up with wanting to stick a proxy in between the client and sql server. Either something that can police the specific queries made or use some custom protocol to generate the query on the proxy (eg. client sends "folderlist [EMAIL PROTECTED]" and the proxy runs the sql for that and returns the results). The former would probably be easier to impliment, the latter would give more flexibility (eg. you could stick the session id in there, too, so the proxy can verify the owner of the session against a query to look up that account's mail, etc.). -- Jesse Norell Kentec Communications, Inc. [EMAIL PROTECTED]
