863569 - Unable to send return receipt (Qmail rejects "bare LF" in MDN / return receipt generated by Tb)

Status: UNCONFIRMED

(Thunderbird :: Untriaged, defect)

Description

[don_vaughn]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

Clicked "Send return receipt" upon receiving an email.  I am using an imap server.


Actual results:

Thunderbird displayed the error message:

An error occurred while sending mail. The mail server responded:  See http://pobox.com/~djb/docs/smtplf.html.. Please check the message and try again.


Expected results:

Receipt email should have been sent.

Comment 1

[WADA:World Anti-bad-Duping Agency]

(In reply to don_vaughn from comment #0)
> An error occurred while sending mail. The mail server responded:  See
> http://pobox.com/~djb/docs/smtplf.html.. Please check the message and try again.

(a) The pointed web page is for "bare LF line" = [LF] only line.
    I looks Qmail's SMTP doesn't permit "bare LF". 
(b) Return receipt sent by Tb is as follows.
    MDNPart3.txt is message header of original mail.
> Content-Type: multipart/report; report-type=disposition-notification;
>	boundary="BoundaryLine"
>
> --BoundaryLine
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This is a Return Receipt for the mail that you sent to [e-mail].
>
> Note: This Return Receipt only acknowledges that the message was displayed on the recipient's computer. There is no guarantee that the recipient has read or understood the message contents.
>
> --BoundaryLine
> Content-Type: message/disposition-notification; name="MDNPart2.txt"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
>
> Reporting-UA: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Thunderbird/23.0a1
> Final-Recipient: rfc822;[e-mail]
> Original-Message-ID: <[e-mail]>
> Disposition: manual-action/MDN-sent-manually; displayed
>
> --BoundaryLine
> Content-Type: text/rfc822-headers; name="MDNPart3.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> <Message header lines of original mails are placed as-is here>
> --BoundaryLine--

Tb perhaps puts message header of original mail as-is in MDNPart3.txt part, because it's return receipt.
i.e. 
(c) The "bare LF" comes from riginal mail sender or SMTP servers used for mail transmission, and your IMAP server passed through it to your  Thunderbird.
(d) Your IMAP server generated the "bare LF" and passed it to your Thunderbird.

(Q1) Can you attach original mail?
(1) Create IMAP folder, call FolderX, with Offlne-Use=Off
    (Folder Properties/Synchronization)
(2) Copy the mail to FolderX, "Repair Folder"
(3) At FolderX, save the mail to .eml file.
(4) With keeping original line ending in data of .eml file.
    edit .eml file, and remove/replace private data.
    "Sakura Editor" is free software who supports "keep line ending".
(5) Attach mail data to this bug(never paste, because line ending is relevant) 

(Q2) When did your problem start to occur? After upgrade of Tb?

(Q3) Does your proble occur on any mail received by the IMAP account?
     Or specific mail only problem?
     Or problem on mail from specific sender only?

Comment 2

[WADA:World Anti-bad-Duping Agency]

Following is bugs which contains "bare LF" in bug summary.
> bug 166172 FIXED dolog.pl sends bare LFs
> bug 301010 ---   Error during IMAP copy: message contains bare newlines
>     (MS Exchange returns stand-alone LF in mail data, and Cyrus rejects it)
> bug 534885 ---   UTF-8 encoding of return address inserts bare LF in the stream, breaking RFC822

(Q4) So typical, MS Exchange relevant problem like bug 301010?
(Q5) Or problem like bug 534885? "(bare LF in To: of return receipt)
     If so, where does the LF come from?
     Tb generated it?
     Or LF comes from From: header of original mail?

Because Qmail's SMTP serer rejects "bare LF", check with other SMTP server who doesn't reject "bare LF". Gmail's SMTP server may not reject "bare LF".

Comment 3

[WADA:World Anti-bad-Duping Agency]

Correction.
To: of return receipt comes from Disposition-Notification-To: header.
Rule out "bare LF in orignal Subject: or isposition-Notification-To: case, please.
 
If same problem as bug 534885(it looks inserted new line==OS line ending), I think "CR" should be inserted on Mac.
Is "OS line ending" LF on Mac OS X too because Mac OS X is internally *nix?

Comment 4

[WADA:World Anti-bad-Duping Agency]

setting dependency to bug 534885 for ease of tracking/analysis/search.

Comment 5

[Wayne Mery (:wsmwk)]

Can we just dup this to bug 534885?