Closed
Bug 93085
Opened 23 years ago
Closed 3 years ago
RFE:enable DSN return receipts on outgoing messages
Categories
(MailNews Core :: Networking: SMTP, enhancement)
MailNews Core
Networking: SMTP
Tracking
(thunderbird_esr91 wontfix)
RESOLVED
WONTFIX
94 Branch
Tracking | Status | |
---|---|---|
thunderbird_esr91 | --- | wontfix |
People
(Reporter: mozilla.org, Assigned: mkmelin)
References
()
Details
(Whiteboard: [gs])
Attachments
(6 files, 3 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/zip
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Bienvenu
:
review+
mscott
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Bienvenu
:
review+
|
Details | Diff | Splinter Review |
(deleted),
text/x-phabricator-request
|
Details |
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: enable DSN return receipts on outgoing messages → RFE:enable DSN return receipts on outgoing messages
Comment 1•23 years ago
|
||
Any idea if this'll make 1.0?
Comment 2•23 years ago
|
||
*** 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)
Comment 4•23 years ago
|
||
Wasn't this implemented in Mozilla RC 1 (see
http://www.mozilla.org/releases/mozilla1.0/)?
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 7•23 years ago
|
||
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.
Status: VERIFIED → REOPENED
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
Status: REOPENED → NEW
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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).
Reporter | ||
Comment 12•23 years ago
|
||
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•23 years ago
|
||
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).
Updated•23 years ago
|
Summary: RFE:enable DSN return receipts on outgoing messages → MDN:RFE:enable DSN return receipts on outgoing messages
Reporter | ||
Comment 14•22 years ago
|
||
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
Comment 15•22 years ago
|
||
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".
Reporter | ||
Comment 16•22 years ago
|
||
This doesn't appear to work yet. I set the preference to request DSN, but
Mozilla still requests MDN only.
Comment 17•22 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
And what about the nsenterprise keyword?
Comment 20•21 years ago
|
||
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•21 years ago
|
||
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?
Reporter | ||
Comment 22•21 years ago
|
||
adding URL for RFC 3461, Simple Mail Transfer Protocol (SMTP) Service Extension
for Delivery Status Notifications (DSNs)
Comment 23•21 years ago
|
||
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•21 years ago
|
||
And of course, Outlook has it since 97 at least.
Comment 25•21 years ago
|
||
*** Bug 242872 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
*** Bug 265953 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Reporter | ||
Comment 27•19 years ago
|
||
*** Bug 242072 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.5?
Flags: blocking-aviary1.5-
Comment 28•19 years ago
|
||
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•19 years ago
|
||
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
Comment 30•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
> 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•18 years ago
|
||
I can look at porting this code so that it can be turned on...
Assignee: jt95070 → bienvenu
Comment 36•18 years ago
|
||
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•18 years ago
|
||
I said the code needed to be ported before it could be turned on...
Comment 38•18 years ago
|
||
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•18 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Comment 42•17 years ago
|
||
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•17 years ago
|
||
Work in Progress patch v0.2 :
Changes since v0.1:
* include David's comments
Attachment #269863 -
Attachment is obsolete: true
Updated•17 years ago
|
Attachment #270013 -
Attachment description: DSN patch → DSN patch 0.2
Comment 44•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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
Updated•17 years ago
|
Attachment #275421 -
Flags: review?(bienvenu)
Comment 47•17 years ago
|
||
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•17 years ago
|
||
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)
Comment 49•17 years ago
|
||
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•17 years ago
|
||
actually, maybe I should just try the patch - did you hide the dsn settings in an advanced pane?
Comment 51•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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+
Comment 54•17 years ago
|
||
Good news David,
For your information,
Milimail Team runs DSN feature with postfix 2.3 wich support DSN.
Comment 55•17 years ago
|
||
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•17 years ago
|
||
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.
Updated•17 years ago
|
Attachment #281195 -
Flags: superreview?(mscott) → superreview+
Comment 57•17 years ago
|
||
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•17 years ago
|
||
thx very much for the patch, Eric, and thx for your patience.
Comment 59•17 years ago
|
||
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•17 years ago
|
||
Milimail Team (Eric Ballet BAZ and Olivier PARNIERE) thank you, David, for accepting our contribution.
Comment 61•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Comment on attachment 275784 [details] [diff] [review]
DSN patch 0.4
clearing request - the latter patch was checked in...
Attachment #275784 -
Flags: review?(bienvenu)
Assignee | ||
Updated•17 years ago
|
QA Contact: grylchan → networking.smtp
Comment 64•17 years ago
|
||
(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•17 years ago
|
||
(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?
Updated•17 years ago
|
Flags: wanted-thunderbird3?
Comment 66•17 years ago
|
||
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.
Assignee | ||
Comment 67•17 years ago
|
||
Yes it's already available in tb3 alpha1 "shredder".
Keywords: helpwanted
Comment 68•16 years ago
|
||
marking - for the remaining part of putting the UI in. The backend is already in.
https://wiki.mozilla.org/Thunderbird:Release_Driving
Flags: wanted-thunderbird3? → wanted-thunderbird3-
Assignee | ||
Comment 69•16 years ago
|
||
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•16 years ago
|
||
I'm not inclined to add the other ui options myself.
Comment 71•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
What about "From Server (DSN)" and "From Client (MDN)"?
Comment 74•16 years ago
|
||
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•16 years ago
|
||
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) :-)
Assignee | ||
Comment 76•16 years ago
|
||
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/
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 77•16 years ago
|
||
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•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #379641 -
Flags: review?(bienvenu) → review+
Updated•16 years ago
|
Attachment #379641 -
Attachment description: Step one, remove unusable strings → Step one, remove unusable strings [checked in]
Comment 79•16 years ago
|
||
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•15 years ago
|
||
unassigning so someone may be tempted to drive in some sort of UI for this (or build an extension).
Assignee: bienvenu → nobody
Comment 81•15 years ago
|
||
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•14 years ago
|
||
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.
Whiteboard: [gs]
Comment 83•13 years ago
|
||
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.
Assignee | ||
Comment 85•3 years ago
|
||
More or less dead code for the last 20yrs.
Updated•3 years ago
|
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Comment 86•3 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/3a39ad26fbff
remove last traces of account specific DSN UI. r=Paenglab
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 3 years ago
Resolution: --- → FIXED
Comment 87•3 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/79bb13d4e400
followup - remove comm/mailnews/extensions/dsn/dsn.js from lintpref.yml. rs=me DONTBUILD
Assignee | ||
Updated•3 years ago
|
Comment 88•3 years ago
|
||
@mkmelin, I'm confused. You WONTFIX it for the 94 Branch?
Assignee | ||
Comment 89•3 years ago
|
||
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.
Description
•