"J. P. Gilliver (John)" <G6JPG-***@255soft.uk> wrote
| >Remote images are pretty much by definition
| >web bugs.
|
| I haven't done any analysis for a while, so you're probably right. Last
| time I looked, some of the "images" - especially company letterheads and
| the like - were remote images to reduce the load on the outgoing mail
| server (total size of all emails sent).
That's possible. Putting it in the email adds
1/3 for base-64 encryption. It can also be done
for both reasons.
Another problem with remote links is that they
make phishing emails easier. Those will often link
to images from domains like wellsfargo.com, to give
the appearance of an official banking email.
But the web bug problem is substantial and
arguably a good reason not to allow remote
linking. Companies like Constant Contact advertise
the ability to know when an email is opened and
how much of it is read. I assume they depend
on webmail read in a browser, but allowing remote
images in an email client also makes that tracking
possible.
Today I went to celebrate Fathers Day at the
assisted living place where my father lives. The
email sent to tell me about the event had external
links to Facebook with unique IDs. It also had a
link to sidekickopen08.com, with a GUID. I did
a whois on that domain and found it's owned by
Hubspot, which turns out to be a "CRM" and
marketing company. That was just in what was
supposed to be a fairly personal from an assited
living center. Two sleazy, datamining companies
were set to collect a record of my reading the email.
And it's not just images. Recently a friend asked
me to look at her "liberal" news email. She gets news
emails from a liberal activist group, which she then
forwards to friends. I think it's thehill.com. The emails
are stuffed with links to other sites, some less reputable
than others. At least one of the links had her full name,
home address and email address base-64-encoded in
the link. So anyone she forwards to who follows that
link will be reporting her personal info as the source
of their click. Not only her info, but enough to put her
on a postal mailing list as well as an email mailing list.
And that's the people who claim to be the good guys.
The data collection is ravenous.
I've been noticing that kind of thing has also been
increasing on websites. You click a link to sears.com
and the link is not to sears.com. Rather, it's something
like:
thissleazywebsite.com&x=sears.com/somepage.html&
adclient=1734&ID=12345678-1234-1234-1234-123456789012
.... and so on.
Little tricks to connect the dots of one's activity are
popping up everywhere.
| I remember the JPG one. (Buffer overflow wasn't it?) Turnpike (and
| IrfanView) don't use the vulnerable Microsoft libraries that that one
| used, to display JPEGs.
|
Gdiplus.dll is very basic. It was made to be an
update to gdi.dll. Gdi is the basic graphics library
that deals with fonts, drawing, handling images,
etc. Gdiplus adds things like parsing JPG files.
But that bug was many years ago and it was
patched. I only mention it because it's an example
of how hard it is to be sure about computer
security. Virtually all bugs require executable code,
but that one didn't.
| some text
| [image 1]
| some more text
| [image 2]
| some final text
|
| The way I mean by "truly embedded" sends it like this (no HTML required,
| either):
|
| some text
| [image 1, encoded in MIME or UU]
| some more text
| [image 2, encoded]
| some final text
|
The only way I know of to do that would be a
data URI in HTML. It's inline base-64 encoding.
Some pages embed fonts that way. It's also a
handy way to embed images in an HTML file
wtihuot needing to have any external files:
<IMG WIDTH=360 HEIGHT=287 SRC="data:image/jpeg;base64,/9j/4AA......
| but the way most clients seem to create is
|
| some text
| [pointer 1, often in the form <cid:xxxxx>]
| some more text
| [pointer 2]
| some final text
| [image 1, encoded] <== these not _necessarily_ in the same
| [image 2, encoded] <== order as the pointers
|
| _Most_ modern clients, if they receive an email of the "truly embedded"
| format, will at best display up to and maybe including image 1, but will
| present the "some more text", image 2, and the "some final text", as
| just a list of attachments at the end (or wherever they normally present
| a list of attachments).
I'd be curious to see the code of "truly
embedded". I've never seen that before.
The internal linking to a separate MIME
section is the standard. If it uses a CID
it links to a section marked with
Content-ID: [same as CID]
If it's an attachment that's indicated by
Content-Disposition.
That's all standards for email formatting. I don't
know of any other methods. Even if it were just
encoded inline like you describe, there would have
to be some kind of standard marker that tells the
client what that blob of base-64 is supposed to be.
| Well, I can send and receive emails of the truly embedded type,
| _without_ involving any HTML. (In fact I don't think I can create them
| _with_ HTML.)
If it's not too much trouble maybe you could post one,
taking out most of the base-64 for brevity. I'm curious
what it is you're talking about.