h a l f b a k e r yFutility is persistent.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
When i send an e-mail, and i don't hear back from them in a few days, i wonder if the server is down or if they haven't received the message. So, how about you receive an e-mail from the ISP saying that it reached their srvers, then an e-mail from the client when they open it or delete it without opening
it.
[...nothing, it doesn't matter...]
RFC 1894: Delivery Status Notifications
http://www.rfc-editor.org/rfc/rfc1894.txt
Part 1: Baked crispy, though obscure. [egnor, Mar 03 2001]
RFC 2298: Message Disposition Notifications
http://www.rfc-editor.org/rfc/rfc2298.txt
Part 2: Also baked crispy. [egnor, Mar 03 2001]
ReadNotify.com
http://www.readnotify.com/
Reading RFCs and evaluating MUA features not your cup of tea? You might try this easy-to-use service. Sign up with them, then append ".readnotify.com" to any e-mail address; they'll add all the magic for you as per your configured preferences. They support DSNs, MDNs, and HTML "gif bugs". This is not a free service, and the operation is a little on the sleazy side, but the concept is definitely there. [egnor, Mar 03 2001]
(?) Readnotify test email. Subject "Foo", body "Bar."
http://www.panix.co...kery/readnotify.txt
Here's what those messages look like "raw". [jutta, Mar 03 2001]
[link]
|
| |
Because generally, if the server is down, you get a message saying the server is down. Sending a message out every time a message arrives will double the traffic without any real utility. |
|
| |
What's your mailer? It may
already support this feature. |
|
| |
Hotmail tells you that "Your message has been instantly delivered to the following recipients..." immediately after you send it. |
|
| |
Which is a blatant lie, for the most part. I've had it take a week to get to another Hotmail user... |
|
| |
The "native" Internet e-mail notification mechanism, MDN, requires user permission for a reason - its authors were trying to preserve recipient privacy.
As Egnor points out, readnotify.com exploits a generic privacy problem in browsers (you can't load a linked-to image without accessing its server, but doing so gives away that you're rendering the message) to circumvent that. In essence, ReadNotify's users can spy on their recipients without giving them a chance to prevent that (they are told about it - by default, but they are *not* told that a "mail open" event has already been sent by the time they see the request), and smart people who notice this may be slightly miffed, or may play worse games in return. |
|
| |
You know, I don't even know about their MDN support. I am supposed to have MDNs turned on in my test account, but all I see is a Return-Receipt-To: header, not the Message-Disposition-To: header that I would expect. |
|
| |
What I really want to know is whether they have a funky hacked DNS server that reports attempts to resolve their dynamically generated hostnames
(e.g., my test mail just then had links to www.yy4pikj5ra1d31.ReadNotify.com), or whether
they're just doing that because they can. |
|
| |
They add HTML to the "text/plain"
section; yuck. They also add an
undecorated URL; I guess they hope
you click it. I would expect some
explanation before the colon; I
wonder why it's missing. |
|
| |
The HTML section is a laundry list
of tracking techniques. Some of
them seem redundant; why load the
blank2x2.gif if they're going to
load footer.gif anyway? What do
they gain from appending
escape(self.location) to the URLs
they load? (What's self.location
for HTML in a typical mailreader?)
Why does the CSS they load
(presumably to trigger a hit even
if image loading is off) actually
contain content (which is unused)?
And, as you note, what *is* up
with those hostnames? Is there
any client scenario where a DNS
lookup would occur but an actual
HTTP request would not? |
|
| |
Baked. It is called a Receipt Request. |
|
| |
Well, no, that's different. A "receipt request" receipt is generated upon a user reading the email not upon the email arriving in the inbox of the destination. |
|
| |