746 lines
34 KiB
Text
746 lines
34 KiB
Text
==Phrack Inc.==
|
|
|
|
Volume Four, Issue Forty-One, File 4 of 13
|
|
|
|
Network Miscellany
|
|
*******************************************************
|
|
< The POWER of Electronic Mail >
|
|
*******************************************************
|
|
Compiled from Internet Sources
|
|
|
|
by The Racketeer
|
|
of The Hellfire Club
|
|
|
|
Network Miscellany created by Taran King
|
|
|
|
|
|
First of all, this guide is more than using fakemail. It literally
|
|
explains the interfaces used with SMTP in detail enough that you should gain a
|
|
stronger awareness of what is going on across the multitude of networks which
|
|
make up the worldwide e-mail connections. It also contains my usual crude
|
|
remarks and grim hacker humor (assuming it hasn't again been edited out, but
|
|
I'm somewhat proud of the fact that Phrack heavily edited my "language" in last
|
|
issue's article. Oh well.).
|
|
|
|
There are two objectives in this file: first, I will attempt to show that
|
|
by using fakemail and SMTP, you can cause an amazing number of useful, hacker
|
|
related stunts; second, I shall attempt to be the first hacker to ever send a
|
|
piece of electronic mail completely around the world, ushering in a new age of
|
|
computerdom!
|
|
|
|
I suggest that, unless you don't want everyone lynching you, don't try to
|
|
fuck up anything that can't be repaired offhand. I've experimented with
|
|
fakemail beyond this article and the results were both impressive and
|
|
disastrous. Therefore, let's examine risks first, and then go onto the good
|
|
stuff. Basic philosophy -- use your brain if you've got one.
|
|
|
|
|
|
RISKS:
|
|
|
|
Getting caught doing this can be labeled as computer vandalism; it may
|
|
violate trespassing laws; it probably violates hundreds of NFS, Bitnet and
|
|
private company guidelines and ethics policies; and finally, it will no doubt
|
|
piss someone off to the point of intended revenge.
|
|
|
|
Networks have fairly good tracing abilities. If you are logged, your host
|
|
may be disconnected due to disciplinary referral by network authorities (I
|
|
don't think this has happened yet). Your account will almost definitely be
|
|
taken away, and if you are a member of the source or target computer's
|
|
company/organization, you can expect to face some sort of political shit that
|
|
could result in suspension, expulsion, firing, or otherwise getting the short
|
|
end of the stick for awhile.
|
|
|
|
Finally, if the government catches you attempting to vandalize another
|
|
computer system, you will probably get some sort of heavy fine, community
|
|
service, or both.
|
|
|
|
Odds of any of this happening if you are smart: < 1%.
|
|
|
|
|
|
PRECAUTIONS SUGGESTED:
|
|
|
|
If you have a bogus computer account (standard issue hacker necessity)
|
|
then for crissake use that. Don't let "them" know who really is hacking
|
|
around. (Point of clarification, I refer to "them" an awful lot in RL and in
|
|
philes. "They" are the boneheadded "do-gooders" who try to blame their own
|
|
lack of productivity or creativity on your committing of pseudo-crimes with a
|
|
computer. FBI, SS, administrators, accountants, SPA "Don't Copy that Floppy"
|
|
fucks, religious quacks, stupid rednecks, right wing conservative Republican
|
|
activists, pigs, NSA, politicians who still THINK they can control us, city
|
|
officials, judges, lame jurors that think a "hacker" only gets
|
|
slap-in-the-wrist punishments, lobbyists who want to blame their own failed
|
|
software on kids, bankers, investors, and probably every last appalled person
|
|
in Stifino's Italian Restaurant when the Colorado 2600 meeting was held there
|
|
last month. Enough of the paranoid Illuminati shit, back to the phile.)
|
|
|
|
Make sure that you delete history files, logs, etc. if you have
|
|
access to them. Try using computers that don't keep logs. Check /usr/adm,
|
|
/etc/logs to see what logs are kept.
|
|
|
|
If you can avoid using your local host (since you value network
|
|
connections in general), do so. It can avert suspicion that your host contains
|
|
"hackers."
|
|
|
|
|
|
IF YOU EVER ARE CONFRONTED:
|
|
|
|
"They must have broken into that account from some other site!"
|
|
|
|
"Hackers? Around here? I never check 'who' when I log in."
|
|
|
|
"They could have been super-user -- keep an eye out to see if the scum
|
|
comes back."
|
|
|
|
"Come on, they are probably making a big deal out of nothing. What could
|
|
be in e-mail that would be so bad?"
|
|
|
|
"Just delete the account and the culprit will be in your office tomorrow
|
|
morning." (Of course, you used a bogus account.)
|
|
|
|
|
|
PART ONE: ELECTRONIC MAIL
|
|
|
|
Basically, electronic mail has become the new medium of choice for
|
|
delivering thoughts in a hurry. It is faster than the post office, cheaper
|
|
than the post office, doesn't take vacations all the time like the post office,
|
|
and is completely free so it doesn't have unions.
|
|
|
|
Of course, you know all that and would rather spend this time making damn
|
|
sure you know what SMTP is.
|
|
|
|
To my knowledge, a completely accurate SMTP set of protocols hasn't been
|
|
published in any hacker journal. The original (at least, the first I've seen)
|
|
was published in the Legion of Doom Technical Journals and covered the minimum
|
|
SMTP steps necessary for the program "sendmail," found in a typical Unix
|
|
software package.
|
|
|
|
When you connect a raw socket to a remote SMTP compatible host, your
|
|
computer is expected to give a set of commands which will result in having the
|
|
sender, receiver, and message being transferred. However, unlike people who
|
|
prefer the speed of compression and security of raw integer data, the folks at
|
|
DARPA decided that SMTP would be pretty close to English.
|
|
|
|
If you are on the Internet, and you wanted to connect to the SMTP server,
|
|
type:
|
|
|
|
telnet <hostname> 25
|
|
|
|
Port 25 is the standard port for SMTP. I doubt it would be too cool to
|
|
change this, since many mail servers connect to the target hosts directly.
|
|
|
|
[Editor's Note: All mail and SMTP commands have been offset by a ">" at the
|
|
beginning of each line in order not to confuse Internet mailers when sending
|
|
this article through e-mail.]
|
|
|
|
When you connect, you will get a small hostname identifier for whatever
|
|
SMTP server revision you've got.
|
|
|
|
220 huggies.colorado.edu Sendmail 2.2/2.5 8/01/88 ready at Tue, 25 Aug 91
|
|
03:14:55 edt
|
|
|
|
Now that you are connected, the computer is waiting for commands. First
|
|
of all, you are expected to explain which computer you are calling in from.
|
|
This is done with the HELO <host> command. This can be anything at all, but if
|
|
you fail to give the exact host that you are connecting from, it causes the
|
|
following line to appear on the e-mail message the recipient gets from you:
|
|
|
|
> Apparently-to: The Racketeer <rack@lycaeum.hfc.com>
|
|
|
|
Instead of the classic:
|
|
|
|
> To: The Racketeer <rack@lycaeum.hfc.com>
|
|
|
|
This is the secret to great fakemail -- the ability to avoid the
|
|
"apparently-to" flag. Although it is subtle, it is a pain to avoid. In fact,
|
|
in some places, there are so many "protections" to SMTP that every outside
|
|
e-mail is marked with "Apparently-to." Hey, their problem.
|
|
|
|
So, go ahead and type the HELO command:
|
|
|
|
> HELO LYCAEUM.HFC.COM
|
|
|
|
The computer replies:
|
|
|
|
250 huggies.colorado.edu Hello LYCAEUM.HFC.COM, pleased to meet you
|
|
|
|
Oh, a warm reception. Older sendmail software explains with the HELP
|
|
command that the computer doesn't care about HELO commands. You can check it
|
|
upon login with the command "HELP HELO."
|
|
|
|
Now what you will need to do is tell the computer who is supposed to get
|
|
the letter. From this point, there are all sorts of possibilities. First of
|
|
all, the format for the recipient would be:
|
|
|
|
> RCPT TO: <name@host>
|
|
|
|
And *NOTE*, the "<" and ">" symbols should be present! Some computers,
|
|
especially sticklers like Prime, won't even accept the letters unless they
|
|
adhere specifically to the protocol! Now, if you give a local address name,
|
|
such as:
|
|
|
|
> RCPT TO: <smith>
|
|
|
|
...then it will treat the mail as if it were sent locally, even though it
|
|
was sent through the Internet. Giving a computer its own host name is valid,
|
|
although there is a chance that it will claim that the machine you are calling
|
|
from had something to do with it.
|
|
|
|
> RCPT TO: <smith@thishost>
|
|
|
|
...will check to see if there is a "smith" at this particular computer. If
|
|
the computer finds "smith," then it will tell you there is no problem. If you
|
|
decide to use this computer as a forwarding host (between two other points),
|
|
you can type:
|
|
|
|
> RCPT TO: <smith@someotherhost>
|
|
|
|
This will cause the mail to be forwarded to someotherhost's SMTP port and
|
|
the letter will no longer be a problem for you. I'll be using this trick to
|
|
send my letter around the world.
|
|
|
|
Now, after you have given the name of the person who is to receive the
|
|
letter, you have to tell the computer who is sending it.
|
|
|
|
> MAIL FROM: <rack@lycaeum.hfc.com> ; Really from
|
|
> MAIL FROM: <rack> ; Localhost
|
|
> MAIL FROM: <rack@osi.mil> ; Fake -- "3rd party host"
|
|
> MAIL FROM: <lycaeum.hfc.com|rack> ; UUCP Path
|
|
|
|
Essentially, if you claim the letter is from a "3rd party," then the other
|
|
machine will accept it due to UUCP style routing. This will be explained later
|
|
on.
|
|
|
|
The next step is actually entering the e-mail message. The first few
|
|
lines of each message consists of the message title, X-Messages, headers,
|
|
Forwarding Lines, etc. These are completely up to the individual mail program,
|
|
but a few simple standards will be printed later, but first let's run through
|
|
the step-by-step way to send fakemail. You type anything that isn't preceded
|
|
by a number.
|
|
|
|
220 hal.gnu.ai.mit.edu Sendmail AIX 3.2/UCB 5.64/4.0 ready at Tue, 21 Jul 1992
|
|
22:15:03 -0400
|
|
> helo lycaeum.hfc.com
|
|
250 hal.gnu.ai.mit.edu Hello lycaeum.hfc.com, pleased to meet you
|
|
> mail from: <rack@lycaeum.hfc.com>
|
|
250 <rack@lycaeum.hfc.com>... Sender ok
|
|
> rcpt to: <phrack@gnu.ai.mit.edu>
|
|
250 <phrack@gnu.ai.mit.edu>... Recipient ok
|
|
> data
|
|
354 Enter mail, end with "." on a line by itself
|
|
> Yo, C.D. -- mind letting me use this account?
|
|
> .
|
|
250 Ok
|
|
> quit
|
|
|
|
Now, here are a few more advanced ways of using sendmail. First of all,
|
|
there is the VRFY command. You can use this for two basic things: checking up
|
|
on a single user or checking up on a list of users. Anyone with basic
|
|
knowledge of ANY of the major computer networks knows that there are mailing
|
|
lists which allow several people to share mail. You can use the VRFY command
|
|
to view every member on the entire list.
|
|
|
|
> vrfy phrack
|
|
250 Phrack Classic <phrack>
|
|
|
|
Or, to see everyone on a mailing list:
|
|
|
|
> vrfy phrack-staff-list
|
|
250 Knight Lightning <kl@stormking.com>
|
|
250 Dispater <dispater@stormking.com>
|
|
|
|
Note - this isn't the same thing as a LISTSERV -- like the one that
|
|
distributes Phrack. LISTSERVs themselves are quite powerful tools because they
|
|
allow people to sign on and off of lists without human moderation. Alias lists
|
|
are a serious problem to moderate effectively.
|
|
|
|
This can be useful to just check to see if an account exists. It can be
|
|
helpful if you suspect a machine has a hacked finger daemon or something to
|
|
hide the user's identity. Getting a list of users from mailing lists doesn't
|
|
have a great deal of uses, but if you are trying very hard to learn someone's
|
|
real identity, and you suspect they are signed up to a list, just check for all
|
|
users from that particular host site and see if there are any matches.
|
|
|
|
Finally, there is one last section to e-mail -- the actual message itself.
|
|
In fact, this is the most important area to concentrate on in order to avoid
|
|
the infamous "Apparently-to:" line. Basically, the data consists of a few
|
|
lines of title information and then the actual message follows.
|
|
|
|
There is a set of guidelines you must follow in order for the quotes to
|
|
appear in correct order. You won't want to have a space separate your titles
|
|
from your name, for example. Here is an example of a real e-mail message:
|
|
|
|
> From: rack@lycaeum.hfc.com
|
|
> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92
|
|
> 12:00:00
|
|
> Message-Id: <666.AA10000@dockmaster.ncsc.mil>
|
|
> To: RMorris@dockmaster.ncsc.mil
|
|
> Date: Thu, 06 Feb 92 12:00:00
|
|
> Title: *wave* Hello, No Such Agency dude!
|
|
>
|
|
> NIST sucks. Say "hi" to your kid for me from all of us at Phrack!
|
|
|
|
Likewise, if you try to create a message without an information line, your
|
|
message would look something like this:
|
|
|
|
> From: rack@lycaeum.hfc.com
|
|
> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92
|
|
> 12:00:00 -0500
|
|
> Message-Id: <666.AA10000@dockmaster.ncsc.mil>
|
|
> Date: Thu, 06 Feb 92 12:00:00
|
|
> Apparently-to: RMorris@dockmaster.ncsc.mil
|
|
|
|
> NIST sucks. Say "hi" to your kid for me from all of us at Phrack!
|
|
|
|
Basically, this looks pretty obvious that it's fakemail, not because I
|
|
altered the numbers necessarily, but because it doesn't have a title line, it
|
|
doesn't have the "Date:" in the right place, and because the "Apparently-to:"
|
|
designation was on.
|
|
|
|
To create the "realistic" e-mail, you would enter:
|
|
|
|
> helo lycaeum.hfc.com
|
|
> mail from: <rack@lycaeum.hfc.com>
|
|
> rcpt to: <RMorris@docmaster.ncsc.mil>
|
|
> data
|
|
> To: RMorris@dockmaster.ncsc.mil>
|
|
> Date: Thu, 06 Feb 92 12:00:00
|
|
> Title: *wave* Hello, No Such Agency dude!
|
|
>
|
|
> NIST sucks. Say "hi" to your kid for me from all of us at Phrack!
|
|
> .
|
|
|
|
Notice that, even though you are in "data" mode, you are still giving
|
|
commands to sendmail. All of the lines can (even if only partially) be altered
|
|
through the data command. This is perfect for sending good fakemail. For
|
|
example:
|
|
|
|
> helo lycaeum.hfc.com
|
|
> mail from: <dale@opus.tymnet.com>
|
|
> rcpt to: <listserv@brownvm.brown.edu>
|
|
> data
|
|
> Received: by lycaeum.hfc.com (5.12/3.7) id AA11891; Thu 6 Feb 92 12:00:00
|
|
> Message-Id: <230.AA11891@lycaeum.hfc.com>
|
|
> To: <listserv@brownvm.brown.edu>
|
|
> Date: Thu, 06 Feb 92 12:00:00
|
|
> Title: Ohh, sign me up Puuuleeeze.
|
|
>
|
|
> subscribe BISEXU-L Dale "Fist Me" Drew
|
|
> .
|
|
|
|
Now, according to this e-mail path, you are telling the other computer
|
|
that you received this letter from OPUS.TYMNET.COM, and it is being forwarded
|
|
by your machine to BROWNVM.BROWN.EDU. Basically, you are stepping into the
|
|
middle of the line and claiming you've been waiting there all this time. This
|
|
is a legit method of sending e-mail!
|
|
|
|
Originally, when sendmail was less automated, you had to list every
|
|
computer that your mail had to move between in order for it to arrive. If you
|
|
were computer ALPHA, you'd have to send e-mail to account "joe" on computer
|
|
GAMMA by this address:
|
|
|
|
> mail to: <beta!ceti!delta!epsilon!freddy!gamma!joe>
|
|
|
|
Notice that the account name goes last and the host names "lead" up to
|
|
that account. The e-mail will be routed directly to each machine until it
|
|
finally reaches GAMMA. This is still required today, especially between
|
|
networks like Internet and Bitnet -- where certain hosts are capable of sending
|
|
mail between networks. This particular style of sending e-mail is called "UUCP
|
|
Style" routing.
|
|
|
|
Sometimes, hosts will use the forwarding UUCP style mail addresses in case
|
|
the host has no concept of how to deal with a name address. Your machine
|
|
simply routes the e-mail to a second host which is capable of resolving the
|
|
rest of the name. Although these machines are going out of style, they still
|
|
exist.
|
|
|
|
The third reasonable case of where e-mail will be routed between hosts is
|
|
when, instead of having each computer waste individual time dealing with each
|
|
piece of e-mail that comes about, the computer gives the mail to a dedicated
|
|
mailserver which will then deliver the mail. This is quite common all over the
|
|
network -- especially due to the fact that the Internet is only a few T1 lines
|
|
in comparison to the multitude of 9600 and 14.4K baud modems that everyone is
|
|
so protective of people over-using. Of course, this doesn't cause the address
|
|
to be in UUCP format, but when it reaches the other end of the network, it'll
|
|
be impossible to tell what method the letter used to get sent.
|
|
|
|
Okay, now we can send fairly reasonable electronic fakemail. This stuff
|
|
can't easily be distinguished between regular e-mail unless you either really
|
|
botched it up (say, sending fakemail between two people on the same machine by
|
|
way of 4 national hosts or something) or really had bad timing.
|
|
|
|
Let's now discuss the POWER of fakemail. Fakemail itself is basically a
|
|
great way to fool people into thinking you are someone else. You could try to
|
|
social engineer information out of people on a machine by fakemail, but at the
|
|
same time, why not just hack the root password and use "root" to do it? This
|
|
way you can get the reply to the mail as well. It doesn't seem reasonable to
|
|
social engineer anything while you are root either. Who knows. Maybe a really
|
|
great opportunity will pop up some day -- but until then, let's forget about
|
|
dealing person-to-person with fakemail, and instead deal with
|
|
person-to-machine.
|
|
|
|
There are many places on the Internet that respond to received electronic
|
|
mail automatically. You have all of the Archie sites that will respond, all of
|
|
the Internet/Bitnet LISTSERVs, and Bitmail FTP servers. Actually, there are
|
|
several other servers, too, such as the diplomacy adjudicator. Unfortunately,
|
|
this isn't anywhere nearly as annoying as what you can do with other servers.
|
|
|
|
First, let's cover LISTSERVs. As you saw above, I created a fakemail
|
|
message that would sign up Mr. Dale Drew to the BISEXU-L LISTSERV. This means
|
|
that any of the "netnews" regarding bisexual behavior on the Internet would be
|
|
sent directly to his mailbox. He would be on this list (which is public and
|
|
accessible by anyone) and likewise be assumed to be a member of the network
|
|
bisexual community.
|
|
|
|
This fakemail message would go all the way to the LISTSERV, it would
|
|
register Mr. Dictator for the BISEXU-L list, >DISCARD< my message, and, because
|
|
it thinks that Dale Drew sent the message, it will go ahead and sign him up to
|
|
receive all the bisexual information on the network.
|
|
|
|
And people wonder why I don't even give out my e-mail address.
|
|
|
|
The complete list of all groups on the Internet is available in the file
|
|
"list_of_lists" which is available almost everywhere so poke around
|
|
wuarchive.wustl.edu or ftp.uu.net until you find it. You'll notice that there
|
|
are several groups that are quite fanatic and would freak out nearly anybody
|
|
who was suddenly signed up to one.
|
|
|
|
Ever notice how big mega-companies like IBM squelch little people who try
|
|
to make copies of their ideas? Even though you cannot "patent" an "idea,"
|
|
folks like IBM want you to believe they can. They send their "brute" squad of
|
|
cheap lawyers to "legal-fee-to-death" small firms. If you wanted to
|
|
"nickel-and-dime" someone out of existence, try considering the following:
|
|
|
|
CompuServe is now taking electronic mail from the Internet. This is good.
|
|
CompuServe charges for wasting too much of their drive space with stored
|
|
e-mail. This is bad. You can really freak out someone you don't like on
|
|
CompuServe by signing them up to the Dungeons and Dragons list, complete with
|
|
several megabytes of fluff per day. This is cool. They will then get charged
|
|
hefty fines by CompuServe. That is fucked up. How the hell could they know?
|
|
|
|
CompuServe e-mail addresses are userid@compuserve.com, but as the Internet
|
|
users realize, they can't send commas (",") as e-mail paths. Therefore, use a
|
|
period in place of every comma. If your e-mail address was 767,04821 on
|
|
CompuServe then it would be 767.04821 for the Internet. CompuServe tends to
|
|
"chop" most of the message headers that Internet creates out of the mail before
|
|
it reaches the end user. This makes them particularly vulnerable to fakemail.
|
|
|
|
You'll have to check with your individual pay services, but I believe such
|
|
groups as MCI Mail also have time limitations. Your typical non-Internet-
|
|
knowing schmuck would never figure out how to sign off of some God-awful fluff
|
|
contained LISTSERV such as the Advanced Dungeons & Dragons list. The amount of
|
|
damage you could cause in monetary value alone to an account would be
|
|
horrendous.
|
|
|
|
Some groups charge for connection time to the Internet -- admittedly, the
|
|
fees are reasonable -- I've seen the price at about $2 per hour for
|
|
communications. However, late at night, you could cause massive e-mail traffic
|
|
on some poor sap's line that they might not catch. They don't have a way to
|
|
shut this off, so they are basically screwed. Be WARY, though -- this sabotage
|
|
could land you in deep shit. It isn't actually fraud, but it could be
|
|
considered "unauthorized usage of equipment" and could get you a serious fine.
|
|
However, if you are good enough, you won't get caught and the poor fucks will
|
|
have to pay the fees themselves!
|
|
|
|
Now let's investigate short-term VOLUME damage to an e-mail address.
|
|
There are several anonymous FTP sites that exist out there with a service known
|
|
as BIT FTP. This means that a user from Bitnet, or one who just has e-mail and
|
|
no other network services, can still download files off of an FTP site. The
|
|
"help" file on this is stored in Appendix C, regarding the usage of Digital's
|
|
FTP mail server.
|
|
|
|
Basically, if you wanted to fool the FTP Mail Server into bombarding some
|
|
poor slob with an ungodly huge amount of mail, try doing a regular "fakemail"
|
|
on the guy, with the enclosed message packet:
|
|
|
|
> helo lycaeum.hfc.com
|
|
> mail from: <dale@opus.tymnet.com>
|
|
> rcpt to: <ftpmail@decwrl.dec.com>
|
|
> data
|
|
> Received: by lycaeum.hfc.com (5.12/3.7) id AA10992; Fri 9 Oct 92 12:00:00
|
|
> Message-Id: <230.AA11891@lycaeum.hfc.com>
|
|
> To: <listserv@brownvm.brown.edu>
|
|
> Date: Fri, 09 Oct 92 12:00:00
|
|
> Title: Hey, I don't have THAT nifty program!
|
|
>
|
|
> reply dale@opus.tymnet.com
|
|
> connect wuarchive.wustl.edu anonymous fistme@opus.tymnet.com
|
|
> binary
|
|
> get mirrors/gnu/gcc-2.3.2.tar.Z
|
|
> quit
|
|
> .
|
|
|
|
What is particularly nasty about this is that somewhere between 15 and
|
|
20 megabytes of messages are going to be dumped into this poor guy's account.
|
|
All of the files will be uuencoded and broken down into separate messages!
|
|
Instead of deleting just one file, there will be literally hundreds of messages
|
|
to delete! Obnoxious! Nearly impossible to trace, too!
|
|
|
|
|
|
Part 2: E-MAIL AROUND THE WORLD
|
|
|
|
Captain Crunch happened to make a telephone call around the world, which
|
|
could have ushered in the age of phreak enlightenment -- after all, he proved
|
|
that, through the telephone, you could "touch someone" anywhere you wanted
|
|
around the world! Billions of people could be contacted.
|
|
|
|
I undoubtedly pissed off a great number of people trying to do this e-mail
|
|
trick -- having gotten automated complaints from many hosts. Apparently, every
|
|
country has some form of NSA. This doesn't surprise me at all, I'm just
|
|
somewhat amazed that entire HOSTS were disconnected during the times I used
|
|
them for routers. Fortunately, I was able to switch computers faster than they
|
|
were able to disconnect them.
|
|
|
|
In order to send the e-mail, I couldn't send it through a direct path.
|
|
What I had to do was execute UUCP style routing, meaning I told each host in
|
|
the path to send the e-mail to the next host in the path, etc., until the last
|
|
machine was done. Unfortunately, the first machine I used for sending the
|
|
e-mail had a remarkably efficient router and resolved the fact that the target
|
|
was indeed the destination. Therefore, I re-altered the path to a machine
|
|
sitting about, oh, two feet away from it. Those two feet are meaningless in
|
|
this epic journey.
|
|
|
|
The originating host names have been altered as to conceal my identity.
|
|
However, if we ever meet at a Con, I'll probably have the real print-out of the
|
|
results somewhere and you can verify its authenticity. Regardless, most of
|
|
this same shit will work from just about any typical college campus Internet
|
|
(and even Bitnet) connected machines.
|
|
|
|
In APPENDIX A, I've compiled a list of every foreign country that I could
|
|
locate on the Internet. I figured it was relatively important to keep with the
|
|
global program and pick a series of hosts to route through that would
|
|
presumably require relatively short hops. I did this by using this list and
|
|
trial and error (most of this information was procured from the Network
|
|
Information Center, even though they deliberately went way the hell out of
|
|
their way to make it difficult to get computers associated with foreign
|
|
countries).
|
|
|
|
My ultimate choice of a path was:
|
|
|
|
lycaeum.hfc.com -- Origin, "middle" America.
|
|
albert.gnu.ai.mit.edu -- Massachusetts, USA.
|
|
isgate.is -- Iceland
|
|
chenas.inria.fr -- France
|
|
icnucevx.cnuce.cn.it -- Italy
|
|
sangram.ncst.ernet.in -- India
|
|
waseda-mail.waseda.ac.jp -- Japan
|
|
seattleu.edu -- Seattle
|
|
inferno.hfc.com -- Ultimate Destination
|
|
|
|
The e-mail address came out to be:
|
|
|
|
isgate.is!chenas.inria.fr!icnucevx.cnuce.cn.it!sangram.ncst.ernet.in!
|
|
waseda-mail.waseda.ac.jp!seattleu.edu!inferno.hfc.com!
|
|
rack@albert.gnu.ai.mit.edu
|
|
|
|
...meaning, first e-mail albert.gnu.ai.mit.edu, and let it parse the name
|
|
down a line, going to Iceland, then to France, etc. until it finally reaches
|
|
the last host on the list before the name, which is the Inferno, and deposits
|
|
the e-mail at rack@inferno.hfc.com.
|
|
|
|
This takes a LONG time, folks. Every failure toward the end took on
|
|
average of 8-10 hours before the e-mail was returned to me with the failure
|
|
message. In one case, in fact, the e-mail made it shore to shore and then came
|
|
all the way back because it couldn't resolve the last hostname! That one made
|
|
it (distance-wise) all the way around the world and half again.
|
|
|
|
Here is the final e-mail that I received (with dates, times, and numbers
|
|
altered to squelch any attempt to track me):
|
|
|
|
> Return-Path: <rack@lycaeum.hfc.com>
|
|
> Received: from sumax.seattleu.edu [192.48.211.120] by Lyceaum.HFC.Com ; 19
|
|
Dec 92 16:23:21 MST
|
|
> Received: from waseda-mail.waseda.ac.jp by sumax.seattleu.edu with SMTP id
|
|
> AA28431 (5.65a/IDA-1.4.2 for rack@inferno.hfc.com); Sat, 19 Dec 92
|
|
> 14:26:01 -0800
|
|
> Received: from relay2.UU.NET by waseda-mail.waseda.ac.jp (5.67+1.6W/2.8Wb)
|
|
> id AA28431; Sun, 20 Dec 92 07:24:04 JST
|
|
> Return-Path: <rack@lycaeum.hfc.com>
|
|
> Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
|
|
> (5.61/UUNET-internet-primary) id AA28431; Sat, 19 Dec 92 17:24:08 -
|
|
> 0500
|
|
> Received: from sangam.UUCP by uunet.uu.net with UUCP/RMAIL
|
|
> (queueing-rmail) id 182330.3000; Sat, 19 Dec 1992 17:23:30 EST
|
|
> Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0)
|
|
> id AA28431; Sun, 20 Dec 92 03:50:19 IST
|
|
> From: rack@lycaeum.hfc.com
|
|
> Received: from shakti.ncst.ernet.in by saathi.ncst.ernet.in
|
|
> (5.61/Ultrix3.0-C)
|
|
> id AA28431; Sun, 20 Dec 92 03:52:12 +0530
|
|
> Received: from saathi.ncst.ernet.in by shakti.ncst.ernet.in with SMTP
|
|
> (16.6/16.2) id AA09700; Sun, 20 Dec 92 03:51:37 +0530
|
|
> Received: by saathi.ncst.ernet.in (5.61/Ultrix3.0-C)
|
|
> id AA28431; Sun, 20 Dec 92 03:52:09 +0530
|
|
> Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0)
|
|
> id AA28431; Sun, 20 Dec 92 03:48:24 IST
|
|
> Received: from ICNUCEVX.CNUCE.CNR.IT by relay1.UU.NET with SMTP
|
|
> (5.61/UUNET-internet-primary) id AA28431; Sat, 19 Dec 92 17:20:23
|
|
> -0500
|
|
> Received: from chenas.inria.fr by ICNUCEVX.CNUCE.CNR.IT (PMDF #2961 ) id
|
|
> <01GSIP122UOW000FBT@ICNUCEVX.CNUCE.CNR.IT>; Sun, 19 Dec 1992 23:14:29 MET
|
|
> Received: from isgate.is by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet
|
|
> id AA28431; Sun, 19 Dec 1992 23:19:58 +0100 (MET)
|
|
> Received: from albert.gnu.ai.mit.edu by isgate.is (5.65c8/ISnet/14-10-91);
|
|
> Sat, 19 Dec 1992 22:19:50 GMT
|
|
> Received: from lycaeum.hfc.com by albert.gnu.ai.mit.edu (5.65/4.0) with
|
|
> SMTP id <AA28431@albert.gnu.ai.mit.edu>; Sat, 19 Dec 92 17:19:36 -0500
|
|
> Received: by lycaeum.hfc.com (5.65/4.0) id <AA11368@lycaeum.hfc.com>;
|
|
> Sat, 19 Dec 92 17:19:51 -0501
|
|
> Date: 19 Dec 1992 17:19:50 -0500 (EST)
|
|
> Subject: Global E-Mail
|
|
> To: rack@inferno.hfc.com
|
|
> Message-id: <9212192666.AA11368@lycaeum.hfc.com>
|
|
> Mime-Version: 1.0
|
|
> Content-Type: text/plain; charset=US-ASCII
|
|
> Content-Transfer-Encoding: 7bit
|
|
> X-Mailer: ELM [version 2.4 PL5]
|
|
> Content-Length: 94
|
|
> X-Charset: ASCII
|
|
> X-Char-Esc: 29
|
|
>
|
|
> This Electronic Mail has been completely around the world!
|
|
>
|
|
> (and isn't even a chain letter.)
|
|
|
|
===============================================================================
|
|
|
|
APPENDIX A:
|
|
|
|
List of Countries on the Internet by Root Domain
|
|
|
|
(I tried to get a single mail router in each domain. The domains that don't
|
|
have them are unavailable at my security clearance. The computer is your
|
|
friend.)
|
|
|
|
.AQ New Zealand
|
|
.AR Argentina atina.ar
|
|
.AT Austria pythia.eduz.univie.ac.at
|
|
.BB Barbados
|
|
.BE Belgium ub4b.buug.be
|
|
.BG Bulgaria
|
|
.BO Bolivia unbol.bo
|
|
.BR Brazil fpsp.fapesp.br
|
|
.BS Bahamas
|
|
.BZ Belize
|
|
.CA Canada cs.ucb.ca
|
|
.CH Switzerland switch.ch
|
|
.CL Chile uchdcc.uchile.cl
|
|
.CN China ica.beijing.canet.cn
|
|
.CR Costa Rica huracan.cr
|
|
.CU Cuba
|
|
.DE Germany deins.informatik.uni-dortmund.de
|
|
.DK Denmark dkuug.dk
|
|
.EC Ecuador ecuanex.ec
|
|
.EE Estonia kbfi.ee
|
|
.EG Egypt
|
|
.FI Finland funet.fi
|
|
.FJ Fiji
|
|
.FR France inria.inria.fr
|
|
.GB England
|
|
.GR Greece csi.forth.gr
|
|
.HK Hong Kong hp9000.csc.cuhk.hk
|
|
.HU Hungary sztaki.hu
|
|
.IE Ireland nova.ucd.ie
|
|
.IL Israel relay.huji.ac.il
|
|
.IN India shakti.ernet.in
|
|
.IS Iceland isgate.is
|
|
.IT Italy deccnaf.infn.it
|
|
.JM Jamaica
|
|
.JP Japan jp-gate.wide.ad.jp
|
|
.KR South Korea kum.kaist.ac.kr
|
|
.LK Sri Lanka cse.mrt.ac.lk
|
|
.LT Lithuania ma-mii.lt.su
|
|
.LV Latvia
|
|
.MX Mexico mtec1.mty.itesm.mx
|
|
.MY Malaysia rangkom.my
|
|
.NA Namibia
|
|
.NI Nicaragua uni.ni
|
|
.NL Netherlands sering.cwi.nl
|
|
.NO Norway ifi.uio.no
|
|
.NZ New Zealand waikato.ac.nz
|
|
.PE Peru desco.pe
|
|
.PG New Guinea ee.unitech.ac.pg
|
|
.PH Philippines
|
|
.PK Pakistan
|
|
.PL Poland
|
|
.PR Puerto Rico sun386-gauss.pr
|
|
.PT Portugal ptifm2.ifm.rccn.pt
|
|
.PY Paraguay ledip.py
|
|
.SE Sweden sunic.sunet.se
|
|
.SG Singapore nuscc.nus.sg
|
|
.TH Thailand
|
|
.TN Tunisia spiky.rsinet.tn
|
|
.TR Turkey
|
|
.TT Trinidad & Tobago
|
|
.TW Taiwan twnmoe10.edu.tw
|
|
.UK United Kingdom ess.cs.ucl.ac.uk
|
|
.US United States isi.edu
|
|
.UY Uruguay seciu.uy
|
|
.VE Venezuela
|
|
.ZA South Africa hippo.ru.ac.za
|
|
.ZW Zimbabwe zimbix.uz.zw
|
|
|
|
===============================================================================
|
|
|
|
APPENDIX B:
|
|
|
|
Basic SMTP Commands
|
|
|
|
> HELO <hostname> Tells mail daemon what machine is calling. This
|
|
will be determined anyway, so omission doesn't mean
|
|
anonymity.
|
|
|
|
> MAIL FROM: <path> Tells where the mail came from.
|
|
|
|
> RCPT TO: <path> Tells where the mail is going.
|
|
|
|
> DATA Command to start transmitting message.
|
|
|
|
> QUIT Quit mail daemon, disconnects socket.
|
|
|
|
> NOOP No Operation -- used for delays.
|
|
|
|
> HELP Gives list of commands -- sometimes disabled.
|
|
|
|
> VRFY Verifies if a path is valid on that machine.
|
|
|
|
> TICK Number of "ticks" from connection to present
|
|
("0001" is a typical straight connection).
|
|
|
|
===============================================================================
|
|
|
|
APPENDIX C:
|
|
|
|
BIT-FTP Help File
|
|
|
|
ftpmail@decwrl.dec.com (Digital FTP mail server)
|
|
|
|
Commands are:
|
|
reply <MAILADDR> Set reply address since headers are usually
|
|
wrong.
|
|
connect [HOST [USER [PASS]]] Defaults to gatekeeper.dec.com, anonymous.
|
|
ascii Files grabbed are printable ASCII.
|
|
binary Files grabbed are compressed or tar or both.
|
|
compress Compress binaries using Lempel-Ziv encoding.
|
|
compact Compress binaries using Huffman encoding.
|
|
uuencode Binary files will be mailed in uuencoded
|
|
format.
|
|
btoa Binary files will be mailed in btoa format.
|
|
ls (or dir) PLACE Short (long) directory listing.
|
|
get FILE Get a file and have it mailed to you.
|
|
quit Terminate script, ignore rest of mail message
|
|
(use if you have a .signature or are a
|
|
VMSMAIL user).
|
|
|
|
Notes:
|
|
-> You must give a "connect" command (default host is gatekeeper.dec.com,
|
|
default user is anonymous, default password is your mail address).
|
|
-> Binary files will not be compressed unless "compress" or "compact"
|
|
command is given; use this if at all possible, it helps a lot.
|
|
-> Binary files will always be formatted into printable ASCII with "btoa" or
|
|
"uuencode" (default is "btoa").
|
|
-> All retrieved files will be split into 60KB chunks and mailed.
|
|
-> VMS/DOS/Mac versions of uudecode, atob, compress and compact are
|
|
available, ask your LOCAL wizard about them.
|
|
-> It will take ~1-1/2 day for a request to be processed. Once the jobs has
|
|
been accepted by the FTP daemon, you'll get a mail stating the fact that
|
|
your job has been accepted and that the result will be mailed to you.
|