194057 - Send mail fails if extra header is present and qmail is the SMTP server

Status: VERIFIED DUPLICATE of bug 195965

(MailNews Core :: Composition, defect)

Description

[Maurice Galland]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Sending of mail fails when using extra header defined in the user.js preferences
file when qmail 1.03 is the SMTP server. It happens with different headers and
different values of header, using offical binary builds of Mozilla 1.2.1 on
Linux or Win2k.

Reproducible: Always

Steps to Reproduce:
Client workstation: RedHat Linux 7.3 or Windows 2000 SP2
Mozilla build: regular Mozilla 1.2.1 binary build (see User-Agent above)
SMTP server: RedHat Linux 6.1 running qmail 1.03

1. Create a "user.js" personal preferences file in your profile if you don't
already have one.
2. Add the line:
user_pref("mail.compose.other.header", "X-FAX-Dialstring");
3. Save the file.
4. Restart Mozilla, open MailNews and click "Compose".
5. Send a mail to yourself, using the new header:
X-FAX-Dialstring: 5551234
6. Click "Send"

Actual Results:  
An alert box appears, with the message:

"An error occured while sending mail. The mail server responded: See
http://pobox.com/~djb/docs/smtplf.html.

. Please check the message and try again."


Expected Results:  
The mail should have been sent.

The intended purpose is to use HylaFAX (www.hylafax.org) as a mail2fax gateway,
and the recipient fax number can be extracted by HylaFAX from the mail header.

The problem is not related to the header itself nor its value. I tried with the
example described here:
http://www.mozilla.org/mailnews/arch/compose/hiddenprefs.html
A custom header like "Approved" with a value of a real mail address like
"[e-mail]" exhibits the same behaviour.

The message displayed in the alert box is a typical qmail complaint about a bare
LF in the message, which is a RFC822bis section 2.3 violation :-(

I guess the problem is in the chrome here:
mailnews/compose/resources/content/addressingWidgetOverlay.js

It is still present in the code as shown by LXR:
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/addressingWidgetOverlay.js#171

I think the line 171:
case "addr_other"       : addrOther +=
awGetPopupElement(i).selectedItem.getAttribute("label") + " " + fieldValue +
"\n";break;
should read:
case "addr_other"       : addrOther +=
awGetPopupElement(i).selectedItem.getAttribute("label") + " " + fieldValue +
"\r\n";break;
where "\n" becomes "\r\n".

I tested this solution on my regular 1.2.1 binary build, unjarring and rejarring
messenger.jar and the problem disappeared! :-)

But I have no idea on the consequences on other mailers, as I only use qmail.

Comment 1

[Maurice Galland]

Mmmh... I think it is more generally discussed in bug 195965 :-)

*** This bug has been marked as a duplicate of 195965 ***

Comment 2

[Vedran Miletic]

v