If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Returning recept confirmation fails if Inbound/Outbound addresses are different

NEW
Unassigned

Status

SeaMonkey
MailNews: Backend
--
major
16 years ago
9 years ago

People

(Reporter: Andreas Troschka, Unassigned)

Tracking

Trunk
Future
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Suppose:

1.hispop3@domain.name        his inbound address
2.hissmtp@otherdomain.name   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 hissmtp@otherdomain.name and he will never
receive mails from his outbound account.

Solution:

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

hispop3@domain.name

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

16 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

16 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,
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

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

sr=bienvenu
Attachment #89081 - Flags: superreview+
(Reporter)

Comment 4

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

Updated

15 years ago
Blocks: 168959

Comment 5

15 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 6

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

Andreas.

Comment 7

15 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

14 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

10 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
Status: REOPENED → NEW
QA Contact: grylchan → return-receipts

Updated

9 years ago
Component: MailNews: Return Receipts → MailNews: Backend
QA Contact: return-receipts → offline
Assignee: bienvenu → nobody
QA Contact: offline → mailnews-backend
No longer blocks: 168959
Duplicate of this bug: 168959
is this core backend?
Severity: critical → major
You need to log in before you can comment on or make changes to this bug.