[QUOTE=Mangetout]
Spammers definitely try to determine whether your account is live or not; very often, they’ll do this by embedding a uniquely-named 1x1 pixel image somewhere in the email; the Image doesn’t even exist on their server, but when you open the email, your client tries to retrieve it to render it on the screen; when it requests the image from their server, they know you’ve read the mail (they know it was you because of the unique name they assigned to the image tag in the email they sent to you)
[/QUOTE]
What you’re describing is is known as a “web bug”. A clear 1x1 pixel. It doesn’t have to be this, of course, it could be a 100x100 picture just as easily; one that was already intended to be in the mail.
A web bug can be tailored to your individual e-mail address. We, my old company, experimented with adding one at the very top and very bottom of the e-mail. From that we could guess how fast your connection speed was, by recording the time between when the first and last bug was served. (This was to be used for “rich media” mailings, to be sent to high-speed customers only.)
We experimented with per-user bugs, too, but that’s very costly - it requires you to have a big database on the backside recording the custom pixel address vs. email address.
Usually we used generic bugs, per mailing, but not per user. What our clients were interested in was “open rates”. How many users discard email based on nothing more than the header vs how many opened it (and presumably read it). This is aggregate data and individualized bugs weren’t necessary.
If we wanted to know legitimate vs. broken addresses, we could, and did, scrape our outgoing mailer logs. We knew successful delivery rates and could tell a “dirty list” from a legitmate opt-in list by the bounce rates pretty dependably. (Our contract with our clients said that we only accepted lists that were opt-in, not harvested or purchased. Despite this, we knew certain clients would buy lists on occaision. We had, a couple of times, cancelled a client’s contract due to consistent abuse of the opt-in policy).
The illegitimate spammer isn’t going to use a web-bug. They’re a volume business, sending a million, delivering ten-thousand is OK by them. Processing inbound bounces and inbound web-bugs are beyond their scope. If they’re running their own servers, they’re discarding or redirecting their bounces so they don’t see them. If they’re just pumping through and ISP, they’ll probably be faking their return addresses.