User Not Found, Email Drops Silently
shervinafshar writes with an International Herald Tribune story explaining just why it is failed emails don't always result in a helpful error message for the sender, which also gives some insight into ways that email can be used to spy on recipients. "In last lines of the article, two companies are introduced which provide services that can 'spy' on your email reading habits. They also can 'call home' too: 'Some entrepreneurs have seen that uncertainty and offered senders the ability to obtain receipts that a given message has been read — without the recipient knowing that a confirmation has been sent back to the sender. ReadNotify, based in Queensland, Australia, started in 2000 and promised to report not only on whether a message was read, but also on how long it was opened for reading on the recipient's PC. It can also send the message in "self-destructing" form, preventing forwarding, printing, copying and saving.' IHT also is asking its readers to comment about these kind of services being against user privacy."
Thunderbird defaults to asking when someone asks for a return receipt; I always change the setting to not even ask but simply never to send them. It is nobodies business to know whether, not to mention when I have first opened their e-mail (which is also, by the way, not the same thing as actually reading it).
In addition, you should set your client to never download external images. This should solve about 99% of these "exploits". As far as I can remember, the company mentioned uses a transparent/invisible image on an intentionally slowed down server that feeds the image byte by byte; usually, mail clients disconnect/cancel the download once you click another message.
I can only imagine "preventing" forwarding to work with really retarded mail clients (I think we all know the one I'm talking about).
The very valid reason why mail servers don't always return a message when a mail address does not exist, is because this can be used to phish for existing usernames - when you don't get a bounce message, you know you've probably hit a valid username. (because for most systems, login/username = default mail alias)
Every expression is true, for a given value of 'true'
The other thing I see around here is the people who request a receipt (we use Outlook) when they send a global email to all 1500 users on the system. Most of them only do it once.
Here's a good summary of why such plans won't work:
http://theamigo.blogspot.com/2007/07/expiring-email-no-not-really.html
Hotmail doesn't loaded remote images, and would even prevent you from clicking on a link if the sender was unknown. They have been doing this for quite a while.
Difference is that the recipient is notified about the return receipt and they can choose to take action from there.
Transparent images embedded in html emails (which never should have been started in the first place) are a different kettle of fish, in that most users won't realize that their email is being monitored
I suppose one way of gaining awareness would be setting up a system (think Sorbs/Spamhaus), which lists domains of people who embed sort of shit in their emails.
Companies frown upon negative publicity and if you can say "Hey, you're listed because jbloggs@example.com sent out an email with this shit in it", then I can't see the company continuing to do that for very long
I'm surprised the author didn't link to the actual services:
Both seem to be easily defeated; indeed, the ReadNotify FAQ mentions that the "invisible" tracking service (which I assume means that it just includes the tracking images in the message) may be unreliable.
I request that people set their email clients to text for forums I'm on...and often, people will do it and didn't know they could change this setting on their email client. Why is html mail the default on so many clients anyway?
Anyway...I was wondering how this company would get this type of info reading plain old email, but, I'd forgotten about using clients set up to download images, javascript...etc.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
Gmail was certainly not the first. I know that Rocketmail(now Yahoo!) and Hotmail had this feature long before Google as a company even existed.
If you sends bits to MY computer, using MY libraries, and running MY kernel, those bits are mine to do with as I wish,
The copyright still remains with the sender, so, no, they are not yours. Furthermore, you cannot legally do with them as you wish.
I return bounces for all errors. If it's coming from a spammy host, there are other solutions far more effective and precise to reduce their volume. For one, Postfix drops the connection if several consecutive errors occur, and greylisting is a marvel against the common pump-and-dump spammers. There are a lot of small things that come together in the modern spam fighting arsenal, few of them require breaking the spec.
-Billco, Fnarg.com
The MIME standards (which are entirely optional) do not require duplicate text and html versions of a message either. There are several MIME content types, of which only multipart/alternative is intended for duplicate content with degraded formatting such as separate text and html versions, and in this case the actual formats can be anything, eg they could be a text version and an MS Word version, without an HTML version.
Well - the overhead isn't big in terms of size - but when you have 18 different images linked to from offsite, it becomes a whole different issue. (And that's just for normal 'catalog'/advert emails that get sent out, not counting this lame tracking silliness.)
...I have my mail software set up so it bounces html-only email (that it doesn't think is spam) back to the sender with an error message explaining that html-only email violates internet standards.
Um. I'm unaware of any IETF standard regarding HTML-formatted email transmission. Unless you can link me to such a standard, there is no violation.Also, you are an ass. Additionally, if you're unable to configure an MUA produced in the last five years to correctly render HTML email, you're a fucking moron.
when you have 18 different images linked to from offsite, it becomes a whole different issue.
Then your problem is not with HTML email, it's with HTML email that links to 18 different images.
And that's just for normal 'catalog'/advert emails that get sent out, not counting this lame tracking silliness.
It only takes a single image to do this tracking. And there are plenty of normal commercial HTML mailings with not a single image. Rich text can actually be useful, you know. The fact that pretty much the entire web opts to use rich text rather than plain text should tip you off to that.
Given you check your email from a known webpage, and visit a lot of non-email webpages, a blacklist solution such as given by yesscript is actually a lot more practical than noscript.
I tried noscript, and it brought the web experience back to the nineties... I'm using yesscript now.
Wanna know the kicker here? Without taking the time to read the article, I bet, you're likely one of the people who bitches about blowback spam. Which is it? Do the folks want to be notified when it doesn't reach the sender or not? Me? I'll take notification and delete the blowback like I do the rest of the garbage.
I'm not the person you are replying to, but here are my (unasked for) 2 cents:
If by blowback spam you mean backscatter spam, it doesn't have to be an "either or" situation. Backscatter spam is caused by poorly written or misconfigured smtp server that will accept a message before processing it for errors (unknown recipients, spam, virus, etc.). A lot of these servers are MS Exchange even tho Exchange provides a mechanism (or filter) to reject these messages at the smtp transaction. Blame it on clueless and lazy mail admins.
And postfix admins, if your distro came with "unknown_local_recipient_reject_code = 450", please remember to change it to 550. It won't cause backscatter, but it will make my users (and probably yours as well) complain needlessly about undelivered mail, when a bounce would have solved the problem in seconds.
No sig
Okiedokie, time to add my $0.02 to the pot :-D
The key difference is that backscatter generating SMTP servers accept an email, close the connection with the remote server, realize that there is no local user by that name, and then generate a bounce e-mail (usually, but not always) with the content of the original message. As spammers usually put some unsuspecting third party's e-mail address as the "from" or "reply to", the third party gets the bounce, AKA backscatter.
The other approach is this: mailserver recieves inbound SMTP connection. When the initial chitchat between the mailservers gets to the part where the remote server lists the recipients, our mailserver recognizes that there is no local e-mail address by that name, and promptly rejects the mail. If the remote mailserver is legitimate, it will then generate a bounce itself, which will go to the (hopefully authenticated) person who sent the e-mail. If the remote mail server is a spam bot, it will just go on to the next target in its list.
So, from a backscatter prevention angle, it's better to reject an e-mail that will cause a bounce at the time of the original SMTP connection, instead of accepting it and then generating a bounce locally at a later time.
kmem russian roulette: Aquillar> dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM
Posting it via the net (email) IS publication. There is NO assumption whatsoever of privacy, unlike sealed mail through the post office. It has the same effect as a post card. If you believe your email isn't scanned, backed up on various servers, etc., you're naive. At any one time ther are multiple copies of your email sitting on your machine, the recipient's machine, undeleted mail queues, etc.
Email is not private. Get over it. If you want privacy, use pgp, or gpg. Don't depend on copyright law to "prevent copying", since for email to work, copies MUST be made - your original didn't disappear from your computer when you "sent" it - only a copy of the data was sent, and you gave authorization for that copying to be made in the act of sending.
Nuts, wasn't logged in so posting this again:
Gmail does however automatically send back read-reciept notification without prompting the user so loading images is immaterial. As part of a mailing list discussion I tested the readnotify.com services and I was frankly surprised by that behavior. While readnotify.com won't be able to get the detailed tracking information, they will be able to determine that someone at least opened the message.
Uh, no it isn't. Granted, a lot of the objects transported over HTTP are text/html, but a lot of them aren't. And you can put text/plain documents up on the web to your heart's content. Most people don't do this very often because with the textual part of the web, unlike with email, the point is to link to other things (hence the term "web"). Furthermore, you don't need HTML to link to other things in email because decent mail clients recognize links in plain text emails anyway.
Now, if Outlook could come configured by default to prevent sending the messages in the first place, that would really help conserve bandwidth.
I am not responding to your post in particular, but it is as convenient a spot as any in the sea of "No HTML email!" posts. I use HTML email for one reason: text formatting. I like including underlines and italics in my emails for emphasis. Yes, I can post like I do here on slashdot and use /slashes/ for emphasis in plain text, but come on, this isn't 1980 anymore, you know?
At work I frequently embed images in my emails because I am discussing engineering problems and it is frequently useful to include pictures to describe the problem.
But the primary reason I use HTML email is for text formatting.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.