Slashdot Mirror
Stopping "PattyMail" Email Bugs
An anonymous reader writes, "In the U.S. Congressional Inquiry into the HP spy scandal, it was revealed that HP used Web bugs to track the source of leaks. HP's Fred Adler considers them a useful investigative tool which HP will keep using. Since dubbed PattyMail after HP Chairwoman Patricia Dunn, Web bugs have been around for a while. But it turns out the vulnerability they represent is far worse than first thought. Microsoft Outlook won't have a patch until 2007. The company at the center of the scandal claims they've done nothing wrong. But could repressive governments use them to track down critics? Can anything be done to stop Web bugs?"
Ship all email programs by default configured to not show images in the mail. That would be a start. I've seen some web clients already that automatically filter out tiny "bug" sized graphics.
Where were you when the voynix came?
Can anything be done to stop Web bugs?"
Um, how about not reading email in HTML? Even LookOut!, er, Outlook you can set to convert mail to plain text.
-- Alastair
like pine
Outlook is doing exactly what it needs to do, blocking download of images. If it lacks the specialization of countering these "bugs" that's too bad for corporate sleuths and leakers, but it does not expose the user to anything, this is not a vulnerability and the "patch" mentioned will simply give you an additional option regarding image handling. I wouldn't think the "let me forward this mail with the secret tracking device turned off" functionality was high on Microsoft's feature list when they released OLK2003.
> 'Web bug'
Nothing new here. Saw this techinque, or do we call them "patterns" these days, used years ago by spammers.
Just set Outlook not to open image attachements...
Sadly, no. Since HTML is a vital component of email, this sort of vulerability is inherent in the 'email' system, much like compromised cookies and overridden passwords. Some time in the future, we may have an email system that is simply composed of raw text which would be invulnerable to such exploits, but for now we can only dream.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
In other news, Webster's Dictionary has replaced the word 'Machiavellian' with the word 'Dunnish' although the meaning will remain "Suggestive of or characterized by expediency, deceit, and cunning."
You know you've done something wrong when your name becomes a common term for something evil like PattyMail. I certainly hope she's still not blowing this off like she didn't do anything wrong. Then again, if everyone in corporate America does this, I hope that comes to light also.
My work here is dung.
Do not use a computer traceable to you, to pass sensitive information on to where you think it needs to go.
Print the email, and store it in a safe place.
Transcribe the information to another paper media, and pass that along as anonymously as possible - the mail with non-lick stamps and evelopes possibly.
Oh You POS
Wikipedia explains web bugs. http://en.wikipedia.org/wiki/Web_bugs
So, is this spyware, or not? I would say yes. The website is spyware, as it is tracking where it's user comes from....but then isn't all of the internet spyware?
The ZDnet article asks it best......"Phoning home? Deception? It must be spyware. Right? At least if you're a politician that's not well steeped in technology, it must be. Or is that the case? Maybe it is spyware after all. And maybe all HTML-based e-mail should visibly disclose that the page contains "tracking" elements with links back to more information on what those elements do and what the privacy policy of the sender is. Does PattyMail qualify as spyware and should the senders of HTML-based e-mail disclose their use of trackable graphical elements in the e-mail itself? Feel free to answer below."
"Some time in the future, we may have an email system that is simply composed of raw text which would be invulnerable to such exploits, but for now we can only dream."
I've even heard that someone is working on a revolutionary OS that runs entirely in text mode, and uses command-line control, and is completely impervious to web bugs, Windows trojans, and other such infestations.
Where were you when the voynix came?
I wonder what else will soon become a business model?
Furthermore, how is it that profits always outweigh ethics?
Don't read your email in HTML format. Problem solved. a) There is nothing to be said in email that can't be said in plaintext and b) I really could care less to see your smiley face sig and pretty flower background.
"The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism."
- Paul Tomblin was talking about USENET when he said this, but he was right.
"maybe all HTML-based e-mail should visibly disclose that the page contains "tracking" elements with links back to more information on what those elements do and what the privacy policy of the sender is."
Why would the sender have to identify email as such? The "bad" senders would ignore such requirements anyway. Realize instead that any email client can easily recognize such emails by looking at the links inside the body of the mail. This would be extremely reliable and foolproof (i.e. anything that uses an outside linking HTML tag is suspect).
Where were you when the voynix came?
United States Postal Service
GetOuttaMySpace - The Anti-Social Network
Mail programs now need the option to retrieve images through an anonymizer.
Mutt!
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
easy way to eliminate all sorts of crap in emails.
A word gayer than "blog." Thank you, Pattymail!
Won't work. If the URL is message-specific, it does not matter where the request
appears to come from.
I read mail in Thunderbird with images turned off. Unfortunately it's an all-or-nothing choice. A better solution would allow me to right-click a specific blocked image and let it through. That way I could see the images I want to see but still keep those little 1x1 gifs from phoning home.
I use a web-based mail provider. It blocks images and a lot of potentially-hazardous html.
No reason a local mail client couldn't do the same. Ditto third-party security software that prescreened email.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
How about blocking the offending IP ranges at the firewall level? Anyone know what IPs to block?
Elm, Mutt, Pine. Need I say more?
No matter where you go... there you are.
I've included small images in emails to people. Images that were hosted on my webserver.
:)
So basically, I'd just check my logs to see if they read the mail or not. In those logs, of course are IP, OS type, browser type, etc. I never really thought of it on the scale of a service such as ReadNotify, but I suppose, that's my shortsightedness, huh?
Sugapablo
Mail user agents should be allowed network access only for the protocols that are actually useful (POP, IMAP, MAPI, LDAP, depending on your needs, and the application's design).
Allowing the content of an e-mail message to establish arbitrary network connections at all (or at the very least, without daully authorized consent from the user) is an immediate and obvious security risk. I understand that it is easiest to simply embed a full-fledged web browser component in the mail client, but it does not need network access of any kind to render the content passed to it.
Any word on whether GMail is vulnerable to such web bugs? I know they do a lot of filtering to strip out javascript and image-based exploits, but this sounds to be iframe-based. I'm a bit busy to test it right now, but this might be the final straw that forces me to use mutt as my GMail front-end. (I love mutt, but the GMail web ui is one of the few e-mail interfaces I actually like better.)
Karma: Incomprehensible (Mostly affected by posting at +5, reading at -1, and metamoderating everything unfair.)
Sending Microsoft Word files can violate your privacy.
http://www.nothingisreal.com/dfki/no-word
Certified mail, return receipt.
I been trying to get this tracking bug to work in my email reader, Mutt, but with no luck. Open source will never be viable on the desktop until we can get these kinds of features implemented.
I'm going to open a feature request witht the Mutt team, but I'm not very hopeful.
$body =~ s///g; # get rid of IMG tags
$body =~ s/url\(.*\)//g; # get rid of CSS links too
Problem solved.
Nathan
"Ah yes, Amish OS 1.0."
Ah. You might have also heard of the secret Apple Ultra-Cube project. An amazing revolutionary project that was revolutionary because not only did not come without a floppy drive, it came without USB and CD/DVD as well (in order for Apple to force us to leave behind clumsy legacy storage). Driver problems were a thing of the past: it interfaced equally well with ANY peripheral hardware available. The amazingly simple interface design completely got rid of cable-clutter. It was hard to steal due to ingeniously designed mass properties that made people tend to leave it where it was installed. It was completely impervious to any malware. They pulled the plug on the project once Dvorak found out that it was merely a painted cinderblock.
Where were you when the voynix came?
Mail programs now need the option to retrieve images through an anonymizer.
The problem is that the image name will allow the user to be traced, so requesting it anonymously still indicates who inititially got the email. The image name can be generated uniqe to each email sent.
IFRAMEs _not_ images!
http://www.freedom-to-tinker.com/?p=610
The more I think about this the more I can appreciate the general simplistic truth of it.
As the demographic of Slashdot is generally technically inclined, we see workarounds as obvious "no brainers." We offer up solutions such as "use text-only! [idiot!]" Other things like keeping up with patches and the like are also pretty similar in nature.
The fact is, the general public is non-technical and wouldn't know where to begin to look for "web bugs" or any other such vulnerability.
And as for HP claiming they aren't doing anything wrong in this practice is, to me, just a step below Sony/BMG's arrogance displayed in their root-kit CDs. They too acknowledge no wrong-doing...
A real email client ... surely you mean UNIX mail?
That ought to be good enough for anybody.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
This is NOT about image bugs, it is about IFRAME bugs.
http://www.freedom-to-tinker.com/?p=610
Shouldn't these be called "Pattycakes"?
Now, if we can get Spamhaus (or someone similar) to put HP and readnotify on its block lists...
Where were you when the voynix came?
The sender knows who initially got the e-mail; that's the addressee. The main article was about tracking to whom the mail was forwarded. Forwarded copies will have the same image links as the original. So if the original recipient and the recipient of a forwarded copy both have anonymous image browsing, the original sender will know only that the message is being read again, but won't know from where.
Using a crappy old version of Zonealarm here, but any decent software firewall would do the same.
Zonealalarm's pretty basic - it* only has concepts of "local" and "Internet" zones; simply ensure that the Exchange server that it wants to connect to is in the "local" zone and that Outlook can't access the "Internet" zone.
*the version I'm using, anyway.
Instead of of smugly assuming you are invulnerable to image bugs like almost every other poster you took the time to read the article and determine it was about IFRAME bugs!
Most insightful post so far! Well done
This sounds like an invitation for some dumbass law "requiring" people to disclose when an email has tracking elements ... except that it would be impossible to enforce, and the spammers/malware-writers would just ignore it anyway.
The solution here isn't regulation. It's just for people to decide whether a feature (in this case, HTML mail) is really worth the risk.
Alterately, we could 'neuter' HTML mail so that only the most basic formatting commands worked; use it purely as a style markup language, with no iframes, images, or externally linked text. That seems like it would solve the problem while preserving the reason 90% of idiot users want HTML: so they can use bold/italic/flashing-red-text or whatever.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
That wouldn't work, at least as far as preventing someone from knowing you have opened the mail.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
> smash his computer into little bits
I thought bits were dimensionless like a point in a line, or the protagonist in "Points on a Plane" (still in production).
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Can anything be done to stop Web bugs?
Funny you should ascii...
Running Windows^H^H^H^H^H^H^H OSX and Linux in the home. (I don't have time for Solitaire any more.)
At this point, it's easier to just draft a new message and paraphrase, "Bob, did you see an email from Alice commenting about the Widget lately?"
A new message leaves the reference too vague for most Bid'ness Bob's to understand the question. You'd have to include the message or eight pages of text to get them into context on the discussion. That kind of defeats "it's easier" part of your suggestion.
Solution #2:
Schwab
Editor, A1-AAA AmeriCaptions
Don't do that. The Government will read your mail. After all you might be a terrorist? Why else would you send your stuff in a closed and sealed envelope. Do you have something to hide?
Undetectable Steganography? Yep, there's an app fo
I don't think so. Please explain how your proposal would prevent the sender from detecting the user reading the mail in the following image tag, where the final part of the URL path is a uniquifier:
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Solution number three:
/var/spool/mail/me
less
If you read the sourced article, disabling HTML email would not be sufficient. The tracking marker is actually embedded in an attached document. Once embedded it turns invisible, so there may be some macro associated as well. It seems that a cascade of nefarious and default behavior of a suite of MSFT products allows unsophisticated users to be duped. Suggested steps to mitigate, if not entirely eliminate, the risk of PattyMail
1) Assiduously avoid MSFT products where possible.
2) If you can avoid all, avoid MSFT Word, the probably culprit in this case. Use OpenOffice instead.
3) If you can't do that, disable automatic macro execution in MSFT Word.
4) Do not use HTML email. HTML makes things PRETTIER, not more useful. Anyone in favor of HTML mail is either a spammer or cares more for form than function. HTML mail is a useless abomination. But I digress.
5) Install something like ZoneAlarm on your individual workstation and explicitly ban all MSFT Office products from accessing the Internet, without at least popping up a dialog box. This way, if there is a "phone home" mechanism hidden in a document, you'll know when it tries and you can intercede.
6) Set your email program to alert you and request permission before sending read receipts. Never auto-send them, and do not auto-reject them either. It's useful to know who's trying to check up on you. Then, once you know someone's trying to check up on you, refuse to send the read receipt.
7) If you must follow a questionable URL of dubious provenance, consider actually using an OLDER browser version. For example, Netscape v4.7 or older. It won't render many pretty things correctly, but who cares. More importantly, it also will simply ignore a lot of the more recent tags and syntax as being noise.
Mailscanner is an excellent spam/virus/web bug scanning tool. It can be set to disarm iframe tags, block phishing emails and many other cool things.
The problem is that it's not just a certain range of people who are doing this.
Tons of companies, including shady ones (spammers, phishers, Microsoft), use email tracking "bugs" to determine whether an email has been read, if an address is 'live,' or determine a user's IP address or location.
Blocking their IPs would be as nontrivial a process as blocking all spam-producing IPs. And we know that's not exactly easy (how's that going, SpamHaus?).
The "solution" in my mind, is just to block all the HTML elements which can trigger loading of resources from remote servers. Basic formatting tags, like italic, bold, and color are fine, as are paragraphs and basic CSS. But remote images are out -- if you want to include images, put them in the email as a MIME attachment where they belong.
Any time you load an image or other element from a remote server, you potentially give away your location, and information about your address (e.g., whether your email address is valid -- useful to a spammer). The only way to stop these sort of attacks is just to not load anything remotely. If it doesn't come in as part of the message, it should be loaded only upon explicit command of the user, and perhaps with the address displayed (in a dialog), item by item.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
www.sendmail.org
www.mailscanner.info
www.pmail.com
Problem solved, oh, maybe five years ago. It amazes me that anyone just figured this was a problem NOW.
I've received hundreds, if not thousands, of emails with a {disarmed} header modification inserted by MailScanner... it's quite interesting to learn who is routinely inserting tracking bugs in their mailings.
I suppose you could also use transparent caching a'la squid to bumfuzzle some of the trackers and speed up browsing for your end users at the same time. But it seems like nowadays the bugs usually contain individualized tracking codes that would make it through the cache anyway.
You just have to strip out external references and tell the end users "that guy who sent you this is using a broken mailer". That's the strategy the HTML addicts used to create this problem, after all - they told the clueless that HTML was normal and that anybody who couldn't read it was using broken or obsolete software. I use the same line (which happens to be true) if somebody complains that they can't read company XYZ's mailings because the image links have been stripped out; "oh, company XYZ is using a broken obsolete mailer that puts external links into the text; until they learn to use the Internet you'd better find a new company to deal with or stick to phone calls".
Thunderbird has the option of allowing images from those in your personal address book.
b ird)
http://kb.mozillazine.org/Privacy_basics_(Thunder
says that its the default setting.
I think this should be modded informative. Yes, it basically says "RTFA", but for those of us who haven't (**ducks**) it's informative, AND a very direct response to the "just read plaintext".
Attached word documents for letters, or powerpoint docs for pictures, are the debbil. >_
How about we quit sending each other email in HTML? Then we don't have to worry about all this crap.
I know it's true Slashdot tradition to not read the article, but the bugging HP did has nothing whatsoever to do with embedded images and HTML e-mail.
What it does have to do with is bugged attachments. Yeah, just like those old worms that portrayed executables as image files or what not. Turn off HTML all you want, but if you want to see what's in the file that is supposed to be extremely important, even vital, you still have to open the file. Thunderbird, and even Mutt won't help you with this.
I read somewhere that it was a PDF that was used in this case. This makes me wonder. I don't use Adobe Acrobat for reading PDF files, I use Evince (And XPDF before that). Does anyone know if these programs support that "feature" of PDF?
... And so it comes to this.
"The company at the center of the scandal claims they've done nothing wrong. But could repressive governments use them to track down critics?"
Why not the possible unknown repressive governments?
I use Pine on Linux. Simple, easy for me to use, and it doesn't do a thing unless I tell it to. People who let their computers run their lives get what they deserve.
For those of y'all that are interested, I just signed up for their trial account and sent myself a message. Here are the interesting parts (truncated headers):
- Confirm-Reading-To: (testemailaddress).qocetpjmzkyyyua.emsvr.comu rn-Receipt-To: (testemailaddress).qocetpjmzkyyyua.emsvr.comi ce-Requested-Upon-Delivery-To: (testemailaddress).qocetpjmzkyyyuk.emsvr.como rs-To: (testemailaddress).qocetpjmzkyyyuk.emsvr.com
H TML><HEAD>t > <Img Border=0 Height=1 Width=3 Alt="" Lowsrc=""o tify.com/nocache/i4a8oxdx3u3tdv/rspr47.gif><Img moz-do-not-send="true" border=0 height=1 width=3 alt="" Lowsrc=http://www.i4a8oxdx3u3td8.ReadNotify.com/no cache/i4a8oxdx3u3td9/footer0.gif><Img moz-do-not-send="true" Border=0 Height=1 Width=2 Alt=""7 .gif ><STYLE TYPE='text/css'>@font-face {font-family: rnfont; src: url(http://i4a8oxdx3u3tdx.ReadNotify.com/fnt.asp/i 4a8oxdx3u3tdS.eot);}</STYLE><EmBed volume=-10000 Alt='' Lowsrc="" height=1 width=1i fy.com/nocache/i4a8oxdx3u3tdv/rspr47.wav>< table height=1 width=3 border=0><tr><tdr 47.gif> </td><td/ i4a8oxdx3u3tdX/rspr47.gif> </td><td style="font:arial;background-image:Url(http://www. i4a8oxdx3u3tdz.ReadNotify.com/nocache/i4a8oxdx3u3t dZ/rspr47.gif);"> </td></tr></table>a 8oxdx3u3tdp=4 frameborder=0 STYLE="width: 0; height: 0px; border:0px"></IfraMe><Img moz-do-not-send="true" Border=0 Height=1 Width=2 Alt=""x 3u3tdw/rspr47.gif></div><div><Link/Rel="stylesheet " TYPE="Text/CSS"a 8oxdx3u3tdj.css>& lrm;‏‍‍‎‎ ...)j ;‍‌‎</title>
X-Mai1er: RNwebmail
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Disposition-Notification-To: "them" <(testemailaddress).qocetpjmzkyyyua.emsvr.com>
X
Ret
Not
Err
<
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
</HEAD><BODY><DIV></DIV><DIV>tes
</DIV>
<div alt="i4a8oxdx3u3td1."><pre> </pre><pre>
<br
Src=https://tssli.i4a8oxdx3u3tdv.ReadN
Lowsrc=http://www.readnotify.com/ca/rspr4
Src=https://tssle.i4a8oxdx3u3tdv.ReadNot
</pre>
background
=http://0320.185.62311/nocache/i4a8oxdx3u3tdP/rsp
background
=http://www.i4a8oxdx3u3tdx.ReadNotify.com/nocache
<IfraMe/width=1 height=1
Src
=http://www.i4a8oxdx3u3tdo.ReadNotify.com/ifrm?i4
Src=http://0320.185.62311/nocache/i4a8oxd
Href
=http://www.i4a8oxdx3u3tdi.ReadNotify.com/styl/i4
</div><div><title> A test message </title>
<title>‏‏‌‌‏‎
(... snip
‎‎‏‏‎‍‎‎&zw
<title> A test message </title>
</div alt="i4a8oxdx3u3td1."></BODY></HTML>
Can someone explain the IP address munging here? http://0320.185.62311/ How does that get mapped to readnotify.com?
As recently as 2002, Microsoft Outlook could be tricked into running Javascript from HTML email. Running Javascript allows the Karl Voth Reaper exploit to run, which goes beyond tracking forwarding to phone home with all the comments added to the message as it gets passed around.
SO... does this mean Bill Gates really can track my email habits and send me $243.00 for everyone I forward email to, while simultaneously preventing my account from being deleted?
Online email providers like Gmail and Yahoo are in a good position to protect their customers against this.
Imagine if you will, that Gmail's mail servers would instantly, upon receiving an HTML message, retrieve all cacheable resources linked by the message and save copies of those resources on Gmail's servers. The sender gets little to no useful information out of it (all they know for certain is that Gmail's servers received the message shortly after it was sent). Gmail's servers would replace URLs embedded in the HTML for those cached resources with URLs pointing to Gmail's cached copies. When the recipient reads the message, any HTTP requests sent by the recipient's computer would be sent only to Gmail's servers, which would send the cached copies of the resources in response, thus preventing the recipient's computer from needing to access the original sender's servers to retrieve the resources. The original sender has no idea who read the message, or when they read it, or even if it was ever read at all.
Any non-cacheable content (if there even is such a thing) could just be blocked, or at least require the user's consent before sending a request to the original sender's servers. This would enable (most, if not all) HTML mail to still be useful, while protecting recipients of HTML mail from these immoral (and possibly illegal) shenanigans.
This could probably be done much more quickly and easily than trying to patch web browsers or other email clients. Hell, for all I know Gmail (or Yahoo or some other provider) may already be doing this.
Despite what EULAs say, most software is sold, not licensed.
Pine. On Unix.
Via a shell account.
Why should a mail program need any way to "retrieve" an image at all? Either the image is attached, or it isn't needed.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
"The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism." think of the dogs!!!
It has been known for over a decade, that MS Word and MS Excel documents are as functional (and dangerous) as software itself. Opening a document with MS Word or MS Excel is essentially the same risk as running a binary. Opening Patty's MS Excel spreadsheet, Patty's MS Word document, Patty's email with MS Outlook, or Patty's webpage with MS Internet Explorer, is the same as running Patty's leak-tracking software. Shocked you got caught? (Shocked that "MS" keeps turning up in the names of those applications?)
I am growing increasing impatient with people who live in denial of this fact, to the point that it's getting really hard to have sympathy for them when they get bitten. How many times have you been told that these applications are security risk? How many times have you been told that their files should be treated as though they were code? Go ahead, make excuses about how you need these apps (the excuses actually can evoke some sympathy), but please stop crying out loud when you get fucked over exactly as was predicted you would get fucked over. I'm tired of hearing it. Complain that you need the software, not that the known-dangerous software screwed you. Complain that you were forced to play Russian Roulette, but don't complain about the game itself.
If you're not enough of a rocket scientist computer nerd to know this shit by now, then MS Windows is not the right OS for you -- just as partially-loaded revolver is not the right toy for you.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Get ESpray!
I mean, if you have to get jazzy e-mail, it means you're bullshitting because the ideas you're conveying don't stand up by themselves.
It's like a rock show where the mediocrity of the music and the utter stupidity of the lyrics have to be hidden by light shows and pyrotechnics and tight leather (or spandex for you KISS afficionados).
The real solution is to not use AOL or AOL software. True email is best viewed in mutt.
When I was young, I had to rub sticks together to compute.
I doubt that it can track messages sent there.
Mail programs now need the option to retrieve images through an anonymizer.
Great idea. I can see the commercials now:
Guy 1: Man, every time I try to download child porn from Thunderbird I get hassled by the police.
Guy 2: What? You haven't heard of Eudora Safewank?
Guy 1: Safewank? What's that?
Guy 2: Only the best way to be a total ponce and not get caught!
Guy 1: I am intrigued. Please tell me more.
brandelf: invalid ELF type 'KEEBLER'
The logs they get are normal HTTP logs, like in Apache where they see whatever computer initiated the request. Blocking random IPs is both stupid and reactive--by the time you know which IP to block, it's too damn late.
The correct solution is to have your email client know better than to make ANY requests to ANY servers, other than your mail server. This includes CSS files, images, and anything else.
Besides, you don't actually need HTML to get this through--the user will suffice. Send them some oddball URL on a server you control that you think they'll visit (an eCard, notice, free porn, whatever). Make that URL something unique (i.e. something no one else will visit) and anyone who visits it has gotten information from that email (whether directly, it was forwarded to them, whatever). Firewalls won't do you a damn bit of good when absolutely ANY old IP or domain with a server they control can be used.
The real trick to it is more generic than embedding an image (something Google took care of in gMail ages ago, if you notice--that's why you have to turn images on all the time). It's giving them information they couldn't have gotten elsewhere, and tracking its spread.
I should know. I programmed one of these several years ago and used it to catch some script kiddie who was trying to hack our site. We nailed his ass and convinced his ISP to cancel his account more than once.
I filed a bug on this while I was working as a tester at MS about 6-8 years ago...
That's a decent solution for now, if you're OK with getting e-mail without images. I know I am, but many people aren't. But if that practice became widespread, the marketers would just start running HTTP servers on the IMAP/POP3/SMTP ports. It's always an escalating arms race. The only real solution is to go back to the days where e-mail was text-only. Oh, how I yearn for those days...
HEY!! What are you doing talking to my mom!?
You don't even need graphics to use HTML for tracking purposes.
...". HP has no such license.
All you need is a UNIQUE URL. Period.
The user might even put the link to a story somewhere.
It doesn't even have to be something "deep inside the site".
It could be something as simple as "press.hp.com", without a link, a subdomain name created just for the purpose of tracking who passes on information to who.
And this is hardly hi-tech.
I was helping vigilantes investigate a scam some years back, where it was not clear where the crooks operated from. They used a webmail service, and we just wanted to track which country the scam originated, as well as get confirmation that the mail was read from the same country as well. I had never heard abut "web bug" or anything like that, but it was obvious to me how to get my answer. I simply sent an html message to the scammers, including a unique image link to my website, and soon after I got my log entry to prove the scammers were in Russia.
That is hardly illegal, becuase
1: The communication had been initiated by the scammers.
2: They were going to make a lot of money if they got away with it.
3: The scammers involved at least one person already under invetigation by FBI.
For an analogy, pretty much what I did was make a chalk mark on the car that tried to run me over.
HP's situation is much worse.
HP did things that police should have been doing, but probably only after a search warrant. It would be fair game to monitor corporate email etc., but to go on to hire gumshoes to dig up dirt on board members is going too far. If HP suspected board members of corporate espionage, they should go to the police. Whan a corporation starts playing James Bond games, they're really heading for trouble. James bond has "License to
I just thought folks might be interested to see what they were actually doing inside the message to try to track the e-mail. I was curious about how ReadNotify was going to pull off some of the claims that they make on their website. ReadNotify didn't track the e-mail I sent to myself because I use a client configured so it doesn't access anything over the network other than the mail server. All ReadNotify knew was that it had been delivered.
Now that is disturbing. And informative; it's enough reason for me to refrain from considering employment with HP.
The Internet is full. Go away.
"Open Source PattyMail..." - Homer Simpson (drools)
with Spam... take that Hormel.
Apple Mail can display the plain text version of an email by default:
Please research your facts before posting incorrect information.
I also tried the experiment with ReadNotify. On receiving the bugged message in Outlook Express, the interesting thing I discovered is that the recipient version of me was informed that the sender was seeking confirmation of receipt. I have OE configured to make that response optional, and I refused to allow the confirmation. Of course, with the bug in there, the ReadNotify system knew I had opened the message anyway. Thus there is an interesting deception going on here. You think that you have declined to return an acknowledgement of receipt, while one has gone out anyway.
to block your e-mail clients attempts to access HTTP ports.
http://www.pcflank.com/fw_rules_db.htm
For Microsoft Lookout block inbound ports 80-83, 443, 1080, 3128, 8080, 8088 and 11523.
nt
I know this is "enumerating badness" but why not just filter the URLs of known offenders of this nature. The real fix of course is to not allow documents to load even "innocous" content but in the meantime this seems reasonable.
You misspelled "foley".
Help stamp out iliturcy.
The solution here isn't regulation. It's just for people to decide whether a feature (in this case, HTML mail) is really worth the risk.
There is no risk. You can have full HTML display, including images, in your E-mail client with no problems whatsoever. Just turn off "remote loading of images"; any legitimate HTML E-mail is going to include everything within the message.
That seems like it would solve the problem while preserving the reason 90% of idiot users want HTML: so they can use bold/italic/flashing-red-text or whatever.
Well, maybe that's true for you and your college buddies. But, in fact, in the business world, people have a legitimate need for sending around formatted text and graphics, and HTML does that quite well. The most common alternative is MS Word attachment, and it has a lot of problems.
Comment removed based on user account deletion
By which I mean software that treats HTML (or Java, or JS, or XML) codes as strings of letters (each one to be looked-up in the characret outline file, then displayed to screen), and that does not even start to display the mail until after the connection to the mail server has been terminated.
In short, an off-line reader. It'll get the message, and only the message, then disconnect from the network (viz - it actually detaches from the TCP/IP stack, or which other protocol it's using). Later, when the viewer is reading their mail, all the content of the message is displayed from the hard drive. If a message's "content" isn't attached as MIME in the body of the mail, then obviously it's not content in any RFC-compliant form.
Just don't use "live" content in email. It's not as if it adds anything significant to messages.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
I'm going to play devil's advocate here...
One thing that detracts from the true 'business' functionality of the Internet is the unreliability of the mail system.
In the real world, we have 'regular' post, which may or may not arrive. We have 'registered' or 'certified' mail, which requires the recipient to acknowledge receipt. We have 'express' services like DHL, Fedex, etc. which give faster delivery plus detailed tracking of where the object is at any point in time.
Why would it be unreasonable for businesses to expect the same from email?
For business (as opposed to personal purposes), there is nothing wrong with having the ability to guarantee delivery, confirm if and when the message was read, and tell whether the message was forwarded to someone else. That's EXACTLY what some of these 'bugs' do.
The problem we have today is exactly BECAUSE the SMTP systm does nothing to confirm the identity of the sender or offer any confirmation or guarantee of receipt. eMail is also totally out of control once it leaves the hands of the sender. It can be hoarded, copied, forwarded to people who should not receive it -- and of course, with the ability to send anonymously -- gives spammers and psychos an easy way to abuse billions of recipients every day.
Maybe we need two mail systems -- one, with PKI, mutual authentication, message confirmation and tracking -- and another system for personal use?
I've mentioned this before, but it bears repeating.
Force all your traffic through a proxy that requires authentication for the services that supports it (http/https/ftp), and deny everything else. Create specific exceptions if required, but enforce the authenticated http traffic, it'll stop all of these web bugs in documents, email etc.
Turning off remote loading of images will not prevent IFRAME bugging, or many other HTML remote-resource bugs.
So that's not the solution you think it is. To prevent bugging, you would need to disable the following HTML elements:
[img]
[iframe]
[style src=""]
[script src=""]
[input type="image" src=""]
[link rel="stylesheet"]
[link rel="next"] (In rendering engines that prefetch)
[embed]
[applet]
[object]
[frame]
Some CSS elements and JavaScript also need to be disabled. Basically, this is the "neutering" that I was discussing. A smart email system (e.g. a corporate one) could be set to block these only from sources originating outside the company; that would prevent its use by spammers but certainly wouldn't have helped the HP folks any.
If you really need to attach graphics, then attach it to the email; MIME exists for a reason and doesn't have the bugging (or dead link) issues that HTML links do. It would be trivial to allow IMG tags that refer to attached files and not remote ones, if this was really needed.
Actually attaching a Word document should be a much safer and better alternative; it's only because of some grevious security problems in Word (macros, embeddable OLE objects, etc.) that it's not safe. If Word treated documents purely as data, and sandboxed it in such a way as to prevent any executable code from being run, or remote resources fetched as a result of instructions in the document, then they would be less prone to bugging than HTML.
Your ad hominem about me being in college is misplaced; I've been out of college and in business for quite a while now, and I have yet to see any convincing demonstrations of the superiority of HTML email over straight text, or over text plus attachments. If anything, it is the overuse of HTML formatting and graphics (particularly backgrounds) in business communications that has convinced me that rendering should be scaled back to a bare minimum. There are far better ways to share format-intensive documents than trying to cram them into the body of an email.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."