Returning recept confirmation fails if Inbound/Outbound addresses are different



17 years ago
10 years ago


(Reporter: signupbox, Unassigned)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
Suppose:        his inbound address   his outbound address

(also good against SPAM!!!)

He sends you an e-mail requesting a reception confirmation.

Now, with such a setup the return receipt function doesn't work correctly!!!

Your receipt confirmation is sent to and he will never
receive mails from his outbound account.


It has to be sent to the address specified in his Reply-to: field instead:

and if no address is specified in this field than, and only than, the address
specified in the sender or return-path fields have to be used (this should be
the last resource!).

Comment 1

17 years ago
Created attachment 89081 [details] [diff] [review]
Patch to fix the problem.

Good catch. Here is the patch to fix the problem.

Comment 2

17 years ago
Adding putterman and bienvenu to the cc list... David, I put up a patch to fix
the problem. Please review and have someone to check it in. Thanks,
Ever confirmed: true

Comment 3

17 years ago
Comment on attachment 89081 [details] [diff] [review]
Patch to fix the problem.

Attachment #89081 - Flags: superreview+

Comment 4

16 years ago
Patch applied and tests concluded without problems.
Last Resolved: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.2alpha


16 years ago
Blocks: 168959

Comment 5

16 years ago
Reopening bug.

Andreas, the patch actually hasn't landed in the trunk yet
so we can't change the status to 'resolve fixed'.

but thanks for testing the patch.
Resolution: FIXED → ---

Comment 6

16 years ago
Sorry, I'm new to Bugzilla and I don't have the process completely in my hands. 
I apologies for the inconvenient and was short to write you to request the
reopening of the bug, also due to the fact that I'd like to add a vector to the
second side of the medal, Bug 168959, as a completion to this issue.


Comment 7

16 years ago
This bug has to be completed also to include the other peer' action (sender of
e-mail with Disposition-Notification).
The sender must be able to specify a different Return-Receipt-To address while
composing his message (willing to set a Disposition-Notification).

This, actually, is not possible in Mozilla due to an incomplete iplementation of
the Mail notification process (see RFC2298 and RFC822).

The process may flow as follows:

a)Open new mail composer
b)Check box "Disposition Notification"
c)Write Destination address(es) in field To: 
d)Approve proposed Return-Receipt-To address(es) (automatically taken from
address book for the destination addresses specified)
d2)Otherwise select from listbox or edit directly
e)compose message and send.

So far...

Comment 8

15 years ago
*** Bug 243229 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
What is the status of this bug?

No comments since May 2004.

Is the problem still happening?

Jeff, Andreas, are you still working on this?

Comment 10

11 years ago
A simple test on T'Bird and other mozilla derived MUAs (as on most MUAs around) shows nothing has been done since I've opened this bug.
You or anybody else are welcome to work on this, and to produce the necessary patches on the actual sources.

Differentiating inbound and outbound mail addresses is still one of the most effective countermeasures against SPAM reception!
It is a shame that the Reception Confirmation protocol part isn't correctly implemented yet.
Mozilla1.2alpha is long past; retargeting to Future.
Target Milestone: mozilla1.2alpha → Future
Resetting A+QA as current (nondefault) values seem out-of-date.
Assignee: jt95070 → bienvenu
QA Contact: grylchan → return-receipts


10 years ago
Component: MailNews: Return Receipts → MailNews: Backend
QA Contact: return-receipts → offline
Assignee: bienvenu → nobody
QA Contact: offline → mailnews-backend


10 years ago
No longer blocks: 168959
Duplicate of this bug: 168959

Comment 14

10 years ago
is this core backend?
Severity: critical → major
You need to log in before you can comment on or make changes to this bug.