382905 - IMAP Login sends illegal quote string during LOGIN

Status: RESOLVED DUPLICATE of bug 312593

(MailNews Core :: Networking: IMAP, defect)

Description

[Bill Hwang]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: version 2.0.0.0 (20070326)

Thunderbird sends user password as quote string during LOGIN command.
This will reject by Zimbra IMAP server as illegal quote string if user password contains 8-bit character

RFC3501 4.3 states that

...
..
A quoted string is a sequence of zero or more 7-bit characters,
   excluding CR and LF, with double quote (<">) characters at each
   end.

For example a password of 1é23é5, is sends to imap server as...

   0x0020:  5018 febc 1f69 0000 3320 6c6f 6769 6e20  P....i..3.login.
   0x0030:  2274 6573 7461 7574 6822 2022 31c3 a932  "testauth"."1..2
   0x0040:  33c3 a935 220d 0a                        3..5"..

See http://bugzilla.zimbra.com/show_bug.cgi?id=16669 for more information

Reproducible: Always

Steps to Reproduce:
1.Set some account with password that contains 8-bit character
2.Connect to Zimbra server using that account
3.
Actual Results:  
Log in failure

Expected Results:  
Log in successful

According to rfc3501, 4.3 password can be sent as literal..

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

Comment 1

[Nikolay Shopik]

can you test using latest trunk of TB?

Comment 2

[WADA:World Anti-bad-Duping Agency]

RFC 3501 says: ( http://www.faqs.org/rfcs/rfc3501.html )

> password        = astring
>   astring         = 1*ASTRING-CHAR / string
>     ASTRING-CHAR   = ATOM-CHAR / resp-specials
>       ATOM-CHAR       = <any CHAR except atom-specials>
>         atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards / quoted-specials / resp-specials
>           list-wildcards  = "%" / "*"
>           quoted-specials = DQUOTE / "\"
>           resp-specials   = "]"
>     string          = quoted / literal
>       quoted          = DQUOTE *QUOTED-CHAR DQUOTE
>       literal         = "{" number "}" CRLF *CHAR8 ; Number represents the number of CHAR8s
>         CHAR8           = %x01-ff ; any OCTET except NUL, %x00

> 1.2.    Conventions Used in This Document
>(snip)
>   Characters are 7-bit US-ASCII unless otherwise specified.  Other
>   character sets are indicated using a "CHARSET", as described in
>   [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
>   additional semantics in addition to defining character set; refer to
>   these documents for more detail.
> 4.3.    String
>(snip)
>  A quoted string is a sequence of zero or more 7-bit characters,
>  excluding CR and LF, with double quote (<">) characters at each end.

>Character of à :
> (Windows-1252) 0xc3
> (Unicode) Unicode Character 'LATIN CAPITAL LETTER A WITH TILDE' (U+00C3)
>   UTF-16 (hex) 0x00C3    (00c3)
>   UTF-8  (hex) 0xC3 0x83 (c383)
>   UTF-7        2b414d
> See following page for other binary representation of Ã
> http://www.fileformat.info/info/unicode/char/00c3/charset_support.htm

(1) Tb's violation.
(1-a) Tb sends 8bit binary greater than 0x7F with "quoted". 
      If the data is to be sent, it should be sent in "literal".
(1-b) Tb looks to blindly send binary of 0xc3 for typed character of "Ã".
      (windows-1252=CP1252 seems to be used. no range check seems to be done)
      Even if "literal" format data is used, there is no way to determine
      binary data to be sent for character of "Ã", because no character set
      information is provide by IMAP server. No one knows "which binary data is
      to be sent", except you and your IMAP server.
I think Tb should reject to send non 7bit-ascii string, until Bug 439046 will be implemented. 

(2) Server side violation, or your violation.
RFC 3501 doesn't define way to inform charset for password string, so your IMAP server doesn't(can't) inform charset to Thunderbird.
Even though the fact that RFC 3501 has no definition about password string other than 7bit-ascii, server(or you) uses non 7bit-ascii password string.

Please consider next situation.
 (1) On your MS Win with CP-1252 : "Ã" == 0x0c
 (2) On other OS with Unicode : "Ã" == 0xc383(UTF-8), 0x000c(utf-16), ...
When login to your IMAP server is executed by both OS'es, what binary shouls be sent?

Note-1:
This issue on mail folder name is already resolved by using modified UTF-7 for non 7bit-ascii folder name.
Note-2:
"Search" command already has capability to specify charset of search string.
Note-3:
Bug 439046 is enhancement request to support extension by RFC 5255.
RFC 5255 is very new. effective from June 2008. 
See http://www.faqs.org/rfcs/rfc5255.html

Comment 3

[Dan Karp]

Zimbra currently decodes non-ASCII password literals as UTF-8, which is the solution provided by RFC 5255.  That seems like the only reasonable solution given that the client charset and the server charset can't be correlated and that UTF-16 and UCS-2 have endian issues.

Comment 4

[Joshua Cranmer [:jcranmer]]

-> IMAP problem.

Comment 5

[Chris Newman]

It is a violation of RFC 3501 (IMAP) and RFC 1939 (POP) to send a username or password encoded in a charset other than US-ASCII, unless the SASL PLAIN mechanism ("AUTHENTICATE PLAIN" or "AUTH PLAIN") is used in which case UTF-8 encoding must be used.

Oracle Messaging Server (formerly Sun/iPlanet Messaging Server) is liberal in accepting non-ASCII characters in either atoms or quoted strings for the LOGIN and USER/PASS commands, but they must be UTF-8 encoded in order to interoperate with standards-compliant clients. In addition, the server uses LDAP simple bind to authenticate and RFC 4511 requires LDAP simple bind passwords to be UTF-8 encoded.

We're considering putting a workaround in our server for clients that violate the standard by using a password charset incompatible with UTF-8, such as Thunderbird, but this will create a lot of deployment complexities for the site administrator as they'll have to manually configure the same password charset at both the client and server in order for the server to be able to convert it to UTF-8 so it can comply with the LDAP standard. It would be much simpler for site administrators if Thunderbird simply complied with the standards.

Comment 6

[Chris Newman]

This bug might be considered a duplicate of bug 312593