93085 - RFE:enable DSN return receipts on outgoing messages

Status: RESOLVED WONTFIX

(MailNews Core :: Networking: SMTP, enhancement)

Description

[J Luh]

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.

Comment 1

[Dave Petrie]

Any idea if this'll make 1.0?

Comment 2

[Jonas Jørgensen]

*** Bug 127305 has been marked as a duplicate of this bug. ***

Comment 3

[Olaf]

is there something new? I am missing this feature, too (at least here at work)

Comment 4

[Ansgar Schrage]

Wasn't this implemented in Mozilla RC 1 (see
http://www.mozilla.org/releases/mozilla1.0/)?

Comment 5

[esther]

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 ***

Comment 6

[esther]

verified

Comment 7

[Joel Nelson (don't send email)]

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.

Comment 8

[J Luh]

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.

Comment 9

[grylchan]

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.

Comment 10

[Jeff Tsai]

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.

Comment 11

[Joel Nelson (don't send email)]

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). 

Comment 12

[J Luh]

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.

Comment 13

[Joel Nelson (don't send email)]

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).  

Comment 14

[J Luh]

This is not an MDN bug. This bug is for DSN.

Comment 15

[Joel Nelson (don't send email)]

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".

Comment 16

[J Luh]

This doesn't appear to work yet. I set the preference to request DSN, but
Mozilla still requests MDN only.

Comment 17

[Don van der Haghen]

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
here.

Comment 18

[:aceman]

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'?

Comment 19

[:aceman]

And what about the nsenterprise keyword?

Comment 20

[Dave Petrie]

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.

Comment 21

[:aceman]

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?

Comment 22

[J Luh]

adding URL for RFC 3461, Simple Mail Transfer Protocol (SMTP) Service Extension
for Delivery Status Notifications (DSNs)

Comment 23

[(address does not accept unsolicited mail)]

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.

Comment 24

[:aceman]

And of course, Outlook has it since 97 at least.

Comment 25

[Scott MacGregor]

*** Bug 242872 has been marked as a duplicate of this bug. ***

Comment 26

[Jo Hermans]

*** Bug 265953 has been marked as a duplicate of this bug. ***

Comment 27

[J Luh]

*** Bug 242072 has been marked as a duplicate of this bug. ***

Comment 28

[Eric S. Smith]

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.

Considerations:
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.

Comment 29

[Scott MacGregor]

We aren't going to block the release on this, but that shouldn't stop anyone from working on a patch and nominating that.

Comment 30

[intendentedelleacque]

A question about this feature: from this part of code http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/src/nsSmtpProtocol.cpp#1251  ,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

Comment 31

[Matthias Wimmer]

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.

Comment 32

[Red_Blue]

As can be seen from the source snippet referenced in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=93085#c30">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)!

Comment 33

[Eric S. Smith]

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:

http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/src/nsSmtpProtocol.cpp#1292

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.

Comment 34

[Red_Blue]

> 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:
http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/src/nsSmtpProtocol.cpp#731

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).

Comment 35

[David :Bienvenu]

I can look at porting this code so that it can be turned on...

Comment 36

[Red_Blue]

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
http://lxr.mozilla.org/mailnews/source/mailnews/compose/src/nsSmtpProtocol.cpp#1321
      buffer += ">";
 to
      buffer += "> NOTIFY=SUCCESS,FAILURE,DELAY";

This works for me.

Comment 37

[David :Bienvenu]

I said the code needed to be ported before it could be turned on...

Comment 38

[David :Bienvenu]

Attachment: start of a patch to turn this 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.

Comment 39

[Tonny Iversen]

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...

Comment 40

[BALLET BAZ Eric]

Attachment: This patch implements the DSN functionnality

This patch implements the DSN functionnality (RFC2634 - http://tools.ietf.org/html/rfc3461)

This patch is based on the sources THUNDERBIRD_2_0_0_0_RELEASE
and is been developped for the milimail project :
http://www.milimail.org/milimail/index.php/Dsn_user

Comment 41

[BALLET BAZ Eric]

Attachment: Screenshots showing the modified UI screens

Comment 42

[David :Bienvenu]

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.

Comment 43

[BALLET BAZ Eric]

Attachment: DSN patch 0.2

Work in Progress patch v0.2 : 

Changes since v0.1:
* include David's comments

Comment 44

[BALLET BAZ Eric]

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 ...

Thanks

Comment 45

[David :Bienvenu]

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).

Comment 46

[BALLET BAZ Eric]

Attachment: DSN patch 0.3

Work in Progress patch v0.3 : 

Changes since v0.2:
* Rebuild the patch against the trunk
* Generate a unique value for the ENVID parameter

Comment 47

[David :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.

Comment 48

[BALLET BAZ Eric]

Attachment: DSN patch 0.4

Work in Progress patch v0.4 :

Changes since v0.3:
* Removed function SendMailMessageWithDSN
* Updated function SendMailMessage to take requestDSN as an argument

Comment 49

[David :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.

Comment 50

[David :Bienvenu]

actually, maybe I should just try the patch - did you hide the dsn settings in an advanced pane?

Comment 51

[BALLET BAZ Eric]

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.

Comment 52

[David :Bienvenu]

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.

Comment 53

[David :Bienvenu]

Attachment: subset of previous patch, without prefs and account mgr ui

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.

Comment 54

[Olivier PARNIERE]

Good news David, 

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

Comment 55

[Tonny Iversen]

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?

Comment 56

[Red_Blue]

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.

Comment 57

[David :Bienvenu]

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.

Comment 58

[David :Bienvenu]

thx very much for the patch, Eric, and thx for your patience.

Comment 59

[Petr Cerny [:hrosik]]

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).

Comment 60

[Olivier PARNIERE]

Milimail Team (Eric Ballet BAZ and Olivier PARNIERE) thank you, David, for accepting our contribution.

Comment 61

[David :Bienvenu]

The Seamonkey folks will need to decide if they want to add this to their UI - right now, it's just in TB.

Comment 62

[David :Bienvenu]

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.

Comment 63

[David :Bienvenu]

Comment on attachment 275784 [details] [diff] [review]
DSN patch 0.4

clearing request - the latter patch was checked in...

Comment 64

[Jiri TRAVNICEK [:JITR]]

(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?

Comment 65

[Jiri TRAVNICEK [:JITR]]

(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

   mail/locales/en-US/chrome/messenger/preferences/dsn.dtd

This file is, however, being referenced from here:

   http://mxr.mozilla.org/mozilla/source/mail/components/preferences/dsn.xul#44

Is this intentional or a mistake?

Comment 66

[Tonny Iversen]

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.

Comment 67

[Magnus Melin [:mkmelin]]

Yes it's already available in tb3 alpha1 "shredder".

Comment 68

[David :Bienvenu]

marking - for the remaining part of putting the UI in. The backend is already in.
https://wiki.mozilla.org/Thunderbird:Release_Driving

Comment 69

[Magnus Melin [:mkmelin]]

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 https://bugzilla.mozilla.org/attachment.cgi?id=269864)

Comment 70

[David :Bienvenu]

I'm not inclined to add the other ui options myself.

Comment 71

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 72

[Petr Cerny [:hrosik]]

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.

Comment 73

[Arya Irani]

What about "From Server (DSN)" and "From Client (MDN)"?

Comment 74

[Bryan Clark (DevTools PM) [:clarkbw]]

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)

Comment 75

[Tonny Iversen]

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) :-)

Comment 76

[Magnus Melin [:mkmelin]]

Yes - in tb3 you'll find the option for in in the composition window, under Options. Try the beta: http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

Comment 77

[Phil Ringnalda (:philor)]

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!"

Comment 78

[Phil Ringnalda (:philor)]

Attachment: Step one, remove unusable strings [checked in]

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."

Comment 79

[Phil Ringnalda (:philor)]

Comment on attachment 379641 [details] [diff] [review]
Step one, remove unusable strings [checked in]

http://build.mozillamessaging.com/mercurial/comm-central/rev/afd0a576e796

Comment 80

[David :Bienvenu]

unassigning so someone may be tempted to drive in some sort of UI for this (or build an extension).

Comment 81

[Raphaël Fairise]

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:
http://www.trustedbird.org/tb/DSN_Settings

All comments are welcome!

Comment 82

[Michael A. Pasek]

Get Satisfaction topic http://gsfn.us/t/1cnm2 inquired regarding DSN capability; directed to extension.  GSfn "short URL" not placed in URL field, because the field was already occupied.

Comment 83

[Cedric Knight]

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.

Comment 85

[Magnus Melin [:mkmelin]]

Attachment: Bug 93085 - remove last traces of account specific DSN UI. r=Paenglab

More or less dead code for the last 20yrs.

Comment 86

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3a39ad26fbff
remove last traces of account specific DSN UI. r=Paenglab

Comment 87

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/79bb13d4e400
followup - remove comm/mailnews/extensions/dsn/dsn.js from lintpref.yml. rs=me DONTBUILD

Comment 88

[Mason]

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

Comment 89

[Magnus Melin [:mkmelin]]

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.