On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Wed, Mar 26, 2008 at 10:29 PM, Bernd Fondermann > <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 26, 2008 at 11:01 PM, Robert Burrell Donkin > > <[EMAIL PROTECTED]> wrote: > > > wondering what measures are wise to take to secure IMAP when running > live over > > > the internet. IMAP is an old fashioned protocol and is insecure by > > > design. i'd like to try running JAMES IMAP live @ ApacheCon EU from a > > > server in the UK but i want to think about security first. i have a > > > few questions but would appreciate it if people jump in with general > > > advice even if it's not covered by the questions. > > > > > > IMAP is not a secure protocol. running securely means deviating from > > > the specification. AIUI JAMES ships with standard configurations which > > > are specification compliant. > > > > being unsecure puts the integrity of the server and the user's data at > > risk. so it is no good to be spec compliant whenever security is > > converned. > > true > > being compliant is important when running over a LAN. perhaps the TLS > configuration could be secure but commented out... > > > > > it seems a little foolish to allow an untrusted client to try > > > arbitrary input against the complexity of the fully featured parser > > > before logging in. perhaps a secure encoder could be used before the > > > client has logged on. > > > > right. in the best case, only a reduced range of inputs is considered > > by the server during handshake. this is what I tried in Apache Vysper. > > this should not reduce spec compliance. > > how did you approach this problem from a design perspective? > > (i've been turning over the idea of using a optional wrapper for the > initial handshake)
the parser is 'abstract' and only identifies command boundaries. every handler receives a full representation of the command text. only then comes interpretation into play. but before the command handler can kick in, a processor checks if the command is valid for the current state of the session. this effectively guards from execution of unauthorized code. Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
