Closed
Bug 135486
Opened 24 years ago
Closed 22 years ago
MDN: Disposition Notification header in a mesg that's posted to a Newsgroup
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla1.0
People
(Reporter: grylchan, Assigned: jt95070)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
1.70 KB,
patch
|
Bienvenu
:
review+
|
Details | Diff | Splinter Review |
Noticed this with 4-2 commercial trunk builds.
If you post to a newsgroup and you have return receipts on.
If you look at the headers (all) of the mesg you posted on
the newsgroup you will see:
Disposition-Notification-To:
Gary Chan <gchan@netscape.com>
This happens also in latest 4.x builds. So this bug has been
there a while. If you don't have return receipts on, the
disposition notification header isn't in the header.
Steps to reproduce:
1.Read a newsgroup
2.Make sure you have either global/individual pref for
Return Receipts on
3Post a mesg to the newsgroup
4.Go to the newsgroup and read the mesg you just posted
5.Change View|Headers|ALL
result: you will see in the header:
Disposition-Notification-to: g<g@email.com>
Expected: that header to not be there.
Adding Jeff's comment link which said for me to open this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=16241#c184
The logical place to fix the problem seems to be in nsMsgProtocol::PostMessage().
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
We only do the special case comparison for message headers only. So, the
performance hit shouldn't be too bad.
Adding Scott and David for review and considering for nsbeta1...
Comment 4•24 years ago
|
||
A couple of questions.
1. Just to reconfirm, but 4.x does the same?
2. When someone reads one of these messages in a newsgroup, will we return the
receipt? If that message gets moved to a mail folder and someone uses it, will
we return it?
Yes, 4.x does the same. No return receipt will be generated if the message were
read from the newsgroup. Messages with request for return receipt copied from
newsgroups to local mail folder or imap mail folder whether read or unread shall
not generate return receipt, both 4.x and current build work fine. I guess, this
bug can be categorized as nice to fix since it touches the very touchy
nsMsgProtocol::PostMessage() method. :-)
Do we consider fixing this in RTM? This make us more conforming to the RFC standard.
Comment 7•23 years ago
|
||
Let's get this into the trunk. I think we can pass on this for rtm.
Comment 9•23 years ago
|
||
is this what 4.x did? strip out the mdn request when posting to news? It seems
OK, but as you say, it's a touchy method.
| Reporter | ||
Comment 10•23 years ago
|
||
4.x left the 'disposition notification to' header in a mesg posted
to a newsgroup. So I guess we weren't doing it properly in 4.x
either..
Comment 11•23 years ago
|
||
Comment on attachment 78302 [details] [diff] [review]
Patch ready for review
r=bienvenu
Attachment #78302 -
Flags: review+
Comment 12•23 years ago
|
||
In some other mail clients (for ex. The Bat!) user can notified is his mail
delivired to remote mail server. Why it's future hasn't in Mozilla Mail ?
just need to add in menu that option and in mail header
"Disposition-Notification-To: sender_mail" row.
Comment 13•22 years ago
|
||
Client: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030521
Thunderbird/0.1a
If a newsgroup-posting with an 'Disposition-Notification-To'-header is
displayed in Thunderbird, Thunderbird asks for sending an MDN. If answered with
YES, it realy send an MDN to the sender of that post. I don't think this is
correct.
Comment 14•22 years ago
|
||
Michael: this bug is about sending messages to newsgroups, not about reading them.
This is now WFM. With trunk-build 2003052908 I'm not able to produce a news
message with the Disposition-Notification-To: header.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•