Closed Bug 93085 Opened 22 years ago Closed 1 year ago

RFE:enable DSN return receipts on outgoing messages


(MailNews Core :: Networking: SMTP, enhancement)

Not set


(thunderbird_esr91 wontfix)

94 Branch
Tracking Status
thunderbird_esr91 --- wontfix


(Reporter:, Assigned: mkmelin)




(Whiteboard: [gs])


(6 files, 3 obsolete files)

DSN return receipt features on outgoing messages would be a great feature addition.

This is not exactly the same as Bug 16241, "Preferences Return Receipts item
lists are NOT enabled." That bug deals with MDN and DSN receipts on both
outgoing and incoming messages, so presumably requires much more work than DSN only.
Keywords: 4xp
Hardware: Macintosh → All
Ever confirmed: true
Summary: enable DSN return receipts on outgoing messages → RFE:enable DSN return receipts on outgoing messages
Blocks: 16241
No longer blocks: 16241
Any idea if this'll make 1.0?
*** Bug 127305 has been marked as a duplicate of this bug. ***
is there something new? I am missing this feature, too (at least here at work)
Wasn't this implemented in Mozilla RC 1 (see
QA Contact: esther → gchan
resolving as dup of 16241.  16241 does involve MDN and DSN, was more work, but
is rsolved fixed.  

*** This bug has been marked as a duplicate of 16241 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
How did 16241 fix both DSN and MDN?  I thought MDN was for "Read receipt" and 
DSN was "server processed message" receipt.  I have enabled "Request a receipt 
for all sent messages" in Preferences (Mozilla 1.0rc1, Mac OS X) and only get 
MDN read receipts.  
   Please check bug 139616.  I filed this bug for a case where the return 
receipt request is at a different location in the headers than the return 
receipt request in other programs (Outlook Express, etc.) causing some 
programs to not recognize the read receipt request.   This is probably for the 
support also for DSN receipts, but it doesn't work... I don't get DSN receipts 
at all and some senders whose e-mail client normally supports receipts don't 
get prompted to send the MDN read receipt as the software doesn't recognize 
the receipt request.
As far as I can tell, Mozilla added MDN return-receipt support with bug 16241
but does not yet have DSN return-receipt support. If this is incorrect, please
point us to more information on how to activate and use the DSN features.
Resolution: DUPLICATE → ---
You are correct this isn't a dupe of bug 16241 (that
bug implements MDN only)

Currently I don't believe there is bug out there about
enabling DSN (other than this one).

I do not know if or when we are planning to implement DSN part
so please be patient.

Reassigning bug.
Assignee: mscott → jt95070
As my understanding, we are not doing DSN at all. DSN is a server side feature
and the request were carried through the out of band channel. It can get lost
easily from one MTA to another. It's not as reliable as MDN can provide.
The only purpose of DSN receipts is to let a sender know when the recipient's 
server received the message.  This is not highly useful except for knowing if 
a message never even reached the recipient's server (which usually only occurs 
in a server error on your SMTP server). 
I personally find DSN more useful than MDN, because 

1) MDN is intrusive of the recipient's privacy
2) you get confirmation when the server receives the message, not when the
recipient reads their mail
3) not every mail client supports MDN

That said, why are you arguing against a feature that other people want? If you
don't want this feature, don't track this bug.
Good point (comment #12).  It is not that I don't want the feature, I just 
would not make it a top priority in Mail&Newsgroups with there being other 
bugs of higher impact to using the mail client. (However, there are 16 votes 
for this bug so maybe it should be a high priority!)  I'm definitely not 
against this fixing this... when it is implemented I'm sure I will request DSN 
receipts for outgoing messages along with MDN.   I did use that feature often 
in 4.7x (despite the fact that I would check mail and get 15 messages and find 
them all receipts!) Features present in 4.x shouldn't be left out of Mozilla 
5.x (Netscape 6.x).  
Summary: RFE:enable DSN return receipts on outgoing messages → MDN:RFE:enable DSN return receipts on outgoing messages
This is not an MDN bug. This bug is for DSN.
Summary: MDN:RFE:enable DSN return receipts on outgoing messages → RFE:enable DSN return receipts on outgoing messages
This feature is currently available by editing the mailnews.js preferences file.
 All that needs to be added is a UI for selecting "DSN", "MDN", or "Both".
This doesn't appear to work yet. I set the preference to request DSN, but
Mozilla still requests MDN only.
Please note that DSN is often used to have legal prove of the delivery of a
message. It gives the user a way to keep track of a message that was send,
without requiring a user to allow the MDN to be send.
Also, I think DSN gives a much more reliable report than MDN, because MDN
depends on the implementation of the client and it's preferences. So, often MDN
is either not implemented in the client, is disabled by the user or fails to be
send because of a configuration problem. Imho MDN is the rather useless feature
This was in Communicator 4.5. Now I have even seen some webmails to have both
types of receipts.

Shouldn't this be changed to the 'Return Receipts component'?
And what about the nsenterprise keyword?
There are 2 types of receipts:  Read Receipts which are triggered by the mail
client, and Delivery Status Notifications: which is a notice sent by the MTA
confirming DELIVERY of your message (or the last hop that supported DSN).

They are destinctly different.
Yes, I know. But aren't they used in the same way - inserting the appropriate
headers in the message? Therefore I thought they could be merged into Return
receipt component (better than mail back end). That isn't said to only apply to MDN.

Anyway, what does this invalidate on my comments?
adding URL for RFC 3461, Simple Mail Transfer Protocol (SMTP) Service Extension
for Delivery Status Notifications (DSNs)
Component: Mail Back End → Networking: SMTP
If there's an RFC for it, and we want to remain standard compliant then this
should definitely be implemented and lazy attitude to implementing it needs to
be overcome. As mentioned, there are webmails out there which feature it and moz
is better than that.
And of course, Outlook has it since 97 at least.
*** Bug 242872 has been marked as a duplicate of this bug. ***
*** Bug 265953 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 242072 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.5?
Flags: blocking-aviary2.0?
Flags: blocking-aviary2.0?
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.5?
Flags: blocking-aviary1.5-
Flags: blocking-thunderbird2?
This bug is a little weak on the technical details; anyone curious about what's involved should check out this material from bug 242072, "Support for NOTIFY parameter of the ESMTP RCPT command (RFC 3461)":

This enhancement would give us the ability to request Delivery Status
Notifications (DSN), known to Outlook users as "delivery receipts".

Before NOTIFY parameter can be used:
1. SMTP server must support ESMTP and DSNs for this to work.
2. Mozilla must EHLO to activate ESMTP extensions on the server.
    a) ...and check for "DSN" as a supported extension.

1. Should there be some notification to the user through the UI if the user's
   SMTP server doesn't support ESMTP or DSN?  Arguably a separate RFE.
2. Documentation in Help about this feature should point out that a DSN may
   not be forthcoming if a server doesn't support the feature.
We aren't going to block the release on this, but that shouldn't stop anyone from working on a patch and nominating that.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Keywords: helpwanted
A question about this feature: from this part of code  ,it seems that the code exists but it's not ready yet and the situation is this one from a long time.
What's exactly the problem to make this code working in the next releases?
Thanks, Paolo
Not sure, if it is right to add this wish to this bug (or if I should file a new one).
I'd like to see, that DSNs I receive (not only the delivery confirmations, but also DSN-encoded delivery failures, would bot be presented as mails, but that they will just trigger and indication on the mail I have sent.
I.e. I'd propose to add a visual indication on mails in the sent folder, that shows one of the following states of a mail: delivered, not yet delivered, delivery failed, or message passed non-DSN-supporting MTA.
As can be seen from the source snippet referenced in <a href="">comment #30</a>, this should be a very minor addition, at least in ESMTP mode (preferably with NOTIFY=SUCCESS,FAILURE,DELAY).

Also, Netscape 7.2 had that (mail.request.return_receipt value of 1 or 3)!
Update:  the line linked to in Comment 30 is no longer the start of the "unready" DSN code.  As of this comment, it's a bit farther down, here:

If looks like this would be *very* easy for an interested party to turn on and test -- I don't have a build environment, or I'd be compiling in hard-coded DSN support right now.

As it stands, it seems to depend on a conditional that tests for TestFlag(SMTP_EHLO_DSN_ENABLED).  I presume that in a fully-implemented version of this feature, SMTP_EHLO_DSN_ENABLED would be set by a checkbox in the prefs UI.
> As it stands, it seems to depend on a conditional that tests for
> TestFlag(SMTP_EHLO_DSN_ENABLED).  I presume that in a fully-implemented version
> of this feature, SMTP_EHLO_DSN_ENABLED would be set by a checkbox in the prefs
> UI.

I think SMTP_EHLO_DSN_ENABLED should get its value from a check of the server response to the EHLO command, which lists server capabilities. If the DSN flag is present, then the server announces DSN availability and the NOTIFY field can be used with the RCPT TO command.

This is actually also in place, but not enabled:

If including it is just about testing if it works, I might try building just to test that. For me moving to Thunderbird is currently only about this essential feature (ISP implemented involuntary outbound filtering with no notification for filtered messages, but supports DSN for SUCCESS).
I can look at porting this code so that it can be turned on...
Assignee: jt95070 → bienvenu
I'm afraid the comments that the DSN code is ready to be just turned on are premature. After compiling HEAD with 'export CPPFLAGS="-DUNREADY_CODE"', it spit this (VC8 for Win32):

"e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(615) : error C2065: 'CE_URL_S' : undeclared identifier
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(615) : error C2227: left of '->msg_pane' must point to class/struct/union/generic type
        type is ''unknown-type''
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(617) : error C2227: left of '->msg_pane' must point to class/struct/union/generic type
        type is ''unknown-type''
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(617) : error C3861: 'MSG_RequestForReturnReceipt': identifier not found
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(622) : error C2664: 'PR_snprintf' : cannot convert parameter 1 from 'nsCAutoString' to 'char *'
        No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(626) : error C3861: 'FE_Alert': identifier not found
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(626) : error C3861: 'XP_GetString': identifier not found
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(627) : error C2664: 'PR_snprintf' : cannot convert parameter 1 from 'nsCAutoString' to 'char *'
        No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(630) : error C2227: left of '->msg_pane' must point to class/struct/union/generic type
        type is ''unknown-type''
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(630) : error C3861: 'MSG_SendingMDNInProgress': identifier not found
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(632) : error C2664: 'PR_snprintf' : cannot convert parameter 1 from 'nsCAutoString' to 'char *'
        No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(636) : error C2664: 'PR_snprintf' : cannot convert parameter 1 from 'nsCAutoString' to 'char *'
        No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(1294) : error C2227: left of '->msg_pane' must point to class/struct/union/generic type
        type is ''unknown-type''
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(1295) : error C2227: left of '->msg_pane' must point to class/struct/union/generic type
        type is ''unknown-type''
e:/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp(1295) : error C3861: 'MSG_RequestForReturnReceipt': identifier not found"

I had to resort to the quick and dirty hack of hardcoding it by just changing line 1321
      buffer += ">";

This works for me.
I said the code needed to be ported before it could be turned on...
This is a start of a patch to turn this on - it has two big flaws, however: 

1. It ignores the user's turning on or off the MDN/DSN request from the compose window, and just always requests DSN if the receipt type pref specifies it. This info needs instead to get passed from the compose window compose fields in the smtp url. The patch demonstrates how to add and get/set a field in nsISmtpUrl.

2. It doesn't do the right thing with draft messages w.r.t. saving and restoring the mdn/dsn request type in the draft message.

If someone wants to fix these issues, using this patch as a starting point, that would be fine with me.
I was more than a little surprised here the other day I must say. I'm working partly as a computer consultant advising customers which software they should use. One customer regularly sends e-mails to a specific person who often denies having received the e-mails, and the case might end up in court. MDN's can be easily rejected by the user, but DSN's can't, and DSN's can be a nice supplement to other proof in court. Since I knew both Outlook and Netscape 4.8 supported DSN's I suggested the user installed ThunderBird 2 and configured it to request both types of receipts. It didn't even cross my mind that it might not support DSN's. I know not all ISP's supports DSN's, but some do, and for the cases where they do, DSN's might have an impact along with other proof in court (and out of court also of course). I don't have a suitable build environment right now, so I can't easily fix this myself, but it seems to me that implementing DSN support should be pretty easy. I really got a problem now recommending ThunderBird, when both Netscape 4.8 and several recent Outlook versions supports DSN's and ThunderBird does not. I discussed this a little with a few others, and I'm not the only one being surprised. Just for clearification: Except this issue, I like ThunderBird. Hope someone gets the time to fix this soon...
This patch implements the DSN functionnality (RFC2634 -

This patch is based on the sources THUNDERBIRD_2_0_0_0_RELEASE
and is been developped for the milimail project :
Eric, in general, that looks very nice. Some minor comments:

+      parm = MimeHeaders_get_parameter(draftInfo, "DSN", NULL, NULL);
+      fields->SetDSN(parm && !nsCRT::strcmp(parm, "1"));
+      PR_FREEIF(parm);
       parm = MimeHeaders_get_parameter(draftInfo, "uuencode", NULL, NULL);

That can be PR_Free(parm); PR_FREEIF is a macro that checks if parm is null (which isn't needed, because free does the same check) and also nulls out parm, which is also not needed since it gets assigned in the next line. 

+  if (useCustomPrefs && (useCustomPrefs.getAttribute("value") == "false")) {
+    requestAlways.setAttribute("disabled", "true");
+  }
+  else {
+    requestAlways.removeAttribute("disabled");
+  }

We try not to use extra braces when they're not needed, unless it makes the code easier to read. 

+  void SendMailMessageWithDSN(in nsIFileSpec aFilePath,
+                              in string aRecipients, 
+                              in nsIMsgIdentity aSenderIdentity,
+                              in string aPassword,
+                              in nsIUrlListener aUrlListener, 
+                              in nsIMsgStatusFeedback aStatusListener, 
+                              in nsIInterfaceRequestor aNotificationCallbacks,
+                              out nsIURI aURL,
+                              out nsIRequest aRequest,
+                              in boolean requestDSN);

When you add a method to an interface, or change a method, you need to generate a new uuid for the interface (in this case, nsISmtpService.)

Generally, we try to make our out params the last params. And, instead of making the method void, it's better style to make it return something useful - this makes it much more convenient for js callers. In this case, I'd have it return the nsIURI. I realize you're doing what other methods in this interface do, but  this is a very old interface and our style has evolved since then.

+NS_IMETHODIMP nsMsgCompFields::GetDSN(PRBool *_retval)
+  *_retval = m_DSN;
+  return NS_OK;
Here you should add an NS_ENSURE_ARG_POINTER(_retval)

There are a few things about the patch that are not good for the trunk, as opposed to the 2.0 branch, because of changes going on on the trunk with respect to making Thunderbird running with xul runner. These mostly involve using nsIFile instead of nsIFileSpec, and not using nsXPIDLStrings or nsCRT:: anymore.
Attached patch DSN patch 0.2 (obsolete) — Splinter Review
Work in Progress patch v0.2 : 

Changes since v0.1:
* include David's comments
Attachment #269863 - Attachment is obsolete: true
Attachment #270013 - Attachment description: DSN patch → DSN patch 0.2
I have a question about the parameter ENVID : for this parameter we kept the value we found in the old sources : ENVID=NS40112696JT
Do you think this value is appropriate ? Otherwise what should we use ?
For me, the RFC is not very clear on this point ...

From my reading of the RFC, I think we'd want something unique for each message, which to me sounds very much like the message-id. Perhaps we could re-use that? Or re-use the code that generates the message-id. The envid is limited to 100 chars, which should be OK, and I think the ENVID allows all the characters that are allowed in message-id's, except for "+" and "=" (not sure if those are allowed in message-ids).
Attached patch DSN patch 0.3 (obsolete) — Splinter Review
Work in Progress patch v0.3 : 

Changes since v0.2:
* Rebuild the patch against the trunk
* Generate a unique value for the ENVID parameter
Attachment #270013 - Attachment is obsolete: true
Attachment #275421 - Flags: review?(bienvenu)
great, thx, Eric. One comment, and I'm not sure how to fix this, but the method SendMailMessageWithDSN is a bit oddly named - the name implies the message will have a DSN, but it just has an argument that says whether to request a DSN.

I realize you don't want to change the other callers of SendMailMessage, but I think it might be a little less confusing if SendMailMessageWithDSN always requested a DSN, and you change the call site to call the appropriate function, depending on whether DSN is requested.
Attached patch DSN patch 0.4Splinter Review
Work in Progress patch v0.4 :

Changes since v0.3:
* Removed function SendMailMessageWithDSN
* Updated function SendMailMessage to take requestDSN as an argument
Attachment #275421 - Attachment is obsolete: true
Attachment #275421 - Flags: review?(bienvenu)
Attachment #275784 - Flags: review?(bienvenu)
I'm thinking we'd like most of this patch, but probably not the account settings and prefs UI, at least for now, since I'm not sure it warrants a whole pane in the account settings. I'm going to try to come up with a patch that does that.
actually, maybe I should just try the patch - did you hide the dsn settings in an advanced pane?
No the settings are not hidden, since you need it to try the patch.
Maybe you can integrate this, and then hide what you want by simply hidding the elements in the XUL files.
we'd much rather just not include the xul files in the TB build, if they're not going to be used by default. Avoid bloat, etc. It should be possible to have them in CVS, and turn them on just by adding dsn to the extensions built...I'm looking into that.
I've built and run with this patch - I can't really test it, because my SMTP server doesn't support DSN (I'm really curious how many do...), but the only change it makes to the UI is a compose window options menu item to request DSN.

I think once we land this, we could land the DSN extension stuff, that adds the prefs and account mgr ui, but not build it by default.
Attachment #281195 - Flags: superreview?(mscott)
Attachment #281195 - Flags: review+
Good news David, 

For your information, 
Milimail Team runs DSN feature with postfix 2.3 wich support DSN.

David, you say you're curious how many SMTP servers supports DSN. At least I can say that Telenor, one of the largest ISP's in Norway, supports it. I'm also pretty sure that Active24 (also in Norway), hosting a lot of webpages/mail-systems, supports it. Don't know which platforms they are on, though.

Netscape Communicator 4.8 (very old) supports requesting both DSN and MDN, so I really hope someone can fix this in Mozilla/ThunderBird, so that people don't need to use old Netscape 4.8 or Microsoft Outlook to be able to request DSN's. Some people wants this functionality, and I don't like having to tell them that they can't use ThunderBird if they want that. Netscape 4.8 is practically unusable today because of it's html parsing not being compatible with many of todays e-mails, so the only alternative I know of is Microsoft Outlook for the users wanting DSN support.

I'm not very familiar with the Mozilla/Thunderbird development process. If someone implements nice and stable DSN support, will it be integrated into the released and precompiled versions - and who decides about that? And what is the timeframe that I can hope on from someone has made a nice and good implementation of this and until the precompiled released versions include it?
David, also the 5 biggest ISPs in Finland all support DSN, TeliaSonera is probably using Critical Path Memova (their server only announces version numbers), Elisa, MBnet and Welho are using Postfix, DNA is using CommuniGate Pro.

In my correspondence with users of both consumer ISP and corporate email systems in all continents, it appears to me that DSN is better supported in Europe and East Asia (Far East) by the receiving systems compared to the rest of the world and also better supported by corporate systems than consumer ISPs. The fact that MS supports it is a big plus in proliferation. 

IMHO DSN is a very important feature and one of those things that can be very successfully used to combat the decreasing reliability of email due to over strict spam/malware filtering and the reduction of value by overall impression of email as being unreliable and not transparent enough about the technical process of delivery.
Attachment #281195 - Flags: superreview?(mscott) → superreview+
Patch landed on the trunk, which means this will be in the next major release of Thunderbird. It's not going to be in a 2.0x security release, for the usual reasons: it's not a security fix, it changes interfaces, and it adds strings, which would require redoing translations.
thx very much for the patch, Eric, and thx for your patience.
BTW: when could this appear in Seamonkey? I'm quite confused with the parallel versioning of SM and TB (and I guess I'm not alone).
Milimail Team (Eric Ballet BAZ and Olivier PARNIERE) thank you, David, for accepting our contribution.

The Seamonkey folks will need to decide if they want to add this to their UI - right now, it's just in TB.
I've landed the various UI files as well, but they're not built by default. With a little work, we could make this configurable with .mozconfig.
Blocks: TB2SM
Comment on attachment 275784 [details] [diff] [review]
DSN patch 0.4

clearing request - the latter patch was checked in...
Attachment #275784 - Flags: review?(bienvenu)
QA Contact: grylchan → networking.smtp
(In reply to comment #49)

> I'm thinking we'd like most of this patch, but probably not the account
> settings and prefs UI, at least for now, since I'm not sure it warrants a whole
> pane in the account settings. {...}

David, what about adding the DSN UI along with the return receipts UI? Or do you have another idea? What form of UI would be acceptable?
(In reply to comment #62)

> I've landed the various UI files as well, but they're not built by default.
> With a little work, we could make this configurable with .mozconfig.

David, I've been studying what's really been checked in and (compared to the patch in attachment #275784 [details] [diff] [review]) I think you omited the file


This file is, however, being referenced from here:

Is this intentional or a mistake?
Flags: wanted-thunderbird3?
Will this be integrated in Thunderbird 3? That would be very nice so that regular users can get it, and not just the ones who can compile their own versions. For some users, it might be important when choosing between Thunderbird and other clients.
Yes it's already available in tb3 alpha1 "shredder".
Keywords: helpwanted
marking - for the remaining part of putting the UI in. The backend is already in.
Flags: wanted-thunderbird3? → wanted-thunderbird3-
Though do we really want/need more UI options for this? We do have the basic UI for sending them out. (The proposed ones are in
I'm not inclined to add the other ui options myself.
We need to work on the UI if this is to get in.  I'm a bit unsure that most people would actually know what a DSN is.

I feel like this should be integrated into the Return Receipt UI.  I understand they are actually different systems, however I feel like most people could understand a return receipt and we could display DSN as a different type of receipt that is non-invasive.
The pull-down menu "Options" already contains toggle "Return Receipt" which has to be split into two options now. The best way is IMHO creating another level of menu, which would have toggles named "On delivery (DSN)" and "On read (MDN)". Ideally, it should be possible to set their initial states somewhere in preferences.
What about "From Server (DSN)" and "From Client (MDN)"?
That seems like the correct breakdown, I just wouldn't reveal the words "Client" and "Server" in the UI as they are often not understood; I like how Petr made it more about the consequences.  

Maybe something closer to:
On Delivery (message arrived successfully)
On Reading (requires permission from receiver)
Will this functionality be integrated into the public build of ThunderBird 3? And when is ThunderBird 3 expected? It would be very nice if it comes in ThunderBird 3, as I think this is important functionality for many people (who are not all able to build their own version) :-)
Yes - in tb3 you'll find the option for in in the composition window, under Options. Try the beta:
Product: Core → MailNews Core
For those (like me before I spent too long looking at the broken and unbuilt UI that's checked in, for what I think was actually the second time now) who are having trouble figuring out what prefs UI we're talking about here:

There are two classes of prefs for dsn:

Global prefs:

* mail.dsn.always_request_on - whether to request DSN for every mail instead of just when you choose it from the compose menu

* mail.dsn.request_on_success_on, request_on_failure_on, request_on_delay_on, request_never_on - whether you want your DSN requests to ask to be notified when the mail is delivered, when it can't be delivered, when it's delayed, or never (a doubly-tricky thing, because it should disable the other three and because it's totally unexpected that you can drill down through all these prefs about requesting notifications, and eventually come to a pref that will get you fewer notifications than just never requesting notifications would)

* mail.dsn.ret_full_on - whether to request that the entire mail be sent back to you with the status notification

Per-identity prefs:

* mail.identity.%identitykey%.dsn_use_custom_prefs - whether to use the value of mail.dsn.always_request_on, or a per-identity pref for whether to always request

* mail.identity.%identitykey%.dsn_always_request_on - whether to always request, if dsn_use_custom_prefs is true

The unbuildable UI that's checked in, for which we have made localizers translate about 90% of the strings (only a few are completely missing, though several are in the wrong file), implements those as a dialog that would be triggered from a button in Tb's prefs,

| Ask notification on :                                                    |
|                                                                          |
| [ ] Success in delivering                                                |
| [ ] Failure in delivering                                                |
| [ ] Delay in delivering                                                  |
|                                                                          |
| ------------------------------------------------------------------------ |
|                                                                          |
| [ ] When sending messages, always request a Delivery Status Notification |
|                                                                          |
| ------------------------------------------------------------------------ |
|                                                                          |
| [ ] Never receive Delivery Status Notification                           |
|                                                                          |
| ------------------------------------------------------------------------ |
|                                                                          |
| (Missing string about "when you get a dsn")                              |
|   ( ) (Missing string about "get the full mail back")                    |
|   ( ) (Missing string about "get just the headers back")                 |

and a per-server account manager pane (which, if it does in fact work, only allows changing the per-identity prefs for the server's default identity)

| Delivery Status Notification                                               |
|                                                                            |
| ( ) Use my global Delivery Status Notification preferences for this account|
| ( ) Customize Delivery Status Notification for this account                |
|                                                                            |
|    [ ] When sending messages, always request a Delivery Status Notification|

which as noted above should be combined with the return receipt account manager pane, and as not noted above is misimplemented, since for per-identity prefs you are supposed to have both an account manager pane that configs the default identity (like the Copies and Folders, Composition & Addressing, and Security panes), and an overlay for the identity editor that lets you config each identity.

What I didn't realize before really looking at this is that the two are utterly separate. It would be a touch weird to have the per-identity UI talking about "use my (hidden) global pref" without UI for the global pref, but the other way around, the global UI without per-identity UI, would be perfectly reasonable, and only requires a string and a button in the advanced prefs pane. Oh, and removing all the existing strings and starting over, since having had 52 blind localizations over the last two years, without letting the localizers see what they were actually doing, means we can't now use those strings without any way of saying "oh, that stuff you translated in September 2007? now you need to look at whether you really said what you meant to say!"
Yet another bite from the unfortunate fact that you can't land strings without jarring them and have that mean "don't localize me yet."
Attachment #379641 - Flags: review?(bienvenu)
Attachment #379641 - Flags: review?(bienvenu) → review+
Attachment #379641 - Attachment description: Step one, remove unusable strings → Step one, remove unusable strings [checked in]
unassigning so someone may be tempted to drive in some sort of UI for this (or build an extension).
Assignee: bienvenu → nobody
I've just wrote an add-on for Thunderbird 3 in order to provide user interface settings for the DSN backend.

There are global settings in "Preferences" window and a per-account override (only for the default identity as for now) for the "always request DSN" option.

You can find screenshots and download it from the Trustedbird project:

All comments are welcome!
Get Satisfaction topic inquired regarding DSN capability; directed to extension.  GSfn "short URL" not placed in URL field, because the field was already occupied.
Whiteboard: [gs]
As well as exposing at least the global mail.dsn settings in a UI, they should also be documented better somewhere.  This bug report (comment 77 by Phil) is the only place I could find them on the web.
Duplicate of this bug: 749413
No longer blocks: TB2SM

More or less dead code for the last 20yrs.

Assignee: nobody → mkmelin+mozilla

Pushed by
remove last traces of account specific DSN UI. r=Paenglab

Closed: 21 years ago1 year ago
Resolution: --- → FIXED
Pushed by
followup - remove comm/mailnews/extensions/dsn/dsn.js from lintpref.yml. rs=me DONTBUILD
Resolution: FIXED → WONTFIX
Target Milestone: --- → 94 Branch

@mkmelin, I'm confused. You WONTFIX it for the 94 Branch?

I marked it wontfix for everything. Almost all the code was gone (from earlier patches in this bug), to the extent there was ever anything implemented. The patch landed just cleared out the remains of the code that was never hooked up to anything.

You need to log in before you can comment on or make changes to this bug.