Microsoft hints at playing hardball to push Win10

"J. P. Gilliver (John)" 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.

"Steve Hayes" wrote

| Yes, I have ones where what they put in the plain text part is "Your
| mail reader is not HTLM capable".
|
| It is HTML cap[able that is what I see because I have set it by
| default to open the plain text version, and if I get mail that says
| that agauin I usually delete it. It's usually spam anyway, and I
| regard HTML mail as a spammer's trick.
|

It sounds like you need a spam filter. I get
maybe 5-6 per day but the name and subject
are almost never convincing enough to look
at them. Lately most are from Russia, using my
contact webpage form, always from different
nonsense domains, but the subjects are gibberish,
so I don't need to check them. And the names are
never quite right, like "Romero Livingston" or
"Lydia Summers".
The rest are stopped by "Spam Assassin" on my
host server, set to delete known spam.

I also get occasional commercial spam. There's
a building supply company called Harvey Industries,
for instance. They won't let me order without an
email address to send the order receipt to. Then they
spam it. They think they're being clever.
But those spam can be easily filtered. They're what
I think of as "legitimate sleaze". They're not trying
to hide who they are, so it's not hard to auto-delete
them from the server or send them to the deleted
items folder.

Today I got one from developer.com. I have no
idea how they got my email, even though it
sounds familiar. But something about it sent it
directly to deleted email.
I looked it up. Developer.com is owned by a company
called Quinstreet, which buys up domains and then
uses them to do advertising. I'm thinking that
developer.com might have been formerly owned
by CNet. (Actually, CNet hasn't really been legitimate
for a very long time, either.)

What a pitiful idea for a business. Quinstreet buys
up domains that used to be legitimate and apparently
then milks them for advertising until people catch on.

pyotr filipivich wrote:
[...]
Bang addresses, and "You had transformers to step down the power?
Luxury! We used to have to have gran bite the wires in her teeth."

Ah, the good old days, they was rotten.

Yup, bang addresses:

....!hplabs!mcvax!hpuamsa![frank!root!news]

Mayayana wrote:
[...]

It can include them as attachments, but not displayed.
Plain text means plain text. I can't even see ketchup red
comic sans on a bile yellow background. (I used to know
someone who sent here email like that.)
With attachments one can look at the email and
possibly the encoding before the image displays. Though
actually, these days I often look directly at the source
code of anything I'm not sure about, before letting it
preview.

This thread cause me to look at the source of a message I sent a few
days ago.

It was a text/plain message with a text/plain attachment (.txt
file). But while the .txt file was pure ASCII (0-127) text, Thunderbird
base64-encoded the attachment, so viewing the source of the message did
not show the innocent text of the attachment, but the base64-encoded
'gibberish'. Sigh!

[At least the text/plain message was not base64-encoded, so *its*
content could be seen in the source.]

A little earlier, I wrote:
pyotr filipivich wrote:
[...]
Bang addresses, and "You had transformers to step down the power?
Luxury! We used to have to have gran bite the wires in her teeth."

Ah, the good old days, they was rotten.

Yup, bang addresses:

...!hplabs!mcvax!hpuamsa![frank!root!news]

Oops, make that:

....!hplabs!mcvax!hpuamsa![frank|root|news]

"Frank Slootweg" wrote

| It was a text/plain message with a text/plain attachment (.txt
| file). But while the .txt file was pure ASCII (0-127) text, Thunderbird
| base64-encoded the attachment, so viewing the source of the message did
| not show the innocent text of the attachment, but the base64-encoded
| 'gibberish'. Sigh!
|
| [At least the text/plain message was not base64-encoded, so *its*
| content could be seen in the source.]

I sometimes get base-64-encoded text content.
Email programs know to handle it, so I usually don't
notice unless I'm looking at a suspicous email's
source code.

I don't know what the point is, unless to get past
spam filters. Since it's base-64 it makes the email
larger, yet there's no added security, since base-64
is obvious and easy to decode.

Maybe it's a leftover from a more innocent time when
base-64 was considered to be encryption. In MIME
standards it's a typical option to pass username and
password as base-64. Someone must have thought
that was more private than plain text.

"Mayayana" news Sun, 17 Jun 2018 12:39:14 GMT in alt.windows7.general, wrote:

And you like it that way? Plain text is safer,
with better privacy. (Spyware web bugs from the
likes of Constant Contact won't work in plain text.
Though they also shouldn't work in an email client.
They're designed for use with web-based email
readers.)

Agreed...

There's only one case I currently deal with where
email doesn't work in plain text. It's from an
assisted living center. The director is not experienced
with computers and usually sends his emails as
JPG files. He doesn't write anything. He just pastes
in a JPG. But even then it's not a problem for me.
I get the JPG as an attachment.

Tech support can be interesting at times, eh?


--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit he
https://tekrider.net/pages/david-brooks-stalker.php
================================================== =
Customer explaining flooded car to insurance claim investigator:
"It didn't look that deep at first glance - it only came half way up
the ducks."