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 "firstname.lastname@domain.com" 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.

Mmmh... I think it is more generally discussed in bug 195965 :-) *** This bug has been marked as a duplicate of 195965 ***

v