Bug#474605: Bug#473572: iceape: After upgrade unable send mail

[Mike Hommey]

forwarded 474605 https://bugzilla.mozilla.org/show_bug.cgi?id=419116
thanks

On Tue, Apr 15, 2008 at 06:00:27PM -0300, Anthony Donegan wrote:
>
>
> Mike Hommey wrote:
>> On Mon, Mar 31, 2008 at 02:33:41PM +0200, Daniel Smolik wrote:
>>   
>>> Package: iceape
>>> Version: 1.0.13~pre080323b-0etch1
>>> Severity: important
>>>
>>> After upgrade to latest package from secutity iceape-mail is unable send
>>> mail. After press Send button alert is displayed "Unable to connect SMTP
>>> server ..." SMTP server is OK only downgrade iceape package solve problem.
>>>     
>>
>> I tried on both x86 and amd64 and couldn't reproduce the issue :(
>>
>> Does it work better with a new profile ? Is there some useful message in
>> the error console (Tools -> Web Development -> Error Console) ?
>>
>> Mike
>>
>>   
> I think that the treatment of Outgoing SMTP servers which have no  
> usernames is indeed broken by the iceape-mailnews security patch.
>
> A workaround which works on my system:
>
> 1. Open the browser with "iceape -browser about:config".
> 2. Filter "smtp".
> 3. Check "mail.smtp.defaultserver" is "smtp1".
> 4. Set "mail.smtpserver.smtp1.auth_method" to 0.
> 5. Right click on "mail.smtpserver.smtp1.username" and select Reset.

Thanks to these informations, I finally was able to reproduce the bug
and find the problem.

The following patch is responsible for the regression:
--- iceape-1.0.12~pre080131b/netwerk/base/src/nsURLParsers.cpp  2004-11-07 21:43:38.000000000 +0100
+++ iceape-1.0.13~pre080323b/netwerk/base/src/nsURLParsers.cpp  2008-03-24 17:27:59.000000000 +0100
@@ -531,9 +531,16 @@
     if (userinfoLen < 0)
         userinfoLen = strlen(userinfo);
 
+    if (userinfoLen == 0)
+        return NS_ERROR_MALFORMED_URI;
+
     const char *p = (const char *) memchr(userinfo, ':', userinfoLen);
     if (p) {
         // userinfo = <username:password>
+        if (p == userinfo) {
+            // must have a username!
+            return NS_ERROR_MALFORMED_URI;
+        }
         SET_RESULT(username, 0, p - userinfo);
         SET_RESULT(password, p - userinfo + 1, userinfoLen - (p - userinfo + 1));
     }

Why? Because in some (strange) configurations, the smtp url construction
leads to (broken) urls in the form: smtp://@host:25/
In such an url is rejected by the new code.

Finding the responsible patch also allowed to find the fix and the
associated bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=419116

Mike