Another LONG page . . .
I know that this is another of my loooooong pages. I worry that it won't
be nearly as fascinating as my account of ILoveYou and FBI NIPC’s incompetence.
However, this is a complex and important issue that can not be quickly
Research Corporation has a lot of really smart people — from Steve Gibson and
… um … well, from Steve right on down the line. But they are human, and they
sometimes make human mistakes. Sometimes it's worse than that, and as a
company they're stubborn in the face of some really bad decisions.
My concern today is
that we have another
SERIOUSLY DUMB IDEA in the works
from RFC standards in eMail attachments.
my silence when MIME was being added to eMail. It was the dumbest thing I had
ever seen, but I didn't care since I use PINE. So I didn't work to make the
world take notice. Now eMail chain letters are born daily to travel the Internet at
light speed. And it could have — should have — been prevented.
time, with the disaster of eMail attachments looming, there is still time
to get the Internet to yank it out. But I have not yet managed to reach the right people or convince
them that they must.
What is "eMail"?
And why are some of them "Attached"?
The Internet — back then a nuclear-era
experiment known as “ARPANet,” first mated eMail clients to each other so
they could “speak”.
This was done by implementing the Internet protocols and creating a
so-called "Mail Transfer Agent". This is shown as
concentric squiggly lines in the diagram to the left.
exchanged across the Internet by either establishing an "SMTP Connection"
between two machines, or by sending a "UUE
thingamabob" from one machine to another. Both of these data transferring
operations employ SMTP standards.
and orderly traffic flow across the Internet requires machines to inform
each other of various non-data events such as “header” information, eMail
address verification, ficticious spam sender addresses, etc. The SMTP (Simple
Mail Transport Protocol) was created to fill this need.
operating system's built-in eMail client automatically and transparently
generates and receives most of these "Internet plumbing" SMTP
messages on behalf of the machine. To facilitate the creation of Internet
plumbing applications, such as "Eudora" and "Outlook",
which also employ SMTP messages, the Department of Defense designers
allowed programmers to manually generate and receive their own SMTP, and
other, message traffic. As shown in the diagram above, the SMTP system
provides this power through the use of a so-called "MTA". A
direct SMTP connection short-circuits your company or ISP’s MTA to open a
"backdoor" directly into the underlying network eMail transport.
This provides full
and direct "SMTP level" Internet
access to any Mail Transfer Agent.
their use for supporting simple "Eudora" and "Outlook" programs,
the original designers intended eMail attachments to be used for Internet
protocol research purposes only. Because they fully appreciated the
inherent danger of abuse of eMail attachments, they deliberately denied eMail
attachment access to any computers not running antivirus software. Doofus
users were thus prevented from accessing and potentially abusing the eMail
Email Attachments were
created as a potent research
tool. They were NEVER INTENDED to be shipped in a
mass-market consumer eMail client.
The Traditional (safe)
the PINE program to other programs like “Eudora.” You will
notice that the PINE’s connection does not "penetrate" the
egotistical Mail Transfer Agent.
means that while eMail attachments can be readily used for their intended
and safe purpose of forwarding raunchy jokes, application programs are
effectively cut off from direct "lower-level" access to the
underlying physical operating system.
am FULLY aware that full eMail attachment-style access can be created by
modifying any standard operating systems through the addition of
third-party email clients. I have been a user of such tools for years.
However, as I demonstrate below, aftermarket operating system modifications
have proven to be irrelevant to the purposes of malicious spammers.
as I stated in my I Can’t Spank a 13yr-old Report,
and as I will demonstrate and prove conclusively below . . .
The Internet’s traditional
lack of eMail attachment
support has been a
silent blessing that
has undoubtedly contributed hugely to the
stability of the global Internet of the past.
It is the Internet's future that concerns me greatly . . .
What IS the threat
from Full eMail Attachments?
I constructed the diagram above in the form of insulating layers surrounding
the system's network core to help demonstrate that the operating system's MTA
and SMTP protocol layers serve to protect the Internet from direct access by
malicious attachments roaming around in eMail.
Any system whose
from arriving in eMail
will be MUCH
harder to exploit.
advent of RFC 822, the most common and familiar, complex, potent, and
untraceable Denial of Service and Distributed Denial of Service attacks have
only been generated by spammers. Due to the sheer volume of RFC 822
compliant machines soon to be loose in the world, spammers will quickly be
supplanted as the premiere launching pad for new torrents of eMails. This
will have an unfortunate corollary effect for eMail users:
The huge number of
eMail client machines will motivate
spammers to find new ways into those machines — AND
THEY WILL. Then users of eMail clients will become
sought-after target for penetration.
words, the use of the high-power, mass-market and unsecurable eMail
attachment, promises to paint a big target on every user of that system.
hands of a clueful spammer, fully-supported eMail Clients is the enabling
factor for the creation of a series of "Ultimate Weapons" against
which the fundamentally trusting architecture of the global Internet
currently has no effective defense.
Email Attachments are the malicious
spammer's dream come true.