257309 - Return receipts should not reveal forwarded email addresses in headers

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Miguel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

Now, when you send a return receipt, all headers of the email you received are
included in the return receipt, so if you redirect your address to another
address you don't want the sender knows, with the headers he can know it has
been redirected and the address. So *I think it would be insteresting _an
option_ to prevent headers be sent with the return receipt*. Another clients
like Outlook don't send all the headers.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Miguel]

Can somebody have a look at this and confirm it?

Comment 2

[Miguel]

I think it's better to consider this as a privacy issue, instead of an enhancement

Comment 3

[Holger Voss]

The same problem with Thunderbird:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0

Comment 4

[Andrew Schultz]

this is not even possible in some cases.  It's easy to think up situations where
it would be difficult or impossible to figure out what the original email
address was (bcc or multiple recipients).  And in the case of bcc being you and
one non-bcc recipient, Mozilla might think it was ok and then send a bogus
return receipt.

If you're concerned about privacy, don't send return receipts.

Comment 5

[Miguel]

Attachment: Sample

Maybe I have not explained it well. The issue has nothing to do with the
original email address (bcc or multiple recipients) but the format of the
return receipt.

I mean, when you now return a return receipt, *the receipt contains the
original headers of the mail* you've just received. The problem is that in
those headers the sender can see a lot of information that maybe you don't want
him to watch.

OE and Outlook don't reveal such information.

I attach a return receipt, I've included deleted information ([DELETED]) due to
my privacy which doesn't affect this bug, and information marked as [PRIVACY]
that can reveal private information. The problem is that sending the original
headers has no sense, with the following part, we wouldn't need anything else:

Reporting-UA: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Thunderbird/1.0.2
Final-Recipient: rfc822; [DELETED]
Original-Message-ID: <[e-mail]>
Disposition: manual-action/MDN-sent-manually; displayed

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The reporter appears to have been using the suite, moving bug back to proper
product and component.

Comment 7

[Misak Khachatryan]

Mozilla/5.0 (X11; U; Linux i686; rv:1.9b5pre) Gecko/2008032401 SeaMonkey/2.0a1pre
Headers are sent with receipt.
I think some info in return receipt should not be sent unless explicitly configured by some option (for example user agent, with can be used to determine buggy version of software and then can be exploited)

This should be decided by someone with someone else. Just bringing up to radar.

Comment 8

[Robert Kaiser]

I don't see any reason to give this special priority, but it's also not unwanted, so cancelling the wanted flag.

Comment 9

[Wayne Mery (:wsmwk)]

Is this a legit privacy issue? And is there spec to deal with this?

Comment 10

[gene smith]

(In reply to Wayne Mery (:wsmwk) from comment #9)

Is this a legit privacy issue? And is there spec to deal with this?

https://tools.ietf.org/html/rfc3798 deals with this. However, I don't see where it says completely how the headers are formatted. Maybe I'm missing the point but if I send an email to someone with a return receipt request and the headers are visible in the receipt message I receive back, how is that a problem? Or is the problem with the person receiving the original message?

(In reply to Miguel from comment #5)

Maybe I have not explained it well. The issue has nothing to do with the
original email address (bcc or multiple recipients) but the format of the
return receipt.

I mean, when you now return a return receipt, the receipt contains the
original headers of the mail you've just received. The problem is that in
those headers the sender can see a lot of information that maybe you don't
want him to watch.

Not sure which "sender" he means above. Is it the original sender of the mail, or the sender of the receipt?

Anyhow, I have never used return receipts so I would need to set it up and test it out to maybe see exactly what the privacy issue is.

Comment 11

[gene smith]

Ok, looking at what is sent back in the return receipt, there are a two attachments following the body text (disposition mime header and the original header). I don't see anything in them that I don't already know, e.g., my address, the recipient's address.

There are some routers the message went through in the original header. Not sure what is private about this. You can see the same thing if they reply the message.

Also, I don't see a record of the sent return receipt being saved by the sender of the receipt anywhere. So nothing to see there other than the originally received message.

Comment 12

[Kai Engert (:KaiE:)]

Let's summarize, to ensure we have a common understanding.

Original sender is [e-mail]

Bob is the recipient. Bob has two email addresses:

• [e-mail]
• [e-mail]

Bob has published the email address [e-mail]
The email address [e-mail] isn't public, and only selected people know about it.

Bob prefers to read all (or some) incoming email using the inbox from [e-mail]

To achieve this convenience, Bob has configured an automatic forwarding, that forwards all (or some) email arriving at @public.tld to @personal.tld

However, when replying, Bob carefully ensures that he selects the correct outgoing identity. When replying to messages received for @public.tld, Bob will use a configuration that uses @public.tld as the sender address.

Now, Alice sends an email to [e-mail] and requests a return receipt (RR).
The configured redirect forwards the message to [e-mail]

In this bug report, I see the following requests for privacy protection:
(a) the current bug subject requests the RR should NOT include the "forwarded email addresses"
(b) comment 5 requests the RR should NOT include "routing headers to the destination"

I think it is impossible to achieve (a).

IIUC the RFC requires that a RR must include the final recipient address.
If Bob allows a return receipt at @personal.tld, then the RR will use @personal.tld as the from address of the RR.

However, in a more complex setup, where a message isn't sent to Bob, but to [e-mail], the email might get rerouted based on its contents, and maybe there's an additional forwarding hop in the middle. The full set of headers would reveal the email address used for the intermediate hop.

Regarding (b), I think that's a valid request.

RFC 3798 section 3 describe what the RR should contain.
The first two parts are required, which are a human readable explanation, and a machine readable section, in which Thunderbird includes Reporting-UA, Final-Recipient (again the @personal.tld address), Original-Message-ID and some information about the nature of how the RR was sent (e.g. automatic/manually).

The third part/component of the RR is described as optional. Thunderbird may decide if it includes any additional from the received message.

I just tested, and I see that:

• Thunderbird includes the optional third component
• the full set of all headers is included, that were added by gateways, as the message was routed to the final @personal.tld address
• (Thunderbird doesn't include the message body of the original message.)

I think the set of incoming headers might indeed reveal some details about the recipient's mail gateway infrastructure, which the sender doesn't need, and which might be considered private. For example, it can expose what spam filtering products were used, the spam rating, filtering information.

Comment 11 claims that the same information can be seen if Bob sends a regular reply. I think it's not as simple as that, I see two differences:

• Bob might decide to not reply at all, and thereby not expose any information. However, an automatic RR would expose that information.
• Incoming routing might be completly different than outgoing routing. For incoming email, headers might reveal information about spam filtering, classification of mails, sorting into folders, hostnames of company internal gateways. Outgoing email might just go via a direct gateway, and not reveal any such information.

IMO it's a valid request to suggest that Thunderbird drops the third component from RR that are sent out.

However, instead of completely dropping the third component, we could alternative send a third component that is limited to the subject and date fields of the original message, which the RFC states as desirable.

It also has been argued that users should disable return receipts completely if they are worried about their privacy. I agree, but there are probably some users who need to keep them enabled. Limiting the amount of information exposed in a RR could help those users.

In short, my opinion is:

• Bug suggests a valid privacy enhancement
• Thunderbird shouldn't send all message headers of received message, only send original subject and date in the third RR component