[Tickets #8012] Re: IMAP Login Loging Fail Message

bugs at horde.org bugs at horde.org
Fri Feb 20 11:53:17 UTC 2009


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8012
------------------------------------------------------------------------------
  Ticket             | 8012
  Updated By         | jvelez at jedmailpr.com
  Summary            | IMAP Login Loging Fail Message
  Queue              | IMP
  Version            | 4.3.3
  Type               | Bug
  State              | Not A Bug
  Priority           | 3. High
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


jvelez at jedmailpr.com (2009-02-20 06:53) wrote:

> You are not understanding the protocol. What the text that you quoted
> means is that the client cannot sent the octets of the literal (i.e.
> the password) until the client receives the command continuation
> response (+) it does *not* mean that we cannot send a octet count to
> the server unsolicited.
>
> Further reading:
> 4.3.    String
>
>    A string is in one of two forms: either literal or quoted
>    string.  The literal form is the general form of string.  The
>    quoted string form is an alternative that avoids the overhead of
>    processing a literal at the cost of limitations of characters
>    which may be used.
>
>    A literal is a sequence of zero or more octets (including CR and
>    LF), prefix-quoted with an octet count in the form of an open
>    brace ("{"), the number of octets, close brace ("}"), and CRLF.
>    In the case of literals transmitted from server to client, the
>    CRLF is immediately followed by the octet data.  In the case of
>    literals transmitted from client to server, the client MUST wait
>    to receive a command continuation request (described later in
>    this document) before sending the octet data (and the remainder
>    of the command).
>
This is not about password only, is in general, check your client well  
it is sending the username in a clearly violation of what you had copy  
above "the client MUST wait
to receive a command continuation request (described later in
this document) before sending the octet data (and the remainder
of the command)"  Check the example again of the RFC, it is clearly  
explained. Well it had been a pleasure but I don't have too much time  
to deal with this. The fact is that I change the procedure of the log  
in process to comply with  the RFC example and now it works. Have a  
nice day.






More information about the bugs mailing list