Closed Bug 749413 Opened 12 years ago Closed 12 years ago

Delivery Status Notification does not work

Categories

(Thunderbird :: Message Compose Window, defect)

10 Branch
x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: etirta, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

Set DSN on the outgoing email via menu 'Options\Delivery Status Notification'.


Actual results:

The message header 'Return-Receipt-To' is absent, so the DSN does not work. In fact the message headers for email with & without DSN are exactly the same.


Expected results:

If the DSN is set, then the message header 'Return-Receipt-To' should be present to make DSN work.
Severity: normal → major
(In reply to Edoardo Tirtarahardja from comment #0)
This is not a bug. See bug 522882 and its comments.
(In reply to Hashem Masoud from comment #1)
> (In reply to Edoardo Tirtarahardja from comment #0)
> This is not a bug. See bug 522882 and its comments.

Hi Hashem,

You misunderstood. The Bug 522882 is about ''Options\Return Receipt' or in RFC term: 'Message Disposition Notification' (MDN), i.e. message header 'Disposition-Notification-To'.

The issue is here is 'Delivery Status Notification' (DSN), i.e. message header 'Return-Receipt-To'.

They are 2 different things. The MDN can be ignored by the recipient upon *reading* the message, while the DSN is supposedly responded  by the destination mail server.

Thunderbird does not even send the email with message header 'Return-Receipt-To'. In fact when I compare the message header of 2 exact test email, one with DSN set and other not, both headers are exactly the same. Meaning setting 'Options\Delivery Status Notification' doesn't seem to do *anything* in Thunderbird.

BR //Edo
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
(In reply to Hashem Masoud from comment #3)
> 
> *** This bug has been marked as a duplicate of bug 93085 ***

Hi Hashem,

The Bug 93085 was asking the DSN feature. In my understanding, the feature has been enabled since in TB3, even though lack of UI for preferences (except on demand request in compose window via 'Option\Delivery Status Notification', but one can set the desire setting via pref.js.

What I'm reporting is that the DSN feature is *not* working in TB10. Shouldn't this be a separate bug report?

Cheers //Edo
Return-Receipt-To is related to MDN (Return Receipts) - not DSN. 
AFAIK, DSN doesn't involve message headers, things happen on the SMTP protocol level.

WFM over here though, just tested.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
(In reply to Magnus Melin from comment #5)
> Return-Receipt-To is related to MDN (Return Receipts) - not DSN. 
> AFAIK, DSN doesn't involve message headers, things happen on the SMTP
> protocol level.
> 
> WFM over here though, just tested.

Are you sure???

As per RFC 3798, the MDN (normally known as Return Recipt, as when the recipient read the email) is using message header 'Disposition-Notification-To'. TB10 set this message header when 'Options\Return Receipt' is set.

And as per RFC 3464, at a glance it seems suggesting the DSN *may* using message header 'Return-Receipt-To'. The RFC indeed stated that the message header used in here is non-standard though.

However as in TB10, whether the 'Option\Delivery Status Notification' is set or not, it generated email the *exact* message header.

I probably need to read further exactly how DSN is performed, so far I just simply comparing the email header with DSN set using Outlook & TB10 (Outlook set message header 'Return-Receipt-To' and I get the delivery notification). Do you have RFCs related to this?
Yes. Return-Receipt-To is the non-standard version of MDNs (Disposition-Notification-To is the standard version, as per rfc 3798). 

DSN is RFC 3461 + RFC 3464. There is no guarantee DSNs will give results. DSN can be used together with DSN but they are completely separate.
Hi Magnus,

I've read RFC-DSN spec. and yes, you are correct. RFC mandated the DSN to be implemented in SMTP protocol level, i.e. NOTIFY parameter on RCPT TO command, etc.

So I took an IP trace with Wireshark to sniff how Thunderbird interact with Microsoft Exchange SMTP and it turned out my SMTP response to 'EHLO' does not contain '250-DSN'. My guess that when Thunderbird does see this '250-DSN' in EHLO response, it doesn't to DSN as per RFC 3461 simply because it can't assume the SMTP support this RFC DSN.

Once again, we are confronted with issue because Microsoft does not do what RFC says (why I'm not surprised). I don't know whether MS-DSN is implemented via their proprietary exchange protocol or by simply using the non-standard 'Return-Receipt-To' in the email header. Do you know Magnus? If this is the case, how likely Thunderbird is willing to add this header to make it work with the darn MS Exchange SMTP?

I really hate this ask this, but unfortunately MS Exchange is widely used :(.
Hi,

It seems the MS Exchange SMTP should support RFC DSN as per below.
http://technet.microsoft.com/en-us/library/dd535395%28v=exchg.80%29.aspx

It's just probably my company does not enable it.

Can you guys close this and set it to something like 'REJECTED-NOT A FAULT'. I can only set it to 'RESOLVED' and I don't think that will be a proper status in this case.

Thanks for the support and I'm sorry for the false alarm.

Cheers //Edo
sure, marking invalid, thx for the update.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → INVALID
See Also: → 1558193, 1269780
You need to log in before you can comment on or make changes to this bug.