815638 - Delivery Status Notification (DSN) does not work using Send Later

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Alexander Bergmann]

The Delivery Status Notification (DSN) does not work using "File -> Send Later" (Message Compose Window of Thunderbird) and "File -> Send Unsent messages" (Main Window of Thunderbird).

Create a new message and select "Options -> Delivery Status Notification". Sending the message using "File -> Send Now" works fine and I receive a Delivery Status Notification (DSN).

Create a new message and select "Options -> Delivery Status Notification". Sending the message using "File -> Send Later" and "File -> Send Unsent Messages" works fine, but I do not receive a Delivery Status Notification (DSN).

However, the source code of the saved message in the Outbox ("Local Folders -> Outbox") looks good:
> X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=1; uuencode=0

Comment 1

[Pavel Tuma]

I confirm this bug in Thunderbird 24.1.0.

Comment 2

[Pavel Tuma]

I observe also this symptom:

Delivery Status Notification (DSN) [mail.dsn.always_request_on;true] doesn't work when send in background is enabled [mailnews.sendInBackground;true].

Comment 3

[Anje]

Using Windows Vista, confirm this occurs in TB version 24.5.0
Setting DSN and using 'Send Later'

Tested between my husbands account and mine, also between my website email address and my main email address, so this was not an email sent to myself.
Source code from message in Outbox:
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=1; uuencode=0

'Return Receipt' was not selected in this test, only DSN.

Same test sent using 'Send' resulted in a DSN delivery notice email.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Pavel Tuma from comment #2)
> I observe also this symptom:
> 
> Delivery Status Notification (DSN) [mail.dsn.always_request_on;true] doesn't
> work when send in background is enabled [mailnews.sendInBackground;true].

Anje, could you confirm if DSN with send later only fails when [mailnews.sendInBackground;true]?

Comment 5

[Anje]

TB version 31.0
set: mailnews.sendInBackground; true
created email and select options > Delivery Status Notification
File > 'Send later'
this was inserted in the Message Source of outgoing mail.
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=1; uuencode=0; attachmentreminder=0

email sent from main account to my website mail account.
Received and read email but no receipt of DSN notification.

Also tried:
set: mailnews.sendInBackground; false

Also tested using Return Receipt and DSN

Tested using the File > Send Later
email sent from main account to my husbands mail account.
Received and read email but no receipt of DSN notification.

Return Receipt email did ask if I wanted to acknowledge.

Nothing received as DSN and i did wait.
I also checked that nothing was on the server.

Comment 6

[David E. Ross]

Windows 7 Ultimate (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
Protocols:  POP3 and SMTP

Using Thunderbird in Safe Mode, I sent a test message from my primary E-mail account an an ISP to another of my E-mail accounts at another ISP.  The E-mail addresses for the sending and receiving accounts are quite different.  In sending the message, I selected [Options > Delivery Status Notification] on the compose window's menu bar but not [Options > Return Receipt].  The message was sent immediately, not "Send Later".  I then repeated this test in the opposite direction.  

I examined the sources of the received messages in both accounts and cannot find any header field that reflects the request for Delivery Status Notification.  Either the Delivery Status Notification capability is non-functional in Thunderbird, or else the indicator for that capability is obscure.

Comment 7

[Alexander Bergmann]

This bug is still affecting Thunderbird 60.9.0 and Thunderbird 68.1.1.

Comment 8

[Wayne Mery (:wsmwk)]

perhaps the cause for this is related to bug 1299430 (even though the symptoms are different)

Comment 9

[Alexander Bergmann]

I just confirmed the bug is still affecting Thunderbird 115.

Comment 11

[betterbird.project+10]

X-Mozilla-Draft-Info should be picked up here
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/nsMsgSendLater.cpp#902
and not ignored. From it some member variables should be filled, like these:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/nsMsgSendLater.h#119-135
From those, the respective comp fields should be set here:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/nsMsgSendLater.cpp#487-501
These attributes should be set from the values picked up at the first reference:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/public/nsIMsgCompFields.idl#43-45

Comment 12

[betterbird.project+10]

https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/815638-fix-DSN-send-later.patch
Some code copied from
https://searchfox.org/comm-central/rev/21588270aceb832666e89f418002087e30123892/mailnews/mime/src/mimedrft.cpp#1331-1347

Comment 13

[Silvia Bonavista i Serrat]

Attachment: Bug 815638 - Fix DSN for send later. r=mkmelin

Based on https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/815638-fix-DSN-send-later.patch

Depends on D204152

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d177d69029eb
Fix DSN for send later. r=mkmelin

Comment 15

[Jonathan Kamens]

Attachment: tb128-smtp-log.txt

This does not appear to be fixed in 128.0esr.

See the attached SMTP log from sending two messages.

The first was sent directly and the second was sent with File -> Send Later followed by File -> Send Unsent Messages.

In both cases I sent the Delivery Status Notification flag on the message before sending it.

I got a delivery status notification message from the direct send and not from the message sent through the Outbox.

If you look at the SMTP log you can see that it's not requesting a DSN for the second message delivery.

I checked the message in the Outbox before doing File -> Send Unsent Messages and it had DSN=1 in the header.

I do want to comment that Alexander Bergmann recently emailed me and claimed that this was working for him: " I have also run a few tests and the Delivery Status Notification is now working as expected with Thunderbird 128, i.e.: When first creating the message in the Outbox and then doing a manual delivery via "File -> Send Unsent Messages", I get a DSN from my email provider now. (This did not work - and still does not work - with Thunderbird 115.)"

This is not the behavior I am seeing. I don't know why he's seeing different behavior from mine.

Comment 16

[[e-mail]]

We provided the patch for this, and as far as we can tell, this is working in 128 (115 was a wontfix, see above). We sent a message through the Outbox and got a read receipt on the receiving side. Sadly we lost the only server that would provide DSN, so we can't re-test this part now. However, read receipts were equally broken before and the work now. We regularly use Mr. Bergmann's "Mail Merge" via the Outbox and get read receipts from some of the recipients.

If you look at the SMTP log you can see that it's not requesting a DSN for the second message delivery.

Where in the log do you see that for directly sent messages, we can't see this being logged.

A few things to keep in mind:

1. If you send a message to yourself, TB doesn't display the read receipt request, you need at least two accounts to test this.
2. Very few servers actually provide DSN.

Comment 17

[Wayne Mery (:wsmwk)]

I have reopened Jonathan's bug 1852413.

Comment 18

[Jonathan Kamens]

(In reply to Wayne Mery (:wsmwk) from comment #17)

I have reopened Jonathan's bug 1852413.

I don't understand why. As far as I can tell nothing has changed; 1852413 is still a duplicate of this bug, and from my testing this bug isn't completely resolved.

Comment 19

[Jonathan Kamens]

(In reply to [e-mail] from comment #16)

We provided the patch for this, and as far as we can tell, this is working in 128 (115 was a wontfix, see above). We sent a message through the Outbox and got a read receipt on the receiving side.

I already acknowledged in my comment that the fix is working for some people. That is not in dispute. What is in dispute is the assertion that it is completely fixed, because from my experience (with evidence provided to prove it) it is not.

Sadly we lost the only server that would provide DSN, so we can't re-test this part now.

If you need an account on a server that does DSN in order to test this then I can provide you with one.

If you look at the SMTP log you can see that it's not requesting a DSN for the second message delivery.

Where in the log do you see that for directly sent messages, we can't see this being logged.

First message (sent directly):

22:57:33.104 mailnews.smtp: C: RCPT TO:<[e-mail]> NOTIFY=SUCCESS,FAILURE,DELAY SmtpClient.sys.mjs:679:19

Second message (sent through Outbox):

22:57:48.399 mailnews.smtp: C: RCPT TO:<[e-mail]> SmtpClient.sys.mjs:679:19

A few things to keep in mind:

1. If you send a message to yourself, TB doesn't display the read receipt request, you need at least two accounts to test this.

I am not talking about read receipt, I am talking about DSN, and in my experience DSN works fine when I am the recipient of the message. Having said that, I also tested it with another email address as the recipient and observed the same behavior.

2. Very few servers actually provide DSN.

...which is not relevant to this discussion, because as I said I was able to make DSNs work sending directly but not through the Outbox, and I attached the log to prove it.

Comment 20

[Jonathan Kamens]

*sigh* This morning I am no longer able to reproduce this issue, and I can't explain what's different about this morning from last night, so I suppose I'm just going to have to close the other ticket that was reopened and I'll reopen again if I am able to reproduce again.