You tell the sender to stop requesting them or you ignore them.

Disable return receipts in your Thunderbird settings.

Allow me to elaborate, since christ1 assumed that I had not done the due-diligence search that is supposedly required before asking a question here.

Thunderbird 24.4.0 with latest service. Windows XP Pro (32bit) with latest service.

Tools->Options->General->Return Receipts...:

 When I receive a request for a return receipt:
   o Never send a return receipt

Tools->Account Settings...->[acctname]->Return Receipts:

 o Use my global return receipt preferences for this account

... for all of my [acctname]s.

It would appear that T'bird does not recognize the 'X-Confirm-Reading-To:' and/or 'Notice-Requested-Upon-Delivery-To:' headers as "Return Receipts" and is responding to them against my wishes and settings.

What a prompt but stunningly unhelpful reply, Airmail!

What part of "automatic response" and "privacy violation" did you miss?

Or more plainly: "How will ignoring them keep them from being automatically sent back to the requester?"

And "How am I supposed to know who is going to request a receipt confirmation before it is received, and Thunderbird automatically replies to it?"

There are settings for return receipts globally and on a per account basis. Have you also checked the per account settings?

OK, I saw you already did check this.

How do you determine Thunderbird doesn't respect the settings?

Thanks for the follow-up crist1.

It's simple. The sender gets a reply every time I open his email. Not just receive it, every time I _look_ at it! I can't believe T'bird is honoring this request without there being any way to disable it.

Unfortunately, I know of no way to request this type of "return receipt" (X-Confirm-Reading-To:) via any of the email clients I have, so it will be somewhat difficult to test. The sender is using Juno.com, if that is relevant.

And the notification looks like what?

What you describe sounds more like a web bug in the mail body reporting back to his. see also http://mailchimp.com/features/ All of that is driven through remote images and iframes, nothing is reported back by the email client.

I wish I knew, Matt. All I know is that the sender was able to report to me the number of times I had opened his email without replying to it.

While it sounds like a web-bug technique, I can see no indication in the email that one has been employed, and I would think that an outfit the size of Juno.com would not be a party to such things.

I cannot attach the email to this note so I have uploaded an obfuscated version of it to www.aviatrexx.com/private/tbird (xxxx@acm.org = my address, yyyy@juno.com = his address, [...] = content elided) as a .txt file. The elided base64 content is in a separate .txt file.

Please let me know if you see anything other than the 'X-Confirm-Reading-To:' and 'Notice-Requested-Upon-Delivery-To:' headers that look suspicious.

Thanks,

-Chip-

ok the attached base64text file, which by the way is the message, your provider or your SPAM tool flagged it as spam. With the following report

X-Ham-Report: Spam detection software, running on the system "harvey.tchmachines.com", has

identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
root\@localhost for details.

The original html, which incidentally simply says "Whats Up" contains a link to this image http://mxsvr.net/we6xgr4zsjbf/signature.gif. The we6xgr4zsjbf is probably a bas64 representation of your email address, or some other value that he has linked to your email address.

Interestingly when I tried to go to that internet address, my anti virus blocked the attempt with the following message.

ESET NOD32 Antivirus - Alert Access denied !

Details:

  Web page:
  http://mxsvr.net/we6xgr4zsjbf/signature.gif

  Description:
  Access to the web page was blocked by ESET NOD32 Antivirus.
  The web page is on the list of websites with potentially dangerous content.

Further information at VirusTotal

Thanks for the time you put into this Matt .

I'm afraid I might have confused you with a few things I did to not reveal personal information. The "[...]" represented redacted message text, which is why the message seemed to contain only "What's up". The second "[...]" was the name of the sender.

As for the "X-Ham-Report", my mail server uses SpamAssassin and automatically includes that boilerplate 'X-Ham-Report' block. Every email has that message; what matters is that the actual spam score is "-3.2" with a "5.0" trigger level.

Nonetheless, it appears that you were right about the web-bug. What I assumed was the sender's .sigline image turned out to be a single white pixel in the middle of a completely black screen. Very suspicious.

Now that I have figured out how the sender knows how often I opened his email, I'm resetting T'bird back to 'plain text' only. That should stop the web-bug problem.

Meanwhile, is there any place I can go to find out exactly which 'X-' headers Thunderbird honors?

Don't worry about the x- headers. Thunderbird does not offer any form of read receipt if you turn them off as discussed in your earlier posting, so you know how.

Thunderbird is an RFC mail client. so we have to look to the RFC for what Thunderbird is designed to do see http://www.ietf.org/rfc/rfc2298.txt

Edit You could always block the domain the image comes from at the firewall. I doubt you will miss it